Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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

share|improve this question

8 Answers 8

up vote 17 down vote accepted

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
share|improve this answer
3  
Even more interesting would be the context in which these are considered insecure, and where they do their job just fine. –  Jörn Zaefferer Nov 12 '10 at 0:37
2  
@Jorn, I would say that with the exception of SHA1 (which is still good enough for non-critical systems for another good couple years), no reason to ever use these (MD5/DES/3DES) in a cryptographic context. Especially 3DES, since AES is quicker! Though I have seen MD5 used in a non-security context, kind of like a content-dependant GUID... or something like that. –  AviD Nov 12 '10 at 0:42
1  
If you have a very weak embedded device, you might choose to use a weaker algorithm for low value and/or time sensitive information (need the data quickly and the data is ages very fast). The problem is that most seemingly innocent information can actually be used in nefarious ways. It's easier to use (currently) unbreakable encryption. –  rox0r Nov 22 '10 at 15:59
3  
@rox0r, even on a weak embedded device, AES is better on resources than 3DES. Only problem is in legacy platforms, that do not support modern encryption. –  AviD Nov 22 '10 at 16:34
2  
Good advice, though SHA256 is faster, shorter and also fine for now. See csrc.nist.gov/groups/ST/toolkit/secure_hashing.html and note that the security of hash functions is still poorly understood, and there are theoretical concerns about SHA512 as well. There is a major hash competition run by NIST to stimulate research and specify, perhaps in 2012, what will be called SHA-3 en.wikipedia.org/wiki/NIST_hash_function_competition –  nealmcb Nov 25 '10 at 18:07

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.

share|improve this answer

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...).

share|improve this answer

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.
share|improve this answer
    
Justice's comments are really important (although a bit terse -- @Justice, you could have explained your points a bit better, or at least included a link to some discussion of those issues) –  Jay Oct 9 '11 at 21:00
    
Stuck a couple of Wikipedia links in there. –  yfeldblum Oct 9 '11 at 21:12

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?

share|improve this answer

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

"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."

share|improve this answer

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.

share|improve this answer
    
I'm not sure just how widely deployed it is, but a questioner here was planning to implement TEA until hearing about the problems with it. en.wikipedia.org/wiki/Tiny_Encryption_Algorithm –  nealmcb Apr 30 '11 at 1:05
1  
@nealmcb: TEA was (mis)used in the Xbox (not the Xbox 360), so it has been widely deployed. Microsoft used TEA as a hash function, and TEA is much worse as a hash function than it already is as a block cipher. –  Thomas Pornin May 2 '11 at 20:48
    
I didn't list TEA because it's not generally available in crypto APIs. Its main draw is that its easy to implement in hardware. –  tylerl May 3 '11 at 20:36

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

share|improve this answer
    
I don't think he claimed this. I parse it as both Blowfish/ECB and AES/ECB being mostly useless. –  Bruno Rohée May 3 '11 at 8:10
    
Thanks, @Bruno. You are right, and I was wrong. I deleted my comment, where I misunderstood @rox0r, and edited the answer to try to be clearer in case anyone else reads it the same way I did. –  D.W. May 3 '11 at 20:09

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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