Use of ECB mode

[irdan]

The AES block cipher mode that is currently being used is ECB. This strikes me as an unusual design decision that I have not seen justification for in the publication, documentation, or code.

ECB mode is perhaps the most difficult block cipher mode to use while still maintaining the security properties that AES seeks to provide.

My intention in filing this issue is to prompt changing to a new block cipher mode or allow the rationale to be more clearly documented.

[kpdyer]

Thanks for asking this question! A bit more information is provided in section 6.1 of [1]. However, it still won't fully address your concerns.

The construction we use is a stateful, randomized authenticated encryption scheme. At one point we had the full proof of security and justification in [2], but we cut it for the conference due to space constraints.

In the implementation (as described in sec. 3.2 of [2]) a single call to ECB is used to encrypt a fixed-length header W1, then we use CTR mode [3] to protect the message contents W2. We then perform a MAC over both W1 and W2. This allows us to detect cases where, say, an attacker is trying to manipulate contents of W1, etc.

If you're still not satisfied, I'm happy to go into further details. Even better --- it'd be great if you could identify a concrete attack against our construction/implementation/instantiation!

[1] https://kpdyer.com/publications/usenix2015-marionette.pdf
[2] https://kpdyer.com/publications/ccs2013-fte.pdf
[3] https://github.com/kpdyer/libfte/blob/master/fte/encrypter.py#L110

[kpdyer]

Also, as you mentioned, it's important to add rationale for our choices. I'll leave this issue open until a comment is added to [1].

[1] https://github.com/kpdyer/libfte/blob/master/fte/encrypter.py

[irdan]

I read the sections of the papers you mentioned, but still don't fully understand the need to use ECB mode for the header. I'm sure the reasoning is sound, I'm just curious at this point.

Is the property of having deterministic encryption of identical block sized chunks desirable? In the nomenclature of marionette, is IV_1 smaller than the block size?

[kpdyer]

Correct, the size of IV_1 is smaller than the blocksize. In fact, by AES_{K_1}, we mean that we do exactly once AES invocation. In our implementation we have that |IV_1| + |M| is exactly the length of the AES blocksize.

In our implementation our IV_1 is 64 bits, of which 56-bits are random [1], and M is 64-bits. So, this should make it challenging for any DPI adversary to recover IV_1 in realtime, without knowledge of K_1.

[1] https://github.com/kpdyer/libfte/blob/master/fte/encrypter.py#L96