What cryptographic algorithms are not considered secure?

Question

What cryptographic algorithms are not considered secure, but yet are still widely used and available in standard libraries? If applicable, mention a secure alternative.

Answer 1

These are the most common:

• MD5 - Use SHA512
• SHA1 - Use SHA512 (Note this is not really insecure, but its showing its age, and will be fragiler in the next couple years....)
• DES / 3DES - Use AES

Answer 2

The links below can quickly help you choose the proper method and key length for your security requirements (thereby avoiding insecure methods):

• http://www.keylength.com/en/3/
• http://www.keylength.com/en/8/
  (or any of the "Choose a Method" options)

"This web site implements mathematical formulas and summarizes reports from well-known organizations allowing you to quickly evaluate the minimum security requirements for your system. You can also easily compare all these techniques and find the appropriate key length for your desired level of protection."

Answer 3

Although this quesiton is already answered, I'm missing a lot of answers.

• RC2, RC4
• MD4 (it is still available in some libraries)

Moreover, it depends on the use and purpose of the algorithm. Breaking DES is no hard, but is quite expensive. Consider who your attackers are and how much money and effor they can spend to break the security?

Answer 4

As of the end of 2010, the US government deprecates these algorithms based on recommendations from the very savvy folks at NIST:

• SHA-1
• 1024-bit RSA or DSA
• 160-bit ECDSA (elliptic curves)
• 80/112-bit 2TDEA (two key triple DES)

MD5 never was an acceptable algorithm for government use, along with many other older algorithms.

For security through the year 2030, they recommend at least SHA-224, 2048 bits for RSA or DSA, 224-bit EDCSA, and AES-128 or 3-key triple-DES be used.

This has been in the works for several years. See this post and the NIST documents it references: http://securitymusings.com/article/1587/algorithm-and-key-length-deprecation

Update: Another concise, useful set of advice is Cryptographic Right Answers by Colin Percival.

Answer 5

Insecure but widely used cryptographic algorithms include:

• hash functions: MD4, MD5, (SHA-1) (MD2 is also insecure but not widely used; SHA-1 is only "weakened"; MD4 and MD5 are also widely used in situations where cryptographic resistance is not required, so that's not a problem)

• symmetric encryption: DES (56-bit key), RC4 (non-randomness -- but most security issues with RC4 are in how it is used, not due to the algorithm itself), the stream cipher in the Zip archive format (newer Zip utilities use AES)

• asymmetric encryption: RSA with a too short key (i.e. 768 bits or less), RSA with improper padding (e.g. ISO 9796-1), Diffie-Hellman modulo a too small prime number (768 bits or less)(Diffie-Hellman is not really an asymmetric encryption algorithm, but a key agreement algorithm -- but most usages of asymmetric encryption are really disguised key agreements)

• digital signatures: RSA with a too short key (i.e. 768 bits or less)

• many (too many) handmade algorithms from people who oversmarted themselves; a prime example being CSS, the encryption for DVD

Secure alternatives: SHA-256 for hashing (SHA-512 if you have the same fetish on size than US Army, and/or if you want to kill performance on 32-bit systems), AES for symmetric encryption. For key agreement, consider ECDH (Diffie-Hellman over an elliptic curve) with one of the standard NIST curves (e.g. P-224, K-233 or B-233 -- but P-256 is more widely supported). For asymmetric encryption, use RSA with a large enough key (1024 bits for short term security, preferably 1536 or 2048 bits) and PKCS#1 padding (v1.5 "old-style" is fine, but OAEP is finer). For signatures, consider ECDSA (same curves than for ECDH) or RSA with a large enough key and PKCS#1 padding (v1.5 or PSS). Never design your own algorithm (or, if you do, never believe that it is secure).

Most security issues, however, are not in the choice of algorithm, but in how they are used. WEP uses RC4, but RC4 is not one of the numerous weaknesses of WEP. Sony protected the PlayStation 3 with ECDSA, which is secure, but botched their randomness generator, resulting in a catastrophic failure (private key exposure...).

Answer 6

Obviously there are as many broken algorithms as there are programmers who write home-grown encryption systems, but by and large those are limited to a given software package. Several "password protection" schemes for documents and archives come to mind as examples.

But the only general-purpose encryption algorithm (not hashing algorithm as others are listing) that is considered "broken" for normal use because of flaws in the algorithm (rather than key length), and which is still widely deployed and accepted, is RC4.

Note that the primary reason RC4 sticks around despite its known flaws is that the vulnerability can be mitigated by throwing out the first few K output. Also, its the only widely-deployed stream cipher, and many programmers don't realize you can turn a block cipher into a stream cipher using an appropriate block chaining mode.

Answer 7

Using a block cipher like Blowfish or AES, when operated in ECB (Electronic Code Book) mode.

Answer 8

Context is important. Secure for what? How is something being used?

For example:

• AES-256 is "secure." Until you decide to encrypt a stream of block-structured data with AES-256 in ECB mode.
• AES-256 is "secure." Until you encrypt multiple messages in CBC mode but with the same key and the same IV.
• AES-256 is "secure." Until you use an implementation the timing of which varies with the bits of the key or of the data.