3
$\begingroup$

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?

Improve this question
$\endgroup$
9
  • 1
    $\begingroup$ you can easily trim if you use CTR mode, but not ECB, which is a very bad idea $\endgroup$
    – Richie Frame
    Nov 16, 2014 at 11:24
  • 1
    $\begingroup$ If you want compact 64-bit block cipher, I would suggest Speck or RC5. XTEA should also be fine, but you have to be careful with key management (as always). $\endgroup$
    – LightBit
    Nov 16, 2014 at 12:40
  • 3
    $\begingroup$ If you use a block cipher in ECB mode, the same plaintext will always lead to the same ciphertext, allowing to detect if the same plaintext is sent twice, which is against the security goals assigned to a cipher, and why good block ciphers operating modes use IVs. $\;$ Also: it would not be the first time when "requested to encrypt" should be understood as also requested to protect against malicious alteration. $\;$ Before choosing the block size of the cipher, find your goals, and what cipher or/and MAC or/and authenticated encryption you want to use. $\endgroup$
    – fgrieu ♦
    Nov 16, 2014 at 14:29
  • 3
    $\begingroup$ What are your actual security requirements? As everyone is pointing out, you've already made some very questionable decisions so what are you trying to accomplish? Confidentiallity? Replay protection? Integrity? Please fill us in with as much detail as possible. $\endgroup$
    – Thomas M. DuBuisson
    Dec 16, 2014 at 18:03
  • 1
    $\begingroup$ I've voted to close this question as you haven't responded to the questions asking for the security requirements and use case. Without that there are too many options / answers possible. $\endgroup$
    – Maarten Bodewes ♦
    Sep 6, 2015 at 12:17

1 Answer 1

Reset to default
2
$\begingroup$

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).

Improve this answer
$\endgroup$

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.