search

paragonie / paseto

Platform-Agnostic Security Tokens
https://paseto.io
Other
3.24k stars 108 forks source link

Reconsider RNG Failure Mitigation Strategy #103

Closed paragonie-scott closed 3 years ago

paragonie-scott commented 5 years ago

From Thai Duong:

In the case of an RNG failure (i.e. all zero bytes), the BLAKE2b of the nonce and message leaks the BLAKE2b hash of the message, which might be enough information (along with the plaintext length) to allow an attacker to recover a plaintext without knowing the key.

The story is similar for v1 with HMAC-SHA384.

Proposed solution: Instead of hashing the message and random nonce together, also include the secret key in the calculation. This changes the attack calculus from "find the input to a hash function with a known output" to "break a keyed PRF without knowing the key".

This solution is backwards compatible with what v1 and v2 are already doing (since the output is just a plaintext nonce that gets stored in the token). However, to make this behavior change explicit and easy to reason about, I'm thinking about incorporating these changes into a v3 and v4.

bdemers commented 4 years ago

@paragonie-scott if these changes are backward compatible, can the v1/v2 specs just be updated? Existing tokens would still be valid, this only refines the nonce calculation?

thaidn commented 4 years ago

Proposed solution: Instead of hashing the message and random nonce together, also include the secret key in the calculation. This changes the attack calculus from "find the input to a hash function with a known output" to "break a keyed PRF without knowing the key".

This would violate the principle of not using a single key for multiple purposes. This (and the current) construction is also somewhat ad hoc, doesn't follow the blueprint of well known constructions such as AEAD or deterministic AEAD.

I don't have any good solutions (but see below), but I want to note that if RNG failure is a concern, one should consider SIV modes such as AES-SIV or AES-GCM-SIV. The problem is there's no obvious way to build a SIV mode out of XChaCha20 and Poly1305 because the tag of the latter doesn't fit the IV size of the former.

The safest construction (but is slow and has large expansion) that I can think of is: 1/ Generate a random nonce N 2/ Derive a per-message key K1 from key, message and N 3/ Encrypt the message with XChaCha20Poly1305 using K1 and N

This follows https://eprint.iacr.org/2017/702.pdf, which doesn't add the message to the key derivation step in 2/. Further analysis is required to tell how such a change affects security. At first glance, it doesn't, but I'm far from an expert in this kind of analysis.

paragonie-security commented 3 years ago

This is resolved by #127.