Question

I am working on a project that involves sending some very small encrypted messages over a high performance socket connection using UDP. I have read in other posts that the bare minimum number of bytes that AES should encrypt with a 128 bit key is the block size, which is 16 bytes.

But, the real question is – is that enough to provide good protection? I am thinking about using a scheme that would add some random data to the message and get a random number between 1 and 12 which would be used to place the 4 bytes of real data within the block. The zero byte in the block would be the random number which is the starting position in the block of the 4 bytes. After building the block, it would be encrypted with AES using a 128 bit key. The data does not have any value after the client disconnects, and connections should not last more than 24 – 48 hours at the most. Will something like this work, or should I send more data to make it harder for a potential adversary to break?

I also will be encrypting other data that does need to be protected after the user disconnects like credit card numbers, bank account info, password hash, etc. I am planning on using AES with 256 bit keys for that. So, same question for this case – what is the minimum number of bytes that should be encrypted to provide good protection for 256 bit keys? Will 16 bytes suffice, or would 32 be better?

I am planning on using bouncy castle’s fast AES engine for the small messages. See:

http://www.bouncycastle.org/csharp/index.html

http://www.bouncycastle.org/docs/docs1.6/org/bouncycastle/crypto/engines/AESFastEngine.html?is-external=true

For the 256 bit AES encryption, I am thinking of using RijndaelManaged since it seems to have better security features on the server and performance is not much of an issue for these infrequent transactions.

Answer 1

First of all, the less cipher text, the less it it susceptible for attacks. It seems you think it is the other way around.

For UDP I would highly recommend to look into counter mode encryption. The advantages is that the key stream can be pre-calculated, which makes for low latency encryption/decryption. It does not require padding either, so you don’t have to send more data than required (note that you have a side channel regarding data length, so the difference between “Yes” and “No” can be clearly seen). You do need a good NONCE though.

If you want integrity protection, then GCM mode encryption would be highly advisable. If it is not available, take a look at HMAC or MAC over your cipher text – but you will require two secret keys instead of just the one.