4 ms·
It's not voiding the cryptographic doom principle, that's one thing. The HMAC is dealt by OpenSSL it seems and is the hash of the timestamp, destination and enc
by kewde 10y ago
It's not voiding the cryptographic doom principle, that's one thing. The HMAC is dealt by OpenSSL it seems and is the hash of the timestamp, destination and encrypted payload. It's appended outside of the encrypted payload.
https://moxie.org/blog/the-cryptographic-doom-principle/ https://moxie.org/blog/the-cryptographic-doom-principle/
https://github.com/shadowproject/shadow/blob/master/src/smessage.cpp#L3510 https://github.com/shadowproject/shadow/blob/master/src/smes...
On the other hand I agree to switching over to a different mode to eliminate padding oracle attacks.
The IV are 16 random bytes generated by OpenSSL's RAND_bytes.
https://github.com/shadowproject/shadow/blob/master/src/smessage.cpp#L3364 https://github.com/shadowproject/shadow/blob/master/src/smes...
- CiPHPerCoder 10y agoIf one of the project devs is reading this thread: https://github.com/shadowproject/shadow/blob/f3fa333f837768823afe16c0347272b5cb8d6c2a/src/util.cpp#L579-L592 https://github.com/shadowproject/shadow/blob/f3fa333f8377688... That's really hard to read. Also, don't use OpenSSL: https://paragonie.com/blog/2016/05/how-generate-secure-random-numbers-in-various-programming-languages#c-csprng https://paragonie.com/blog/2016/05/how-generate-secure-rando...
- kewde 10y agoHi, Yes we're always where the critics are, they are or best source of information. I'm very happy to see our work being reviewed. I'm not an expert cryptographer but I am capable of understanding it. (fyi I didn't code it). Our memcmp in constant time is not the prettiest, but it's short so we roll with it :P This project started around 2014, LibSodium was still very small back then and OpenSSL, in ours view, remains the defacto standard. Is there any particular reason on why we should move away from RAND_bytes() ?
- CiPHPerCoder 10y agoYes: Aside from being a userspace CSPRNG (which is an additional risk of failure over the kernel's CSPRNG and doesn't provide defense-in-depth), it isn't thread-safe. https://github.com/ramsey/uuid/issues/80 https://github.com/ramsey/uuid/issues/80 https://github.com/nodejs/node/issues/5798 https://github.com/nodejs/node/issues/5798 There are also some recent IACR papers (linked in the Node thread), but those are the two biggest concerns.
- kewde 10y agoThank you CiPHPerCoder! That link to NodeJS was a good read, I'm fairly convinced that we should ditch RAND_bytes from OpenSSL for something more secure, we'll look into LibSodium. I've caught rumours of a possible RAND_sys_bytes which operates over the systems CSPRNG? We like to be conservative on the libs. We'd like to tip you for your efforts, do you have a Bitcoin (or ShadowCash) address?
- CiPHPerCoder 10y agoI do, actually, but I haven't accessed it in almost two years. EDIT: And I forgot my password. Here's a new one: 1D6RMsgnTAf2GLWpD91EaQvQ5ppuaZKkGT