Open AljoschaMeyer opened 7 years ago
This makes very little difference to either security or performance. I think you'd have a hard time actually detecting the performance difference in practice, apart from in a carefully contrived setting. (timing attacks are relatively academic) and in the context of pull-box-stream, the security comes from the key. If we had a public nonces attached to each packet, we wouldn't loose any security.
The reason for using an incrementing nonce is just to save those 24 bytes. It doesn't matter if they are secret or not... generally, the key should be secret but it doesn't matter if the nonce is or not. to be honest, I'm having a hard time imagining an app where the timing of the nonce increment is a security hole.
It doesn't make a difference on non-optimized implementations, but sodium assumes little-endian encoding.
Also, a constant-time implementation is even simpler that the current one:
for (var i = 0, len = buf.length, c = 1; i < len; i++) {
buf[i] = c += buf[i];
c >>= 8;
}
@jedisct1 great point! "simpler" persuades me.
unfortunately the increment on pull-box-stream is big endian, so I guess that rules out using the sodium one. I'll make sure if we change the protocol that we change to little endian.
Libsodium recommends sodium_increment to increment nonces, which works in constant time. The increment function in the reference implementation optimizes by stopping when there's no more carry.
What should a fresh implementation of box-stream do? Optimize for efficiency or choose the more secure constant-time increment?