8
$\begingroup$

There are many papers out there that show that a message authenticated and encrypted by AES-GCM can be forged if the used key is weak (e.g. by Handschuh and Preneel, Saarinen or Procter and Cid). With weak keys I refer to the definition given by Handschuh and Preneel:

In symmetric cryptology, a class of keys [D] is called a weak key class if for the members of that class the algorithm behaves in an unexpected way and if it is easy to detect whether a particular unknown key belongs to this class. For a MAC algorithm, the unexpected behavior can be that the forgery probability for this key is substantially larger than average.

All these papers give suggestions how to avoid weak keys or how to minimize the class of weak keys. However, none of these suggestions have been accepted in the NIST standard. The standard is obviously older than the papers about weak keys, yet AES-GCM is still one of the most accepted algorithms.

Thus, I would like to know if famous applications like TLS or IPSec have implemented a weak keys detection or how do they avoid weak keys? Or is the probability to get a weak key (assumed that one is using secure random number generators) still so so small that the existence of weak keys is negligible?

Improve this question
$\endgroup$
5
  • $\begingroup$ just because AES-GCM can be exploited if the key is weak, that does not mean that classes of weak keys exist for AES, thus the problems lie with GMAC. The GCM spec places conditions and limits on most of its exploitable properties $\endgroup$
    – Richie Frame
    Commented Aug 27, 2016 at 0:18
  • $\begingroup$ Also, since H is equal to $AES_K(0_{128})$, I do not believe it is probable for H to equal 0, which is one of the more exploitable scenarios $\endgroup$
    – Richie Frame
    Commented Aug 27, 2016 at 0:42
  • $\begingroup$ @RichieFrame, is there something in AES that specifically prevents $E_k(x) = x$ for every k? (Of course even with a random-looking output hitting it would be impossible in practice with the same $2^{-128}$ odds as for every output.) Also, wouldn't that be a theoretical weakness in AES, as it's technically the same problem Enigma had? (or am I taking this too far) $\endgroup$
    – ilkkachu
    Commented Aug 28, 2016 at 9:39
  • 1
    $\begingroup$ A little bit off-topic... But, anyway... I think the Latin term i.e. is miss placed in the question. Maybe it should be replaced by e.g. but I'm not going to make an edit to change two characters :s $\endgroup$
    – Hilder Vitor Lima Pereira
    Commented Aug 28, 2016 at 18:19
  • $\begingroup$ @ilkkachu no there is not. In fact, for a 128-bit key, I would say that for a substantial qty of keys that would happen for some $x$. I would suspect however, that it is not likely that it would happen if $x$ is 0, or would be no more likely to occur than random, due to the design of AES. $\endgroup$
    – Richie Frame
    Commented Aug 29, 2016 at 1:52

1 Answer 1

Reset to default
2
$\begingroup$

However, none of these suggestions have been accepted in the NIST standard.

The suggestions are to use a different group. Those are not changes that could be done to the standard without complete loss of compatibility. They are things to consider when designing and choosing new algorithms, however.

Or is the probability to get a weak key (assumed that one is using secure random number generators) still so so small that the existence of weak keys is negligible?

Yes. From Saarinen's risk analysis:

The probability of randomly hitting an exploitable weak key with a real-world AES-GCM cryptographic protocol such as SSH [4], IPSec [6] or TLS [12] is vanishingly small.

No protocol that I know of uses GCM with a 64-bit cipher (like 3DES or Blowfish), which Saarinen calls out as risky and recommends against.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.