Accordion: Padding, ciphertext indistinguishability, and deniable encryption
John Preuß Mattsson
Hi,
I think the accordion mode is very exciting and I think it will be a very important building block for future ICT systems. I think the accordion mode and derived functions should strive to be very high security. One important aspect is to increase usable security by designing APIs that are hard to use incorrectly. The more I think about it, the more I think NIST should not only design derived functions that are resistant to misuse but also derived functions that take care of functionality such as nonce handling, sequence number concealment, replay protection, and padding. This does not only decrease the risk that these things are used incorrectly and insecurely but also enables important security functionality in cases where the accordion mode is used on its own.
I am planning to attend the workshop, but I had a bit limited time before the workshop deadline. I hope to have much more feedback during the workshop and in the official comments. Below is my current thought about padding.
Padding, ciphertext indistinguishability, and deniable encryption. A required feature in most modern security protocols such as MACSec, IPSec, SSH, TLS, DTLS, QUIC, EDHOC, and MLS is the possibility to pad messages and to send packets with no message and only padding. The IND-CCA2 game assumes that all messages have the same length. In practice this is of course not the case and without padding a passive attacker can trivially see the length of the message, which can be extremely revealing. Sending packets with no message and only padding complicates traffic flow analysis. Military systems sometimes take this to the extreme by always sending at full bandwidth so that an adversary cannot determine when actual communication is happening. We think plaintext length concealment is an important cryptographic property and we think it is best handled by the encryption algorithm, not the protocol using the algorithm. We suggest that the derived functions support padding. NIST’s current proposal for an AEAD mode in Section 3.1 of [1] already includes padding ”to ensure that the input is an allowed size for the accordion mode”, we think this should be changed so that the amount of padding is determined by an input parameter. We also think the padding needs to be included in the calculation of the authentication security tau . A ciphertext with incorrect padding should be discarded by the decryption function. Our understanding of NIST’s current proposal described in Section 3.1 is that the plaintext is first padded with a variable length bitstring 1000… of minimum length t. If the amount of padding is determined by an input parameter, the authentication security is then tau >= t - 1/(2^g - 1) >= t - 1, where g is granularity defined in Section 4.4 of [1].
[1] “Proposal of Requirements for an Accordion Mode”
Cheers,
John Preuß Mattsson
Expert Cryptographic Algorithms and Security Protocols, Ericsson Research