github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
samcv so i did some work over a few days. and i wasn't able to do a meet in the middle attack on our current hash implementation. due to how it has three state variables rather than just 1 in most hashing systems 04:06
the space of three uint32's is too great to be able to attack it easily this way it appears to me 04:08
i may still switch to siphash since it's been studied more though, but the need isn't very pressing
and i think they're about the same speed as each other in the testing i had previously done 04:10
though i may be able to speed up what we're doing now a bit 04:11
and i would like a 64 bit hash value 04:17
samcv I got this with asan gist.github.com/samcv/4d12bb5e80a6...4dd6efb541 05:55
in t/concurrency/01-thread.t. it's a flapper 05:56
actually it only happened once :\ 06:03
even though i tried runnig it in a loop
lizmat do we have a writeup on MoarVM's garbage collection somewhere I can refer to in an article? 10:05
japhb samcv: www.schneier.com/blog/archives/201...s_law.html seems relevant. :-) 15:10
samcv japhb: yep very true. switching seems good just because i haven't found any security research on it. though it doesn't appear Meet in the middle vulnerable. there may be other ways to exploit it :P 17:47
or it is, though i fairly suspect it's not given it has three but not two state variables 17:48
since you need all three 32 bit uints to match up to do it properly. just not likely enough to make it feasible and i think slower than a brute force attack 17:49
samcv siphash is slower though 19:28

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!