I am working on an unusual setup and wonder if OpenSSL can deal with it:

  1. Small amounts of data, about 64 bytes per request / response, which I'd like to squeeze into a single protocol data unit (datagram segment, I think).
  2. The program will send the exact same requests / responses repeatedly.
  3. There will be PSK not PKI configuration so the encryption key will not change between sessions.

The key is 256-bit PSK. My guess is that OpenSSL library will pad it automatically under the hood and even if I send the same one byte a million times over, it will be securely encrypted. Or are there limitations? My knowledge of OpenSSL is rudimentary but I know these days most data is sent in the form of massive streams and not several bytes.

  • "There will be PSK not PKI configuration so the encryption key will not change between sessions." - from my understanding PSK is not about the encryption keys but about authentication. And in case of plain PSK also about creating the premaster secret. The encryption keys used for the application payload will still differ between TLS sessions since the also involve things like client random. Nov 17 '21 at 8:41

TL,DR: it's not a problem under any remotely decent protocol.

Assuming you're using the TLS or DTLS protocol: theses are properly designed protocols, so you don't have to worry about things like sending partially guessable or repeated messages. The encryption only reveals the length of the encrypted data, nothing more. The authentication of messages protects against replay attacks (i.e. if an adversary records a session and resends messages from that session, they will be rejected).

At the beginning of each session, both sides send a unique random value, which is used to guarantee that every session will use different keys. Within a session, each separately-encrypted datagram uses a nonce, i.e. a value that is never repeated for a given key. The details of how this nonce works friends on the cipher suite: some (CCM, GCM) use a simple counter while others (CBC) have more complex requirements. But in every case, the nonce ensures that even if the same message is encrypted twice, the ciphertexts will be completely different.

Do not compress any data that must remain confidential. The only thing that leaks from encrypted data is the length, but that does leak, and in the right conditions (for the attacker) this can allow to recover the message based on how similar but not identical messages compress to different lengths.

Note: if you're using your own protocol, so immediately and use a well-established protocol such as (D)TLS instead. To have any chance of designing a secure protocol, you need to fully understand my answer, fully understand CBHacking's answer, and in fact to understand the topic well enough that you wouldn't need to ask this question.


Symmetric encryption almost always uses a value, called a "nonce" or "IV" (Initialization Vector), that is unique with every encryption even if the key is constant. The IV doesn't have to be secret - it's typically transmitted in plain text concatenated to the ciphertext - but it does prevent encryptions of the same plain text, with the same key, from producing the same ciphertext. Reusing the IV and key together is very dangerous and should never be done, but the IV for modern ciphers is usually at least 128 bits - 16 bytes - so there is absolutely no lack of possible values.

You should definitely makes sure you're using a cipher (or, for block ciphers like AES, that you're using a mode of operation) that takes a nonce/IV. Most of the more popular ones do, but OpenSSL supports a lot of ciphers and modes, and some of them are very old or otherwise less secure. OpenSSL can generate the IV/nonce for you, though frankly I'd recommend checking its documentation very carefully to ensure it does so correctly and won't repeat them, or else generating the IV explicitly; OpenSSL's API is bad and full of footguns; a string of nulls is technically a valid IV and quite possibly what it uses if you don't tell it otherwise.

Note that, since the IV/nonce is required for decryption, you will need space to store and transmit it along with the ciphertext. However, that shouldn't be a problem. Unless you're using a protocol with extremely small datagrams, you have tons of space to play with. Note also that you'll probably want something for message integrity (a Message Authentication Code such as an HMAC, or an authentication tag if you're using authenticated encryption), which will need a bit more space itself.

As a side note, padding is used when using a block cipher with a block size larger than the message size and a mode of operation that requires full blocks (most of them do, counter modes being the main exception). However, the padding is deterministic - it needs to be, so the decryption end knows how to remove it instead of mistakenly treating it as part of the message - so it doesn't actually solve your problem.

Important note: If padding is handled incorrectly, some modes of operation that require it (such as CBC) can be completely compromised - the attacker able to decrypt the message entirely - using a padding oracle attack. Although it's possible to avoid these while still using padding, it's better to use stream ciphers, or stream-like modes of operation, that don't have a block size and thus don't need padding.

Also, 64 bytes is 512 bits - longer than the block of any symmetric cipher in common usage - so you don't have to worry that the whole message will need padding. However, the last block might (especially if the message isn't exactly 64 bytes, or some other multiple of 128 bits, that being the most common block size).

  • There's a lot of good in this answer but also several major flaws. First and foremost, the right answer to this question is to use a well-established protocol that does all this correctly. HMAC should not be used for authenticity of encrypted data: HMAC is fine on its own, but you should use AEAD instead. Nonces in message transmission are typically counters, not random, so you don't have to transmit them (all proper AEAD modes are ok with that). CBC is the only popular message transmission protocol that uses padding and it's thankfully on its way out. Padding doesn't have to be deterministic. Nov 17 '21 at 22:20
  • 1
    Padding should in fact not be used at all (which implies that CBC should not be used at all) due to the risk of padding oracles. Nov 17 '21 at 22:22
  • @Gilles'SO-stopbeingevil' Padding oracles are only a risk if your errors (or timing, etc.) distinguish between "invalid padding" and "message authentication failed", and can be avoided entirely by checking the MAC first and not decrypting if it's invalid (requires encrypt-then-MAC). It's a good point, though, I'll add a mention.
    – CBHacking
    Nov 18 '21 at 0:18

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.