Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ask Slashdot: Is SHA-512 the Way To Go?

Soulskill posted more than 3 years ago | from the go-big-or-go-home dept.

Encryption 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?"

Sorry! There are no comments related to the filter you selected.

Here we go (5, Insightful)

Anonymous Coward | more than 3 years ago | (#36339948)

This will probably get marked flamebait, but I feel it needs to be said.

If you are working on something where you believe or you've been told this level of security is necessary, yet are at a "what's even out there" stage, you really need to bring someone with experience onto the team.

If this is just for a personal blog or something and you are just having fun with security, then by all means go for it. People are gonna tell you that you are insane, that plain ol` "out of the box on most distros" SSL is gonna be fine, but if you enjoy playing with this stuff then no harm throwing practicality (and your time) out the window and having fun.

I'll also note that the problem with implementing anything beyond SSL is the age old legacy problem. You can probably come up with a very secure scheme, but if no one's browser can handle it, you'll be playing with yourself!

Re:Here we go (3, Informative)

Anonymous Coward | more than 3 years ago | (#36340010)

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.

Re:Here we go (2)

Omnifarious (11933) | more than 3 years ago | (#36340430)

Applied Cryptography is an awful book if you really want to build something. It's basically a giant algorithm survey. And while some of the more unusual algorithms are pretty useful in some limited contexts, it gives you very little guidance on which algorithms to use when and why.

I would instead suggest Practical Cryptography. It has the information the OP would need to answer the exact questions he's asking. It gives you really good information about which algorithms to use when and why, and how to design secure systems by combining the various kinds of algorithms and offers guidance on how to pick them.

Re:Here we go (2)

_Shad0w_ (127912) | more than 3 years ago | (#36340776)

I would instead suggest Practical Cryptography. It has the information the OP would need to answer the exact questions he's asking. It gives you really good information about which algorithms to use when and why, and how to design secure systems by combining the various kinds of algorithms and offers guidance on how to pick them.

They renamed it "Cryptography Engineering" for the second edition, just in case someone goes round looking for it can only find the first edition. I don't actually know how different it is, mind you.

Re:Here we go (3, Funny)

Ihmhi (1206036) | more than 3 years ago | (#36341216)

Pfft, noobs! The best book is Impractical Cryptography by #5fgj@!53!@. You can't even read it without breaking the cypher (key sold separately).

Re:Here we go (2)

Profane MuthaFucka (574406) | more than 3 years ago | (#36340458)

Actually Applied Cryptography should give you the false feeling of security which will undoubtedly bite you in the ass when your system is tested in a real-world security environment.

It's not that the information is bad. It's not, the book is excellent. It's just that so many people are completely incapable of judging their own competence and will make stupid newbie mistakes even when they are guided by the most excellent of resources and advice.

Go ahead and read Applied Cryptography. Go ahead and implement your application. But don't think for a second that you're smart. Don't think that your app doesn't have a million holes in it. It does, and it will go down when right at the worst moment.

However, none of this should stop you from trying to be better. It's just the nature of the game that you have decided to play.

Calm down and read up (5, Insightful)

marcansoft (727665) | more than 3 years ago | (#36340046)

You can probably come up with a very secure scheme, but if no one's browser can handle it, you'll be playing with yourself!

Quite the opposite. The chances of someone coming up with something nontrivial that is more secure than SSL on their own are practically zero. Inventing your own cryptosystem is a sure-fire way to end up with something insecure. Don't do it.

To the original asker:

Calling SHA-512 (a cryptographically secure hash) "encryption" is your first clue that you need to either 1) calm down, learn about moderm crypto, about what all of those funky acronyms and bit sizes mean in practice, or 2) hire someone who does. There is no "shortcut". If you plan to use SSL, at the very least you need to know the difference between a cipher and a hash, and some vital information about the different choices that you can make.

And please, please, please don't invent workarounds, hacks, wrappers, tricks, or anything else on top of SSL or any other cryptosystem, like that multiple stream thing (and don't even think about implementing your own from scratch). These systems were (hopefully) designed by experts in cryptography who know the implications of their design decisions, which can be devastating for security if done wrong. They don't need wrappers or workarounds to stay secure, and they certainly don't need to be reinvented. "Shotgun cryptography" (throw every buzzword and algorithm in there, because more bits and more layers is more secure!!1) is exactly what made the PS3 a cryptographic laughingstock and gave everyone Sony's private keys. Don't make that kind of mistake. SSL works just fine as is, and you can almost certainly make it do whatever you actually need without having to hack around it.

I could write a few lines attempting to answer your questions about SHA-512, the SHA-1 attacks, etc., but I won't, because the questions are wrong to begin with. Start by understanding what you're asking first, then you'll be able to ask relevant questions. You don't need blind instructions that are ultimately going to lead you somewhere without really knowing where you're going; what you need to do is get a map and figure out where you are and where you want to go first.

Re:Calm down and read up (0)

Anonymous Coward | more than 3 years ago | (#36340136)

"If you plan to use SSL, at the very least you need to know the difference between a cipher and a hash, and some vital information about the different choices that you can make."

Exactly what I was thinking, and the slashdot article itself is what seems to confuse the two. When I read that, I was like, huh?????

Re:Calm down and read up (2)

iluvcapra (782887) | more than 3 years ago | (#36340138)

And please, please, please don't invent workarounds, hacks, wrappers, tricks, or anything else on top of SSL or any other cryptosystem

Notable exception: salt your inputs to hashing algorithms when recording passwords and other data that can be attacked with rainbow tables.

Re:Calm down and read up (4, Informative)

marcansoft (727665) | more than 3 years ago | (#36340216)

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:Calm down and read up (2, Informative)

Anonymous Coward | more than 3 years ago | (#36340498)

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:Calm down and read up (1)

avxo (861854) | more than 3 years ago | (#36340566)

Nonsense. A simple, properly implemented salted hash is perfectly adequate for the vast majority of sites, provided you use large (at least 32 bit and preferably 64 bit) random salts, and a cryptographically secure hash algorithm (although I would avoid MD5).

00894983a50dc526-0e71bd5a380617a402bd24c6be3e7a7f2dd06109

This is salted password, hashed with SHA1. The salt is the part of the data before the dash. Please show me how I lost?

Re:Calm down and read up (0)

Anonymous Coward | more than 3 years ago | (#36340638)

by using Th3_g4m3 as your password

Re:Calm down and read up (0)

Anonymous Coward | more than 3 years ago | (#36340708)

I'm not going to try to figure out whether you've done it correctly or not, but I will say that just salting your input data without understanding how the hash algorithm works is a recipe for being insecure. For example, do you know whether the random salt should be appended or prepended to the hashed data? One of those two options can result in an insecure hash. A secure solution should also take into account the block size of the hash algorithm being used when determining the size of the random salt. If you don't understand the hashing algorithm you're using well enough to understand why these are considerations and how you should adjust your solution accordingly, you should probably choose something built by crypto experts.

No one is saying that it's impossible to come up with a secure solution on your own...the standard solutions use the same underlying algorithms, so it is possible. But when it comes to security, it's important to not take chances. Choosing one of the off-the-shelf solutions saves you from having to understand the intricacies of the hashing algorithm that you're using.

Re:Calm down and read up (0)

Anonymous Coward | more than 3 years ago | (#36340816)

Just to clarify the parent's relevance to the grandparent post: the PBKDF2 standard includes salting (as well as key stretching). So salting is still a good idea - but you should be using a standard function for it, rather than rolling your own.

Re:Calm down and read up (-1)

Anonymous Coward | more than 3 years ago | (#36340202)

So the long of the short is. You know everything about cryptosystems, and are willing to tell everyone you know about it. But, in the end, just ended up babbling and not offering anything really constructive to use.

Quit Bogarting my bandwidth.

Re:Calm down and read up (1)

Hypoon (1095383) | more than 3 years ago | (#36340234)

I couldn't say that better myself. The only comment I would like to add is that there may be some clever people out there who might be able to devise a simple encryption algorithm that may be stronger than SSL, but I'd bet they have a degree in mathematics rather than computer science, if you know what I mean. Check out the Vernam cipher, for example. Simple, yet perfectly secure (in theory, implementations may vary). I don't know what education Gilbert Vernam had, but in 1917 I doubt it was in computer science.

Re:Calm down and read up (1)

NotQuiteReal (608241) | more than 3 years ago | (#36340276)

As I understand it, the Vernam cipher is basically a OTP, which, while cryptographically "perfect", as you say, the implementation is a bit hairy...

Re:Here we go (3, Insightful)

Kenja (541830) | more than 3 years ago | (#36340100)

If you are working on something worth stealing, then it may also be worth hitting you with a wrench till you give up the password.

Re:Here we go (5, Interesting)

Hypoon (1095383) | more than 3 years ago | (#36340248)

If you're securing something like THAT, it's very sensible to use algorithms that permit decoys using one key and hiding the real data under an alternative key. Truecrypt does this, for example.

Re:Here we go (1)

Nursie (632944) | more than 3 years ago | (#36340542)

This is a good reason for session keys and Diffie-Hellman style key exchange. Using those there is no way to decrypt a captured datastream afterwards (assuming each end lives up to their end of the bargain and discards key data at connection end).

this doesn't mean you won't still get a wrench to the face, but SSL has done kit's job by then ;)

Re:Here we go (3, Interesting)

Opportunist (166417) | more than 3 years ago | (#36340118)

I'd even say IF this isn't just tinker-toying with security and trying to find something cool and nice to put together, go with a pro: Hire someone or buy a solution that suits your needs.

The reason is simple: Security is the one thing you can't really test sensibly yourself whether it's doing its job. For a server, you can easily check whether it's working; Can you connect, can you see what you're supposed to see, does everything run as it should, etc. Security? Until someone tries to break it, you'll never know for sure whether it was set up correctly.

I've seen it time and again in audits, companies (even rather well known ones) that considered themselves "secure" because they hashed out some kind of security system, only to see it crumble under the first few kicks I gave it. Why didn't anyone notice, why wasn't it discovered earlier? Because they didn't know what they were doing, and because they were lucky enough that no "bad" people tried it before they called us.

Allow me to add that security is not only a matter of the algorithm used, what also matters is how it is implemented and how the system handles it. A metaphor I love to use is this: The best, most stable security steel door is useless if your walls are made out of paper. For reference, play Monkey Island.

Re:Here we go (1)

chrispix (624431) | more than 3 years ago | (#36340436)

+1 for Monkey Island Reference

Re:Here we go (1)

Opportunist (166417) | more than 3 years ago | (#36340886)

Seriously, the cannibals in MI and their increasingly secure door is a perfect example for the way some companies treat security. Whenever the need arises that "more security" is required (hardly ever, sadly, security is mostly dictated by the law, not by internal pressure), the steel door gets bolstered, often to the point where normal operation is no longer feasible, the nobody ponders the fact that an invader doesn't care whether the "house" remains in one piece, he'll simply come through the wall. Allow me to illustrate by an example of an audit I had a while ago. I'll not name the company nor the actual exploit that could be used, but the dialog went something like this:

Me: (illustrating how an attack could be executed)
CISO: But that would trash the server.
Me: Yes.
CISO (leaning back): Then you cannot do it, the contract states clearly that you must not cause damages.
Me: Yes, but an attacker wouldn't care.
CISO: Did you do it?
Me: Of course not, as you said, our contract forbids...
CISO: Then how can you be sure?
Me: I checked for (a certain response to a certain challenge, it was more complicated than that but let's keep it at that).
CISO: You didn't prove that it is possible.
Me: If your door's made of plywood, I needn't kick it in to know that I can.

And so on.
I can understand that audits have to be noninvasive and must not interrupt normal work, I'm there to aid, not to damage. Unfortunately it's not always simply possible to recreate the live system in an audit environment and the audit has to be done on the production system (not something that's easy on your nerves, mind you), and of course that system must not take damage, but it's amazing how hard it is to get it through the skull of a C-level that someone breaking in doesn't care whether you can continue doing business.

Re:Here we go (1)

Kral_Blbec (1201285) | more than 3 years ago | (#36340124)

you'll be playing with yourself!

Whats wrong with that?

Re:Here we go (1)

buchner.johannes (1139593) | more than 3 years ago | (#36340126)

SHA-1 can be broken for document hashing. Use SHA-512 there. Also for encryption.
For password hashing, SHA-1 is sufficient, although there is no harm in using SHA-512. The reason SHA-1 is not broken here is that the hash (or seed) is not known to the attacker so he can not forge a cleartext with the same hash. This is why it is different from document hashing / encryption.
There is no reason to use MD5 anymore, The SHA-ciphers are superior.

Re:Here we go (2)

syousef (465911) | more than 3 years ago | (#36340454)

There is no reason to use MD5 anymore, The SHA-ciphers are superior.

For web site security, you're right.

It's still useful as a checksum algorithm. I use it on my photos to determine if software has messed with the metadata. Clearly we're not talking about a security application here.

Re:Here we go (1)

node 3 (115640) | more than 3 years ago | (#36340704)

you really need to bring someone with experience onto the team.

That's essentially what he's doing.

Same issue (1)

afterthought (179161) | more than 3 years ago | (#36339954)

Good question. I am in the same boat. I setup a home VPN and went through the same thought process in generating keys.

SHA-256 is enough (1)

Anonymous Coward | more than 3 years ago | (#36339964)

SHA-256 is fine. Any bugs in SHA-224/256/384/512 will likely be structural and if a bug is found it'll probably break of all of them.

Nothing wrong with using SHA-512, but it's not buying you 2^256 times extra security.

Re:SHA-256 is enough (5, Interesting)

Bloodwine77 (913355) | more than 3 years ago | (#36340272)

I use SSHA-256 (salted/seeded SHA-256). I haven't even looked at going to 512.

One thing I do, though, is store a prefix to all my hashes denoting the algorithm used. That way if anything better comes along down the road I can start using the better algorithm for new accounts and password changes and will hash user input during login based upon that prefix. That way legacy passwords do not break.

I do not know if I weaken my security by prefixing the hash with something like "{SSHA256}", but I am not one to rely on obscurity for security.

Re:SHA-256 is enough (1)

definate (876684) | more than 3 years ago | (#36340570)

I don't think it would, since if they've got access to that, they've probably got access to the code, which will show what it is anyway.

Also, I think that's a good idea. Something I'll take on board in the future, me thinks.

Re:SHA-256 is enough (1)

SanityInAnarchy (655584) | more than 3 years ago | (#36340940)

Out of curiosity, is there a reason you'd store that as a prefix and not as a separate field?

Re:SHA-256 is enough (1)

leuk_he (194174) | more than 3 years ago | (#36341054)

>

Nothing wrong with using SHA-512, but it's not buying you 2^256 times extra security.

No, If in brute force(not feasable?) it is giving you only 2^128 times extra security.

THE SOLE ANSWER (2, Informative)

Anonymous Coward | more than 3 years ago | (#36339970)

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!

Re:THE SOLE ANSWER (0)

Anonymous Coward | more than 3 years ago | (#36340494)

"Problem solved" is an overstatement.

Applied Cryptography is a good book (perhaps I should say "was a good book" as it's getting dated), but it has a pretty bad rep in the crypto community. It teaches you enough to be dangerous, but (at least on a first reading) not quite enough to securely design a protocol or other system that uses cryptography, and not enough of how to evaluate whether such a design is secure. Too many people read it, then go design something completely broken. Use of Blowfish (a fine cipher, by the way) is a classic symptom of this.

I'm not sure what the best book on the subject is, though. I've heard good things and bad things about Schneier and Ferguson's "Practical Cryptography", and their chapter on Fortuna is good. Boneh and Shoup's "A Graduate Course in Applied Cryptography" will probably be good if they ever finish it. I'm not really familiar with other textbooks.

Re:THE SOLE ANSWER (4, Interesting)

vadim_t (324782) | more than 3 years ago | (#36340950)

Bruce Scheneir once said "A colleague once told me that the world was full of bad security systems designed by people who read Applied Cryptography". See more on that in the preface to Secrets and Lies [schneier.com]

A single book, no matter how good, doesn't make one an expert. Now if you're interested in crypto, by all means get it. I have it and I think it's a good one. But it makes oh so tempting to start coding something without really understanding what are you doing and why. Be careful with that.

Now, despite the excellent intro, I think Secrets and Lies is of more value to normal people than geeks. I think it's a fine book, but to anybody who already is interested in security and crypto topics a very large part of it is going to come off as blindingly obvious. It's a good book to have to lend to non-technical people though.

Ask Sony (2, Funny)

Anonymous Coward | more than 3 years ago | (#36339972)

Ask Sony what they used, then find something 10x stronger.

Re:Ask Sony (2)

c0d3g33k (102699) | more than 3 years ago | (#36340048)

Bad advice. 10 x 0 = 0

Even ROT-13 would be better than what Sony was using.

Re:Ask Sony (5, Insightful)

marcansoft (727665) | more than 3 years ago | (#36340088)

Sony was using pretty much every modern cryptographic algorithm in every possible way.
All at once.
And that is why they failed miserably.

People who think cryptosystems are made of buzzwords like AES and SHA and ECDSA and numbers of bits are doomed to create insecure pieces of crap. To make a secure cryptosystem you only need a couple good algorithms and, most importantly, one or more professional cryptographers to design the overall system for you. Or do the sane thing, and use an existing cryptosystem correctly instead of even thinking about rolling your own.

Re:Ask Sony (2, Funny)

youn (1516637) | more than 3 years ago | (#36340168)

Whatever you do, avoid ROT-13 ten times :)

Re:Ask Sony (0)

davester666 (731373) | more than 3 years ago | (#36340404)

Yes, in general, avoid applying ROT-13 any multiple of 2 times to keep your data secure.

SHA isn't encryption. (5, Informative)

grub (11606) | more than 3 years ago | (#36339982)

SHA-2 (of which SHA-512 is a part) isn't encryption, it's a hash function.

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:SHA isn't encryption. (5, Informative)

Marillion (33728) | more than 3 years ago | (#36340074)

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:SHA isn't encryption. (3, Informative)

Anonymous Coward | more than 3 years ago | (#36340882)

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

Yeah, OpenSLL is all fine and good for security (1, Funny)

scourfish (573542) | more than 3 years ago | (#36339988)

However I'm told that OpenSSL works a bit better.

go home (0)

Anonymous Coward | more than 3 years ago | (#36339992)

I don't know much [...]

QFT. You won't have a secure website until you pay someone to handle this for you.

SHA-1 is fine, but go for SHA-512 (1)

iYk6 (1425255) | more than 3 years ago | (#36339996)

I don't know much about SHA, but I figure that if you're going to go to the trouble of setting up SSL, you may as well go for the best you can get, right?

If that's the way you feel, then yes, go for SHA-512. I think it is the heaviest NSA blessed hashing algorithm.

I've read about how SHA-1 was 'broken', but from what I can tell it still takes many hours.

Replace "hours" with "centuries". Or maybe more. Nobody has ever created a SHA-1 collision.

What is the practical risk to the real internet from this capability?

None for the near future. And CA certs expire after a year.

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?

That would be ridiculous. There are valid concerns about SSL, but only regarding trusting CAs. The problem isn't the encryption itself, but the fact that you require a trusted avenue to exchange keys, and the CAs can't necessarily be trusted. The technical merits of AES and RSA and the SHA families are good.

Re:SHA-1 is fine, but go for SHA-512 (3, Insightful)

Secret Rabbit (914973) | more than 3 years ago | (#36340066)

"""
Replace "hours" with "centuries". Or maybe more. Nobody has ever created a SHA-1 collision.
"""

There is however a theoretical attack (2^{52}) discovered in 2009 (better than prior breaks). It has been recommended to go for SHA-256 or SHA-512 until the next hashing algorithm standard comes out. In fact, this recommendation is years old.

The SHA family is coming to an end; it's just a matter of time. And I would suspect that we'll see that day sooner rather than later (read: decades).

Re:SHA-1 is fine, but go for SHA-512 (2)

GrievousMistake (880829) | more than 3 years ago | (#36340342)

The SHA family is coming to an end; it's just a matter of time.

An end, but also a beginning; the final selection of the hash algorithm that will become SHA-3 is scheduled for 2012. [nist.gov]

The current candidates are all faster than SHA-1 on platforms without hardware acceleration, even with the added security. Unless a weakness is discovered after the standardization, SHA-3 should eventually replace SHA-1 in all security critical applications.

You're right to be concerned. (5, Funny)

Anonymous Coward | more than 3 years ago | (#36340002)

SHA, which stands for Simply Hard Enough, has always been considered the successor to MD5.

As the numbers suggest, SHA1 5). SHA512 is formidable indeed, and no respectable website will go with anything less than SHA500.

However, there is always a balance between security and convenience, and it's important that you discover this for yourself and your users. If, for example, you find yourself with more than 500 users, you may want to bump up to SHA1024 to make sure you have enough room. Better yet, look into elliptic-curve algorithms that can be stretched to fit.

Also consider using Python instead of PHP.

Re:You're right to be concerned. (1)

Confusador (1783468) | more than 3 years ago | (#36340318)

Simply Hard Anough?

Re:You're right to be concerned. (0)

Anonymous Coward | more than 3 years ago | (#36340540)

Simply Hard Anough?

AKA wush

Re:You're right to be concerned. (1)

Terrasque (796014) | more than 3 years ago | (#36340584)

Wait, what? What the hell? That is just completely wrong. You're completely out of touch with the world. You're, in fact, crazy.

Everyone, EVERYONE! knows that hand crafted assembly is the only way to create a web page.

Re:You're right to be concerned. (1)

PwnzerDragoon (2014464) | more than 3 years ago | (#36340856)

Don't be silly. True experts use butterflies, released at the exact right moment to deflect cosmic rays coming in from space, intersecting the network cable and modifying the bits traveling through the router to the desired HTML.

Re:You're right to be concerned. (1)

Terrasque (796014) | more than 3 years ago | (#36340964)

Butterflies? How quaint.

I just tweaked the universal constant at the start of creation so this comment would spontaneously appear by itself.

Re:You're right to be concerned. (0)

Anonymous Coward | more than 3 years ago | (#36340972)

You mean Secure Hash Algorithm. I think you are getting confused with PGP.

Additional info (1)

MikeDawg (721537) | more than 3 years ago | (#36340008)

As grub stated, SHA-512 isn't the encryption, that is part of the hashing. I would generally be more particular about the encryption algorithm used. Make sure you use something 128+ bit (preferably 256+ bit). Some functions, especially those covered from RFC 3268 would be preferred.

Don't worry (1)

shutdown -p now (807394) | more than 3 years ago | (#36340012)

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

That's precisely how it works already, except that it's not just a public/private pair. Public key encryption is fairly slow, so instead of using it for the entire connection, the parties generate symmetric keys for a block cypher to handle the stream itself, and exchange them during handshake, those keys themselves encrypted by their (also generated) private keys.

SHA-512 is not "encryption" at all, it's a cryptographic hash function. As such, it has no bearing on the security of your data (i.e. SHA512 certificate does not make it harder for someone who intercepted your encrypted stream to decrypt it), but it makes MITM attack slightly less probable. In practice, even with SHA256, it is unbreakable for all practical purposes.

A few things (5, Insightful)

betterunixthanunix (980855) | more than 3 years ago | (#36340034)

SHA-512 encryption

SHA-512 is a hash function, not a cipher.

if you're going to go to the trouble (or expense) of setting up SSL

What trouble and expense? TLS (SSL is obsolete) is only expensive if you need to get your certificates signed by a commercial CA i.e. if you are interacting with random people who are not affiliated with you or your organization. If you are only deploying TLS for internal purposes, just maintain your own internal CA and deploy your internal signing key to all of your organization's systems.

Also, what would be the minimum level of encryption required for, say, online banking?

AES-128 is perfectly reasonable here; it has a sufficient security margin for online banking and is nowhere near the weakest link in the security chain. If you happen to have extremely sensitive information and you need >30 years security, a more conservative cipher like MARS or Twofish might be appropriate (given the attacks on the AES-256 key schedule; in any case, 256 bit ciphers are recommended for >30 year security last I checked). Really though, any of the AES finalists are fine.

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?

CAs should not be trusted; the CA system is based on a typically bad assumption, which is that there are enough users who are aware of what it means for a CA to be untrustworthy to force the CAs to exercise appropriate security policies (or lose their business). Since only a tiny minority of Internet users even know what a CA is, and only a tiny minority of those people know how often CAs issue signatures for fraudulent certificates, the assumption does not hold. CAs are not trustworthy and should not be trusted.

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

You should take more time to read about cryptography. Confusing a hash function with a cipher is not a good indication that you have the minimum level of knowledge needed to understand what Schneier is saying.

Re:A few things (1)

sco08y (615665) | more than 3 years ago | (#36340682)

What trouble and expense? TLS (SSL is obsolete) is only expensive if you need to get your certificates signed by a commercial CA i.e. if you are interacting with random people who are not affiliated with you or your organization. If you are only deploying TLS for internal purposes, just maintain your own internal CA and deploy your internal signing key to all of your organization's systems.

Having your own CA raises the distribution problem, which is different or at least flaky for virtually every browser / OS combination, and you're still running on what may as well be a compromised system so TLS is irrelevant since the attacker can just root the system and grab keypresses.

The best solution short of buying laptops and putting epoxy in the ports is mastering a Knoppix CD. You can get a kiosk-style browser [mozdev.org] loaded with only your org's CA and a TLS client certificate. If you can distribute your own CA certs, you may as well also distribute client certs. You can disable storage drivers except for ramFS. You can block everything but 443 outgoing. You can verify your server before launching the browser.

You now have a simple procedure to force users to access your site properly. There is no possibility of a MITM by creating a fake site from a misspelling, and rather than clicking through security warnings, you can display a dialog telling them that something is seriously wrong and who they need to call, with no way of just clicking through the warnings.

You have two factor authentication; the client cert on the CD and password are separate factors. You have honest to god protection from CA fraud since only the CA you created is loaded. The only ways (I know of...) to compromise this setup are a hardware attack, user completely bypassing you by booting in a VM, or a rootkit in BIOS [arstechnica.com] or the hypervisor [root.org] .

Recommended keylengths/algorithms (4, Informative)

Herrieman (167396) | more than 3 years ago | (#36340042)

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

Rainbow tables? (1)

CPE1704TKS (995414) | more than 3 years ago | (#36340050)

On a similar note to this, since hashing can be defeated with rainbow tables, does anyone have any authoritative information on the state of rainbow table cracking? I just from a previous post that lulzboat cracked their passwords using rainbow tables, and looking through the password file, the passwords were substantially more complex than what I would use. Are rainbow tables at the state now where using special characters and numbers aren't good enough anymore? How long do we need to make our passwords? Does anyone like Bruce Schneier give guidance on this now?

Re:Rainbow tables? (1)

pthisis (27352) | more than 3 years ago | (#36340116)

User-chosen passwords are unlikely to be secure. One proposed solution is to generate secure keys for each user (a la ssh); there is then a problem of key distribution and of how to remember/carry and enter a key, which is itself nontrivial (lots of 2-factor authentication systems at least partially address this problem).

There are other possible solutions as well, but but if you're really paranoid then you absolutely don't want user-chosen passwords in any super-secure application. A major problem, of course, is properly weighing the need for security against convenience and getting the job done (make things too tough on the user and they'll work outside the system or find ways of gaming it that make things less secure than they were to begin with).

Re:Rainbow tables? (2)

Opportunist (166417) | more than 3 years ago | (#36340146)

I like Bruce, if that's enough. :)

And if you take your security with a grain of salt [wikipedia.org] they lose a lot of their byte. (ok, ok, I'll stop with the puns)

Re:Rainbow tables? (1)

BlueParrot (965239) | more than 3 years ago | (#36340200)

Salt makes it a non-issue when used correctly.

Re:Rainbow tables? (1)

swillden (191260) | more than 3 years ago | (#36340338)

Salt makes it a non-issue when used correctly.

Sufficient salt defeats rainbow tables, but doesn't change the fact that most user-chosen passwords are crackable without tremendous effort.

Re:Rainbow tables? (5, Informative)

Eil (82413) | more than 3 years ago | (#36340324)

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:Rainbow tables? (2)

VortexCortex (1117377) | more than 3 years ago | (#36340500)

Hmmm... well, most hash algorithms are made to be fast. This is unfortunately the wrong thing to do for passwords. The SHA family of algorithms process many megabytes of data per second -- they have to, they are general purpose. The hash algorithm that I use for passwords generates 4 per second on a fast server. The CPU strain only occurs during authentication, and those are time delayed anyhow (to avoid timing/side channel attacks). For a brute force attack this means cracking even one password is significantly more difficult.

Instead of the SHA family use a function that is computationally intensive AND RAM intensive (like bcrypt). Any hash algo that requires a significant amount of memory to operate is much less feasible to run in parallel. The SHA family of hashes require little memory even when key stretching is used. Ergo, the number of hashes that can be computed at once relys primarily on your processing power. Even a 4K pool significantly increases the memory requirements of a hash -- effectively tying the hash to RAM size as well as CPU/GPU power. System memory to GPU is a slow transfer, GPUs typically have less RAM than main system memory -- use this to your advantage, there is really no reason not to.

Also note: do not use a single salt for every hash in the DB -- use a different salt for each PW. This completely defeats "Imma build a rainbow table" based attacks.

Re:Rainbow tables? (4, Informative)

avxo (861854) | more than 3 years ago | (#36340538)

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.

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:Rainbow tables? (1)

Unequivocal (155957) | more than 3 years ago | (#36340600)

With salts in place, they wouldn't be creating "their own specialized rainbow table for the job." They would have to create N rainbow tables - one for each salt value. That's the point. You don't have one salt for your whole table, you should have one salt per hash. This makes it much more difficult to brute force the entire set of passwords at once (which is the point of a rainbow table).

I'm not saying you don't know this, but I wanted to clear this up for anyone who might read your statement and get confused.

Re:Rainbow tables? (0)

Anonymous Coward | more than 3 years ago | (#36341070)

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

Stupid detected. The idea behind salts is that you have a different one per password; in essence making the concepts of rainbow tables pointless.

Rainbow tables work because you *don't* do them per password - you do them once per setup. Salts (done properly) require you to create one per key - IE, just plain brute forcing the keys is faster.

And yes, you do store them in plaintext in the database.

Re:Rainbow tables? (1)

Kjella (173770) | more than 3 years ago | (#36341084)

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.

If you can't reuse the table, it's not a rainbow table. Then it's simply a brute force attack.

Re:Rainbow tables? (2)

sco08y (615665) | more than 3 years ago | (#36340370)

Salting has been around since the 70s and it makes rainbow tables completely useless. If I add salt, I'm now storing H(salt & pass), where & is binary concatenation. Now if my salt is, say, 16 bits the rainbow table be 65536 as large and take 65536 times as long to generate. 32 bits of salt makes *each* password require 4 billion entries.

So the only reason anyone is being cracked by using rainbow tables is that they are making well known mistakes trying to solve problems that have been solved thirty years ago.

You must store a separate, completely random salt for each stored hash. There should be a SALT column in your database along with USERNAME and HASHED_PASSWORD. The salt is not supposed to be a secret! The salt is to force the attacker to attack each hash individually and to make rainbow tables infeasible. Salting does not actually make any individual password harder to break, it makes it harder to attack *groups* of passwords.

Do not store one salt for the whole system. Do not use the salt as a key to a cipher on the hash, e.g. C(key=salt, H(password)) does not work, nor does H(password) XOR salt. Do verify that the salts really are random. Do use a reliable RNG, like /dev/urandom or Java's crypto PRNG.

The next item is to use a hash function that is designed for password hashing. MD5, the SHA family, etc., are fast hashes, designed to digest huge amounts of data quickly and prevent collisions, accidental or deliberate. These have important security applications, but they are not appropriate for hashing passwords.

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. Even assuming it's some years down the road and they have specialized hardware, you can have passwords that are a reasonable length and still infeasible to break.

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.

And lastly, when it comes time to upgrading your login procedures whether hardware or software, you aren't going to know anyone's password. If you change, say, the hash or the stretching parameter or the salt length, you'll need users to go through a change password screen! That means you have to design your application to handle users having different algorithms with different parameters. All this should really require is adding HASH_FUNC and STRETCH_FACTOR columns.

Re:Rainbow tables? (3, Informative)

SmilingBoy (686281) | more than 3 years ago | (#36340924)

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]

Re:Rainbow tables? (0)

Anonymous Coward | more than 3 years ago | (#36340954)

...does anyone have any authoritative information on the state of rainbow table cracking?

it's dire
word around the net is a attach vector
double rainbow tables

Re:Rainbow tables? (0)

Anonymous Coward | more than 3 years ago | (#36341120)

I think you misunderstand how rainbow tables work.
The table is generated by creating passwords and hashing them until all possible hash have one matching known password.
Then, lookup a hash to crask in your database, read the password which ended up with that hash, done.
So the password you read is one wich has the same hash as user's password. It's not necessarily the exact same password, but the login system cannot tell the difference anyway, which is the whole point.

What if you're a nigger? (-1)

Anonymous Coward | more than 3 years ago | (#36340080)

You know what I mean bitches.

Re:What if you're a nigger? (0)

Anonymous Coward | more than 3 years ago | (#36340872)

then give up because you're too stupid to understand crypto.

Stream Cipher (1)

joek1010 (980753) | more than 3 years ago | (#36340122)

Would a sort of rolling key be a possible next step,

So, a stream cipher?

Windows XP is the bottleneck (1)

MetricT (128876) | more than 3 years ago | (#36340174)

Windows XP's crypto stack doesn't support any hash stronger than SHA-1, so if you have to worry about XP users, that's a big constraint.

Note that's for browsers/apps that use Windows native crypto stack. Browsers that include their own SSL implementation (Firefox and I believe Chrome too) can use whatever.

Don't rely on a hash, and not on a single defense (5, Interesting)

Opportunist (166417) | more than 3 years ago | (#36340214)

First of all, congratulations that you try to take security serious. Even though what I can tell from your questions is that any answer we could give you here would leave you with even more questions and very little enlightenment. A few very good books have already been recommended, and I'd recommend the same that was already said: Go read. Don't implement a security scheme, don't even plan it. Go read the books, teach yourself what's necessary to actually understand what you're doing and then go and plan your security.

On the danger of sounding patronizing, but that's simply as it is. It doesn't matter if you use MD5 or SHA-512 before you understand how to use them in a secure way. I gave the parallel of the steel door with paper walls above, so I won't repeat it, but security is always the security of the weakest part. If someone can bypass your secure entrance, the whole security is voided. I've seen too many rely on a "strong" hash only to see that the algo used was weak and allowed other ways of attacking. I can easily recommend anything Bruce Schneier wrote, he sure is one of the security gurus of our times and his books aren't as dry as many others on the subject. I'd start with the already mentioned "Applied Cryptography".

While we're at it, something I would also highly recommend is to implement a "fail well" [wikipedia.org] strategy. Another thing I've seen many, many times ignored, and it's maybe the easiest way to improve security in a system, especially if the person responsible for it is not a security guru himself. The general idea is that, if (ok, when) security gets broken, the system should not instantly be fully accessible to the perpetrator. Try to compartmentize and contain the damage. Many times it is quite easy to do but ignored for simplicity's sake, like using the same database user (with admin privileges, of course) for different databases or using the same credentials for different systems. It's, IMO, the first step to more security and it can be easily implemented without a lot of knowledge of security because most of it is in the administrative field, not the technical one.

I'm not sure I understand but here goes (1)

WaffleMonster (969671) | more than 3 years ago | (#36340232)

Reading between the lines I'm assuming SHA-512 is the signature algorithm to sign the key and the author is just confused in thinking it effects encryption when it just applies to the effectiveness of chain validation and therefore the systems resistance to Active-MITM.

If this assumption is correct the right answer is to use whatever algorithm the signer above you used as you are limited by them as the weakest link. You gain nothing by rolling the dice with a dependancy on multiple signature algorithms.

Re:I'm not sure I understand but here goes (1)

Unequivocal (155957) | more than 3 years ago | (#36340610)

SHA-512 is a one-way hashing algorithm, not a signing algorithm. It's main purpose (for passwords) is to allow you to store a representation of the password which can be compared with a future submission of the same password, to see if they are in fact the same. You can create a kind of signatures with such a hashing algorithm but what most people think of as "digital signatures" involves public/private key signatures. These signatures allow you to verify (roughly) "the person who controls the private key associated with this public key, is the same person who authored this message." PGP and X.509 are good places to read up on digital signatures.

Encryption strength isn't important (1)

iceco2 (703132) | more than 3 years ago | (#36340282)

Even though certain attacks are available against some hash algorithms, I am unaware of anyone ever successfully attacking an SSL protected server in the wild by attacking the encryption, head on, not the hash function or the public key encryption or the symmetrical key encryption.
However the main issue is as you mentioned trust, which in this case is obtained with certificates.
When I browse to an SSL enabled web site over https, I trust the web site operator, I trust the company who signed the certificate proving he is who he says he is,
and I trust my browser to convey this information properly and give a good list of CA's. (I am ignoring non SSL related trust issues).
Note it is common for most site's certificate to only sign the server address and not the company name, note that this doesn't really tell you much about who is running the site.

SLL! HASH! ENCRYPTION! !!!1! (0)

zindorsky (710179) | more than 3 years ago | (#36340350)

Oh. My. God.
If you do not know the difference between a hash algorithm and a cipher algorithm, then STEP AWAY FROM THE SECURITY!
DIY crypto is a good idea like DIY brain surgery is.
Rolling your own crypto system is like rolling your own mercenary army. It feels really awesome and at first it's all running around in the woods with your camo and guns and FUCK YEAH WE RULE. But then you meet reality and it's all OMFG WE GOT PWNED. and ALSO WE'RE DEAD

Re:SLL! HASH! ENCRYPTION! !!!1! (1)

jensend (71114) | more than 3 years ago | (#36340546)

I have to wonder whether the editors got trolled. Even beyond confusing a hash with a cipher, a number of things about the post seem to suggest it might have been crafted feigning total ignorance as a joke.

Re:SLL! HASH! ENCRYPTION! !!!1! (1)

White Flame (1074973) | more than 3 years ago | (#36340612)

And I in turn wonder if I should be mad at the editors for letting a garbage story like this through, or agree with them that a person like this needs to be publicly thrown to the wolves.

Sir, step away from the key generator (4, Insightful)

The Famous Brett Wat (12688) | more than 3 years ago | (#36340374)

It sounds like you have an oversimplified idea of "security". Security is not a scalar property that increases with the number of bits in a hash or key. Security depends on your threats, and it's possible to be reasonably secure without the addition of any cryptography at all (although this will be the exception rather than the rule). Let's discuss security threats for a moment.

One threat is that of the eavesdropper. This is the classic threat from online shopping: "OMG, some hacker will see my CC number when I submit it to the shop." This threat can be defeated with encryption -- sort of. You don't need any kind of "certificate" to effect this level of security: you just need a key-sharing technique which defeats a passive eavesdropper. SSL/TLS has this, and it's independent of the number of bits in any hash, since that's a different part of the security puzzle.

Now the bad news: your CC number will still be compromised, despite your super-strong encryption. If you're using a malware-prone OS, then any malware on your system makes an end-run around the encryption. If you're using a public terminal, you need to be sure that it doesn't have keyloggers installed on it, either hardware or software. And even if your client-end computer isn't compromised, your CC number will be stored in a PCI-compliant database, where "PCI-compliant" means "this kind of thing gets compromised several times a week, leaking X thousand CC numbers in one go" for large values of X.

Encryption of the channel, in this case, provides security against the least convenient and least likely attack. You should probably encrypt the channel anyhow, but you simply can not achieve security, because most of the real threats lie outside your control.

Another threat is the impostor. This is where someone gets lured into going to BadGuy website which is dressed up as GoodGuy website. This is where public key certificates are supposed to help, and that's where you need to worry about how many bits there are in the hash. But if you're worried about the number of bits in the hash, or the kind of hash algorithm, then you're probably fussing over the smallest of problems. Certificates have a very limited lifespan, and so long as your current one isn't at the bottom of the pile, strength-wise, it's probably satisfactory for now.

The real problems that you face in this case are usually beyond your control. You can't create a self-signed certificate in general, because every browser on earth will throw up a warning (that 99% of users won't understand anyway) saying that the certificate can not be verified. You don't want that: you want the browser to do the "I'm secure now" thing, whatever that happens to be, visually. So you'll need to pay up for a certificate. Unfortunately, your clients must then be smart enough to pick the difference between your website with its "I'm secure now" indicator, and an exact copy of that website which lacks this indicator at a different URL, or one that has an "I'm secure now" indicator which doesn't match your identity. How smart are your clients?

If you're a really important target (e.g. Gmail), you have much bigger worries. You ask, "Can I trust that my SSL provider hasn't been hacked (or at least snooped)?", but the problem is much worse than this: you need to trust that every issuer of certificates on Earth hasn't been compromised, which you can't, because some of them have. When any certificate issuer is compromised, it's possible that a fake certificate has been generated for your identity, and someone else can set up a server which validates itself as "secure" for your domain name. There are browser add-ons in some cases that will raise a red flag when a "valid but previously unseen" certificate is shown, but then you're asking for even greater security expertise on the part of your end users to diagnose the situation.

So, in summary, step away from the key-generation software, and go back to square one. Think about your threat model, and whether any of your crypto-magic will protect you better than the Maginot line protected France against invasion by the Germans. And if you're into Bruce Schneier, go pick up a copy of "Secrets and Lies". It will give you a much better education on the difference between cryptography and security than I've done here.

You need to use GoDaddy (0)

Anonymous Coward | more than 3 years ago | (#36340402)

They're secure, just read over their website. I mean they can't say it if it isn't true, right?

Re:You need to use GoDaddy (0)

Anonymous Coward | more than 3 years ago | (#36340914)

and they have danica.. she basically makes anything they say true.

You're in over your head (4, Insightful)

fluffy99 (870997) | more than 3 years ago | (#36340446)

As most folks here have pointed out already, you are in over your head. First, you need to understand that the strength of the hash used to setup an SSL session isn't necessarily an indicator of the strength of the SSL session encryption. Your concern about server power isn't warranted as the strength of the cert used to start up the SSL session is negligible. My advice is to stick to standard methods and don't try to get inventive. You have much bigger things to worry about that the strength of your SSL cert. Like making sure everything else is secure and that you're not subject to things like SQL injection or stolen cookies that result from shoddy programming.

so I created a certificate using OpenSSL for SHA-512 encryption

Great, so now your clients have no real way of verifying the authenticity of your web site. If you intend to deal with the public, get a certificate from a reputable provider that typical browsers already trust. Self-signing is a sure sign of an amateur and usually people don't trust a website when the browser keeps nagging them that the certificate is not trusted.

"Can I trust that my SSL provider hasn't been hacked (or at least snooped)?"

Another clue that you need help. There is no such thing as an SSL provider. There are providers that sign certificates intended for specific (or general) purposes. What you do with them is your problem.

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?

You don't. But keep in mind the risk of a compromised certificate is primarily the threat of someone else pretending to be you, such as a fake site or a man in the middle attack. If you're issuing certs to clients for authentication, the risk is that a compromised cert means someone else can pretend to be your client.

Algorythm is not the bottleneck. (1)

muxecoid (1061162) | more than 3 years ago | (#36340496)

As correctly noted in your post trust is the real bottleneck. Hacked CA is a risk. Man-machine interaction on the end user side is much greater weakness. User can be fooled by SSL strip. User can believe that "legitsite.ucvgsuivuis.cn" is your site if it provides valid certificate for "*.ucvgsuivuis.cn". Social engineering can be used to make user skip warnings by browser. If users authenticate with certificate hackers are more likely to get the certificate by social engineering than by exploiting crypto weakness.

Most times SSL is not the problem (2)

Bloem (528155) | more than 3 years ago | (#36340510)

IMHO SSL is often not the problem. Most websites/webapps are hacked through badly configured and unpatched servers or through programming errors in the site itself. If you're concerned about security, make sure that your website/webapplication/cms is secure. OWASP [owasp.org] is a good source for hints and tips. They even have a top-10 [owasp.org] for this stuff. So, if SHA-512 is you're only problem, you're doing just fine.

Too late (1)

drmofe (523606) | more than 3 years ago | (#36340664)

If you are asking on here at that level of naivete, you are probably already compromised.

Remember Ken Thompson C Compiler Backdoor (2)

Pepebuho (167300) | more than 3 years ago | (#36340780)

Ha, you want security and trust? Remember Ken Thompson's C Compiler Backdoor
Make sure you built your PC out of sillicon yourself! Otherwise, you have to rely on someone else's code:

ACM Classics: Reflections on trusting trust

http://cm.bell-labs.com/who/ken/trust.html

Re:Remember Ken Thompson C Compiler Backdoor (2, Funny)

maxwell demon (590494) | more than 3 years ago | (#36341152)

Ha, you want security and trust? Remember Ken Thompson's C Compiler Backdoor
Make sure you built your PC out of sillicon yourself! Otherwise, you have to rely on someone else's code:

ACM Classics: Reflections on trusting trust

http://cm.bell-labs.com/who/ken/trust.html

Well, building your computer from silicon yourself isn't enough. After all, how do you know the machines you used to fabricate your chips are not compromised? Maybe they don't produce exactly those chips which you designed? There's no way other than to build those machines yourself as well.

Oh, and don't make the mistake to use VHDL or similar to design your chips. Your VHDL compiler may be compromised, too. Only if you understand your chip down to the wire, you can be completely sure.

Well, provided that you can prove that you are not in the Matrix, that is. :-)

Deterrence (1)

mmmmbeer (107215) | more than 3 years ago | (#36340792)

All security is about deterrence. As long as you're making your systems a less desirable target than others, you're doing enough. (There are some exceptions, e.g. those that are targeted for political reasons, who are going to be targeted no matter what. This may not apply to those.) Consider a bank vault: the classic example of real world security. The doors of modern bank vaults are so secure that it's generally easier to go through the wall of the vault than to try to "hack" the door. Technically, that wall's a security hole; someone could break in through it. But even though it's possible for someone to tunnel through a wall, it never really happens, because it's just too much trouble. There are easier ways to make a dishonest living. Computer security is the same way. It doesn't matter whether it would take a day or a week or ten thousand years to break encryption; as long as it's enough trouble that it makes you a bad target, it's enough. It's like what they say about escaping a bear: you don't have to outrun the bear, you just have to outrun your friend.

TLS (0)

Anonymous Coward | more than 3 years ago | (#36341022)

TLS providers are well behind the cryptographic state-of-the-art: SHA-1 is now known to have serious flaws but it's the highest any of the mainstream certificate providers use or accept (to their credit they have finally dumped MD5, but SHA-1 will only get worse). It is, at the moment, not feasible for anyone to collide your certificate, although perfectly possible for someone to create two colliding certificates of their own (although at this time I still haven't seen any SHA-1 collisions actually produced).

Really they should be on SHA-256 or SHA-512 already, and preparing to migrate to the SHA-3 function when it is selected next year (my own money's on Skein, and it has such a nice, parallelisable native hash tree format that even if it doesn't get selected as SHA-3, I'm probably going to use it regardless as long as it doesn't get broken). It may be that they're simply waiting for that: plus it's still actually very rare to see a TLS 1.2 exchange in the wild, and you need TLS 1.2 to even actually rely on any hash functions that aren't SHA-1.

It would be nice to see an authenticated encryption mode as well, and the key exchange is slow enough that people like Google are coming out with unofficial shortcut extensions. Greater elliptic curve use would also be preferred but the ecdsa code in OpenSSL is not well tested (the b curves, it turns out, even had a timing attack, which is surprising because OpenSSL is normally one of the better libraries for resisting those).

I have no idea why it moves so slowly...

No such thing as "SHA-512 encryption"... (0)

Anonymous Coward | more than 3 years ago | (#36341052)

... so I have no idea what you're talking about. SHA-512 is a cryptographic hash function, not a form of encryption.

The only place a hash function is used in SSL certificates is to verify the certificate. The primary purpose of that is for the client to identify your server; it in no way affects the strength of the encryption.

Don't get me wrong, identifying your server is important, too.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?