In #36 I explained why using long-term key with short random nonce is a bad idea. Later in that discussion @wongsryone raised the issue that higher entropy consumption of SIP004 might be problematic on some VM and embedded devices.
Well, technically we are not consuming entropy faster in SIP004 as we are still generating one random number per TCP connection. However we are consuming available nonce space at a much faster pace because we're incrementing it as a counter twice per chunk, effectively increasing the probability of (key, nonce) pair reuse by a few orders of magnitude.
Now I think this is a design flaw which could be avoided by a minor change.
In #36 I proposed to deprecate ciphers with short nonce/IV to increase available nonce space. Unfortunately it eliminated some nice ciphers like chacha20 and chacha20-poly1305 (8-byte nonce/IV).
Actually there's a better way.
Instead, we could generate a random session key and encrypt it using the pre-shared key (with random nonce/IV if AEAD/stream cipher) and send it at the beginning of a connection. We then use the session key to encrypt the rest of the connection. As a result:
- For stream ciphers, random IV is no longer necessary (but we could still use one) because the key is random.
- For AEAD ciphers, random nonce is also no longer necessary, and we can use a simple counter from zero as nonce.
Since key size is usually longer than nonce/IV, we are free to use ciphers with short nonce/IV. We're looking at 128-bit randomness at least and 256-bit for chacha20, instead of 64-bit or 96-bit nonce/IV. Much, much larger space.
To summarize, here is a structure of a connection encrypted by a stream cipher
[fixed-length random IV to encrypt session key]
[fixed-length encrypted session key using pre-shared key and the random IV above]
[variable-length encrypted content using the session key above with optional IV]
And the structure of a connection encrypted by an AEAD cipher
[fixed-length random nonce]
[fixed-length encrypted session key using pre-shared key and the random nonce above]
[fixed-length tag]
[fixed-length encrypted payload length using session key and nonce 0]
[fixed-length encrypted payload length tag]
[variable-length encrypted payload using session key and nonce 1]
[fixed-length encrypted payload tag]
[fixed-length encrypted payload length using session key and nonce 2]
[fixed-length encrypted payload length tag]
[variable-length encrypted payload using session key and nonce 3]
[fixed-length encrypted payload tag]
...
In #36 I explained why using long-term key with short random nonce is a bad idea. Later in that discussion @wongsryone raised the issue that higher entropy consumption of SIP004 might be problematic on some VM and embedded devices.
Well, technically we are not consuming entropy faster in SIP004 as we are still generating one random number per TCP connection. However we are consuming available nonce space at a much faster pace because we're incrementing it as a counter twice per chunk, effectively increasing the probability of (key, nonce) pair reuse by a few orders of magnitude.
Now I think this is a design flaw which could be avoided by a minor change.
In #36 I proposed to deprecate ciphers with short nonce/IV to increase available nonce space. Unfortunately it eliminated some nice ciphers like chacha20 and chacha20-poly1305 (8-byte nonce/IV).
Actually there's a better way.
Instead, we could generate a random session key and encrypt it using the pre-shared key (with random nonce/IV if AEAD/stream cipher) and send it at the beginning of a connection. We then use the session key to encrypt the rest of the connection. As a result:
Since key size is usually longer than nonce/IV, we are free to use ciphers with short nonce/IV. We're looking at 128-bit randomness at least and 256-bit for chacha20, instead of 64-bit or 96-bit nonce/IV. Much, much larger space.
To summarize, here is a structure of a connection encrypted by a stream cipher
And the structure of a connection encrypted by an AEAD cipher