GCM counter incrementation isn't stopped at 2^32 blocks, which breaks GCM #129

Merged

sjaeckel merged 1 commit from fix/gcm_counter_reuse into develop

2016-10-02 13:51:01 -05:00

sjaeckel commented

2016-09-28 13:20:21 -05:00

(Migrated from github.com)

As reported privately by @rjamet

https://github.com/libtom/libtomcrypt_p/blob/develop/src/encauth/gcm/gcm_process.c#L60

I haven't found a check that the encrypted plaintext is shorter than 2^32 blocks? If there's one, then it's fine. Otherwise, the counter will continue, and that causes IV reuse. In CTR or so it isn't so bad (the attacker can get a xor of plaintexts), but in GCM, if the plaintext is controlled by the attacker, this allows forging authentication tags: see 3. in http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/Joux_comments.

Instead, GCM should just throw after (2^32)-1 blocks / (2^39)-256 bits as per http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/gcm/gcm-spec.pdf p18.

As reported privately by @rjamet > https://github.com/libtom/libtomcrypt_p/blob/develop/src/encauth/gcm/gcm_process.c#L60 > > I haven't found a check that the encrypted plaintext is shorter than 2^32 blocks? If there's one, then it's fine. Otherwise, the counter will continue, and that causes IV reuse. In CTR or so it isn't so bad (the attacker can get a xor of plaintexts), but in GCM, if the plaintext is controlled by the attacker, this allows forging authentication tags: see 3. in http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/Joux_comments. > > Instead, GCM should just throw after (2^32)-1 blocks / (2^39)-256 bits as per http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/gcm/gcm-spec.pdf p18.

coveralls commented

2016-09-28 13:33:06 -05:00

(Migrated from github.com)

Coverage decreased (-1.6%) to 85.676% when pulling 7d418b34b3 on fix/gcm_counter_reuse into 6ad5225268 on develop.

[![Coverage Status](https://coveralls.io/builds/8096086/badge)](https://coveralls.io/builds/8096086) Coverage decreased (-1.6%) to 85.676% when pulling **7d418b34b3fe6d49354d5a9ef5a442c387a1bd06 on fix/gcm_counter_reuse** into **6ad52252688bb34f90b5e79da4830a927e87b81f on develop**.

sjaeckel commented

2016-09-28 14:34:08 -05:00

(Migrated from github.com)

@fperrad what does your linter say? :-)

karel-m (Migrated from github.com) reviewed

2016-09-28 15:08:38 -05:00

karel-m (Migrated from github.com) left a comment

Just a side note: similar check for max. size is perhaps worth considering also for CCM (where it depends on chosen tag len and nonce len) and maybe other encauth as well