An application encrypts data with AES (aes-256-cbc) using a key and IV derived from a randomly-generated pass-phrase (openssl enc -pass...). It encrypts the pass-phrase with 2048-bit RSA. So the pass phrase data is limited by the size of the RSA key (i.e to a maximum of 256 bytes) and any padding scheme

Given the random characteristic of the pass-phrase data (e.g. openssl rand), which is better: more data or better padding ?

Example pass phrase lengths:

  • 256 bytes with no padding (pass -raw option to openssl rsautl)
  • 245 bytes with the OpenSSL default pkcs padding
  • 214 bytes with oaep padding (using the default SHA1 digest)
  • 190 bytes with oaep padding using a SHA256 digest

To paraphrase, if the random source is good enough is there anything to gain from using fewer random bits for the key and then applying a padding scheme and, if so, which padding scheme is best ?

  • Any more than 32 bytes of random key is a total and complete waste of effort. However, rand can produce all 256 8-bit values but trying to pass those through a shell to a process like openssl enc usually loses at least some of them, which changes the derived key and your decryption doesn't work. You should either generate a password of characters (not bytes) with 256 bits entropy and allow openssl enc to use its (poor) PBKDF, or generate a key and IV (max 48 bytes), convert to hex and use -K (uppercase) and -iv. Or if your keys are single use you can use fixed IV like zero. Jun 28, 2017 at 2:54
  • It isn't a key though, it's a password. Are you suggesting having a random password of more than 32 bytes is pointless? Admittedly, if the password is comprised of bytes then care does have to be taken when passing it - don't assign to a shell variable - or restrict to characters as you say.
    – starfry
    Jun 28, 2017 at 9:05
  • A key for AES (and most symmetric algorithms) can be any combination of bits and 256 bits is enough, which is 32 bytes on pretty much all systems of interest today (although there are some exceptions, which I didn't note due to comment limits). But shells and the openssl program both can't handle aribtrary bits, hence you need workarounds, and the one used here is hex (so 32 bytes is 64 hexits=characters, but still 256 bits of entropy). ... Jun 29, 2017 at 4:43
  • ... A password is characters that at least notionally a human can type, and in this situation a shell can pass to openssl, and that are derived to produce the key, which is different from the password; this is always less dense and often significantly less so than the all-bits case, but how much depends on details of your systems and some choices you make. One fairly easy choice nowadays is a 64-character set so that 43 independent uniform characters is enough (slightly over 256 bits of entropy); there are lots of other choices. Jun 29, 2017 at 4:47


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.