Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How I implemented my own crypto

loup-vaillant.fr

Post reply on HN
Print view View original

271–280 of 409 posts

Re: How I implemented my own crypto

#271

Post by JohnStrange »

the_stc wrote: post #198
ramphastidae wrote: post #188

Earlier quoted context omitted.

> How do you handle biased entropy input from that hairdryer someone is blowing on your chips? Sounds fascinating. Can you please tell us more?

If you had a RNG that sampled some hardware noise but then you altered the environment by introducing extreme temperatures, maybe the RNG would end up with biased output. A simple example: you can use a camera as a good source of randomness, even taking a picture of a wall indoors. But if an attacker was able to flood that room with light and overwhelm your sensor, he could predict the image would be 100% white pixel…

Well, to be fair, a good implementation should throw some simple statistical sanity checks at RNG input during self-test and throw an error when it doesn't pass. Passing such tests doesn't indicate that the RNG is cryptographically secure, but failing them indicates that it is insecure.

Re: How I implemented my own crypto

#272

Post by curun1r »

loup-vaillant wrote: post #177
Piskvorrr wrote: post #121

Earlier quoted context omitted.

Note that the author is not inventing crypto algorithms, rather implementing them (although the part about XChaCha20 being a mix of ChaCha20 and XSalsa20 is IMHO dancing on the line). Still a risky business, and tricky to get right, but several orders of magnitude safer than "hey, what if we just XORed everything with a random number? Unbreakable, eh?"

> the part about XChaCha20 being a mix of ChaCha20 and XSalsa20 is IMHO dancing on the line It was a few months ago. Then Libsodium danced on the same line, and I was able to compare the results (they behave the same, phew). It's not inventing crypto either: it's a straightforward application of what was done to Salsa20. The security reduction that worked for XSalsa20 (guaranteed secure if Salsa20 is secure) applies…

> Then Libsodium danced on the same line, and I was able to compare the results (they behave the same, phew).

Do they really? What about timing attacks? Does all your code run in constant time? If not, there's a whole class of vulnerability that basically will only be found when experienced attackers have a chance to poke at it. Timing attacks are a great example of why "don't roll your own crypto" is sound advice. No amount of testing your library against a reference library will uncover them.

Re: How I implemented my own crypto

#273

Post by brians »

lisper wrote: post #258
tptacek wrote: post #240

I would like to clarify: The thing that I said was "table stakes" for implementing cryptography was passing the algorithm test vectors , which this author's previous post claimed as a security feature. If you're unfamiliar with the concept, a test vector is a series of strings and intermediate values used to ensure that your (say) OCB3 is the same as everyone else's OCB3. Had he asked, I'd further claim that not havi…

> You just have to know what a carry propagation bug is This is one of the things that drives me nuts about the crypto community. The natural response upon reading, "You just have to know X" if you don't already know is to go search for X. Well, if you go search for "carry propagation bug" you will find lots of examples of carry propagation bugs being found and fixed, but no explanation of what one is. The thing that…

Carry propagation is one pixel in the 4K movie that is safe crypto implementation. One reason not to link to trivia and factoids about safe crypto implementation is that it builds a dangerous false sense of competence.

There are programs that teach this, but they take years. Nobody who's passed through that is interested in creating an easy scaffolding whose levels are unclear.

Re: How I implemented my own crypto

#274

Post by moosingin3space »

willtim wrote: post #25
thinkMOAR wrote: post #18

Earlier quoted context omitted.

Curious about the other language. What other language that doesn't add another layer between the code and system instructions were you thinking about?

OCaml was used recently by the MirageOS folks to implement a better TLS than OpenSSL.

TLS != crypto. TLS is actually very well-suited for a higher-level language like Rust or OCaml, especially due to how state machine patterns can be expressed safely in those languages. Crypto, on the other hand, often relies on low-level intrinsics to get good performance and cache timing attack resistance.

Re: How I implemented my own crypto

#275

Post by Kalium »

lisper wrote: post #258
tptacek wrote: post #240

I would like to clarify: The thing that I said was "table stakes" for implementing cryptography was passing the algorithm test vectors , which this author's previous post claimed as a security feature. If you're unfamiliar with the concept, a test vector is a series of strings and intermediate values used to ensure that your (say) OCB3 is the same as everyone else's OCB3. Had he asked, I'd further claim that not havi…

> You just have to know what a carry propagation bug is This is one of the things that drives me nuts about the crypto community. The natural response upon reading, "You just have to know X" if you don't already know is to go search for X. Well, if you go search for "carry propagation bug" you will find lots of examples of carry propagation bugs being found and fixed, but no explanation of what one is. The thing that…

Is it possible that you are expecting the cryptography community to be one organized around being newbie-friendly and encouraging to beginners?

The crypto community has repeatedly been burned by overeager beginners with false senses of competence making rather nasty mistakes. Consequences can be dire, from destroying companies to getting people killed. On the lighter end, you have things like Decrytocat.

In some arenas, it's appropriate and a good practice to assume that everyone reading is a beginner who needs 101-level info on everything. Webdev is a good example - CSS, or cascading style sheets, are good for handling the display logic of semantic markup. The stakes are low and the costs for screwing up trivial. With cryptography, it needs to be driven home to the idle reader that this is serious stuff.

Re: How I implemented my own crypto

#276

Post by curun1r »

JohnStrange wrote: post #146
ZoFreX wrote: post #75

I am terrified that I do not consider myself competent enough to write a crypto library, and yet there isn't a single mention - in this article, nor at the time of writing the comments here on Hacker News - of many of the pitfalls I know to avoid when undertaking such an endeavour. There is even a list of "you have to do A, B, C, and that's about it" that is missing some major - well known, even! - items. I know "don…

I apologize if that sounds dismissive (it's not intended to) but your post is not more than the usual vague FUD. Take a look at so-called 'professional' cryptographers and their libraries, and you'll find that practically all of their code had severe bugs. Professionals make errors like everyone else, 'professional' just means you're being paid for it. You will have a hard time finding a professional and widely used…

Having implemented crypto algorithms for educational and enjoyment purposes, I've always looked at "don't roll your own crypto" as less having to do with the actual writing of code which, as you state, isn't really that hard. Instead, what that statement is saying is that when you write your own code, you'll almost never get enough attention from the white-hat community to have any confidence that the code can be used in production.

You're right that the code written by professionals has lots of bugs. Bug is a term that describes a problem in code that has been found. With crypto software, the danger isn't the problems that get found (and then addressed), it's the problems that aren't found. "Roll your own" solutions have problems that never get found. That's the danger and it has nothing to do with the skill of the programmer.

Re: How I implemented my own crypto

#277

Post by dankent »

JoachimSchipper wrote: post #268
dankent wrote: post #216

Earlier quoted context omitted.

I am aware of the usual (and strong in my opinion) argument. Every time this discussion does the rounds, though, I do wonder whether the hypothesis could be tested. Most vulnerabilities do not come from breaking the core algorithm but rather from a flaw in how they are implemented or applied. Standardisation can lead to monocultures that become tempting targets for those with plenty of resources to throw at them.

> I do wonder whether the hypothesis could be tested Data point: everyone who evaluates crypto constructions says not to roll your own.

That's what leads me to being reasonably sure the hypothesis is valid.

As a scientist, though, I'm always going to wonder whether there is a way to subject it to a proper test rather than just relying on opinion (no matter how much I respect those opinions)

Re: How I implemented my own crypto

#278

Post by pierrebai »

brians wrote: post #273
lisper wrote: post #258

Earlier quoted context omitted.

> You just have to know what a carry propagation bug is This is one of the things that drives me nuts about the crypto community. The natural response upon reading, "You just have to know X" if you don't already know is to go search for X. Well, if you go search for "carry propagation bug" you will find lots of examples of carry propagation bugs being found and fixed, but no explanation of what one is. The thing that…

Carry propagation is one pixel in the 4K movie that is safe crypto implementation. One reason not to link to trivia and factoids about safe crypto implementation is that it builds a dangerous false sense of competence. There are programs that teach this, but they take years. Nobody who's passed through that is interested in creating an easy scaffolding whose levels are unclear.

I wish the meme that crypto is hard would just die.

The reason is that the statements is wrong and is probably encourage exactly what it wants to discourage. Crypto is hard is not factually incorrect. The problem is that it is trivially correct, because programming is always hard. Every algorithm and design is hard to get right.

The correct statement, and the one that should be repeated instead is that crypto's stakes are high. Getting it wrong carries bigger consequences than a normal program.

So stop propagating that crypto is hard. (Because people do hard stuff everyday and might thus think they've got the right stuff to write crypto.)

Say that crypto has too high stakes to be done off the cuff.

Re: How I implemented my own crypto

#279

Post by tptacek »

baby wrote: post #246
tptacek wrote: post #236

Earlier quoted context omitted.

This is a deeply misleading list. Daniel Bernstein, Daniel Bleichenbacher, Dan Boneh and Thomas Pornin are professional cryptographers and world-renowned experts. Even I would feel comfortable writing crypto if Bleichenbacher was watching behind my back. Frank "wrote" libsodium, but libsodium is effectively a port of NaCl. Frank had Daniel Bernstein watching behind his back. Eric Young wrote OpenSSL. Look how that tu…

> are professional cryptographers and world-renowned experts They were not in the beginning. And implementing crypto helped them get there. That's my point. > Finally: you obviously know that "writing your own crypto" isn't the only way to become good at it. In fact, it's a terrible way to get good at it. The right way to get good at crypto is to learn how to break it. I strongly disagree with you on this, but I'll a…

I would suggest that for each of them, a 10+ year career in academic cryptography, in each case accompanied by significant new research results, is what helped them get there. Implementing a library, not so much.

As for your second point: literally everyone can implement cryptography that appears secure to them. It's tautological.

Re: How I implemented my own crypto

#280

Post by tptacek »

Kalium wrote: post #275
lisper wrote: post #258

Earlier quoted context omitted.

> You just have to know what a carry propagation bug is This is one of the things that drives me nuts about the crypto community. The natural response upon reading, "You just have to know X" if you don't already know is to go search for X. Well, if you go search for "carry propagation bug" you will find lots of examples of carry propagation bugs being found and fixed, but no explanation of what one is. The thing that…

Is it possible that you are expecting the cryptography community to be one organized around being newbie-friendly and encouraging to beginners? The crypto community has repeatedly been burned by overeager beginners with false senses of competence making rather nasty mistakes. Consequences can be dire, from destroying companies to getting people killed. On the lighter end, you have things like Decrytocat. In some aren…

Decryptocat isn't the lighter end of things. Snowden used it to communicate with Glenn Greenwald's associates during the same time period Decryptocat was found (there are worse flaws in that software than Decryptocat, by the way).

Now you see the issue!

Post reply on HN