Proposal: simplify / improve secretbox construction about libhydrogen HOT 3 CLOSED

There is also a slightly simpler version of my proposal:

kmac || pnonce = HChaCha12(n=({0}||id), k=key)
nonce          = pnonce || random_data
e              = XChaCha12(m=msg, n=nonce, k=key)
mac            = Siphash(m= (random_data || e), ctx, kmac)
c              = mac || random_data || e 

If a random value is used anyway, there's no need to use kn and because of XChaCha generates a subkey, we can use the "root" key here (it's never used directly for encryption)
This also reduce the overhead to |mac| + |random_data| = 16 + 8 = 24.The random_data would be 8 bytes long - so it's still secure to encrypt the same message with the same key and the same msg_id 2^32 times.

from libhydrogen.

Hi,

And congrats for your implementation!

One of the things hydrogen tries to mitigate is the implication of a completely broken PRNG, which is a common cause of security disasters on embedded systems.

If we have a PRNG, great. We can use it to generate unique nonces. If we don't, we have to work around it, i.e. compute deterministic nonces from the message. Both proposals would fail if the PRNG produced the same output twice.

Even if the PRNG is not that broken, but produces data that can be distinguished from random data, the second construction will clearly expose any bias of the PRNG in the ciphertext.

The first version will also expose all weaknesses of the PRNG if a (message, id, key) is reused. Not so much after the diffusion provided by the extra call to the hash function. That extra call also provide better domain separation, doesn't do unusual things with the nonce, but more importantly, it incorporates the context in the computation of the ciphertext.

With your proposal, the same message encrypted with the same key and different context will produce different MACs, but the same ciphertext.

We're trying to mitigate the implications of a broken PRNG, repeated message ids (after all, this is optional, and if multiple devices are using the same key simultaneously, keeping counters is hard), and key reuse across multiple messages. All of these happening simultaneously is a realistic scenario.

The flipside is that it requires two passes over the message (if you consider the encryption+MAC computation as a single pass, which could be), and all the discussions about misuse-resistance never lead to a magical alternative to this.

A universal hash function could be used instead of a generic hash function in order to compute the nonce key and the MAC. That would be faster on some platforms, not so much on microcontrollers.

from libhydrogen.

Your right, a (completely) broken PRNG is something between bad and catastrophic. I didn't consider the implications of a broken PRNG in my proposals.

A bias of the PRNG could probably be fixed (e.g. use the output of HChaCha12(nonce) instead of the nonce itself), but I can't see how to defend against a PRNG, which produces the same output twice, in the "worst case" (key, msg_id, context are the same).

Furthermore my proposals have some strange properties like:

With your proposal, the same message encrypted with the same key and different context will
produce different MACs, but the same ciphertext.

The solution I can image is exactly your approach.

from libhydrogen.