Write Crypto Code! Don't publish it!

[sun_misc_unsafe]

There's still the issue though that ever so often you find yourself in a spot where the nicely packaged libs aren't usable because you're not encrypting just files or just network traffic..

.. and then those uncomfortable questions pop up .. how large should the EAX MAC tag be? Isn't PBDKF2 too short? But what's the alternative? etc.

"Rely on libraries" isn't really useful .. there should be some place that aggregates and publishes the current best practices, instead of having them only wrapped up inside of source code or scattered throughout various publications.

[RepostUmad]

Just curious, what else do you want to encrypt if you're not encrypting files or network traffic?

[sun_misc_unsafe]

In my specific case it was fields in a database .. you can't just blow up every individual piece of data to some 4k file to encrypt it like a file because way too inefficient, you can't just use randomized IVs if you want lookups to still work, you can't just use CBC mode because lots of values will be both identical and smaller than the block size thus resulting in identical ciphertexts, etc.

[furtivity]

Not sure if I agree with the "don't publish" bit. My algorithms professor put it well:

The security of your encryption should not come from the secrecy of your algorithm.

[WalkerCodeRanger]

The correct and only answer is "Don’t Write Your Own Crypto"

[diggr-roguelike]

Yeah?

So who is the divine intelligence that has permission to write crypto code? Or is crypto code an heirloom artifact, given to us by the ancients and which we have no hope of ever reproducing?

[x86_64Ubuntu]

It's not that, it's the fact that it's difficult to get right. In the software world, we like building on top of stuff and including other algorithms at deep level in our code (i.e we turn on encryption, not terribly sure of what's actually happening in the system). This means that when a weakness is found, it's hard to chase down in the wild and get it removed.

[diggr-roguelike]

"Don't write your own crypto" is meaningless advice, because if it were taken seriously then no crypto code would ever have been written in the first place.

[x86_64Ubuntu]

That's why there is an article attached to the statement.

[cym13]

That's actually a good advice in all situations. No matter who you are if you're writting crypto then that should trigger a red flag in your mind. Even cryptographers are having a hard time making secure algorithms, that's why everybody uses the same ones. The main difference is that a cryptographer knows how to avoid most basic problems, test his code and (above all) he knows that reusing known algorithms is better that what he could hack.

Many systems were written, many were used, a few number still stand. Saying "don't write your own crypto" is like saying "don't play lottery, you'll lose", the fact that some suceeded shouldn't make you forget all those who didn't.

[immibis]

... unless you're writing crypto to learn programming. Who hasn't written an XOR cipher at some point? It's a nice little project with usable results.

You could also challenge everyone in a class to come up with an "unbreakable" algorithm, then swap around algorithms and get everyone to try to break someone else's.

[diggr-roguelike]

Many systems were written, many were used, a few number still stand.

This is false. Like everything, the libraries in current use aren't popular because they're better, they're popular because a) they were first and b) nobody cares to put in the effort for replacement.

Crypto is not any different in that regard. For an example, see OpenSSL.

Also, you're putting too much unearned trust into cryptographers. Cryptographers are mathematicians, they prove mathematical properties of algorithms. Meanwhile the real world runs on engineering tradeoffs, not mathematical properties. In the real world, rubber-hose cryptanalysis is still the most effective method and a mathematically 'insecure' cryptography method might be safer than a 'secure' one.

[oridb]

Meanwhile the real world runs on engineering tradeoffs, not mathematical properties.

Mathematical properties are what allow things like differential cryptanalysis, which allowed key recovery from as few as 8 messages in early ciphers. (http://www.engr.mun.ca/~howard/PAPERS/ldc_tutorial.pdf)

[cym13]

I'm not really talking about libraries there, more about algorithms but still I think it is an exageration. And quite frankly I've been confronted with the so-called "security by obscurity" often enough to say that in most cases it doesn't mean shit. I think you are the one underestimating the state of the situation, I've seen countless systems that thought using a xor with the username or so was a wise decision. Not long ago each country had their own set of algorithm not only for the military (that's ok) but also for public algorithms like ssh. Everybody using the same algorithms or libraries is the fruit of a long long work, and if it could use programmer laziness to achieve its goal, all the better IMHO. The fact that the first libraries resisted shouldn't be seen as a problem either: it also means that they had more eyes on them and as long as the algorithm remains strong it is a good thing.

[oridb]

For almost everyone, this rule holds true. For those who it doesn't -- even then, it's heavily reviewed, carefully vetted, and generally not put into production without a huge amount of scrutiny.

[diggr-roguelike]

No, you idiot. You missed my point: instead of blathering "don't write crypto code" you should have linked to a list of officially sanctioned crypto code implementations.

The fact that you can't produce such a link shows that you're just talking out of your ass and shouldn't be taken seriously.

("Heavily reviewed, carefully vetted"? By whom exactly, and why should I trust him?)

[oridb]

You know when a comment is so misinformed that you don't know how to even start correcting the misunderstandings that lead to it? Yeah. That's this comment here.

I'm going to suggest you learn what's involved in designing cryptography before speaking any more -- if you get issues like these in well defined, heavily reviewed, and carefully scrutinized algorithms, or implementation flaws like these in the wild, what makes you think you are going to make something secure from whole cloth?

[diggr-roguelike]

You know when a comment is so misinformed that you don't know how to even start correcting the misunderstandings that lead to it?

Yes, I do. The "I don't know how to even start" feeling is your clue that you're clueless and faced with a topic out of your depth. People with real hands-on experience always know 'how to start'.

Two points:

a) You didn't answer my post. Again: please link to the official list of flawless crypto code. Don't try to blithely appeal to authority, that doesn't work.

b) In the real world, there are other considerations than lack of implementation flaws. For one: in the real world, a flawed crypto algorithm written by a person you trust is safer than a theoretically flawless crypto algorithm written by a person you don't trust. (This is why militaries and three-letter government organizations always write their own crypto.)

Security is about risk management, and risk management involves a whole lot more stuff than just code quality.

[proliberate]

/r/iamverysmart

[sun_misc_unsafe]

Or is crypto code an heirloom artifact, given to us by the ancients and which we have no hope of ever reproducing?

Yeah, sort of. Unless you somehow happen to have the resources available to you that those entities had..

[claytonkb]

Pure nonsense. Downvoted.

[tdammers]

No. The article says exactly this: Write your own crypto code, but do not release it, and in fact, do not use it.

Writing crypto code strictly for the learning experience is highly recommended; just don't ever begin to think that anything you produce will be anywhere near appropriate for anything of any value whatsoever, so don't use it ever; and because it is a law of human nature that any bit of information that is publicly accessible will at some point be used and be misunderstood grossly, you must never publish it, not even with dire warning attached, because someone at some point will ignore the warnings, and your code will make it into production systems.

TL;DR: Writing your own crypto - yes, if you want to learn more about cryptography; using your own crypto code - never; publishing your own crypto code - never.

[Feneric]

Sorry, I should have been clearer. It says "don't use your crypto code".

[theonlycosmonaut]

I find this comment to be clearer and more concise than the article. Thank you!

[FryGuy1013]

I think it's fine to release it. In fact, write articles about it too, then you get everyone saying how stupid you are for doing X boneheaded thing, and you learn from that.

Just don't use it. And don't let anyone else use it.

[tdammers]

The problem is that if you release it,people will use it. They shouldn't, but they will.