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

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

Comments

Here we go

[Anonymous Coward]

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

[Anonymous Coward]

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

[Kenja]

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

[Opportunist]

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

[Kral_Blbec]

you'll be playing with yourself!

Whats wrong with that?

Re:Here we go

[buchner.johannes]

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

[Hypoon]

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

[Omnifarious]

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

[syousef]

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

[Profane MuthaFucka]

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.

Re:Here we go

[Nursie]

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

[node 3]

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

That's essentially what he's doing.

Re:Here we go

[_Shad0w_]

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

[Opportunist]

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

[Ihmhi]

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

[JoelKatz]

To be precise, there is no reason to use MD5 other than when you have to interoperate with something that uses MD5 and can't easily be changed or when you're already using it and it's good enough for your application. You're not using MD5 to verify your photos because it was a considered choice, you're using it because you have no particular reason to change it.

Re:Here we go

[Anonymous Coward]

The best, most stable security steel door is useless if your walls are made out of paper. For reference, play Monkey Island.

Thanks, I have been stuck in that room for 20 years. Now I can finally finish the game!

Re:Here we go

[julesh]

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.

You may as well use CRC32, though, which is just as useful for that application and much, much cheaper to compute.

Re:Here we go

[the 99th penguin]

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.

This is very true. Reminds me of a story someone told me once. He was going over to a secure datacenter his company was using to see for himself how they handled things. He got there and had to admit they seemed to actually know what they were doing. Until he felt a draft... One of the employees inside the center had decided it was a bit too hot in there and propped open a door to let air in. All it took was one person's bad decision to nullify everything else they had done. Remember people, weakest link...

Re:Here we go

[Anonymous Coward]

Slashdot editors must invent these questions just to keep things stirred up. Like car magazines: "Porsche or Corvette: which is really better?"

The article has give-aways, particularly "what is the minimum level of encryption needed, for, say, on-line banking?"

Nerds like these questions. "What is the minimum number of bits needed for good encryption, for, say, moving a billion dollars online?"
"How many terabytes of storage are in the machine room?" "What is the total bandwidth of, say, the entire Internet?"

It's why we all keep coming back here.

Re:Here we go

[s0litaire]

Think he's be best starting with Cryptography for Dummies: http://www.amazon.com/Cryptography-Dummies-Chey-Cobb/dp/0764541889

Then on to the other suggested books...

Re:Here we go

[TheRaven64]

There are defences against that sort of attack too. For example, only permitting logins from a physically secured terminal. You can then tell your abductors the password, but they can't use it unless they also compromise the physical security. You can add a layer to that requiring logins at specific times, so that if they don't compromise the physical security within one hour (for example) then the data is permanently erased. If they're willing to go to that much effort, then you're pretty much fucked whatever you do. No security system is 100% safe, the point is to make it more expensive to get the data than it's worth. My bank wouldn't last very long if the Chinese sent a few battalions of tanks to take control of it, but if they were going to go to that much effort, a high-street bank would probably not be their main concern.

Re:Here we go

[TheRaven64]

Or, better, use something with error correction capabilities, not just error detection. Create something like a small parchive for each file (or file set) and you can repair small modifications (or large ones if you create larger check files).

Re:Here we go

[Anonymous Coward]

Your problem space and proposed solution space have been corrected and mocked enough by other posters, so I'll desist from doing it any further.

All I'm posting for is to put forth the idea that if the cryptography algorithms are becoming a burden on the server, will we (would it be a viable solution to) see GPGPU used in Internet servers anytime soon? Initially, I could see ATX-based server hardware simply plug the latest/greatest gamer graphics card into their expansion slots and off-load cryptographic algorithms to them. Then, of course there will be the headache of vetting that graphics hardware for secure computation.

After that, websites will use the latest/greatest workstation graphics engines. Eventually, blade servers will have "certified" (whatever that means) GPU-based blades to do crypto work for an entire rack of servers.

Granted, this would just push the crackers to step up and use GPU farms to crack SSL traffic, but that's what the security game is. Not gate barring all from entry, just a high enough wall to keep out everyone without tall enough ladders.

Re:Here we go

[Midnight Thunder]

That's why security guys always seem paranoid. Security is a moving target and has to be frequently audited. The solution that was good enough today may be useless tomorrow and what was great today may simply be good enough tomorrow

The other thing is trying to balance good security with the appropriate level of usability for the scenario in question. That is as much an art as it is a science.

Security is like a fortress, in that there is always a weakness you haven't thought of and unmanned there is an even bigger one.

Re:Here we go

[emt377]

There are defences against that sort of attack too. For example, only permitting logins from a physically secured terminal. You can then tell your abductors the password, but they can't use it unless they also compromise the physical security.

It's much easier to have a second alarm password, that appears to give access but provides only fake data. When used it disables the real access and sets off alarms. Write it on an official looking card and keep it in your wallet; this way an abductor won't have to beat you to get it. Or it could provide access but set off alarms in a situation where it's hard to fake access and lives might be at stake. For a bank employee for instance it could notify police and the FBI, then make all operations so slow the criminals will have to sit around for half an hour to get anything done, permitting tracing and staging the local tactical squad.

Re:Here we go

[Midnight Thunder]

This is /. Most people are in single player mode ;)

Re:Here we go

[WaywardGeek]

I loved reading Applied Cryptography, especially the jibes at AI. Anyway, it's been a few years, but last I read, it looked like SHA-256 would be a solid document signing method for many years, and SHA-512 is for the truly paranoid. It's mostly used as a signing method, so I'm confused by the OP worrying about SHA rather than his stream encryption, which is likely some sort of AES. Truth is, ARC4 was hacked, but if you drop the first bytes, say 768, it's perfectly secure, so far as anyone publicly acknowledges (unless you count the ability to detect that a gigabyte of data isn't actually random as compromising security). We could still be using WEP securely today with this minor change.

Anyway, I always hear people pleading for hackers to avoid rolling their own security protocol. I believe that so long as you confine it's use to an appropriate application, go have fun and hack up a new one. It's not likely to be as good as existing algorithms, but how is the new generation of crypto hackers suppose to get any good without rolling their own a few times?

Re:Here we go

[emt377]

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.

You may as well use CRC32, though, which is just as useful for that application and much, much cheaper to compute.

I'd use Adler-32; much simpler than CRC32 (which really is a PITA to implement correctly) and about twice as fast as the most optimized CRC32, while plenty good to thumbmark files. Rsync uses it, for instance. CRC16/32 generally rules supreme for hardware though (shift registers are dirt cheap in hardware, but suck in software, leading to really complex, error-prone optimizations).

Re:Here we go

[grub]

Great points all.

I have an older copy of Applied Cryptography which I still use. Not far into the book, it was most humbling to realize just how much I didn't know about the field.

Re:Here we go

[ron_ivi]

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

That's the actual *problem* with security on the internet.

If people want a more secure internet it needs to get dumbed down to where the people who build and install such systems can do it without needing a PhD in applied math.

It's like when you buy a lock for your front door - you don't really need to study how many pins are in the lock; and your locksmith who installs it doesn't need to do research in what kind of metal the springs pushing the pins are made out of.

Re:Here we go

[BrokenHalo]

...Practical Cryptography. It has the information the OP would need to answer the exact questions he's asking.

Seems to me the OP hasn't really thought out what he is trying to secure. The best place to start is to decide exactly what you are worried about, and then go about setting up a suitable system to secure it.

There are some things, such as online banking, where there is no reason to use any level of encryption other than the best available. But having said that, the most critical security aspect is establishing a robust authentication system. If you have the resources to implement a one-time-key system of any kind, you've made a good start.

Re:Here we go

[mr_mischief]

What? No XKCD link?

"Security"

Re:Here we go

[CastrTroy]

In that world, online banking wouldn't even by on the WWW. There would be not website where you could do your banking, because the "best available" isn't http servers with SSL. We have much stronger encryption, and we have much less hackable networks. The problem is, is that they are way to inconvenient for the common user to connect to. I mean, ideally you'd create a VPN with the bank, using Private key encryption with a lot of bits. And now somebody is going to come along and tell me that indeed, this isn't enoung, and that we should be using one time pads delivered by trained assassins., with another group of ninjas watching the assassin to ensure there's not man in the middle attack. In everything, even banks, there has to be a compromise. You have to ask, what is good enough for your threat level, and for the users trying to access your system. SSL is secure enough for almost all environments, and is dumb simple for anyone to use. Anything beyond that, you are probably just kidding yourself anyway, because the weakest link is the end user.

Re:Here we go

[Mysteray]

There is no reason to use MD5 anymore.

MD5 isn't bad, for example, as part of the "stirring" function for the entropy pool in a pseudo random number generator. I believe it's used this way in the design of several open-source kernels. Possibly OpenSSL too, but my memory's not as sure about that one. But, yeah, even in cases where it might still be useful you probably don't want to use it. It's likely to trigger a lot of unnecessary discussion about it being broken (unless that's your goal of course :-).

Re:Here we go

[Mysteray]

By asking Slashdot?

Re:Here we go

[Anrego]

It's like when you buy a lock for your front door - you don't really need to study how many pins are in the lock; and your locksmith who installs it doesn't need to do research in what kind of metal the springs pushing the pins are made out of.

To carry on the analogy, buying a lock from the hardware store and installing it is quite the same as just enabling SSL in apache and plugging in a certificate. For most users, this is gonna be more than enough.

If you need higher security, you generally need to bring in someone who knows what they are doing in both cases though. What this guy is basically saying is: "I don't trust medico any more because someone at defcon figured out a really obscure way to break it so I'm thinking of building my own door lock. How many pins should I be using?"

Re:Here we go

[Anonymous Coward]

Then all it takes is a little more ironing until you give up the true composition and design of the system with all its passwords.

Re:Here we go

[silverspell]

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

Ah, but there are two keys. Solved one way, you get the Jailbreaker edition, which is nicely formatted for iPhones.

The other key, however, gives you the Proletariat version. I've almost got this one cracked, given that the text is very short:

"!N $@V!3+ R%$$!&, C@Dx BR3&K$ ¥@%"

Just a little more CPU time, and I think I'll have it...

Re:Here we go

[Foolomon]

Two factor authentication is popular amongst corporations for a good reason: the password itself isn't sufficient to get access. Arcot's solutions not only provide decoys but also provide two factor authentication. And they are the ones that patented the 3-D Secure technology that Visa uses for mobile transactions.

Re:Here we go

[Savantissimo]

Yup, a good algorithm and strong key length are indispensable, but that's maybe 5% at most of what is needed for security. The algorithm per se is rarely the weak link - it's the implementation (there are always more wrinkles than anybody can foresee when writing such code), or the client computer with no physical security, a gazillion processes with more access than is safe, broken antivirus and firewall, insecure OS, poor configuration, browser vulnerabilities etc. ad nauseam.

Dropping SHA-bignum into an existing web application is like putting a bank-vault door into a camping tent.

Re:Here we go

[Mattpw]

While I agree two factor is the way to go especially for the poster whos primary goal which seems to have been missed is securing a website I couldnt see anything great/innovative on the Arcot website. Primarily everything they have put forward seems to be vulnerable to localized infection (ie a trojan on the local device performing MITM) and I am particularly concerned with their pushing mobile based authentication which I can tell you most Asian countries are bailing out of there are so many different attack methods. The key to the authentication problem is mutual authentication otherwise you are only protecting against keylogging which is a very 80's attack unfortunately there are very few 2FAs which can do it securely.

Re:Here we go

[Anonymous Coward]

incoming "WHOOSH!"

Re:Here we go

[Andy Dodd]

Most critical sign that the article poster has a lot to learn:

SHA-512 is a hashing algorithm that is a component of digital signature techniques (among other uses). It is NOT an encryption algorithm!!!!

Re:Here we go

[Anonymous Coward]

confine it's use

"its"

Re:Here we go

[slew]

One take away people should learn is that they shouldn't use hacks for PRNG they "heard about" on Slashdot. People have learned quite a bit about cryptographically secure psuedo random number generators over the years and apparently aren't consulted very often by people who write kernels (open-source or otherwize). http://www.pinkas.net/PAPERS/gpr06.pdf

Even Linux switched from their crappy TGFSR/SHA-1 hack which does NOT use MD5 hack to an expert designed Yarrow/Fortuna which do NOT use MD5. If you must do something different, perhaps use a HASH-DRBG specified in NIST SP 800-90 with an approved hash function (e.g, NOT MD5).

Of course there's no stopping someone from using MD5, in their proprietary crappy PRNG for their toy code that they typed from memory and in this case there's probably no need to have unnecessary discussions about it.

Re:Here we go

[WaywardGeek]

So, not to pick on you specifically, but don't the spelling and grammar police on slashdot realise that half of us are massively dyslexic? The reason "it's" gets through is the spell checker blessed it. Otherwise, spelling is up to my fingers. It's weird, but as I age, my muscle memory has begun to learn to spell, while my "inner eye" remains blind to spelling. You don't even want to know how bad my spelling was before I typed a few millions of lines of text.

Same issue

[afterthought]

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

[Anonymous Coward]

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

[Bloodwine77]

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

[definate]

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

[SanityInAnarchy]

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

[leuk_he]

>

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.

Re:SHA-256 is enough

[Anonymous Coward]

Because apparently he doesn't like his database being in normal form.

Re:SHA-256 is enough

[Surt]

The point is that it isn't even giving you that much extra security.

Re:SHA-256 is enough

[Anonymous Coward]

Isn't SHA-512 having less rounds than SHA-256? Actually SHA-512 might be less secure than SHA-256.

Re:SHA-256 is enough

[Mysteray]

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.

Just prepending a fixed string to the input or output does not weaken the hash algorithm. In fact, you should include as much contextual information as is practical into the information being authenticated. The NIST SHA-3 candidate Skein, for example, has defined inputs for exactly such custom "tweaks" to the function. NIST defines truncated versions of SHA-256 and SHA-512 where all they do is change the initialization vector so the functions aren't accidentally compatible.

But watch out, where it might weaken the security is if your system later reads that value and uses it in the interpretation of the hash. For example, what if I fed you "{SMD5}aa64fc8e163669ba598fb3fff8c57741", would your system then degrade to the security of MD5 instead?

Re:SHA-256 is enough

[Bloodwine77]

In my system it prepends {SSHA256} to the hash in the database. When authenticating, it grabs the hash from the database and uses the stored prefix to denote how to hash the authenticating input to compare against the stored value.

So if someone somehow manages to pass in, "{SMD5}aa64fc8e163669ba598fb3fff8c57741", then it fails on two fronts. First, any prefixes in user input is flagged as a potential attack. Second, it doesn't matter if they pass me "{SMD5}" if the stored value has "{SSHA256}" prefixed, because the stored value is the only one that is consulted.

The end-user, either through manual entry or via API, can not dictate the algorithm used. So there is no way for an attacker to ever be able to store a password in a weaker format. Once I move to a new algorithm, either it be {SSHA256}, {SHA3...}, or what ever, then every password operation from that moment forward is forced to use the new algorithm. All existing accounts are then flagged to prompt the user to change their password upon next login to try to get as many passwords switched over to the new algorithm.

I would not be surprised if I am overlooking something, or if there is an even better way to do it.

Re:SHA-256 is enough

[the entropy]

Just one thing, you don't need them to change their password. Upon login, if the password they provide checks out and if it's still using the older algorithm, hash it with the new one and store it. That way, you can transfer accounts to the new hashing algorithm on the fly without your users ever needing to do anything or even notice.

Re:SHA-256 is enough

[cbiltcliffe]

Normal form for the sake of normal form is useless. In this case, it's a hashing algorithm that's associated with a password hash. You could put a key in, instead, referring to another table, but your key isn't going to be much shorter than "SHA256", and it will add more complexity to the code, which means more chance of security holes.
It will also slow things down needlessly, as you'll have to reference two tables for the data that could easily be stored in not only one table, but only one field.

Unless you're already sticking passwords in various places in your database, in which case you're already screwed on your normal form, then there's nothing wrong with this from a practical point of view.

THE SOLE ANSWER

[Anonymous Coward]

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

[Anonymous Coward]

"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

[vadim_t]

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

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.

Re:THE SOLE ANSWER

[TheRaven64]

The point of reading Applied Cryptography is to learn how little you know. It doesn't make you much less ignorant, but it does make you a lot more aware of your ignorance. This is very important when it comes to security systems.

Re:THE SOLE ANSWER

[Surt]

In fairness, it's also full of literally thousands of systems that have never been broken built by people who read that book.

Re:THE SOLE ANSWER

[tangent]

Schneier hasn't written a "hard" CS book since that first one because it turns out that the crypto solves only a tiny part of the problem. People are a much bigger part. I think Schneier felt he had to write these later books because he kept seeing software developers ignore the people problem.

You may say you really get this problem. Maybe you are right. The evidence, though, tells us that most people really do not get it, and need to be beaten over the head with it several times before they do get it. Much better to receive that beating at the hands of a benevolent master, rather than watch your carefully-built perfectly-designed cryptosystem fall to social engineering, or to a kid peeking at a stickynote under a keyboard.

For more stories of this sort, read Mitnick's book. It is not an especially enjoyable book, and Mitnick is not an especially good hacker. That's exactly the point, though. These are real stories of how real systems get compromised. Mitnick describes your actual enemy, not the one so many people seem to imagine. (The NSA, et al.).

Ask Sony

[Anonymous Coward]

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

Re:Ask Sony

[c0d3g33k]

Bad advice. 10 x 0 = 0

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

Re:Ask Sony

[marcansoft]

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

[youn]

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

Re:Ask Sony

[davester666]

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

Re:Ask Sony

[Anonymous Coward]

Uh, applying ROT-13 ten times just gives you the original plaintext...

Re:Ask Sony

[owlstead]

And a real RNG of course, never forget the random number generator (like Sony forgot when trying to implement ECDSA).

Re:Ask Sony

[marcansoft]

Sony used a real RNG, they just had the brilliant idea of using it once and storing the output as a constant. Seriously. The random nonces were different for each keyset, but the same for each signature made with a specific key - they were storing the nonces as part of the private key, as far as we can tell.

Re:Ask Sony

[Anonymous Coward]

So you're saying that ROT-13 applied 11 times will keep the data secure...

Re:Ask Sony

[owlstead]

As long as we agree that a good RNG is required to be in the mix (and that a constant value is an exceptionally bad RNG :).

Re:Ask Sony

[davester666]

Yes.

SHA isn't encryption.

[grub]

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.

[Marillion]

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.

[Anonymous Coward]

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 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:SHA isn't encryption.

[sdiz]

> If you're going to work on cryptographic security or have even a passing interest in encryption, please don't

fix it for ya.

Re:SHA isn't encryption.

[Argilo]

I think you meant Quantum Computing. Quantum Crypto already exists and in no way threatens the security of classical crypto.

Re:SHA isn't encryption.

[Velex]

It's still essentially a web of trust. You trust Verisign, Thawte, the DPRK, and all kinds of others, and they trust whomever they trust.

If you wanted to trust me, I could give you my public CA key, and you could install it.

You're correct in a social way, but incorrect in a mathematical way.

Re:SHA isn't encryption.

[Surt]

People are concerned that quantum computers may be able to factor public keys quickly, which breaks public key cryptography.

Re:SHA isn't encryption.

[Freebirth Toad]

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

I quick browsing of the wikipedia page for Diffie-Hellman key exchange leads me to believe that what makes breaking it difficult is the discrete logarithm problem, which is precisely what Shor's quantum algorithm solves efficiently. However, to the best of my knowledge, there is no quantum algorithm for finding rational points on a general elliptic curve (the hard part of breaking elliptic curve crypto).

To summarize: quantum computers break DH key exchange and RSA, but not ECC.

Re:SHA isn't encryption.

[Anonymous Coward]

Actually, hashing is classified as a '1-way encryption' where the original data can't be recovered - but can be re-hashed and verified as the same data. AES, on the other hand, is a '2-way encryption' where the data can be recovered with a password and/or key file(s). And PGP being '3-way encryption' using a master key for encryption and a public key for decryption.

Re:SHA isn't encryption.

[bwcbwc]

But never, ever, trust Comodo. Or at least many of their resellers. Every single story I've seen about compromised root certificates has involved a Comodo reseller.

Re:SHA isn't encryption.

[Mysteray]

It's still essentially a web of trust. You trust Verisign, Thawte, the DPRK, and all kinds of others, and they trust whomever they trust.

Except that they don't trust anybody. Which makes it very un-web-like.

In computer sciencey lingo, PKI is a set of short trees rather than a general directed graph.

Re:SHA isn't encryption.

[VTI9600]

Ahem...I hate to nitpick, but Diffie-Hellman does not belong in the same category as RSA and DSA. It is an algorithm for symmetric key exchange. Public key cryptosystems, by definition, use asymmetric keys...not to mention that they can be used to encrypt and/or sign data, which Diffie-Hellman does not do.

Yeah, OpenSLL is all fine and good for security

[scourfish]

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

go home

[Anonymous Coward]

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

[iYk6]

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

[Secret Rabbit]

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

[GrievousMistake]

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.

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.

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

[DarkOx]

The multiple streams idea seems risky to me. If you start splitting things up you might be opening yourself it unknown side attacks, timing attacks, and other leaks. As others have said the problems with SSL/TLS are not the encryption but the chain of trust. The best security you are going to get is to use it as designed.

If you are really worried about Authentication, then distribute a self signed certificate out of band. That way there are no chain of trust issues. The other thing you can do is used a CA signed certificate and distribute the thumb print out of band, but you have to insist clients check it. Thumbprints are a little easier to read over the phone though. :-)

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

[julesh]

There is however a theoretical attack (2^{52}) discovered in 2009 (better than prior breaks).

The authors of that attack withdrew their paper due to a miscalculation. Until they release details, 2^57 is the best published attack. And besides, it is irrelevant to the original poster: the flaw these attacks exploit allows creation of a pair of documents that hash to the same value, but *not* general creation of a document with a specific hash value, which is the only way you could attack an SSL server based on a flaw in its certificate hashing algorithm.

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

[mazesc]

The 5 remaining SHA-3 candidates, however, are new designs. The current SHA algorithms (up to SHA-512) are based on MD4 and have some operations added to incorporate the higher number of message blocks into the hash.

MD4, and MD5 have been badly broken years ago. Some collisions were even calculated by hand. SHA-1 was under heavy attack before the SHA-3 competition started, but there have not been any collisions found yet. Bart Preneel has a great slide as an overview of the state of hash functions based on MD4: http://homes.esat.kuleuven.be/~preneel/preneel_hash_icics10v1.pdf (slide 46)

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

[WuphonsReach]

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

That varies by vendor. Most offer 1/2/3 year options for the certificate.

But your point stands, the choice you make today will be revisited in 1-3 years anyway. At which point you can redo your risk assessment and change things.

The only issue here would be backwards secrecy as an older cipher might have a weakness that allows an attacker to read traffic streams a few years down the road. The question is - do you care? The second question is - have you secured other methods of obtaining the same data? Encryption is like a fence pole, it does nothing unless the rest of the fence is there to prevent intrusion.

(Which is why the OP needs to read books like Secrets and Lies so that they can do better risk analysis.)

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

[Mysteray]

In 2008, Stevens, Sotirov et al. proved that you could, in fact, pwn PKI with just a collision. It doesn't take a full preimage. http://www.win.tue.nl/hashclash/rogue-ca/

Remember, usually all you have to do is confuse the SSL client. There's usually little that can be gained by agonizing over the crypto parameters of the legitimate server cert, because the attacker gets to choose the weakest thing that the client will accept.

You're right to be concerned.

[Anonymous Coward]

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.

[Confusador]

Simply Hard Anough?

Re:You're right to be concerned.

[Anonymous Coward]

Simply Hard Anough?

AKA wush

Re:You're right to be concerned.

[Terrasque]

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.

[PwnzerDragoon]

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.

[Terrasque]

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.

[Anonymous Coward]

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

Re:You're right to be concerned.

[Anonymous Coward]

Simply Hard Enough

That's what she said.

Re:You're right to be concerned.

[arglebargle_xiv]

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

Yeah, sorry about that, it's a design flaw that you can still do that. Creation SP2 should fix it, I'm currently working on it. My bad.

Re:You're right to be concerned.

[tqk]

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

Yeah, sorry about that, it's a design flaw that you can still do that. Creation SP2 should fix it, I'm currently working on it. My bad.

Sorry, Sony just released another rootkit that runs on anything imaginable, so your SP will never take effect as the Universe is presently rebooting itself. You just haven't noticed it yet because of all these damned black holes fscking around with time dilation and multiverse stuff ...

Additional info

[MikeDawg]

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.

Re:Additional info

[WuphonsReach]

Make sure you use something 128+ bit (preferably 256+ bit). Some functions, especially those covered from RFC 3268 would be preferred.

It is not always true that the higher bit version of an encryption function is stronger then the lower bit version. Specifically in AES-128 vs AES-256, but can apply to other algorithms.

(Basically, when they designed AES-256, they flubbed the key scheduling portion compared to AES-128. Which makes AES-256 weaker then it should be.)

Don't worry

[shutdown -p now]

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

[betterunixthanunix]

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

[sco08y]

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 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 or the hypervisor.

Re:A few things

[Anonymous Coward]

CAs are not trustworthy and should not be trusted.

But they are trusted, and there's little you can do about it. The trust decision is made by the web browser. You really can't prevent somebody from acquiring a "valid" certificate for your domain. And that means you can't prevent MITM and connection highjacking.

(Besides, even if the CAs were perfect, the client computer would likely have been highjacked by malware anyway.)

Re:A few things

[w_dragon]

Wait, what? If you're using an internal CA in a company then you just push the config for it to your users. If you're like 99% of corporate users and have Active Directory then it's dead simple, I think the wizard to set up the CA will actually ask you if you want to hook it up to AD so your users don't get warnings. If you're using a *nix administration setup there are still ways to get it to the users without having to mail them CDs. (I have 20k employees at my workplace, I'd feel like retro AOL if I started mailing out CDs to every user!)

Re:A few things

[dkf]

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.

Actually, if you're just doing something internal and only need a single host certificate and aren't trying to run multiple domains off the same site, a CA-signed certificate's very cheap. Possibly even free, depending on what you've already got in place. (For reference, it cost nothing for me to get one set up recently under the condition that it was bound to a particular machine.)

As for why trust a CA you don't run? You don't have to really, but it's a lot of work to run a CA well even if you're not accepting submissions from the general public and you add having to distribute your CA key and get people to trust it. Plus you really want to be able to change your service certificates when (not if) you have deployment problems (such as a service compromise by insufficiently secured PHP; remember, security's not just one thing) which CA-based solutions have down pat whereas most of the others (e.g., web of trust) find difficult.

Self-signed certificates can only ever be safely trusted by the person who made them. Nobody else.

Re:A few things

[betterunixthanunix]

it's a lot of work to run a CA well even if you're not accepting submissions from the general public and you add having to distribute your CA key and get people to trust it.

If it is internal to your organization, distributing the key is really not hard to do, particularly since new members of the organization will (presumably) go through some sort of orientation process. If new members never meet current members in-person, then you have something of a challenge, but there are all sorts of security issues in such a situation. When I said "for internal use" I meant, in a very literal way, "for internal use" -- not for situations where you need to securely communicate with people who are external to your organization.

Plus you really want to be able to change your service certificates when (not if) you have deployment problems (such as a service compromise by insufficiently secured PHP; remember, security's not just one thing) which CA-based solutions have down pat whereas most of the others (e.g., web of trust) find difficult.

This is not a CA issue, it is just an issue of separating master signing keys from keys that you intend to use. Using PGP as a WoT example, you can create subkeys which do not need to be verified by the WoT, and keep the master signing key safe (perhaps in a safe). Revoking the master signing key is still going to be hard, but I can say something similar for the CA itself: revoking the CA's root certificate is a very hard thing to do.

Additionally, I would be worried about a CA that makes the process of obtaining a new signed certificate too easy. Most CAs are not nearly strict enough when it comes to verifying the authenticity of the certificates they are signing. We are unfortunately stuck with CAs, mainly because most computer users are nowhere near knowledgeable enough to remove an untrustworthy CA's root certificates from their systems, and the CAs all know it.

Re:A few things

[owlstead]

The attacks on AES-256 are rather specific - I don't think they are applicable to their usage in TLS. But never mind that, because AES-128 should be ample for normal TLS connections. Strangely enough (for people not knowing the internal design), 3DES can be more secure against side channel attacks. Most side channel attacks are much more easy to implement than the attacks on hashes on ciphers.

Re:A few things

[Anonymous Coward]

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.

CaCert and StartSSL do free certificate signing.

Recommended keylengths/algorithms

[Herrieman]

You might want to have a look at http://www.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 ...

Calm down and read up

[marcansoft]

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

[Anonymous Coward]

"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

[iluvcapra]

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

[marcansoft]

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

[Hypoon]

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

[NotQuiteReal]

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

[Anonymous Coward]

If you're using anything other than PBKDF2, bcrypt or scrypt to store your user's passwords, you have already lost.

Re:Calm down and read up

[avxo]

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

[Anonymous Coward]

by using Th3_g4m3 as your password

Re:Calm down and read up

[Anonymous Coward]

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

[Anonymous Coward]

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

[JoelKatz]

Cryptography doesn't work that way. The onus is on you to demonstrate that your scheme is secure. Anyone who doesn't have the expertise to do that (which is almost everyone) has to use a scheme that was developed by someone else and vetted by others as well.

It is trivial to make a scheme that you yourself cannot break. It is not that hard to make an insecure scheme whose insecurity cannot be easily demonstrated.

Re:Calm down and read up

[palegray.net]

He didn't say he was inventing his own method at all. Your lack of education is showing; there are a plethora of cryptographically sound hashing libraries available. Please research the topic more thoroughly and review available resources such as Crypt::SaltedHash before attempting to dissuade others from following what was not only sound advice, but critical advice for folks who deal with legacy systems and don't even know about salting.

If you feel I'm somehow misguided on this topic, I'd encourage you to speak with folks like Schneier et al before attempting to mount a counter to the aforementioned statements.

Re:Calm down and read up

[palegray.net]

Don't worry too much about misguided replies you've received thus far. I addressed one in this thread, and am frankly too fed up with armchair cryptographers to reply to any more comments here. All I can really say here is "carry on smartly if you can" :).

Re:Calm down and read up

[JoelKatz]

Actually, a simple salted hash *IS* a validated algorithm. But don't do it because some guy on Slashdot said it was okay. ;)

Re:Calm down and read up

[Thad Zurich]

The onus is on you to demonstrate that your scheme is secure [...] It is not that hard to make an insecure scheme whose insecurity cannot be easily demonstrated.

Demonstrating that a scheme is secure would mean proving a negative -- an impossible np-complete problem. That's why it's so difficult to trust *anything*, because even the schemes people think are the most secure today may be broken tomorrow. It may be hard to make a scheme whose insecurity cannot be easily demonstrated, but when it finally is demonstrated, it usually appears to be easy.

Re:Calm down and read up

[marcansoft]

Crypt::SaltedHash is significantly less secure than PBKDF2. It doesn't iterate the hash, which is a very good idea for password hashes, as it significantly increases the cracking time (very important for not-so-good passwords). Hashes are meant to be fast, so deliberately slowing down the algorithm helps a lot. Going from 10000000 cracking attempts per second to 10 cracking attempts per second is going to stop a lot of attacks, and all it takes is using a properly designed algorithm instead of just sticking the password and a salt into a hash (which is what SaltedHash does).

Re:Calm down and read up

[Urkki]

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

Either impossible or very easy depending on how you look at it, since SSL is not encryption algorithm... SSL is cryptographic protocol which generally uses two encryption algorithms, an asymmetric one for authentication etc, and symmetric one for session data encryption. It also bunch of other cryptgraphic algorithms, at least a hashing algorithm and a key exchange algorithm.

Re:Calm down and read up

[emt377]

Going from 10000000 cracking attempts per second to 10 cracking attempts per second is going to stop a lot of attacks, and all it takes is using a properly designed algorithm instead of just sticking the password and a salt into a hash (which is what SaltedHash does).

Store the number of iterations alongside the salt and hash. This way as computers get faster you can rehash your password database once a year by increasing the number of iterations.

Re:Calm down and read up

[marcansoft]

That's an interesting idea. Unfortunately it wouldn't work with PBKDF2, because the output of PBKDF2 isn't equivalent to an intermediate step (you can't hash it further to increase the strength and come up with the equivalent of running PBKDF2 with a larger number of iterations to begin with). Of course, you could just rehash passwords as people enter them to log in, but chances are a significant portion of your database (people with abandoned accounts) will keep using the old hash, unless you regularly purge those accounts.

What you suggest would work with PBKDF1, which is probably sufficient for password hashing purposes (you could use a simple SHA-2 extension of PBKDF1 to increase security, since PBKDF1 usually uses SHA-1).

There's a reason why PBKDF2 doesn't work (by design). Quoting from the RFC:

Note. The construction of the function F follows a "belt-and-suspenders" approach. The iterates U_i are computed recursively to remove a degree of parallelism from an opponent; they are exclusive-ored together to reduce concerns about the recursion degenerating into a small set of values.

With PBKDF1 you lose the XORs, so you lose a certain degree of protection against problems with the underlying hash function, but you gain the ability to increase the iteration count of the hash after the fact.

Re:Calm down and read up

[rsk]

Really appreciate you posting some specifics here. There's been a lot of hand-waving and big-brothering in the thread so far (justifiably so, security is a hot-button/serious topic) but you actually posted something concrete that helped me put a name-to-a-face as far as a pw hashing technique goes.

Re:Calm down and read up

[PalmerEldritch42]

00894983a50dc526-0e71bd5a380617a402bd24c6be3e7a7f2dd06109

Weird. That's the passcode to my briefcase.

Re:Calm down and read up

[Anonymous Coward]

instead of wasting your time with that shit just use bcrypt: http://en.wikipedia.org/wiki/Bcrypt

Re:Calm down and read up

[errandum]

If someone enters your system, they can access your salting code which is half way to breaking it.

I believe you'd be better off doing multiple hashes of the password in a big enough magnitude for it to become slow. That way most brute force approaches wouldn't easily work.

Re:Calm down and read up

[Anonymous Coward]

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

Or just call Unix's crypt(3) with a salt generated from calling arc4random(3). If you have a $2$, $5$, or $6$ in the output of crypt(3) then you're fine.

Re:Calm down and read up

[Mysteray]

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.

How? I have some ideas but am interested to learn more. Do you have a reference for this?

Re:Calm down and read up

[Anonymous Coward]

Please in a couple sentences explain the difference between a hash and encryption or post some useful links to further knowledge as apposed to pointing out ignorance and leaving them ignorant.

Re:Calm down and read up

[davesque]

It seems like the last couple times I've read through responses to Ask Slashdot questions, some people choose to answer by saying "You have no right to ask this." or "Your question itself is wrong." C'mon guys. Can we be a bit nicer about these things?

Re:Calm down and read up

[Anonymous Coward]

He doesn't since it's bullshit. If it matters your hashing algorithm is broken (why yes, MD5 is broken for the purposes of the discussion, thanks for asking).

Re:Calm down and read up

[Anonymous Coward]

Is it more worrying that a newb is asking the wrong questions about his homework, or the fact /. editors no longer understand enough tech to know it was asking the wrong questions, and approved the story? Is /. now run by a bunch of suits?

Re:Calm down and read up

[JavaRob]

doing multiple hashes of the password in a big enough magnitude for it to become slow

Hash algorithms like SHA1 and MD5 are designed to be fast. This is great if you are fingerprinting large amounts of data looking for patterns, comparing files, etc.. This is not great if you don't want your passwords to be brute-forced.

Rainbow tables are not the real danger to hashes. The real danger is simply that brute-forcing many password hashes is startlingly fast on modern hardware.

If you're hashing passwords that need to be safe from brute-forcing, use something like bcrypt, which let's you set a work factor.

More explanation here:
http://codahale.com/how-to-safely-store-a-password/

Re:Calm down and read up

[JavaRob]

http://lmgtfy.com/?q=difference+between+a+hash+and+encryption :D

[Okay, I admit this is slightly mean fun. And to be sure, responses that just say "you clearly are in way over your head -- go hire a lawyer/expert/whatever" are far less helpful than ones that say "you may need to hire an expert... they'll probably tell you to do X or Y based on your Z". But while I think the original poster was asking a valid question that's not trivially answered by google, finding the difference between a hash and encryption isn't so hard to find.]

Re:Calm down and read up

[errandum]

I said exactly that.

If the average computer can do 5 million hashes/secod, then just loop one million re-hashes so it will only get 5 hashes / second. No one can brute force that (for now)... And yes, bcrypt will work, but this is an easy solution to implement, that's all I meant.

Re:Calm down and read up

[Anonymous Coward]

I would prefer he invent his own cryptosystem than listen to you, he won't be protecting anything that secure with it, and who knows the guy may be more talented than YOU
We wouldn't have Linux today if all people thought the way you do, we would be A-OK with mudhuts and rocks
So prior to you spouting garbage that reveals YOUR ignorance, post something that is actually insightful..
Try not to be a condescending prick too!

To the OP if he reads this, keep trucking, you had the balls to post to slashdot, so you apparently know your limits

Re:Calm down and read up

[SoopahMan]

Slashdot: Like StackOverflow, but with more insults and less answers.

Re:Calm down and read up

[Anonymous Coward]

which let's you

"lets".

Rainbow tables?

[CPE1704TKS]

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?

[pthisis]

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?

[Opportunist]

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

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

Re:Rainbow tables?

[BlueParrot]

Salt makes it a non-issue when used correctly.

Re:Rainbow tables?

[Eil]

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

[swillden]

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?

[sco08y]

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?

[VortexCortex]

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?

[avxo]

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?

[Unequivocal]

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?

[SmilingBoy]

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

Re:Rainbow tables?

[Anonymous Coward]

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

[Anonymous Coward]

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

[Kjella]

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?

[Anonymous Coward]

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.

Re:Rainbow tables?

[JoelKatz]

Well, even if you picked a relatively-weak 128-bit hash, there are 340 billion, billion, billion, billion possible hashes. So that would be one heck of a table. And if the hash was salted, you'd need one such table for every possible salt. For a 160-bit hash like SHA1 with 32-bit salt, your rainbow table would need over six thousand billion, billion, billion, billion, billion, billion entries. If you had a billion computers each of which could calculate a billion, billion hashes per second, you could perhaps fill your table in 4,777,094,000,000,000,000,000,000 years. I leave it as an exercise for the reader to calculate how many 2TB hard drives you'd need to hold such a table.

Re:Rainbow tables?

[i.r.id10t]

Of course, this assumes that your salt and hashing scheme (pw first, then salt, or salt first then pw?) isn't stored in plain text files - like PHP scripts, etc.

Even if your salt string isn't stored and changes for every password, if how you compute the salted string to be hashed is visible in code, then it doesn't really matter....

Re:Rainbow tables?

[Fnord666]

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.

While this is true, you are effectively forcing the attacker to create a rainbow table for every possible salt value. Assuming that the salt value is different for each password (otherwise why store it in the database), you have forced the attacker back into using brute force.

Re:Rainbow tables?

[WuphonsReach]

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

Agreed, which is why you have to also nip the problem in the bud, before the password gets accepted by the system. Minimum length requirements, password complexity requirements, etc. Which goes hand-in-hand with using 16-32 bits of salt.

(Currently, if the attacker has $10,000 and a copy of the hash, any password under 8 characters is doable in less then a week. Even randomly generated passwords that can still be typed on the standard keyboard. If it's in a dictionary, or comprised of multiple words strung together, it's even easier and can be done in less then a few hours.)

Re:Rainbow tables?

[WuphonsReach]

Except that when you create a rainbow table, the size is not primarily determined by the size of the hash. It's determined by the size of the search space - which is the passwords that can be entered on a standard keyboard. Then it gets multiplied by the size of the salt in use.

Assuming A-Z, a-z, 0-9, and 24 symbols, you have about 86 possibles for each character position. We'll be lazy and call it an even 90 possibles.

The size of a rainbow table for all 8-character passwords using 90 possibles per position is: 90^8 = 4,304,672,100,000,000. Assuming 32 bytes of storage per password / hash pair, you end up with needing about 128,289,226 GB worth of storage (roughly 122 petabytes). Which is still a lot, but a lot less then what you think.

If your users are lazy (most are) and your password complexity requirements are weak, then you can assume that (a) the password is comprised of dictionary words (b) upper-case probably only happens at the start of the word or at the start of a syllable and (c) the use of numbers and symbols will happen on word boundaries.

Which means your search space drastically shrinks and there are a lot less possibles. Figure 300,000 words in the dictionary, and most passwords will contain words from a list of about 10,000. If the password is constructed from those 10,000 words, plus a few numbers thrown in at word boundaries, there's not much complexity there. A rough estimate would be that you could see user-created passwords, that meet modest complexity requirements, that might only have 30-36 bits of entropy. Which means your table only has to contain between 1 and 16 billion different hashes. At 32 bytes per hash-password pair, that's only 512GB, multiplied by the size of the salt.

If the salt is less then 8-12 bits, it might still be worth doing a rainbow table. For larger salts, it is better to identify key accounts and attack those hashes directly rather then rely on the rainbow table. An attack like that is embarrassingly parallel and can be farmed out to a cluster or to machines with multiple GPU cores.

Re:Rainbow tables?

[JoelKatz]

Right. I was responding to:
"The table is generated by creating passwords and hashing them until all possible hash have one matching known password."
I was pointing out the absurd consequences of that. But of course, it's not true. Rainbow tables are generated as you suggest, not as the anonymous coward suggests. You are done when you have hashed every plaintext of interest for every salt of interest. The table will cover an insignificant fraction of possible hashes and the probability it will ever encounter a single 'wrong plaintext that hashes the same' is negligible. That certainly isn't its primary purpose.

Re:Rainbow tables?

[Anonymous Coward]

(same AC as above)
Well, my point was actually:

The password picked from the raibow table is not necessarily the actual password user chose, just one whose hash collides with it.

i.e., I'm convinced some super-complex password hash can collide with stupid one-letter password hash (but, I'm as lazy as coward, so I didn't try to compute one). It happened to me once (I have nothing left to demonstrate it, that machine is long gone): I could login on a single linux user account with 2 different password (neither was 1-letter long, but still).

I shouldn't have gone about generating *all* possible hash values, as indeed it's not realist.

Re:Rainbow tables?

[WuphonsReach]

It happened to me once (I have nothing left to demonstrate it, that machine is long gone): I could login on a single linux user account with 2 different password (neither was 1-letter long, but still).

And if it was an old box, back when "crypt" (?) was the hash method used. It would discard anything after the first 8 letters in the password prior to calculating the hash and comparing it against what is in the password field. Salt was typically one of 4096 possible combinations (12 bits) and the password hash was probably only 56-64 bits. Which gives a pretty high chance of collision for such a small hash size.

So, if both passwords were identical in the first 8 letters, that could be the answer. Otherwise it was the issue that with so few bits in the hash, having two different passwords hash to the same value was quite possible.

(Note: I'm sure about the 8-character truncated password. Saw it happen on Solaris boxes from the early 2000s. Not so sure about how big the stored hash value was. I don't have those shadow files any longer. But 56-64 bits is likely if it was using single-DES as DES operated with 56bit keys.)

Re:Rainbow tables?

[Mysteray]

Yep. And most typical passwords fall to brute force attack within seconds.

Millions of guesses per second is pretty common for modern GPUs.

Re:Rainbow tables?

[Anonymous Coward]

I understand the importance of the salt before the hash. Brute force attacks are not feasible.

But of greater importance (and of interest to me--obviously) are my bowel movements. I hope they will
interest you too.

Like you and me, we all have enjoyed a lifetime of bowel movements. We revel in their endless variety
and we often conjecture about what "went in" before it "came out". I'm sure each of us has experienced
corn "going in" on the cob and "coming out" on the cob.

Today I just want to talk about my morning bowel movement. Yesterday, our local community pool had a free
reception with wine and cheese. They were hoping to enlist new members. So to make a long
story short, I loaded up on wine.

This morning I woke up in half a stupor, with little or no memory of the previous night. I was
somewhat flatulent, and I must admit that I admired the fragrance of the gas. When I finally
squatted on the toilet, the distinctive aroma was a real hint of what was to follow. This was
not a strained bowel movement--no tar balls, no constipated chunks of beef and white bread.
No, what slithered out of my rectum was a veritable slimy, slippery eel. It was not the longest
bowel movement (although it was coiled and long). Nor was it the most thick. In many ways
it was typical.

However, the smooth way it squirted out my rectum, and into the bowl was more satisfying than
anyone has a right to expect. At least momentarily, a living creature, something that was once
part of me, was swimming in the porcelain bowl. Yes, I eventually flushed it, after a suitable
time of respect.

In our diverse world of the 21st century, I came to realize that my lovely eel would mingle with
the feces of chinamen, colored people, and beaners. We are the world indeed!

love,

Mister Bob

Re:Rainbow tables?

[Anonymous Coward]

if you lost the password db, you lost the game already
sql injection attacks should be security priority #1, never trust the user

Stream Cipher

[joek1010]

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

So, a stream cipher?

Windows XP is the bottleneck

[MetricT]

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

[Opportunist]

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

[WaffleMonster]

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

[Unequivocal]

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.

Re:I'm not sure I understand but here goes

[JoelKatz]

SHA-512 is a hashing algorithm that can be used to generate the hash that you actually sign with the low-level signature algorithm. To sign a digital certificate, you generate the secure hash of the 'inner certificate' (called a "TBS certificate" -- 'to be signed') and sign that, combining them to form the final, signed certificate. This is advantageous for a variety of reasons but it's necessary for one -- the low-level signature algorithm has a certain maximum length that it can sign and the certificate as a whole may exceed that.

Encryption strength isn't important

[iceco2]

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.

Re:Encryption strength isn't important

[JoelKatz]

I can't follow your claim. You say "breaking the encryption head on" but then say "not the hash function or the public key encryption or the symmetrical key encryption". Breaking the encryption head on would have to mean breaking either the PK encryption or the symmetrical key encryption since that's the only encryption there is.

In any event, it's obvious that historically breaking the encryption head on, particularly the symmetric encryption, was a real issue. That's why the NSA worked so hard to hold down key sizes in exported SSL products. The NSA forced Netscape to make a version of their browser for International use with shorter keys, and since such a key could be broken in less than a week with less than $250,000 in hardware, it stands to reason that a few of them were in fact broken.

SLL! HASH! ENCRYPTION! !!!1!

[zindorsky]

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!

[jensend]

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!

[White Flame]

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

[The Famous Brett Wat]

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-

You need to use GoDaddy

[Anonymous Coward]

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

[Anonymous Coward]

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

You're in over your head

[fluffy99]

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.

[muxecoid]

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

[Bloem]

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 is a good source for hints and tips. They even have a top-10 for this stuff. So, if SHA-512 is you're only problem, you're doing just fine.

Too late

[drmofe]

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

Remember Ken Thompson C Compiler Backdoor

[Pepebuho]

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

[maxwell demon]

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

[mmmmbeer]

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.

Re:What if you're a nigger?

[Anonymous Coward]

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

TLS

[Anonymous Coward]

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

Re:TLS

[JoelKatz]

You can't create two colliding certificates that are signed by any reputable CA since they all now include random material prior to any user-supplied material (for example, by using random serial numbers). So at best someone could compromise their own CA. But someone you choose to trust can always compromise whatever you've entrusted them with. Essentially, the SHA-1 problems have been side-stepped by a CA policy change. This won't apply to any CAs that don't follow this type of policy, of course.

No such thing as "SHA-512 encryption"...

[Anonymous Coward]

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

Cryptographic Right Answers (from C. Percival)

[fph il quozientatore]

I'm surprised no one pointed out this link already: http://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html

I remember how we deployed GOST...

[hotfireball]

I am working for banks long years, here is a bit of security sights for you.

I remember how we deployed GOST encryption at a number of Russian banks, by saying "Hey, but AES (Rijndael) is seems to be better (at least more attacked and thus proven to be secure). You know what did they said? They said: if you are needed to nobody, then anyway nobody cares. But if somebody will need you, then nothing will help you ever.

The moral of the story above is: people are so much paranoid about SSL strength, yet it is OK that all your private information is known everywhere around? Got your credit card? Then I assure you that all your most important information is there in the database. For example, before you get a credit card in a City Bank, we will check you from your top to your bottoms and if you seems to be not reliable, you will not get a credit card. How do we know about you, you think? :-)

As of SSL strength: even 64 bit is impossible to decrypt, since your session lifetime is too short.

Yes I Remember Ken Thompson C Compiler Backdoor

[Anonymous Coward]

David A. Wheeler’s Page on Fully Countering Trusting Trust

http://www.dwheeler.com/trusting-trust/

Well, I guess you'll have to find a new reason to polish your tin foil hat.

Don't listen to these folks

[Anonymous Coward]

I design and implement security systems for the transportation industry. From a theory perspective there's nothing I know that you couldn't learn yourself in 6-weeks of Safari Books Online. You don't have to build a crypto system, that's what OpenSSL is for.

You can use the OpenSSL CLI to do everything you need, CA authorities, certs, key generation etc... Unfortunately you'll need to trust other PKIs (i.e. Verisign), the point about a disgruntled admin selling a private key is exactly why some feel that internet security is inherently flawed.

    RSA 2048 keys for digital signatures. ECC is a fine choice as well but a little harder to implement. Use AES-128/256-cbc for symmetric/hybrid encryption (e.g. TLS). On your question about different key pairs for various streams, they'll all be using shared secrets (i.e. content encryption keys) that are unique to that session. In TLS the asymmetric key is just used for the handshake (to share the secret so to speak). You don't really want/need the overhead of maintaining unique certificates for every institution. Best thing you can do for security is secure your keys at rest.

You can configure the RSA digital signature to use a SHA-2 512 hash. 256 is fine as well.

The first thing to understand about SSL

[petermgreen]

Is that in the way SSL is typically implemented the crypto is not the main weakness. In a typical SSL setup the client verifies the server is who it says it is is by looking at a certificate chain and checking that chain against a list of "trusted" roots. The server then verifies the client is who it says it is by requesting a password or other credentials be transmitted across the encrypted channel (in the https case this happens in the form of a http post followed by http cookies).

The problem comes that in typical implementations of SSL the list of trusted roots is HUGE and if the holders of ANY of those trusted roots can be compromised then a MITM attack can be mounted against your communications.

If you have control over both endpoints of an encrypted link you can make SSL far more secure by using your own root and making sure that is the ONLY root the client trusts.

Book Recommendation on the Topic

[Anonymous Coward]

I am reading Understanding Cryptography: A Textbook for Students and Practitioners. While a textbook, the materials are current and very readable for a layperson. The text might provide some background for your inquiry as the book specifically includes chapters on hashes, encryption types, and related materials. Again, the book is readable and, in my opinion, informative (plus it is current as a newer text).

SHA-1 isn't the thing to worry about (yet)

[owlstead]

SHA-1 has not been broken in the sense that forging a signature takes a few mere hours. Actually, the attack is about in the order of 2^51 minimum, and no successful collision has yet been found. Even then, it is not broken for many uses such as specific key generation functions or pseudo number generation functions - although it is worrysome for signature verification as used in SSL/TLS. Actually, many CA's (see the certificate store in your browser) still deploy SHA-1, even for extended validity certs. Personally, I'm slightly worried about the state of many (non-PC) browsers and CA's that don't support SHA-256, SHA-512 or derivatives.

If SHA-1 is ever broken in the sense that collisions can be calculated for pre-existing signatures, you'll certainly hear it in the news. All CA's and SSL/TLS sites will be vulnerable. Before that I would focus on getting the most secure server, configuring it safely and keeping it updated, making sure that nobody (except you and your server) get hold of the private key. Actually, the askers case, you might want to sub-contract that part.

with ... by ... whatever ...

[SplatMan_DK]

but if no one's browser can handle it, you'll be playing with yourself!

Ahemm, English is not my first language, but I believe you mean "by yourself" ...? ;-)

- Jesper

Expanation of SSL, Encryption, etc

[Anonymous Coward]

First, SHA is hashing function that is used to create a 'fingerprint' of a certificate which is used in the certificate signing process. It is not encryption and has no relevance with respect to the 'strength' of the encryption.

SSL Certs contain several pieces of information:
1) A public key (which is paired with a private key only known to the owner of the certificate)
2) Usage information (what the certificate can be used for)
3) Issuer - indicates the certificate that was used to issue (i.e. sign) this certificate
4) Lots of other stuff (serial numbers, subject names, etc) that are used for a variety of purposes

So where is the encryption in SSL? There are two places that encryption shows up, neither of which have anything to do with the hash algorithm used to sign the certificate. The first is the public-private key pair. Only the public key is contained in the certificate. The paired private key is held by the certificate owner. With respect to encryption, the public-private key pair is used to periodically exchange a symmetric key which is used to encrypt the actual data sent over the connection. basically, the server creates a random symmetric key, encrypts it with the private key, sends the encrypted key to the client, who then decrypts it using the public key from the certificate. The client/server then uses that symmetric key to encrypt the session data. SSL/TLS has a protocol to periodically generate a new, random symmetric key so that over time a series of different keys are used to encrypt the session data.

So in terms of crypto-strength, the relevant factors are:
1) Public-Private crypto algorithm and key size (which is always RSA as far as I have ever seen with key sizes ranging from 1024 bits to 4096 bits - more bits is stronger, but much more expensive). This is used to protect the symmetric keys when they are exchanged over the wire.
2) Symmetric crypto algorithm and key size. This is negotiated between the client/server to find a commonly supported algorithm. AES is generally considered to be a good algorithm for the symmetric encryption, though some servers/clients still use 3-DES. Key size for AES is 128, 192 or 256 bits (again, more bits is better but more expensive).

The algorithms and key sizes are what impact the 'strength' or 'security' of the encryption.

So where does the hash function (such as SHA-512) show up? This is used in the generation of the signature of a certificate. In order to ensure that the contents of the certificate have not been tampered one generates a hash of the contents of the certificate and then that hash is signed using the private key from the issuing certificate. So hash functions are only relevant to the process of checking the certificate for tampering. MD5 should not be used for this process because there is a viable "collision attack" known for MD5. This means that if you have a message which you hash using MD5, there is a viable method for creating a slightly modified version of that message that will hash to the same value. So if one is using the hash to

Last time I checked, there was no viable collision attack for SHA-1. People have shown ways to make it easier than brute force, but it is still sufficiently hard as to be prohibitive. SHA-2 (of which SHA-512 is one example) does not yet have a known reduction for the collision attack.

What this means is that if you use MD5 to sign your certificate, I can create another certificate which contains a slightly modified version of your cert's information which will hash down to the same 'fingerprint' as yours when using MD5. This means that I can simply copy your cert's signature into my modified cert and the signature will still check out. I can now create a cert with my own information which will allow me to mascarade as you.

So what the hash algorithm impacts is whether an attacker can try to pretend to be you by compromising the certificate signature process. It does not impact the strength of the encryption itself.

Worry more about user authentication

[Mattpw]

I realise people like to talk about crypto but user authentication is much more pressing security problem and the weak link in all the recent attacks. Im not reading about X breaking X crypto instead I hear static passwords being gotten one way or another and all the crypto being bypassed. A friendly suggestion for your secure site would be to use 2FA dynamic passwords in as many places as you can preferably with mutual authentication capabilities to prevent MITM, further suggestions would be using Yubikeys or ShieldPass cards and I believe Verisign has a service but the former are much easier to implement and relatively cheap.

Or try SHA-513

[Gothmolly]

You: The numbers all go to 513 bits. Look, right across the board, 513, 513, 513 and...
h4x0r: Oh, I see. And most SSL goes up to 512 bits?
You: Exactly.
h4x0r: Does that mean it's more secure? Is it any more secure?
You: Well, it's one more secure, isn't it? It's not 512. You see, most blokes, you know, will be using SHA-512. You're on 512 here, all the way up, all the way up, all the way up, you're on 512 bits on your SSL key. Where can you go from there? Where?
h4x0r: I don't know.
You: Nowhere. Exactly. What we do is, if we need that extra push over the cliff, you know what we do?
h4x0r: Put it up to SHA-513.
You: 513. Exactly. One more secure.
h4x0r: Why don't you just make 512 more secure and make 512 be the top number and make that a little more secure?
You: [pause] These keys use 513 bits.