Adress active attacks on privacy

[bellebaum]

The draft mentions passive attacks on confidentiality, as well as an adversary's ability to generate forgeries. The assumption seems to be that "a forgery now and then" is harmless. This however depends very much on the protocol and I believe should be addressed. In particular, it should be mentioned in the security considerations that tag forgeries may have an impact on confidentiality, rather than just integrity and authenticity.

For example, consider a protocol which takes noticeably longer to process inputs with a particular bit pattern, say starting with 32 ones (but imagine any form of structured header here). Finding out whether a given ciphertext c corresponds to a plaintext starting with the arbitrary 32-bit sequence B could involve calculating c' := c xor ((B xor 111...111)||0000), forging a tag for this and measuring the time it takes the recipient to process c'.

This attack vector is very different from the occasional forged packet problem and may, depending on the context, have severe implications for privacy. In general, this is a special case of a so-called Chosen Ciphertext Attack, and there are many more forms varying e.g. in the number of forged messages that need to be sent. Yehuda Lindell mentioned on the mailing list the possibility of a statement like "Any attack taking Q queries without tags would take 2^t * Q queries with length-t tags", but this has not been proven yet. Even if it eventually is proven, the outlined attack above has Q=1, so in general, if 2^t is online bruteforceable, then there is a potential threat to privacy which protocol designers need to be aware of when choosing t.

[bellebaum]

To add some numbers:

This site by Cisco claims that you can get about 14,880,960 packets per second on a 10Gb/s interface. It might be slightly below that, but let's be conservative and assume 2^24 packets per second. At this rate, a chosen ciphertext attack on the 4-byte variant might take you 2^8 seconds, which is about 5 minutes, thus doable given the lifetime of protocols.

So mitigations might include choosing a longer tag and changing keys very frequently, say every minute, or after every message using some kind of ratchet. Ideally, you would choose all three as mitigations.

E.g. with 64 bit tags, a single forgery takes about 2^40 seconds, which is already about 35k years given no technological improvements, so there is room for future improvements to this attack. Changing a key after every minute would translate to a roughly 2^-34 chance of pulling the attack off within any given minute, which still might not be good enough (it definitely is not for multi-target attacks or longterm attacks), but is at least reasonable.