Even more interesting would be the context in which these are considered insecure, and where they do their job just fine.
–
Jörn ZaeffererNov 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.
–
rox0rNov 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

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

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)
–
JayOct 9 '11 at 21:00

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?

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

@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 PorninMay 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.
–
tylerlMay 3 '11 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).

I don't think he claimed this. I parse it as both Blowfish/ECB and AES/ECB being mostly useless.
–
Bruno RohéeMay 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