4 ms·

It could be made more resistant to birthday attacks by using the session message count as the IV, but I guess it wouldn't matter unless someone kept one of thes

It could be made more resistant to birthday attacks by using the session message count as the IV, but I guess it wouldn't matter unless someone kept one of these terminals open for a really long time.

unscaled 5y ago
I think it's important to clarify the statement above, for anymore who is not familiar with the issue and keeps misusing AES-GCM. AES-GCM has a relatively short IV (= nonce): only 96 bits (12 bytes). To make things worse, if an IV ever gets repeated GCM fails catastrophically[1]. The design document[2] explicitly point out that a FIPS 140-2 compliant GCM hardware[3], must take all possible precaution to ensure an IV never gets repeated, even if the device suffers a critical power loss. The safe way to use AES-GCM in software (for instance, the way it is used in TLS) is to just use a running counter and replace the key before the counter overflows and starts repeating itself. Random counters bad, since if enough messages are generated with the same key the chance of a message that repeats an IV under the same key increases. The statistic phenomenon behind the chance of something like that being repeated is called the "Birthday Problem"[4], so exploiting this kind of weakness is often referred to as a "Birthday Attack"[5]. tl;dr: If you want an easy life, just never use any form of AES at all. Most AES mode can be completely safe if used and implemented with care - but it is generally quite hard to do that. AES has too many knobs and there is too much bad advice on places like Stack Overflow and various blogs. Generally, for encrypting multiple messages with the same key, the solid advice is to use NaCl secretbox (XSalsa20-Ply1305) or libsodium aead_xchacha20poly1305_ietf[6]. But you probably need more than that when encrypting potentially long-lived bidirectional streams of data. --- [1]: It fails even worse than other authenticated counter mode ciphers due to the design of the GHASH function: https://csrc.nist.gov/csrc/media/projects/block-cipher-techniques/documents/bcm/comments/800-38-series-drafts/gcm/joux_comments.pdf https://csrc.nist.gov/csrc/media/projects/block-cipher-techn... [2]: See section 9 here in NIST 800-38D: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpubli... [3] Keep in mind that like most 2000s vintage cipher specs, GCM was designed as a hardware cipher. Software was more or less an afterthought, if anything at all. [4]: https://en.wikipedia.org/wiki/Birthday_problem https://en.wikipedia.org/wiki/Birthday_problem [5]: https://en.wikipedia.org/wiki/Birthday_attack https://en.wikipedia.org/wiki/Birthday_attack [6]: https://libsodium.gitbook.io/doc/secret-key_cryptography/aead/chacha20-poly1305/xchacha20-poly1305_construction https://libsodium.gitbook.io/doc/secret-key_cryptography/aea...

unscaled 5y ago

I think it's important to clarify the statement above, for anymore who is not familiar with the issue and keeps misusing AES-GCM. AES-GCM has a relatively short IV (= nonce): only 96 bits (12 bytes). To make things worse, if an IV ever gets repeated GCM fails catastrophically[1]. The design document[2] explicitly point out that a FIPS 140-2 compliant GCM hardware[3], must take all possible precaution to ensure an IV never gets repeated, even if the device suffers a critical power loss. The safe way to use AES-GCM in software (for instance, the way it is used in TLS) is to just use a running counter and replace the key before the counter overflows and starts repeating itself. Random counters bad, since if enough messages are generated with the same key the chance of a message that repeats an IV under the same key increases. The statistic phenomenon behind the chance of something like that being repeated is called the "Birthday Problem"[4], so exploiting this kind of weakness is often referred to as a "Birthday Attack"[5]. tl;dr: If you want an easy life, just never use any form of AES at all. Most AES mode can be completely safe if used and implemented with care - but it is generally quite hard to do that. AES has too many knobs and there is too much bad advice on places like Stack Overflow and various blogs. Generally, for encrypting multiple messages with the same key, the solid advice is to use NaCl secretbox (XSalsa20-Ply1305) or libsodium aead_xchacha20poly1305_ietf[6]. But you probably need more than that when encrypting potentially long-lived bidirectional streams of data. --- [1]: It fails even worse than other authenticated counter mode ciphers due to the design of the GHASH function: https://csrc.nist.gov/csrc/media/projects/block-cipher-techniques/documents/bcm/comments/800-38-series-drafts/gcm/joux_comments.pdf https://csrc.nist.gov/csrc/media/projects/block-cipher-techn... [2]: See section 9 here in NIST 800-38D: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpubli... [3] Keep in mind that like most 2000s vintage cipher specs, GCM was designed as a hardware cipher. Software was more or less an afterthought, if anything at all. [4]: https://en.wikipedia.org/wiki/Birthday_problem https://en.wikipedia.org/wiki/Birthday_problem [5]: https://en.wikipedia.org/wiki/Birthday_attack https://en.wikipedia.org/wiki/Birthday_attack [6]: https://libsodium.gitbook.io/doc/secret-key_cryptography/aead/chacha20-poly1305/xchacha20-poly1305_construction https://libsodium.gitbook.io/doc/secret-key_cryptography/aea...