Hacker News Reader

> No. This is incorrect. This is exactly the right attitude for most developers to have about cryptography, because on a subject as complex as cryptography most developers (including me!) are nowhere near smart enough to understand the ins and outs.

I hear that a lot, and it always reminds me of Jante Law[1]. Its a disservice to keep telling people that they are too stupid to understand something. Too ignorant, perhaps - that can be remedied - but everyone is not too stupid to understand crypto. It's simply another field, mostly mathematical, and goof-ups are easy to make and often very costly.

edit: I should also make another point. Cryptography is exactingly and excruciatingly hard to do at industrial strength. I am not recommending people go out and roll their own crypto for production systems. It's possible for the initiated to do right; it's possible to get initiated. The uninitiated almost certainly will goof. I'd like to further point out [2], which is a discussion and break on a homebrew crypto, for a taste of the difficulties and mathematical sophistication needed.

[1] http://en.wikipedia.org/wiki/Jante_Law

[2]http://phrack.org/issues.html?issue=64&id=10#article

Cryptography is exactingly and excruciatingly hard to do at industrial strength.

Related: Which is why I'm against any and all forms of electronic voting. I've done a fair share of crypto (as a user of crypto libraries) and I barely understand how it works. There's ZERO hope for the layperson to understand crypto-based voting systems.

One of the central tenets of American style voting is a public vote count. Using crypto puts the "public vote count" into the hands of a the high priesthood (a few adepts), which is a really bad idea.

Regardless of what you think of the kind of people who the government would contract to develop electronic voting machines, I don't think I'd call them "laypeople". Or are you saying that every individual voter needs to understand the inner workings of the system for it to be effective?

I would say that yes, every voter needs to be able to comprehend the system. Counting paper ballots is something anyone of normal intelligence can understand. Auditing them is something everyone can understand. Not so for cryptographic based systems, particularly proprietary systems.

The only electronic voting system I'd probably be OK with is one that is totally open-source, software and hardware. The implementation must be completely transparent.

Even then, fraud will happen. Always has, always will.

Or are you saying that every individual voter needs to understand the inner workings of the system for it to be effective?

Um, yea. That's what "public vote count" means.

As for the technical competence of our nation's election administrators, have you not been paying attention? I've met many many. Great at elections. Terrible at computers. Completely and utterly reliant on the vendors. Who've manifestly demonstrated their complete inability to code their way out of a wet paper bag, much less be entrusted with the foundations of our democracy.

But they don't need to understand the mathematical details of the cryptographic protocol (do they?), which seemed to be what you were implying. It seems to me the details could easily be abstracted away into a sequence of idiot-proof steps, but I don't know much of anything about public voting systems.

Edit: I'm not sure why I'm getting downvoted - am I misinterpreting what specialist is saying? For another example, look at HTTPS - it secures your communication without any need for knowledge of how it's doing so, you just need to know that if you see the green lock icon you're "safe" (though I'm aware of all the usability issues, like how everyone just ignores warning messages when something goes wrong). Is there something fundamentally different about public voting systems in this regard?

I guess you're getting downvoted because that's exactly the point: Every layperson should be able to double check the vote in case of doubt. That includes the nitty gritty details, including the security of the cryptographic protocol. Paper-Ballots are simple. There's not much to understand: Make your cross, count the votes, add up, done. If in doubt, count again. You don't need to trust any expert on anything for that.

There are crypto-based voting systems that are very simple to understand, although not being entirely electronic: http://www.wombat-voting.com/

By all means, there are different shades of grey. It should not be all black or white.

Crypto-based voting systems are not designed to work for real-world elections. They work fine for contrived academic studies.

They all rely on one's vote being lost within a herd of votes. So if your ballot is one of a million, and the ballots are simple with a few races/issues, it's easy to have a secure one-way hash with collisions. (The collisions make it impossible to work backwards to infer how each person voted.)

Alas, real-world elections in the USA are administered at the precinct level. In my state, that's between 0 and 1000 registered voters.

Further, a general election (November) ballot will have dozens of issues and races.

So it's more than likely that any single ballot will be utterly unique. So with the voting systems I studied, it's trivial to infer how everyone voted.

I could imagine crypto-based voting systems working for certain applications. Like corporate shareholder meetings. Or maybe Australian and British style parliamentary elections. (Don't hold me to the last guess, I only have cursory knowledge of their election systems.)

Edit: I discussed these practical issues with one of the grad student authors of a crypto-based voting system. Being completely ignorant of real elections, he had NO IDEA what I was talking about. He denigrated my input; saying our elections should be easily tailored to accommodate crypto. (Good luck with that.)

Maybe it's just me, but I'm of the opinion that people setting out to solve a problem should probably make some token effort to first understand the problem. YMMV.

> Its a disservice to keep telling people that they are too stupid to understand something

That's not the point. Specialization - developing a deep understanding requires time and effort. As a developer choosing a way to store passwords securely is one task out of 1,000 I'm responsible for. So I acquire a general understanding of cryptography to make a decision - but that decision relies heavily on experts and consensus. The worst thing I can do as a developer is to go down the rabbit hole of cryptography and spend 10 hours researching an optimal password hashing scheme for my app. Sure, I've begun the journey of having a deep understanding of crypto - but I still have 999 things to do!

Which reminds me I need to get off HN and get some work done .....

> So I acquire a general understanding of cryptography to make a decision

But this is precisely what the cult priests don't want you to do. There are only two words you need to know: "use bcrypt". Any attempt to learn more is heresy.

Perhaps. But so what? As a developer the buck stops with you. If something goes wrong the boss (or client) will not be impressed by an excuse of "well I just did what someone on the internet said was best practice".

However I can see the problem with such a culture if your boss happens to be a bcrypt-tard and is closed off to discussion/learning.

Option 1: Rely on what everyone else does.

What happens if that method is flawed? You hear about it as soon as it's discovered and it gets fixed quick.

Option 2: Roll your own stack based on a personal understanding of cryptography.

What happens if that method is flawed? Perhaps only you and an attacker could possibly know such a thing. You have to be ever vigilant and you have to acquire an incredible amount of crypto knowledge. If you ever leave the company they are pretty much fucked from then on until whatever you wrote is replaced.

Don't roll your own system.

To add on to this, it is of course necessary to have enough familiarity and competence with the basic principles of cryptography to know that you're "doing what everyone else is doing" correctly, instead of just some silly pantomime, such as: http://thedailywtf.com/Articles/Topgrade,-SHA1-Encryption.as...

But it's not necessary to understand the depths of cryptography beyond that there are various black boxes that have certain properties.

The point here is that this particular cargo cult around bcrypt (one subscribed to by some really loud people) has a shaky foundation and does not deserve its reputation. He's offering alternatives that have been better studied.

So, by all means, subscribe to a cargo cult for crypto. But pick the cult carefully.

He's wrong. (Read downthread for why I said this; my bluntness here is a mercy).

But just the existence of multiple cargo cults causes damage, because it leads people to assume that "the experts are divided." Which will lead some people to go with the wrong batch of experts, and others to just throw up their hands in confusion and store their passwords in plain text because it's too hard for them to figure out which group of experts is right.

This is a case where unanimity in the message is important. If all the experts say "use A," people will take that to mean there's no debate about the merits of A over B and C, and use A. If some say "use A" while others say "use B" or "use C", some fraction of listeners will give up and use nothing at all.

He's correct in that if you've selected bcrypt for key derivation, there's a good chance you could be doing things better (for one, its output is only 184 bits long; insufficient for AES256) where PBKDF2 works in a way where you can customize the output length.

However, the point of the bcrypt argument is not that bcrypt is the best algorithm for certain things, but that it's (at a minimum) about four orders of magnitude better than most people's "secure" password storage algorithm: sha1(password). Because it requires both a salt and a work factor, even a dictionary attack is wildly impractical unless there's a massive flaw discovered in the algorithm.

If developers are going to be trained to pick a specific algorithm for password storage, I'd much prefer bcrypt (no known flaws, many benefits) over sha1 or md5 (designed to be fast for checksumming, salt not required). Might PBKDF2 be a better choice still? Very possibly; I haven't done enough research to intelligently answer - and since this is crypto, I will not best-guess it.

My real point here? The article attacks bcrypt as a key derivation algorithm, but I've never seen someone suggest it to be used in such an application. Even the post that started what you may call the bcrypt movement (http://codahale.com/how-to-safely-store-a-password/) is linked in the article, and it's titled "How to safely store a password". It is NOT titled "How to safely derive encryption keys".

So yeah, I'm calling linkbait.

It's not better than bcrypt for password storage; it's marginally worse. See downthread.

One more example: pseudorandom number generation (non-cryptographic). There are lots of algorithms out there, and lots more you could design, but the Mersenne twister has pretty much become the first-choice algorithm.

Especially with linear congruential generators, it's easy for people who don't know what they're doing to add "extra randomization" that makes the resulting numbers worse than the originals.

It's better for most people to not get fancy and use the standard algorithm.

MT uses a lot of memory. IIRC, it's multiple KiB where 64 bits ought to do fine.

A modern CSPRNG like the SHA-3 candidate Skein can produce random data at a steady rate of only a few cycles per byte. I wonder if at some point something like that will dethrone MT for non-crypto PRNGs.

Something will dethrone the MT -- everything gets dethroned eventually. Besides what you mention, its algorithm is somewhat over-complex.

But it will be a long time before an alternative is better in a compelling way. And take a look at the list of implementations for the MT:

http://en.wikipedia.org/wiki/Mersenne_twister#Implementation...

That's not a single throne, it's a multifaceted empire.

You're defending cargo cult cryptography? If you try to use crypto without understanding it, you're at great risk of using it wrong.

The opposite turns out to be true in practice. People have the choice of using a simple crypto library interface (like BouncyCastle PGP) or "really getting to understand" AES, and so end up fielding software with vulnerabilities PGP addressed in the '90s.

A pithier way to say the same thing is, "you're right, except for the words 'without understanding it'".

This is true, but most programmers don't and won't ever get a deep understanding of crypto. For that large majority, it makes complete sense to ask "What do the people who do understand crypto use in a case like this?" and use that.

That kind of copying is clearly inferior to either gaining the knowledge to make an informed decision or hiring an expert to do it for you, but for most projects that need crypto neither one of those is practical. So, copying the experts is the best practical approach in most cases.

I can use a microwave without any understanding of its functioning, or I can try to understand electromagnetism well enough to build my own. I know which method I'd trust not to render me sterile.

It depends what level you are using it on. If you are writing crypto libraries on your own then sure you are at significant risk of screwing it up, but a good crypto library should have good defaults that will provide proper security.

Expecting every programmer who needs to build an application that stores passwords or personal information etc to have a rigorous mathematical understanding of crypto (this probably means having a PhD or similar in the subject) is just plain unrealistic.

It's sort of akin to suggesting you shouldn't allow a mechanic to change the brakes on your car without them having a detailed understanding physics.

It is very dangerous to be ignorant about critical computer science fields like cryptography and just go with the cult.

I'm not saying you should build your own cryptography, but a good hacker (or a good engineer how we call them in early 90s) should understand difference between bcrypt, PBKDF2, and scrypt. At least to understand why bcrypt is better than salt+SHA-1. And some other aspects of security.

However, if somebody has no clue about cryptography and security then she/he should go with bcrypt - but I'm not sure if that person should be responsible or in business of storing somebody's critical data at all.

That attitude is abrasively condescending.

Why not just say, "people who spent a lot of their time studying cryptography strongly recommend this approach. They feel the approach that you are considering is simply insecure."?

Framing things in terms of intelligence isn't going to win anyone over, if that's your goal. And it probably isn't accurate, either.

Sounds pretty close to accurate to me. Do you want to feel good, or do you want to choose good crypto? Pick one or the other.

He's probably using "smart" in the sense of "accumulated knowledge in a particular space" instead of in the sense of raw mental horsepower. http://news.ycombinator.com/item?id=3583985

Yes, that's right. It doesn't mean that you are hopelessly non-cognitive if you can't understand the complexities of cryptography. (As I said, I certainly can't.) It just means that unless you are one of the very few people who are 1) exceptionally mathematically talented and 2) able to have spent your entire life studying the subject, it's unlikely that you could make an informed choice.

By all means, use different wording when passing this message along if you're worried about hurting the recipient's fee-fees. But you won't be doing them any favors if you change the message to a Stuart Smalley-style "You can do it! You're good enough! You're smart enough! And gosh darn it, people like you!" Because on this specific subject, the odds are very, very, very unlikely that they actually are.

it's not necessarily about intelligence per se.

I think "smarter" in this context means more well read about the particular subject of crypto, although people good at that are likely to very intelligence all round too.

A different approach is not necessarily "less secure" it's just that it may have had less people banging on it trying to figure out ways to break it.