I have a question about the AES-128 and AES-256 encryption method. I need to encrypt 64-bit size data in and out. I want to encrypt them with AES.

So I turned to AES-OFB or AES-CFB because these methods do not require padding. I have at my disposal a number of 256 bits which are shared by the source and the receiver (this number is created internally by both, this number is totally unknown to the rest of the world). I would like to use half of the number for the IV and the other half for the key. The IV and the key would be fixed.

In my specifications, it doesn't matter if someone can decipher the messages. However, someone should not be able to send encrypted messages that would be recognized by the recipient.

So my question is this:

  • Can someone find the IV and the key from the encrypted messages?
  • If so, can they then generate the encrypted messages to take control of the system?
  • 1
    $\begingroup$ Out of curiosity: how would prevent someone from "sending encrypted messaged that would be recognized by the recipient"? You don't have a MAC so the decrypted message might be garbage but you can't know for sure who sent it. Also: the IV is not meant to be secret, just the key. $\endgroup$ – Marc Jul 6 '20 at 12:46
  • 1
    $\begingroup$ Replay attack. That is a simple attack that can have devastating results. What is the structure of the data? Why not CTR mode or better AES-GCM? $\endgroup$ – kelalaka Jul 6 '20 at 12:48
  • 1
    $\begingroup$ "because these methods do not require padding" - does that mean it is important to keep the ciphertext length the same as the plaintext length? If so, that makes the problem considerably harder... $\endgroup$ – poncho Jul 6 '20 at 12:59
  • $\begingroup$ Yes it is important to keep the ciphertext lenght the same as the plaintext length.... It's for encrypting a CAN bus. For a 64-bit frame, the frame containing the encrypted message is also 64-bit. No other frame can be sent. It's just that nobody can send a command to the recipient. I'm stuck on the amount of data being transmitted. $\endgroup$ – Niki Jul 6 '20 at 13:47
  • $\begingroup$ Thinking about this some more, I suspect that, with your design constraints, you'll need something tailored around the CAN bus, rather than a generic crypto design (and no, I personally don't know enough about the CAN bus requirements to give you useful advice there). However, even though I feel I cannot personally help, I'm glad to hear that someone is taking automobile security (or wherever you're using the CAN bus) seriously... $\endgroup$ – poncho Jul 6 '20 at 17:12

In my specifications, it doesn't matter if someone can decipher the messages. However, someone should not be able to send encrypted messages that would be recognized by the recipient.

If that's the case, then encryption is the wrong solution; you are looking for a Message Authentication Code (MAC), such as CMAC.

With CMAC, you hand the message and the key to the CMAC code, which generates a 'tag'. You send the message and the tag to the recipient, which takes the message (and their own code of the key) and calls CMAC to generate their own tag. If the tag they computed agrees with the tag you sent, they accept the message; otherwise, they reject it.

CMAC (and any other MAC) was designed with the security property that, if you don't know the key, you cannot find a message/tag pair that validates (even if you were given a large number of valid message/tag pairs). This is exactly what you want; someone cannot generate a tag that would be accepted (except for the message/tag pairs they have already seen). Of course, if replay attacks are potentially an issue (that is, if an adversary takes a message/tag pair verbatim and resubmits it, would that be an issue?); if it is, you can add further protection (e.g. include a sequence number with the message; this sequence number always increases; the recipient verifies that it is higher than the previously seen valid messages, and the sequence number is included in the CMAC computations).

Obviously, someone listening in can find the message (it's in the clear); however you said you didn't care about it.

I suggested CMAC in particular because you appeared to have AES in mind (and CMAC based on AES is not a bad option); other good message authentication codes are HMAC and KMAC.


I have to encrypt 64-bit messages and then send them as a 64-bit message as well. I can't afford to send more than one 64-bit encrypted message for one 64-bit unencrypted message.

If that is the case, then the security that you can achieve is rather limited; you'll have to accept those limits, or find a way to allow some ciphertext expansion.

One thing that the attacker can do is generate a completely random ciphertext 64 bit ciphertext and submit that. If the encryption process accepts arbitrary 64 bit plaintexts and generates 64 bit ciphertexts, then every ciphertext will correspond to some plaintext, and in particular, the random ciphertext will correspond to some random plaintext. The best you can do in this scenario is to make sure that the attacker has no better attack; that is, he can cause you to decrypt into unpredictable values, but he cannot do any better.

What you'll need to do is have the recipient vet the decrypted plaintext somehow (e.g. if there is a 'type' field that is from 0-5, reject any message where the type field is outside that range). No security person would be overjoyed at the security you can achieve with this; however that's the best you can do.

As for how to make random plaintext/ciphertext mappings, well, it turns out that for 64 bits, there just happens to be some standard block ciphers that can do that [1]; 3DES naturally has a 64 bit block size, as well as some Speck parameter sets. 3DES is still fairly commonly implemented in crypto libraries (generally deprecated, but still there), and Speck is quite simple. What you would do is use the block cipher in ECB mode [2]; take your 64 bit plaintext, and give it to the block cipher in encrypt mode; that'll give you a 64 bit ciphertext. The recipient will take the 64 bit ciphertext, and give it to the block cipher in decrypt mode; that'll give you a 64 bit plaintext (which you'll vet). The block cipher acts like a random permutation; that is, the attacker will not be able to predict what any ciphertext he has not seen to decrypt to.

This does bring up the question of replay attacks. Those are even more challenging in this scenario, and I'm rather hoping those are not a concern (especially if message transmission is not guaranteed; that is, it Is possible for the recipient to not receive every message the encryptor has sent).

[1]: For someone reading this later with a similar problem, but with slightly different ciphertext sizes, there are some other standard solutions, known as Format Preserving Encryption methods, which can take arbitrary plaintext sizes (e.g. 42 bits), and map then into the exact same ciphertext size. However, there are rather more obscure, and so I do not suggest them for Nicolas.

[2]: Using ECB mode is generally the Wrong Thing; this is one of the few cases where it makes sense


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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