2

First off, please let me explain why I'm asking this at all:

The default implementation of EnvelopedCms is using AlgorithmIdentifier which by itself will use RSA_DES_EDE3_CBC or OID
1.2.840.113549.3.7 as encryption algorithm. Many tools using EnvelopedCms seem to just copy & paste example code. Now I don't know about you but in 2017, when I read DES, I think "not safe". Maybe I'm wrong at this point already, DES atleast still is used here and there, but the last time I checked the recommandation was to rather use more advanced block ciphers such as AES.

Now for my question(s):

  1. Is RSA_DES_EDE3_CBC still "secure" enought? When I ask this I mean like is it secure enough for the next few years, since a typical user doesn't want to re-encrypt files every year. For the sake of the discussion let's just assume Moore's law and ignore any unforeseen breakthrough e.g. quantum computing.
  2. If not, as I presume (see title), what OID would be a better pick when using EnvelopedCms? Perhaps OID 2.16.840.1.101.3.4.1.42 (is this even a correct block cipher OID?) or something even more advanced? And most important: where can I find a list of OIDs / FriendlyNames supported by AlgorithmIdentifier?
omni
  • 189
  • 6
  • Personally a new implementation I would stay clear of DES in any format. It doesn't look good to stakeholders and clients, especially if you get compromised. But ultimately the level of protection you may feel is good enough for the data in which you are protecting. – ISMSDEV Jun 18 '17 at 08:31

2 Answers2

2

RSA_DES_EDE3_CBC means RSA is used together with an encrypt-decrypt-encrypt (EDE3) version of DES. If for each step (E, D, E) a unique key is used you are effectively using Tripple-DES (3-DES). According to NIST it still provides a security of 112 bit, which is supposed to be sufficient today (06/2017 - who knows...). However, NIST also recommends using AES (128 or more).

You can find a list of some supported OIDs here: https://msdn.microsoft.com/en-us/library/windows/desktop/aa381133(v=vs.85).aspx

I do not know what kind of software you are building. If you just want to encrypt something, you may want to use RSA toghether with AES. So you would go with encrypting a message with AES128_CBC (OID 2.16.840.1.101.3.4.1.2) and the encrypting the used key with RSAES_OAEP (OID 1.2.840.113549.1.1.7)

Personally I would try libsodium (https://download.libsodium.org/doc/) which does a lot of things for you without any hazel (key genaration, wrapping, ...). It uses ChaCha20-Poly1305 instead of AES-GCM and Ed25519 instead of RSA.

fr00tyl00p
  • 2,329
  • 1
  • 15
  • 17
  • Thanks. I'm not working on a new application but I was looking into some sources that I want to harden here and there. The application in question will generate a random key (which is used to encrypt data) and then currently encrypts that key with the public key from a smartcard using RSA_DES_EDE3_CBC. I want to replace the RSA_DES_EDE3_CBC cipher with something more up-to-date. Since the key that gets encrypted with RSA_DES_EDE3_CBC by itself is a random key I guess that a symmetric cipher like AES256-CBC will be just fine? Or am I missing something here? – omni Jun 18 '17 at 15:24
1
  1. DES is not secure, you should not use it. However, the algorithm in question is not DES but 3DES in Encrypt-Decrypt-Encryt mode. Here's an answer about the security of this version.
  2. The OID you posted is for AES256-CBC that is a recommended, up-to-date algorithm. Although CBC mode is not the best you could use, for symmetric crypto this is the best Microsoft provides - here's a list of supported OIDs.
buherator
  • 1,730
  • 1
  • 9
  • 15