| Time |
Nick |
Message |
| 00:09 |
|
v-rob joined #minetest-dev |
| 00:26 |
[MatrxMT] |
<Zughy> MisterE: yes, just modified ronoaldo's scripts to suit my needs |
| 00:33 |
|
v-rob joined #minetest-dev |
| 00:36 |
|
v-rob joined #minetest-dev |
| 01:17 |
|
v-rob joined #minetest-dev |
| 01:29 |
|
v-rob joined #minetest-dev |
| 01:38 |
|
v-rob joined #minetest-dev |
| 02:51 |
|
Lupercus joined #minetest-dev |
| 03:24 |
|
v-rob joined #minetest-dev |
| 03:33 |
|
hwpplayer1 joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:12 |
|
v-rob joined #minetest-dev |
| 04:28 |
|
hwpplayer1 joined #minetest-dev |
| 07:09 |
|
mtvisitor joined #minetest-dev |
| 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. |
| 07:19 |
|
hlqkj_ joined #minetest-dev |
| 07:20 |
|
panwolfram_ joined #minetest-dev |
| 07:22 |
|
fluxionary joined #minetest-dev |
| 07:22 |
|
pmp-p joined #minetest-dev |
| 07:30 |
|
cranez joined #minetest-dev |
| 08:40 |
|
TenPlus1 joined #minetest-dev |
| 08:41 |
TenPlus1 |
Hi folks |
| 09:28 |
|
cranez joined #minetest-dev |
| 09:29 |
|
cranez left #minetest-dev |
| 09:41 |
|
mtvisitor joined #minetest-dev |
| 09:45 |
|
mtvisitor left #minetest-dev |
| 09:46 |
|
cranez joined #minetest-dev |
| 10:45 |
|
Lupercus joined #minetest-dev |
| 11:08 |
|
hwpplayer1 joined #minetest-dev |
| 11:20 |
pgimeno |
"<red-001> 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:11 |
|
SpaceManiac joined #minetest-dev |
| 12:20 |
|
grorp joined #minetest-dev |
| 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:43 |
|
red-001 joined #minetest-dev |
| 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 |
<luatic> 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 |
| 13:51 |
|
SFENCE joined #minetest-dev |
| 13:56 |
|
SFENCE joined #minetest-dev |
| 13:59 |
|
SFENCE joined #minetest-dev |
| 14:17 |
|
SFENCE joined #minetest-dev |
| 14:22 |
|
SFENCE joined #minetest-dev |
| 14:25 |
|
SFENCE joined #minetest-dev |
| 14:39 |
|
SpaceMan1ac joined #minetest-dev |
| 14:43 |
|
SpaceMan1ac joined #minetest-dev |
| 14:49 |
|
SFENCE joined #minetest-dev |
| 14:54 |
|
SpaceManiac joined #minetest-dev |
| 14:57 |
|
Desour joined #minetest-dev |
| 15:08 |
|
SFENCE joined #minetest-dev |
| 15:19 |
|
SFENCE joined #minetest-dev |
| 15:23 |
|
SFENCE joined #minetest-dev |
| 15:38 |
|
SFENCE joined #minetest-dev |
| 15:48 |
|
v-rob joined #minetest-dev |
| 15:53 |
|
SFENCE joined #minetest-dev |
| 16:21 |
|
SFENCE joined #minetest-dev |
| 16:26 |
|
SFENCE joined #minetest-dev |
| 16:28 |
|
SFENCE joined #minetest-dev |
| 16:44 |
|
SFENCE joined #minetest-dev |
| 16:47 |
|
SFENCE joined #minetest-dev |
| 16:49 |
|
SFENCE joined #minetest-dev |
| 16:57 |
|
SFENCE joined #minetest-dev |
| 17:21 |
|
SFENCE joined #minetest-dev |
| 17:26 |
|
SFENCE joined #minetest-dev |
| 17:31 |
|
SFENCE joined #minetest-dev |
| 17:56 |
|
SFENCE joined #minetest-dev |
| 18:05 |
|
SFENCE joined #minetest-dev |
| 18:07 |
|
SFENCE joined #minetest-dev |
| 18:12 |
|
SFENCE joined #minetest-dev |
| 18:19 |
|
v-rob joined #minetest-dev |
| 18:23 |
MTDiscord |
<luatic> 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 |
<sfence> 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 |
<luatic> 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:06 |
|
SFENCE joined #minetest-dev |
| 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 |
<luatic> 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:22 |
|
SFENCE joined #minetest-dev |
| 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. |
| 19:28 |
|
SFENCE joined #minetest-dev |
| 19:29 |
|
Sokomine joined #minetest-dev |
| 19:32 |
|
v-rob joined #minetest-dev |
| 20:31 |
|
Lupercus joined #minetest-dev |
| 20:36 |
|
red-001 joined #minetest-dev |
| 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 |
| 22:32 |
|
panwolfram joined #minetest-dev |
| 23:05 |
|
Eragon joined #minetest-dev |
| 23:10 |
|
Eragon joined #minetest-dev |
