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

  • 1
    I'm voting to close this question as off-topic because Answers will go stale very quickly. We are hoping to modify the Answers to provide more general guidance on discovering the most recent advice on cryptographic standards.
    – schroeder
    Sep 2, 2015 at 19:36

9 Answers 9


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
  • 5
    Even more interesting would be the context in which these are considered insecure, and where they do their job just fine. Nov 12, 2010 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, 2010 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. Nov 22, 2010 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, 2010 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, 2010 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.


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


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.
  • 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, 2011 at 21:00
  • Stuck a couple of Wikipedia links in there.
    – yfeldblum
    Oct 9, 2011 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?


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


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.

  • 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, 2011 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. May 2, 2011 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, 2011 at 20:36

RC4 is probably best avoided. Its improper use was the cause of the problems in WEP which suggests it an be tricky to get right even for experts. To use it properly means choosing a large enough key (at least 128 bits), mixing key and IV in a secure manner (e.g. hashing as opposed to concatenation) and discarding the initial part of the keystream to mitigate against weak-key attacks (256 octets at the minimum).


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

  • I don't think he claimed this. I parse it as both Blowfish/ECB and AES/ECB being mostly useless. May 3, 2011 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, 2011 at 20:09

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