1
$\begingroup$

The paper The Galois/Counter Mode of Operation (GCM) describes mainly the 128-bit case, for use with 128-bit block ciphers such as AES. AES-GCM test vectors are available from NIST.

The paper also describes GCM for 64-bit block ciphers. My question is, has anyone actually implemented GCM for a 64-bit block cipher, and/or published test vectors?

Improve this question
$\endgroup$

2 Answers 2

Reset to default
4
$\begingroup$

This would not be recommended in most cases. Note that AES-GCM fails terribly if an IV repeats. In a 64-bit block cipher, if you want the probability of such a failure to be below $2^{-32}$, then you would be very limited in the number of messages you can encrypt. If you can guarantee a unique IV each time, and are not using a random IV in order to get uniqueness, then maybe it can be OK.

Improve this answer
$\endgroup$
4
  • $\begingroup$ Does AES-GCM fail terribly with a repeating IV if I'm using it only for AAD (Additional Authenticated Data), ie authenticated but not encrypted? $\endgroup$
    – Craig McQueen
    Commented Dec 24, 2018 at 9:34
  • $\begingroup$ I'm contemplating a usage scenario with a low quantity of data. E.g. a remote unlocking fob for a car, with a very small amount of data (1 byte lock/unlock/trunk/etc) and sufficient IV and auth tag. $\endgroup$
    – Craig McQueen
    Commented Dec 24, 2018 at 9:37
  • $\begingroup$ If the IV repeats then the authenticator is completely broken. If you are doing very small messages, and you choose the IV to be random 64 bits, then you can encrypt at most 2^16 messages while maintaining an error probability of 2^-32. For this application, you are better off with CBC-MAC; with one byte messages you have a single AES operation only (essentially ECB). $\endgroup$
    – Yehuda Lindell
    Commented Dec 24, 2018 at 9:41
  • $\begingroup$ They specified that it would be for a key fob or similar, but they shouldn't use 64 bits because they'll "only" get 65536 lock or unlock operations before someone else could - if they monitored every fob event - forge the same? That's 20 years at 10 fob events per day! $\endgroup$
    – WDS
    Commented Dec 24, 2018 at 10:31
1
$\begingroup$

I've been struggling with good ways to protect data from passively-powered RFID tags that send less than 1k of data during their life. Cryptographers do not understand engineering constraints that are more real than the money that you can throw at security. I have all of the codebook vectors for the Simon Cipher, and I ended up using SIMON32/64 in some RFID applications because the total value was less than $10. For a car, you might want to consider something with some more strength than 64-bits.

Improve this answer
$\endgroup$
2
  • $\begingroup$ Maybe cryptographers who are given the constraints when asked would understand and guide their answer appropriately. Saying "cryptographers do not understand" is a massive generalization. Would you say that about the entire block cipher community working on constructing lightweight ciphers for these applications? Would you say that about the cryptographers doing TLS and side-channel research? It is probably true of most theoreticians, but this isn't what they are trying to do. By the way, I know plenty of theoreticians who do have this knowledge, but if they don't know the constraints... $\endgroup$
    – Yehuda Lindell
    Commented Dec 25, 2018 at 16:29
  • $\begingroup$ @YehudaLindell It is a massive generalization and a jab at the community. I going to stick by it until more people put their (grant) money where their mouths are. Begin a theorist is easier than being a pragmatists, and in my experience, these are very, very hard to find in the cryptographic community. As a semiconductor person, I tend to be the funder of last resort because I make things and understand the mathematics. I would love to find some pragmatist cryptographers for collaborate with in the semiconductor space, but so far I've not found any. It's a sad state of affairs. $\endgroup$
    – b degnan
    Commented Dec 25, 2018 at 17:18

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.