Hacker News new | past | comments | ask | show | jobs | submit login

The "Don't roll your own crypto" mantra is overly ambiguous and enforces the culture of elitism in information security. I hope that something displaces this regurgitated "advice" with something more helpful. I know Moxie's article is a few years old but it is a step in the right direction regardless.

--EDIT--

I don't think I was perfectly clear in my original comment. I attempted to expand on my position in a follow-up comment: https://news.ycombinator.com/edit?id=9376131




>enforces the culture of elitism in information security

The NSA is elite. Nobody has any business trusting you to outsmart them unless you are also elite.

This is like complaining that nobody will bet on you to defeat Gary Kasparov means there is a culture of elitism in chess. Of course there is. It's a game of skill. Other people are more skilled than you, by a lot, and you're probably going to lose.


> This is like complaining that nobody will bet on you to defeat Gary Kasparov means there is a culture of elitism in chess.

A closer analogy would be berating everyone who tries to play chess unless they studied it for years and they are professional and renowned chessographers. :)

Edit: If we're going to stretch the chess analogy further, it's important to note that the best chess players come from a very chess-positive culture, where many people grow up playing the game from a very young age.


>tries to play chess

Go ahead and play chess for fun, certainly, and you might become one of those grandmasters eventually, it's just that you shouldn't be betting people's privacy and potentially safety on the proposition that you already are one when you start.


The modern argument isn't "don't roll your own crypto". It's "don't build with crypto until you've learned how to break crypto". There are plenty of resources for people to learn how to do that online. Skipping that step and then shipping weak crypto is inexcusable.


I agree but you are the first person I've seen frame it in that way. I see people spew "don't roll your own crypto" often. Hopefully some variation of your "modern argument" becomes more prevalent in the near future. It is certainly more meaningful.


Ok, and thank you for listening to me, but let me just add that in every instance I know of where someone has been berated for shipping crypto without having a background in it, those people also hadn't taken the time to learn how to break crypto.

So agree that the argument you're calling out has the potential to be harmful in the long run, but do not agree that it has harmed anyone we know of, and would add that it has --- to the extent it's warded people off things like Cryptocat --- helped end-users.


Don't over-value being able to break crypto, though. Yes, it'll get people to skip the unauthenticated CBC, but exploiting a padding oracle is no guarantee that you'll be able to write e.g. a proper secure boot system, a fast and secure implementation of a low-level primitive, or that you'll get forward-security right - and there are quite a few levels above that...


The thing like going through all of the http://cryptopals.com/ exercises is that it raises your overall awareness (as of specific attacks) that this stuff is much more breakable than I thought. It is more enlightening than just how to protect against a specific attack.


What about using existing crypto libraries (such as OpenSSL) to add crypto to an existing project? I'm adding encryption to an open source backup tool I'm working on, planning on using AES from OpenSSL. Would it be enough to document exactly what I'm doing, and put out a call for an audit of the methods that are being used? I really want to make sure I get this right.


You are probably going to get it wrong, not because there's anything bad with you, but because standard crypto libraries are too fine grained. The primitives are too low level, and you have to assemble sequences of calls in the right order and be in the watch for unexpected side effects.

I could tell you how I have gotten it wrong in the past, but there is no guarantee that I won't get it wrong again in a different way. So, the audit idea has it's merits, but you really want not to rely on the Linus Law of eyeballs. That means knowledgeable auditors who charge actual money for their time.


Same as "rolling your own crypto"; in fact, that's generally, except in extreme cases, exactly what we're referring to when we talk about people rolling their own.


So what are my options then? I could put out an initial version that shows what I want to accomplish, then either have it reviewed heavily, or see if I can get someone who's more of an expert to give it a go based on those specifications. Here's the problems I have so far, which I know I'm out of my depth:

1) In order to keep the backup software's deduplication functionality (and to minimize the server trusting the client), I need to have the IV (initialization vector) be a computed value based on the file's contents (so that multiple copies of the same file on the clients will encrypt to the same contents going to the backend server). I know that _This will leak some data_ (i.e., you may not want an attacker to know that a given set of files are the same contents). So I plan on making this optional -- either the user gets to take advantage of dedup, or better encryption.

2) To do number 1 above, I was planning on taking a hash of the file, encrypting that with the users key, then using that as a predictable IV. You will still have a unique IV per unique file, but I don't know enough to see if this can leak any other data. It looks like RFC 5297 describes an approach similar to this, but I think it is for a different use case.

3) I need the backup server to know which version of an encryption key the client used. That is, if the client changes keys between backups, I need the server to instruct the client to do a full backup, not incremental. So I can either have the client provide a version number for the key (or if using a keyfile, use the datestamp of the file as a version string), or I can encrypt a given string using the key, and use a hash of the encrypted string as the key version number. (Note, in no case will I ever be storing a hash of the plaintext of the client's files on the backup server, as that too can leak information)

My apologies if the above makes any experts here cringe, but as I mentioned my constraint is to have same-content files encrypted to the same target contents (for dedup purposes), although I will give the user to turn that off and use a random IV for better security (and give up dedup).


I could not disagree with you more.

Maybe you could suggest what might be "more helpful" but I personally could not think of anything more useful that than telling people to not do something that puts their customers' and their own critical information at risk.

Good crypto algorithms don't get stale or anything. The point is they're fundamentally difficult.

Perhaps you could give a single decent reason for rolling your own crypto algorithm, vs something as easy as 4096 bit RSA or something.


I certainly agree with you. I just think the "don't roll your own crypto" advice is overly ambiguous. Ironically, I think my original comment was ambiguous as well. Let me clarify. I'm not endorsing rolling your own cryptosystem (e.g. a replacement for RSA). Rather, I think the advice should often be paired with additional insight on what "rolling your own" means. When building some sort of software, not everyone (currently) has the luxury of a cryptographic library that handles everything painlessly.

For example, I think most would say that I'm not "rolling my own crypto" if I'm implementing some piece of functionality in my application leveraging the use of some API with "mac", "encrypt", and "decrypt" functions. There are still ways I can screw up using these functions, but I'm arguably not "rolling my own" crypto. So in this situation, the mantra is confusing at best.


Maybe; but handing a MAC to generalist developers is going to end in a timing attack, like http://rdist.root.org/2009/05/28/timing-attack-in-google-key.... (And Keyczar is not amateur hour!)


I don't know anyone who has ever taken "don't roll your own crypto" to mean "don't write things that use crypto".


> Perhaps you could give a single decent reason for rolling your own crypto algorithm, vs something as easy as 4096 bit RSA or something.

I would not characterize implementing RSA safely as an "easy" task.


Which is part of what's meant. Don't create your own crpyto algorithm and don't write your own implementations of existing algorithms. There are so many gotchas that it would take a lot of effort to get something that's less buggy even than the much-maligned OpenSSL. Someone (I don't remember who) said that even typing the letters "RSA" is too close to rolling your own crypto.


Excuse my ignorance, but why aren't there options for salting / seeding / external RNG alternatives to crypto algorithms?


This.

The problem is that in this community you are witch-hunted if you talk about crypto and you are not a famous cryptographer.

People start with the assumption that what you are saying is wrong (this is a good thing). But then many don't have the competence to judge what you are saying (no problem. we all are ignorant in many subjects). And then, they react as if you were really wrong (this is a huge problem).


> People start with the assumption that what you are saying is wrong (this is a good thing). But then many don't have the competence to judge what you are saying (no problem. we all are ignorant in many subjects). And then, they react as if you were really wrong (this is a huge problem).

I've been dealing with crypto on a near-daily basis for the last 15 years. I'm well within the top percentile of understanding of the subject, from a theoretical and practical standpoint, having worked to break cryptographic protocols for most of my life. I wouldn't trust myself to design a crypto protocol for grocery lists, let alone anything important.

This isn't false modesty or elitism or ignorance. It's recognizing that even if every smart person I know looks at it and says it's fine, it probably isn't. Crypto isn't hard to get right -- that's actually not the argument that anyone will make -- but it's impossible to know if you did get it right or not.

You do not have the knowledge required to build safe cryptographic protocols. Neither does anyone else on this site.


I think to say we can't build safe cryptographic protocols is too strong. I'd say that it's very hard to design safe systems from the ground up. But it's still possible to realistically and practically work around certain threats without opening another vulnerability.


It's not realistic, because you will never consider every possible attack scenario. You may have considered timing attacks, but if you don't consider the way that the processor uses power when running through your algorithm, you may have just leaked key material. This sounds like an obscure case, right? Except that the Trezor bitcoin security appliance was just broken in that way last week.

Secure crypto comes from a lot of smart people repeatedly trying to destroy an algorithm and its implementation. It doesn't come from a super smart person building a cryptosystem; that's how we end up with DVD CSS.


The attack scenarios you described are against an implementation whereas I said your statement regarding protocols was too strong. Having that in mind, our comments don't disagree.


The format of a discussion does not necessarily have to follow a strict pattern of point->counterpoint->point->counterpoint->win in order to be meaningful or useful to the participants and spectators.


It's really not that hard, huh? Do you have some evidence or solid reasoning? Given that this is a hard question to get objectivity on, do you think you have more experience with crypto than daeken? If no, you should probably update your beliefs to consider daeken's opinion, rather than repeat your own without substantiation.


> You do not have the knowledge required to build safe cryptographic protocols. Neither does anyone else on this site.

You'd probably be right on any other site; but I'm guessing there are a few people who do this for a living somewhere on HN.


> there are a few people who do this for a living somewhere on HN.

And Daeken would still be right.

You skipped over daeken's point, which would stand on HN or crypto.stackexchange.com where there are undoubtedly people more qualified to talk about crypto than HN.

Crypto is impossible to know if you got it right. Read that again. It's impossible to know that you got it right.

If you get it really wrong it'll be obvious to a competent cryptoanalyst, but if you get it a tiny bit wrong, and this is computer security related, so 'tiny bit wrong' is likely bad enough to render your protocol unusable, then it won't come out at first or second glance, and may even stand up to some fairly rigorous scrutiny.

Even RSA which has stood the test of time since 1977, is only considered 'safe' in so far as there's no algorithm better than brute force for factoring products of large primes - if someone came out with an algorithm tomorrow that trivialized factoring numbers, RSA would quickly get moved to the 'unsafe' list. And that's just on the crypto primitive.

There's all sorts of manner of other attacks against an implementation of a protocol to be considered too.


> Even RSA which has stood the test of time since 1977, is only considered 'safe' in so far as there's no algorithm better than brute force for factoring products of large primes

https://en.wikipedia.org/wiki/General_number_field_sieve but most of your point still stands. RSA is edging slowly closer to the abyss.


That's actually the point, though. People that do this for a living will agree with me on this. They don't have the knowledge individually to make secure crypto. Secure crypto comes from lots of smart people and a lot of battle testing; the idea of one person making secure crypto protocols/implementations is completely ludicrous.


> culture of elitism

Reality is elitist. You either know how to do things or you don't, and if you don't, you fail. Sometimes you fail anyway. That's elitism.





Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: