9

I have created an OpenSSL RSA private key and certificate request with 4096 bit with the following command:

openssl req -newkey 4096

When I view the private key with

openssl asn1parse -in privkey

I get the following output:

    0:d=0  hl=4 l=2446 cons: SEQUENCE          
    4:d=1  hl=2 l=  64 cons: SEQUENCE          
    6:d=2  hl=2 l=   9 prim: OBJECT            :PBES2
    17:d=2  hl=2 l=  51 cons: SEQUENCE          
    19:d=3  hl=2 l=  27 cons: SEQUENCE          
    21:d=4  hl=2 l=   9 prim: OBJECT            :PBKDF2
    32:d=4  hl=2 l=  14 cons: SEQUENCE          
    34:d=5  hl=2 l=   8 prim: OCTET STRING      [HEX DUMP]:XXXXXXXXX
    44:d=5  hl=2 l=   2 prim: INTEGER           :0800
    48:d=3  hl=2 l=  20 cons: SEQUENCE          
    50:d=4  hl=2 l=   8 prim: OBJECT            :des-ede3-cbc

What bothers me is the part with des-ede3-cbc. Why is there des-ede3-cbc in my RSA private key? As far as I know "DES" is an encryption standard from the seventies and it's considered broken.

Improve this question

2 Answers 2

Reset to default
13

Why is there des-ede3-cbs in my rsa private key?

Because your private key is encrypted with that.

As far as I know "DES" is an encryption standard from the seventies and it's considered broken.

Yup. Pretty much. Consider reencrypting it with AES like so:

$ openssl rsa -in desencryptedprivkey.pem -out aesencryptedprivkey.pem -aes128

EDIT 2015-06-29: Good enough after all
Reading Bruno's answer I realize now that it's actually still 112 bits of security in the default mode. And that's pretty good.
(What made me unsure about this is that you can run triple-DES with 1, 2 or 3 keys. And I wasn't sure that this was really the 3-key-version. But it turns out that it actually is.) -- See comments under Bruno Rohée's answer for details.

EDIT 2015-07-03: Some Terms and Conditions May Apply
As discussed in the comments thread with @dave_thompson_085 it's not quite so clear cut.

While 128 bit AES is indeed preferable to 112 bit Triple-DES (if only for speed and not for practical security), both encryptions suffer from weak key stretching. -- At least in the way it's implemented in OpenSSL.

This means that the mechanism by which the encryption password is turned into one 128 bit-AES-key or three 56-bit-DES-keys is not state of the art.

What key stretching is MEANT to do is turn a relatively weak password like Asdf123! into a strong encryption key. However OpenSSL uses weak key stretching.

And AFAIK there is no way of passing in stronger key stretching parameters.

So the most practical recommendation, as suggested by Dave, right now is: Consider key stretching to be virtually non-existent and use a very strong password.

Improve this answer
10
  • 2
    Am I understanding this correctly that when using "openssl req -newkey 4096" the requested password is pretty much useless beause the private key is encrypted with an old and broken algorithm? That means that openssl is providing the user with a false sense of security because the default encryption option for the private key is insecure.
    – rosix
    Jun 28, 2015 at 18:23
  • 1
    What version of OpenSSL do you use? Old versions will have old default algorithms.
    – Vilican
    Jun 28, 2015 at 18:41
  • 1
    No. While DES is past its prime, it's still far from useless. Especially in this "data-at-rest" encryption scenario. (Wikipedia says that NIST gives it until 2030.) But for new deployments I'd try to go without it.
    – StackzOfZtuff
    Jun 28, 2015 at 19:21
  • 1
    If/when you do re-encrypt a privatekey, don't use the old rsa utility (or dsa or ec) unless you use a very strong password (at least 80 bits entropy); they use almostPBKDF1 with one iteration. The old but generic pkcs8 -topk8 or the "new" (1.0.0 in 2010) pkey uses PBKDF2 with 2048 iterations. @Vilican Debian/Ubuntu (and Redhat/Centos) don't take new head versions of outside packages like openssl into a stable release, instead they apply needed security patches to the version they took for the release. The Ubuntu site agrees that version is current for Ubuntu trusty 14.04.
    – dave_thompson_085
    Jul 1, 2015 at 13:50
  • 1
    First a correction: pkcs8 -topk8 -v2 des3. pkcs8 does default to 2048 iterations, but PBKDF1 and SINGLE-DES YUCK! I misremembered pkcs12 which does default reasonably, 2048 iterations (corrected!) in PBKDF1 with 3DES, and options for PBKDF2. The definitive word on details like this for opensource like openssl is the source; you can apparently browse github.com/openssl/openssl but I much prefer to download the tarball from www.openssl.org/download and access locally. ...
    – dave_thompson_085
    Jul 3, 2015 at 12:40
13

Your private key is encrypted with Triple DES. While DES is easily broken, Triple DES is safe for now, especially in this context. AES was made to replace Triple DES not so much because Triple DES was broken, but because it was way too slow. In the context of private key encryption, a non issue.

Improve this answer
4
  • +1. I was unsure if there really were three keys here. Turns out there are. Here's the related question that made me realize this: Which default encryption does OpenSSL use? -- So (taking into account the meet-in-the-middle-attack) we have 112 bits of security here. Which is less than 128 for AES128 but still good enough.
    – StackzOfZtuff
    Jun 29, 2015 at 6:48
  • 1
    Triple DES increase the key size, but it doesn't increase the block size. The small block size reduces security if you encrypt a lot of data using the same key. For encryption of a single secret key, I wouldn't worry too much. I'd say one should start worrying if 512KB or more had to be encrypted using a single key.
    – kasperd
    Jun 29, 2015 at 8:54
  • 2
    With current known attacks, 3DES is still good with petabytes of data encrypted with the same key... I really wonder where that 512Kb figure comes from...
    – Bruno Rohée
    Jun 29, 2015 at 19:47
  • 64bit block ciphers are vulnerable to the SWEET32 attack but the attack on 3DES requires more than 2³⁶ blocks encrypted with the same key, which just doesn't happen in the context of private key encryption.
    – Bruno Rohée
    Aug 2, 2022 at 12:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .