Ask Slashdot: Is SHA-512 the Way To Go? 223
crutchy writes "When I was setting up my secure website I got really paranoid about SSL encryption, so I created a certificate using OpenSSL for SHA-512 encryption. I don't know much about SHA (except bits that I can remember from Wikipedia), but I figure that if you're going to go to the trouble (or expense) of setting up SSL, you may as well go for the best you can get, right? Also, what would be the minimum level of encryption required for, say, online banking? I've read about how SHA-1 was 'broken', but from what I can tell it still takes many hours. What is the practical risk to the real internet from this capability? Would a sort of rolling key be a possible next step, where each SSL-encrypted stream has its own private/public key pair generated on the fly, and things like passwords and bank account numbers were broken up and sent in multiple streams with different private/public key pairs? This would of course require more server grunt to generate these keys (or we could take a leaf from Google's book and just have separate server clusters designed solely for that job), but then if computing performance was a limiting factor, the threat to security of these hashes wouldn't be a problem in the first place."
(Continued below.)
"I guess with all security infrastructure, trust becomes a more important factor than technical abilities. Can I trust that my SSL provider hasn't been hacked (or at least snooped)? How do I know some disgruntled IT admin hasn't sold the private key of his company's root CA to the same organization that developed the conficker virus? It would certainly make for a more profitable payload. I've read some of Bruce Schneier's work (I'm subscribed to Cryptogram) and he tends to highlight the FUD that surrounds internet security, and I agree that there is a lot of FUD, but complete ignorance and blase attitude toward security can also be taken advantage of. Where is the middle ground?"
THE SOLE ANSWER (Score:2, Informative)
Not 42.
Read this book:
http://www.schneier.com/book-applied.html
Problem solved. You understand the basics of crypto, and can now make decisions!
SHA isn't encryption. (Score:5, Informative)
If you're going to work on cryptographic security or have even a passing interest in encryption, Schneier's Applied Cryptography is a great place to start.
Re:Here we go (Score:3, Informative)
As the prior poster said, you don't know enough of what you're doing to even begin. Go pick up a copy of Applied Cryptography, spend 3-4 weeks reading it, and then at least you'll have perspective and can begin deeper research. Actually, Applied Cryptography should tell you everything you need to know for nearly any application.
Recommended keylengths/algorithms (Score:4, Informative)
You might want to have a look at http://www.keylength.com/ [keylength.com] (overview of all 'official' recommendations regarding protocols and minimal keylengths).
If you work for banks: take into account the Payment Card Industry standard (https://www.pcisecuritystandards.org/ - strictly speeking only valid for credit card handling systems) and look at national compliancy requirements ...
Re:SHA isn't encryption. (Score:5, Informative)
Mod parent up.
There are four parts to SSL: Ciphers, Hashes, Randomness, and Public Key Crypto.
Public Key and Hashes are used by the SSL endpoints to validate the identity of the other end. Both ends must agree on a mutual Certificate Authority and the web of trust that extend from it.
Randomness is used to create a session key, shared via Public Key to seed the Cipher used to encrypt the session.
Weaknesses in hashes makes it easier to spoof a trusted site. Weaknesses in Randomness makes it easier to guess the Cipher key (this is the vector I've seen exploited the most). Weaknesses in Public Key makes everything vulnerable - which is why people are worried about Quantum Crypto.
Ciphers include: AES, Camellia, DES, RC4, RC5, Triple DES. Hash Functions include: MD5, MD2, SHA-1, SHA-2. Public Key includes: RSA, DSA, Diffie-Hellman key exchange.
Re:Calm down and read up (Score:5, Informative)
Inventing your own method of hashing passwords (based on a standard hashing algorithm) counts as making up your own cryptosystem (sadly, the vast majority of web programmers seem to fall into this trap). You should be using a standard password hashing mechanism, such as PBKDF2 [wikipedia.org] (RFC2898). Although the name implies symmetric key derivation (Password-Based Key Derivation Function 2), it works just as well for hashing a password before storing it in a database, and it's much better than 99% of the schemes in use out there.
Re:Rainbow tables? (Score:5, Informative)
Rainbow tables are basically premeditated brute forcing. They're only useful to attackers when the password hashing in use is weak. Which is quite still common, unfortunately.
For example, every developer knows (or damn well should) that it's a remarkably bad idea to store user passwords as plaintext in a database. So when it comes time to write the code, many of them just pick an arbitrary hashing function that isn't widely known to be broken and move on. After they're attacked and the user database stolen, all the attackers need to do is run the database against any of the common rainbow tables floating around and they have the passwords for a good percentage of the database.
Some people will say, "well duh, that's why you add a salt before you hash!" But where do you propose to store the salt? That's right, in the database. The one that the attackers may eventually have access to. It might cost them some time, and possibly some money, but it wouldn't be at all impossible to rent some time on EC2 or a botnet to effectively create their own specialized rainbow table for the job.
It is still not common knowledge that you need to use a more secure password hashing function. This is called key stretching [wikipedia.org]. Key stretching makes it deliberately expensive to brute-force every password combination and, to an extent, dictionary attacks. Plain old hashing functions are designed to be very quick and efficient. You can generate thousands (millions?) of hashes per second on modern hardware. A good password hashing function which employs key stretching is deliberately designed to be many orders of magnitude slower so as to make brute-forcing and rainbow tables computationally infeasible. The idea is, if each guess takes 2-3 seconds to compute (as opposed to 2-3 milliseconds), you will be waiting a very long time before you have anything close to a usable rainbow table.
This doesn't mean users are off the hook when it comes to using secure passwords. Even with key stretching, any dictionary-based password can be found with some patience. But a secure hash of any reasonably "random" password can be safe for a very long time even if^H^Hwhen the password database is compromised.
Re:Calm down and read up (Score:2, Informative)
If you're using anything other than PBKDF2, bcrypt [codahale.com] or scrypt [tarsnap.com] to store your user's passwords, you have already lost.
Re:Rainbow tables? (Score:5, Informative)
I'm sorry, but this borders on nonsensical... Assume each user has a distinct, hopefully large (at least 32-bit and preferably 64-bit) salt, generated by a cryptographically secure PRNG and the SHA-1 algorithm for hashing. What does this mean? If Eve somehow gets a dump of the salted-hashed passwords from Alice's database, she would need to generate a unique rainbow table for each user. Sure, Eve could just target one particular user from the database -- say Bob -- explicitly and get together enough computing power to attempt to mount a brute-force attack on the salted-hash, but that's an awful lot of work to compromise one account.
So much work, in fact, that will almost certainly make an attacker choose a different attack vector. It's just an impractical attack for all but the most well-funded adversaries -- adversaries who work for three-letter government agencies that employ more mathematicians and programmers than you can count, and who run massive data centers that require their own, dedicated power plants -- and who are targeting a particular very-high-value target, we're talking about the sort of attackers who work for .
Password stretching, as you mention, is a great idea, and more people should use it. But a simple salted hash, provided the salt is large and the hash is cryptographically secure, is almost certainly good enough for the vast majority of applications.
Re:SHA isn't encryption. (Score:3, Informative)
Mod parent up.
There are four parts to SSL: Ciphers, Hashes, Randomness, and Public Key Crypto.
Public Key and Hashes are used by the SSL endpoints to validate the identity of the other end. Both ends must agree on a mutual Certificate Authority and the web of trust that extend from it.
Randomness is used to create a session key, shared via Public Key to seed the Cipher used to encrypt the session.
Weaknesses in hashes makes it easier to spoof a trusted site. Weaknesses in Randomness makes it easier to guess the Cipher key (this is the vector I've seen exploited the most). Weaknesses in Public Key makes everything vulnerable - which is why people are worried about Quantum Crypto.
Ciphers include: AES, Camellia, DES, RC4, RC5, Triple DES. Hash Functions include: MD5, MD2, SHA-1, SHA-2. Public Key includes: RSA, DSA, Diffie-Hellman key exchange.
Two things:
- Your note about the CA is not quite correct. The term Web of Trust (as I know it) refers to a PGP-like infrastructure, as opposed to the hierarchical model used by X.509 (which implies CAs). The difference is that trust in a CA always means trust in any key singed by it (and thus also the CAs below it in the hierarchy).
For those interested, you can more on this in these lecture notes [win.tue.nl] from my crypto class.
- I know quantum computers can do fast factorisation (ie. break the RSA assumption), but can they also break the DDH assumption (diffie-hellman, elliptic curve crypto)?
Re:Rainbow tables? (Score:4, Informative)
If you're hashing a password, use a slow hash, one that can be "stretched" to take seconds of CPU time. If it takes a second of CPU time to hash a password, your attacker is going to need 6622 years of CPU time to break an 8 character A-Z password, whereas you'll need one second to approve a valid user.
Don't try to roll your own slow hash by using many rounds of a fast hash, there are slow hashes that have been designed and reviewed by the security community. bcrypt is one I often hear about, but search around, there are others.
Agree entirely with you. However, you could do even better than bcrypt (which is very good already). The reason is that bcrypt (and the like) only depend on a lot of CPU time, but do not demand a lot of memory. CPU time is much easier to come by than memory, and easier to parallelise. One algorithm that uses both a lot of CPU time and a lot of memory is scrypt. The author estimates that (with the same constraints on the time taken to calculate the derived key from the password) scrypt is typically at least 30 times more expensive to an attacker than bcrypt.
More information on scrypt here: http://www.tarsnap.com/scrypt.html [tarsnap.com]