If you're worried about nonce reuse on embedded systems, feed H(m) to the kernel's entropy pool before requesting random bytes.
-
-
Replying to @CiPHPerCoder
Sure, why NOT just design a crappy version of SIV instead of using SIV?
1 reply 0 retweets 2 likes -
Replying to @tqbf
I'm not convinced that SIV is a meaningful win over large random nonces and a CSPRNG.
2 replies 0 retweets 0 likes -
Replying to @CiPHPerCoder @tqbf
The only places it seems somewhat useful is the same corner cases where "just use /dev/urandom" isn't good advice.
1 reply 0 retweets 0 likes -
Replying to @CiPHPerCoder @tqbf
My suggestion here is a much simpler side-step for those corner cases (doesn't change the protocol being used by the other party).
1 reply 0 retweets 0 likes -
Replying to @CiPHPerCoder
This is like saying “why bother with Rust when we have strncpy”.
1 reply 0 retweets 1 like -
Replying to @tqbf
It's more like saying "everyone's communicating with Xsalpoly, our devices are corner cases, let's solve the problem while being compatible"
1 reply 0 retweets 0 likes -
Replying to @CiPHPerCoder @tqbf
If you think instead, we should upgrade everyone to using AES-SIV-GCM and AEZ, well, that'd certainly nullify my question.
1 reply 0 retweets 0 likes -
Replying to @CiPHPerCoder
I still don’t understand the argument. Fewer bug classes = better.
1 reply 0 retweets 0 likes -
Replying to @tqbf
The argument is "Instead of forcing AES-SIV-GCM, can't we solve this problem without more algorithm choices"
3 replies 0 retweets 0 likes
If you're using xsalsa you may just consider something likehttps://github.com/codahale/xsalsa20poly1305 …
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.