←back to thread

157 points lladnar | 1 comments | | HN request time: 0s | source
Show context
upofadown ◴[] No.41864130[source]
>Generally, NIST recommends[1] not using a wholly deterministic derivation for IVs in AES-GCM since it is easy to accidentally re-use IVs.

A quick skim of the referenced document did not show where NIST recommended against the use of deterministic IVs. The document actually spends a significant amount of text in discussing how one would do such a thing. Did I miss something?

>Lack of forward secrecy

The article mentions that the key is forgotten when you close the app. Probably enough forward secrecy for most people.

>Since AES-CBC is used alongside PKCS7 padding, it is possible that the use of this encryption on its own would be susceptible to an AES-CBC padding oracle, which can lead to recovery of the encrypted plaintext.

This is a messaging app. Is there actually an available oracle? Does the implementation even generate a padding error?

[1] https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpubli...

replies(1): >>41864969 #
tptacek ◴[] No.41864969[source]
The GCM IV thing didn't ring true to me either; in fact, the whole reason we have XAES-type constructions is to enable fully nondeterministic IVs, which don't fit comfortably in the GCM IV space.

Regarding padding oracles: it is most definitely not necessary for a target to generate a "padding error", or even an explicit error of any sort, to enable the attack.

replies(2): >>41865302 #>>41865438 #
mozman ◴[] No.41865438[source]
> nondeterministic IVs

Can you explain what this means?

replies(1): >>41865480 #
1. tptacek ◴[] No.41865480[source]
In this case it's just a fancy way of saying "random". What's important about a GCM nonce is that it never repeat, not that it's unpredictable (to me, a distinction between a "nonce" and an "IV"; a CBC IV must be unpredictable).

Because you only get 96 bits of nonce space with vanilla GCM, there's common advice to use a counter as the nonce.