Time Nick Message 00:26 [MatrxMT] MisterE: yes, just modified ronoaldo's scripts to suit my needs 07:10 mtvisitor AncientMariner: hi, nice to meet you in this channel. 🤝 07:11 mtvisitor how long have you been playing for minetest game ? are you also engineer background ? 🤝☕ 07:12 mtvisitor MTG: minetest_game. 08:41 TenPlus1 Hi folks 11:20 pgimeno " I can't help but suspect mini-gmp was probably not written to be cryptographically sound when it comes to timing" - Indeed it wasn't. GMP (the full one, not the mini one) has _sec functions specifically for this purpose. 12:25 grorp planning to merge #15017, #15100, #15111, #15114 in 30 min 12:25 ShadowBot https://github.com/minetest/minetest/issues/15017 -- [no sq] TouchScreenGUI: Grid menu improvement + fix by grorp 12:25 ShadowBot https://github.com/minetest/minetest/issues/15100 -- TouchControls: Fix setUseCrosshair not being called by grorp 12:25 ShadowBot https://github.com/minetest/minetest/issues/15111 -- Remove no* prefixes from settingtypes possible flags by appgurueu 12:25 ShadowBot https://github.com/minetest/minetest/issues/15114 -- VoxelManipulator code cleanup by red-001 12:44 red-001 pgimeno: maybe full GMP should be a requirement then? 12:45 pgimeno in that case, these _sec functions (which tend to be much slower than their non-_sec variants) should be used 12:46 red-001 what a mess, I mean I suspect the issue as it stands is not exploitable in any meaningful way 12:47 red-001 but it's still not ideal 12:48 red-001 is there a aPAKE (or really just the zero knowledge password proof part, don't really need a key exchange) that uses primitives that are easier to get right? 12:50 red-001 OPAQUE seems popular but I don't know if it comes with the same implementation issues 12:51 red-001 and at a glace seems a lot more involved in general 12:55 pgimeno I'm looking, I can't find any mpz function ending with _sec other than mpz_powm_sec https://gmplib.org/manual/Integer-Exponentiation 12:56 pgimeno it seems that most side-channel resilient functions are implemented at the mpn level: https://gmplib.org/manual/Low_002dlevel-Functions 12:56 red-001 do you know what the implication are there? I don't know what the difference between mpz or mpn is 12:56 red-001 implications* 12:57 pgimeno mpn requires handling of pointers to raw limbs, mpz requires the mpz_t type 12:57 red-001 maybe the MPZ functions are already safe? or am I too optimistic here 12:57 pgimeno mpn is the low-level interface that GMP uses under the hood 12:57 pgimeno yeah I think you're too optimistic :) 12:58 red-001 someone needs to be! 12:58 red-001 that seems like a rewrite of the whole implementation would be required 12:58 pgimeno it's not that hard to deal with mpn functions, you just need to be careful because there's no buffer overflow checking or similar 12:59 pgimeno yes, that's likely 12:59 pgimeno on the other hand, how exploitable is a side-channel kind of attack? 12:59 red-001 over network? 13:00 red-001 probably not exploitable but I'm not sure, PARASITE is a local attack 13:00 pgimeno that's the big question; side-channel attacks are typically performed in the CPU under attack 13:00 pgimeno is there a way to exploit it locally? 13:01 red-001 not currently, well not in any sane way 13:01 red-001 I think there's a risk if and when SSCSM is added 13:04 pgimeno I haven't thought about it and right now I have other priorities, sorry, so I'll pass on that question. I'm not sure if SSCSMs can actually exploit that, given the time at which they are executed. 13:04 red-001 I think they would need to be paused during password change operations and that might be enough? 13:05 red-001 it's not a major issue in any case 13:05 red-001 on a side note there's a rust crate for SRP. I find the warning that the implementation has never passed a security audit reassuring. Neither has the Minetest one but it doesn't have a warning label on it 13:06 red-001 "This crate has never received an independent third party audit for security and correctness." - https://docs.rs/srp/latest/srp/ 13:06 MTDiscord surely there are some libraries that have passed security audits though 13:07 red-001 openssl I presume has passed many 13:08 red-001 I don't know if any of those would have checked the SRP implementation 13:12 red-001 Wikipedia has a helpful list of SRP implementations that the deletionists will probably delete one day: https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol#Implementations 13:13 red-001 it's not very promising 18:23 MTDiscord oof the memsets in srp.cpp might very well be optimized out, i think we need the same forced memset there as in the "don't store passwords in memory" PR 18:24 sfan5 memset_s 18:24 SFENCE memset_s is not avaliable everywhere. 18:26 SFENCE If #14196 will be reactivated as wanted, I can change memset in srp.c that PR. 18:26 ShadowBot https://github.com/minetest/minetest/issues/14196 -- Change the way how password is stored in C++ engine. by sfence 18:28 sfan5 are you sure that's true? json.h contains a reference to memset_s 18:28 SFENCE I was fighting with it when I was working on 14196. 18:30 MTDiscord See https://github.com/minetest/minetest/blob/74520fb49661005ef1891ff76161332d54e62fdc/src/porting.cpp#L895-L908 18:30 SFENCE I have to do this like this, to make in compilable on all systems supported by Minetest. 18:37 Krock or implement the loop in assembly for x86, x86_64, armv7, armv7 and whatever else we support 18:40 SFENCE Btw it looks like json uses memset_s only if is configured to use secure memory. 18:43 SFENCE And I don't found that symbol in Minetest.app. 18:48 SFENCE Krock: using assembler is really crazy think. Different compilers, platforms.... there is no standart for it. 18:51 Desour cppreference also says one should use std::fill with volatile, or the other things SFENCE used, if memset_s in not available, btw. 18:52 Desour you could consider copying more at once with the volatile loop, i.e. use `volatile u64 *` as long as the size is >=8 18:53 Krock * as long size % 8 == 0 18:53 Krock unless you can be certain that there's unused padding bytes 18:57 Desour Krock: for data alignment, you'd need `(size_t)ptr & 7 == 0`. otherwise you could for example have an aligned array of size 8*n+1 for example, and you'd make it unaligned 18:58 Krock Desour: does that also hold true on 32-bit systems? 19:00 Desour idk, I think I misunderstood you. why would 32 bit systems make a difference? 19:00 Krock I'm not talking about the pointer alignment but the data length that you'd like to zero out 19:02 MTDiscord no need to reinvent duff's device 19:03 Desour I said >=8 earlier, because I meant that you zero out a `volatile u64 *` until 8 bytes would be too big, then switch to `volatile u8 *` 19:05 sfan5 something something premature-optimization 19:05 Desour yes, that's what C++ is all about after all :D 19:09 SFENCE Yes, it can be optimized. But if we used it only for one times erase password, and maybe some srp data after connection to server is done, it should not bring any interesting performance change. 19:11 MTDiscord btw SFENCE i'd just do the porting::memset_s + converting memsets e.g. in srp.cpp to it in a separate commit if not PR, this is a much more manageable change and, if merged first, would also slightly simplify the password PR 19:14 SFENCE Ok, in case PR will be closed as unwanted, lets do it. 19:24 SFENCE Lars: Maybe, it don't take much sense to do it in separate PR. In actuall implelemtation, SRP object is holded in memory until player disconnect from server. So it will be no big difference if you only add memset_s implementation. 19:25 SFENCE To make it effective, you will have to implement also part of my PR, where I keep only needed part of SRP object in memory. 20:38 red-001 HACL* has a few more memset_s like functions it supports, libsodium supports like half a dozen 20:38 red-001 no real standard for it cause it's outside the C/C++ standard tbh 20:38 red-001 even if there is now a standard function 20:39 celeron55 the name of the game is, just write a wrapper which does its best on each platform 20:44 red-001 if only we lived in a perfect world were optimizing compilers were never taken further than wherever GCC was at in 2005