0

With the new release of Windows 10, Microsoft has given .NET, Javascript and C++ developers a whole new bunch of options for cryptographic algorithms.

Where as the old .NET code only allowed AES and RSA, the new Windows 10 libraries allow thos algorithms:

Symmetric Algorithms

  • AesCbc
  • AesCbcPkcs7
  • AesCcm
  • AesEcb
  • AesEcbPkcs7
  • AesGcm
  • DesCbc
  • DesCbcPkcs7
  • DesEcb
  • DesEcbPkcs7
  • Rc2Cbc
  • Rc2CbcPkcs7
  • Rc2Ecb
  • Rc2EcbPkcs7
  • Rc4
  • TripleDesCbc
  • TripleDesCbcPkcs7
  • TripleDesEcb
  • TripleDesEcbPkcs7

Asymmetric Algorithms

  • DsaSha1
  • DsaSha256
  • EcdsaP256Sha256
  • EcdsaP384Sha384
  • EcdsaP521Sha512
  • RsaOaepSha1
  • RsaOaepSha256
  • RsaOaepSha384
  • RsaOaepSha512
  • RsaPkcs1 (represents an RSA public key algorithm that uses PKCS1 to pad the plaintext. No hash algorithm is used)
  • RsaSignPkcs1Sha1
  • RsaSignPkcs1Sha256
  • RsaSignPkcs1Sha384
  • RsaSignPkcs1Sha512
  • RsaSignPssSha1
  • RsaSignPssSha256
  • RsaSignPssSha384
  • RsaSignPssSha512

The algorithms that are italic are those I assume already approved as "insecure"/should not be used.
So what of those algorithms are still secure, which are explicitly unsecure?

I already considered this post, but I guess it's already outdated, again?

  • 5
    Your last sentence exemplifies why these sorts of questions aren't a good fit for StackExchange. I'm not sure why the previous one didn't get closed. For a proper answer, I'd suggest keeping up with the latest standards & recommendations from trusted organizations like NIST and CIS. – Iszi Sep 2 '15 at 18:28
  • 4
    "considered secure" by whom? – schroeder Sep 2 '15 at 18:44
  • 1
    Ah, yeah. Then there's what @schroeder said. So it's a "product recommendation" and time-sensitive, as well as being "primarily opinion-based". – Iszi Sep 2 '15 at 19:26
  • @Iszi I'm well aware of the fact that duplicate questions should be avoided in the SE network. But in terms of security, I may not rely on a 2 year old answer. Beside the answers given, I'll also take a look into NIST and CIS recommendations. Thanks for that. – Herdo Sep 2 '15 at 20:02
  • 3
    The problem isn't that this is a duplicate, but rather that any answer is temporary. We are trying to modify the old answer to be more general in order to point people to NIST and CIS for recommendations and make that a canonical answer. – schroeder Sep 2 '15 at 20:17
11

An algorithm can be secure only if used properly within a protocol that matches what the algorithm was meant to do. So none of the algorithms you list can be deemed "secure" in an absolute, unconditional way.

On the other hand, some algorithms are necessarily insecure and should never be used (for a security purpose). In your list, these are:

  • DES block cipher: it uses a key which is too short to be strong against the most stupid of brute forces attacks. 3DES, however, is fine in that respect.

  • Block ciphers in ECB mode tend to leak a lot of information on the encrypted data, with "real-world" plaintext data, and should be avoided except in some very specific cases.

  • RC4 has some biases which are rarely deadly, but are still a concern.

The rest of the list is "fine", in that they can be used properly and provide useful security. A lot of people nowadays are very nervous when they see "SHA-1" but this is a crowd-induced reflex which is mostly unsubstantiated.

6

I can tell you which ones are currently not secure:

  • Anything ending in "Ecb" is insecure. ECB mode does not hide large-scale patterns in the data.
  • Anything beginning with "Des" is insecure. The key size for DES is simply too small to resist attacks using modern hardware.
  • Anything beginning with "Rc2" may be insecure, depending on how you use it. It's vulnerable to a related-key chosen-plaintext attack, and it permits insecurely-short keys, either of which can be mitigated at a higher level in your system.
  • Anything beginning with "Rc4" is probably insecure. The current known weaknesses in RC4 can be mitigated, but there are so many of them and new ones keep getting discovered.
  • Anything beginning with "Dsa" may be insecure. The problem is not the algorithm itself, but interoperability concerns may restrict you to unacceptably-short key lengths.
  • Anything ending in Sha1 is insecure. Current attacks against SHA-1 are not feasible in practice, but as the history of MD5 shows, it's probably only a matter of time.
  • Anything beginning with "TripleDes" is questionable. There are no known practical attacks against it, but since it's built on top of the weak DES algorithm, nobody really trusts it.

Any of the others may be insecure. Just because there are no known practical attacks on them doesn't mean that a three-letter agency somewhere hasn't found one.

  • 1
    Personally I have no security-related problem with 3DES, except that it has a block size which is too small for encrypting large amounts of data. It is still in use in many places. As for "RsaPkcs1", it probably stands for RSA encryption (with "v1.5 type 2 padding"), so it involves no hash function at all. DSA is no less secure than ECDSA (ECDSA is normally faster for the same security level, with keys that can be encoded over less bytes). – Thomas Pornin Sep 2 '15 at 19:02
  • I've re-worded the DSA part to emphasize that the problem is not with the algorithm itself, but with implementation constraints. – Mark Sep 2 '15 at 19:19
  • 1
    The biggest issue with 3DES (other than the blocksize that @ThomasPornin mentioned) is that it's absurdly slow, particularly now that many modern processors have AES instructions in hardware. – Xander Sep 2 '15 at 19:20
  • @ThomasPornin I added the description (provided by Microsoft) about RsaPkcs1 - yes, it has no hashing. What do you say about @Marks statement about Sha1, in relation to your answer? – Herdo Sep 2 '15 at 20:08
  • 3
    I am not overly worried about SHA-1 collisions -- in many cases, collisions are irrelevant, and only second-preimage resistance is need; for that, there is not the slightest indication right now that SHA-1 could have any exploitable or even theoretical weakness. However, it is highly unfashionable to keep using SHA-1, so one often has to switch to SHA-256, if only to get auditors off your back. – Thomas Pornin Sep 2 '15 at 20:13

Not the answer you're looking for? Browse other questions tagged or ask your own question.