CODEWITHSUNDEEP
csecurityencryption
Raghavendra Ganiga
Raghavendra Ganiga

Reputation: 99

Encryption algorithm for 14 byte data

I have an application, where I have to transfer an encrypted packet over BLE advertisement which is fixed 14 byte in length. AES algorithm restricts data to be minimum of 16 bytes long and DES requires it to be in multiples of 8 byte. I have a odd length of 14 byte which I cannot change. Is there any encryption algorithm which can be used to encrypt this 14 byte data. Also it would be good, if someone could point out any C based implementation of the algorithm?

Upvotes: 1

Views: 1174

Answers (5)

Artjom B.
Artjom B.

Reputation: 61892

You can use ECB-based Ciphertext Stealing (CTS) with a block cipher that has a block size smaller than 14 byte. I won't go into detail how CTS works, because the Wikipedia article does a pretty good job.

If you heard that ECB is bad then you are correct. Sadly any other mode requires some sort of IV which will eat away your payload constraint. Since CTS moves a part of the ciphertext to the last plaintext block the bad property of ECB goes away.

Block ciphers with small block sizes such as 64-bit have worse security properties than say block ciphers with 128-bit blocks. Just look at the Sweet32 attack. In your case I would guess that this is not really an issue since an attacker cannot get you to generate many many encrypted broadcasts and if they tried it would take them a really long time.

A popular block cipher with 64-bit block size is DES. You might have heard that DES is easily brute forceable due to the small key size and you would be correct. Triple-DES (EEE or EDE) comes to the rescue which has a key size that is three times larger and has a much better protection against brute force attacks.

Sadly, you cannot use AES because CTS needs at least two blocks to work and a single block of AES already breaks your size constraint.

Upvotes: 3

Joshua
Joshua

Reputation: 43278

Assuming you mean both plaintext and ciphertext are exactly 14 bytes in length:

Use AES in CTR mode. This yields the same 16 byte chunks of data on each side. You can use 14 of the 16 bytes as an XOR key and discard the last two.

Initialization of the IV is done with 14 bytes of IV and two bytes of zeros.

However, there's a wrinkle here. The underlying protocol is stateless broadcast. The only way to get an IV is to use a unique packet identifier, and there might not be one. Without about 10 additional bytes I would have a very hard time coming up with a unique IV generator.

Upvotes: 3

Gem Taylor
Gem Taylor

Reputation: 5613

Assuming you want to transmit in the same 14 bytes you are a bit stuck. The suggestions above mean that you would need to transmit 16 bytes (or even more), then ignore the last 2 bytes.

How secure do you need the data to be? One answer might be to use DES to encrypt all the full blocks (one block of 8 bytes in your case), then use something weaker to encode the remaining (6 in your case) bytes. A reasonably secure way would be to simply xor the previous 6-byte decoded byte values over your remaining 6 bytes of tail data. Until the DES protected data has been decoded, the xor value cannot be determined.

Of course, if the DES portion was all-zeros then your tail codes are going to be visible. If this is a rare occurrence this may not be an issue as the hacker does not know that the DES data is zeros. You don't have a lot of data, so it is hard to think of much more that you could do.

In general, you could generate a 64-bit (8-byte) checksum of the previous 1K of original data, and use this as the xor. In general you will have a number less than 8 bytes of tail data, which you would xor, and only transmit the number of bytes. On decode, the remaining bytes are ignored.

Upvotes: 0

Den-Jason
Den-Jason

Reputation: 2573

Why not frame your data so that it features:

  1. header
  2. payload
  3. padding

The header would contain the length of the data, plus maybe a "magic" code to check synchronisation. The payload is your data. The padding is then a block of zeroes (or random numbers if you so wish) in order to fit the necessary multiple of blockside for the block-cipher.

Upvotes: 0

luser droog
luser droog

Reputation: 19504

Both AES and DES are Block Cipher algorithms, so you're right that they have minimum sizes for the blocks they can handle. BUT there are many different ways to use block encryption, some of which can process streams of data of arbitrary length. Check out "s-bit Cipher Feedback Mode" where the s is the size of the actual chunks that are individually being encrypted. Here you could use s=2.

Upvotes: 0

Related Questions