Your April update to add the chart by "RIM's encryption vendor" adds lots of confusion. It is really an ad for Certicom's ECC stuff with oversized RSA lengths added for effect. They misleading quote NSA and NIST work. As others have already clarified, even the earlier recommendations were overkill. I suggest just deleting the update, or putting it out as an answer, since updating the question also makes it unclear what previous answers were referring to unless people check the dates.
–
nealmcbApr 1 '11 at 14:27

@nealmcb - I thought it was helpful... I removed it. Thanks for the feedback
–
LamonteCristoApr 1 '11 at 14:33

May be worth calling out that the specific requirement of a hash for password storage is different from the requirement for a hash for message integrity (whether transmission, or signing). There are on-going arguments over what is the best approach to password hashing - scrypt/bcrypt/PBKDF2 - but plain SHA-256/SHA-512 is definitely not the right answer.
–
Richard GadsdenJul 4 '11 at 13:33

7 Answers
7

The recommendations you cite are kind of overkill. One point to take into account is that beyond a certain level (e.g. on key size or hash function output size), all functions are "unbreakable with foreseeable technology" and it is a bit delicate to compare them. Stating that SHA-512 is "more robust" than SHA-256 means that you are imagining that SHA-256 could be broken, which, as far as we can tell for now and the next 40 years, is not true (beyond 40 years, trying to envision what technology we could have is risky; 40 years ago, nobody was imagining the Internet as it is today, but most people assumed that by 2010 we would all drive flying cars).

The currently largest broken RSA key is a 768-bit modulus, and it took some huge effort (four years, and really big brains). 1024-bit keys are considered usable for short term security, although larger keys are encouraged. 2048-bit keys are appropriate. Using a key twice larger means 8 times more work for signing or decryption, so you do not want to overdo it. See this site for a survey of how RSA key length can be related to security.

ECDSA over a 256-bit curve already achieves an "unbreakable" level of security (i.e. roughly the same level than AES with a 128-bit key, or SHA-256 against collisions). Note that there are elliptic curves on prime fields, and curves on binary fields; which kind is most efficient depends on the involved hardware (for curves of similar size, a PC will prefer the curves on a prime field, but dedicated hardware will be easier to build with binary fields; the CLMUL instructions on the newer Intel and AMD processors may change that).

SHA-512 uses 64-bit operations. This is fast on a PC, not so fast on a smartcard. SHA-256 is often a better deal on small hardware (including 32-bit architectures such as home routers or smartphones).

Right now, cheap RFID systems are too low-powered to use any of the above (in other words, RFID systems which can are not as cheap as they could be). RFID systems still use custom algorithms of often questionable security. Cellphones, on the other hand, have ample enough CPU power to do proper cryptography with AES or RSA (yes, even cheap non-smart phones).

In terms of security, these recommendations are still valid and the same I would make.

For asymmetric ciphers, there are really three things you are concerned with: encryption, key exchange, and signatures. RSA can be both an encryption and signature scheme, while ECDSA is specifically a signature. However there are elliptic curve versions of encryption and key exchange as well (not sure what is in the public domain though). That said, the parameter sizes are the same for all three.

The only other cavet is that SHA-256/512 will soon be replaced but "soon" in this case will be 2012.

Regarding low-powered, it really depends on how low-powered. If by cellphone, you mean a smartphone, all of these are appropriate. For a smartcard, RFID, sensor network, etc. it is a different story. Also, most low-powered algorithms will not be in a standard library. However I would steer you toward the parameter sizes in the "not overkill" last sentence.

It is unclear whether SHA-3 (chosen in 2012) will "replace" SHA-2 (SHA-256 and SHA-512). The NIST certainly did not claim that. It seems that SHA-3 was initiated in order to be ready if SHA-2 was to be broken, but SHA-2 turns out to be quite resilient.
–
Thomas PorninJan 19 '11 at 23:17

1

Fair enough. I believe that SHA-2's resilience may be artificially inflated from all the cryptanalysists focusing on SHA-3 candidates and not on breaking SHA-2. ;)
–
PulpSpyJan 19 '11 at 23:20

1

Also the list is missing a stream cipher -- do have a recommendation @Thomas?
–
PulpSpyJan 19 '11 at 23:22

2

A "stream cipher" is mostly a specific usage context; AES in CTR mode is a stream cipher. If we want something faster then we can look at algorithms specifically designed for that; the smart thing is to look at the eSTREAM Portfolio. I would choose Sosemanuk, but I am slightly biased on that question.
–
Thomas PorninOct 6 '11 at 15:48

I completely disagree. That's a complete misinterpretation of those results. (I am knowledgeable about this area.) Those results are not applicable to most uses of AES (or indeed to any proper use of AES). Moreover, none of the results cited there apply to the full 14-round AES-256 cipher.
–
D.W.Apr 3 '11 at 3:30

2

daemonology.net/blog/… has more on this subject, basically if you chose your key randomly (which is good protocols do) those related key attack are of no significance whatsoever.
–
Bruno RohéeApr 7 '11 at 15:50

What we did is to select several encryption and hashing methods and converted all output to a common hex format. Our most sensitive data is using SHA-256 and DES-3, while less sensitive data that can be guessed easily is using MD5 & RC4 and we are also using a straight XOR conversion for some things. Each symmetric cipher has it's own password and all encrypted data is keyed with a check-sum. Relying on one encryption for everything is dangerous.