[upofadown]

>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...

[tptacek]

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.

[upofadown]

There has to be some reverse channel to do an oracle. Timing? That might not be a thing for messaging. Signal apparently also uses CBC with the same type of padding. So the same shade could be thrown in that direction if someone really wanted to do so.

I would be happier if there were fewer vague assertions in these sorts of writeups...

[tptacek]

I'm not sure what part of Signal you're referring to, but the Signal Protocol generally uses AEAD constructions. That aside: the kind of padding is not the issue; every serious system that uses CBC uses PKCS7 padding. The issue is the lack of authenticated ciphertext, which is what enables the attack. The authenticated scheme composing CBC and HMAC in an EtM arrangement is not susceptible to padding oracle attacks. There are other error and behavior oracles for other padding schemes, and for different block cipher modes.

[mozman]

> nondeterministic IVs

Can you explain what this means?

[tptacek]

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.