Block cipher to encrypt 8 bytes/64 bits - Use 64 or 128 bit cipher?

Question

Here's the problem: I have a transport stream that I have been requested to encrypt between the transmitter and receiver. The data size is at most 8 bytes so it seems I can only use ECB as I only have a single block - the most I can do is pad to 8 bytes if its less, which I intend to do with random data (the receiver can figure out the correct length from the decrypted data).

I've been looking for 64-bit ciphers and came up with the most popular: DES, 3DES, TEA, XTEA, XXTEA, Blowfish. I've discounted DES, 3DES and Blowfish due to their code size (not enough space to implement it, and concerns over speed of encryption/decryption on the embedded platform we are using)

I'd rather not use TEA, as it seems insecure from what I've read.

Is there another 64-bit cipher that is more secure than TEA, but doesn't require lots of code space plus lots of constant data like Blowfish does?

Is it possible to use a 128-bit cipher and "trim" the result to 64-bits?

Answer 1

You can safely use ECB if all of the following conditions are met:

• Your messages can be unambiguously encoded in a form with a fixed size which is equal to the cipher's block size. For example, your messages all have the same size which is smaller than the block size, or they're all smaller than the block size and they never have trailing null bytes.
• You only need message confidentiality, not authenticity or integrity (i.e. you don't need to protect against an attacker who might modify the message in transit, possibly without knowing its content).
• You don't mind that an observer can tell if you're sending the same message twice.

Even if you don't think you need authenticity or integrity checks, carefully consider the design of the whole system. What happens if an adversary submits fake messages (either made from whole cloth, or modifications of legitimate messages)? What happens if an adversary resubmits a previous message after having observed its effect?

If the messages are all produced and received by the same entity, and the sender and the receiver can agree on some kind of message identifier (e.g. a number that is incremented for each message), then there's a better mode: counter mode (CTR). CTR has several advantages:

• By mixing the message number into the encryption, messages with identical content have distinct, unlinkable ciphertexts.
• CTR turns a block cipher into a stream cipher, so you can send the exact number of bytes (of bits, even) that matches the length of the message.
• CTR requires only encryption on both sides, never decryption, which can same a tiny bit of code size.

CTR only works if the sender and the receiver agree on the initial counter value for each message. Usually the initial counter value is sent as a prefix of the ciphertext, but if you already have a unique identifier for the message, you can repurpose it.

CTR requires distinct counter values for each block of all messages. For messages that are shorter than the block length, this requirement simplifies to not reusing a counter value for different messages.

Note that CTR does not help with message integrity. It even makes it trivial to make predictable changes to the ciphertext without deciphering it (flipping a bit in the ciphertext flips the corresponding bit in the plaintext).