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

361–370 of 409 posts

Re: How I implemented my own crypto

#361

Post by lisper »

tptacek wrote: post #357
lisper wrote: post #355

Earlier quoted context omitted.

Not to sell. But for their own use, yes, absolutely. Anybody who wants to. It turns out not very many people want to, particularly when they find out how much work it is. But almost certainly the same is true of crypto.

Not only is that not true, it's demonstrably not true: when people write code, they actively want other people to use it. By way of example, the author of the library we're discussing here, "Monocypher", has declared it "ready for production" and has a web page selling its virtues versus libsodium and NaCl. People who write crypto code as a rule are not doing it for their own edification, which is why so many more pe…

> Not only is that not true,

What is the antecedent of "that"? I think you read something into what I wrote that I didn't intend.

Re: How I implemented my own crypto

#362

Post by baby »

pornin wrote: post #359
tptacek wrote: post #349

Earlier quoted context omitted.

Ok, I'll ask Thomas Pornin myself.

I indeed learned a lot, and still learn a lot, by doing implementations. Doing a proper implementation forces me to consider all aspects; when the code runs properly, I know that I have, by definition, been exposed to all the parts. You cannot get that kind of exhaustiveness from simply reading an article. However, doing implementations is not at all the same thing as publishing implementations! The first one or two…

Thanks for the input! This reminds me of what Amelie Nothomb says: "unlike a lot of writers, I have the decency to toss most of what I write". I don't think it's necessarily bad to publish crypto code. Marketing it as secure is another thing. I've marked most of my implementations as "readable" implementations meaning that are only there for educational purposes.

Re: How I implemented my own crypto

#363

Post by ZoFreX »

catoc wrote: post #259
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…

Definition question: would you say that AgileBits (1password) are "rolling their own crypto" or 'merely' implementing proven third-party crypto?

I would have to read their source code to answer that question (I know almost nothing about 1Password). Some password managers just call a PGP executable. Others are assembling crypto primitives into larger pieces and making choices like "let's use CBC mode" themselves.

Re: How I implemented my own crypto

#364

Post by infraruby »

tptacek wrote: post #348
dahart wrote: post #333

Earlier quoted context omitted.

I see a few kinds of intermediate crypto errors possible. You can weaken the crypto without breaking it, you can leak metadata, you can screw up protocols without compromising the algorithm, etc.. But yes in some sense you're completely right, perhaps just because the aim of a crypto algorithm is so narrow? The number of things you can do right with a pair of encrypt/decrypt functions is so limited that the number of…

In the same sense that modern vulnerability research is in large part the study of leveraging the smallest possible memory corruption bug to obtain remote code execution, modern practical cryptanalysis is the study of leveraging the smallest possible unexpected behavior of any sort to full breaks in both confidentiality and integrity. By way of example: you could "weaken" an RNG so that where a construction expects a…

> You could "weaken" a protocol so that attackers can replace an original plaintext with 16 uniform random bits. If the protocol is using CBC mode, you've allowed attackers to recover whole plaintexts.

Do you have a link explaining this?

Re: How I implemented my own crypto

#365

Post by IncRnd »

pierrebai wrote: post #278
brians wrote: post #273

Earlier quoted context omitted.

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 stake…

What is the definition of "crypto" that you are using?

Re: How I implemented my own crypto

#366

Post by defen »

dahart wrote: post #312
idlewords wrote: post #286

Earlier quoted context omitted.

No, crypto is actually hard. One difference from regular programming is that there really are no 'intermediate' errors. Experience shows that getting one small detail wrong is as bad as getting the whole thing wrong. I can't think of another programming domain where that holds.

I agree crypto is actually hard. But there are lots of domains where details matter and small errors have big consequences. Vehicles, medicine, and manufacturing are all places where errors have killed people. Obviously severity depends on the situation, but generally speaking I'd rather my encryption get broken than die. Software defects in the Therac-25 radiation therapy machine killed several people [1]. Software…

Crypto software also has the property that "internal implementation details matter". Nearly all other software does not have this property - you don't care how your hardware/software multiplies two numbers; only that it does it correctly in a reasonable amount of time. That property does not hold for crypto software - the nature of your multiplication may actually leak information, depending on how it is implemented. So in a way crypto software goes against the entire edifice of modern software engineering, which says that you can build software against an abstract lower-level "stack" and generally not care how the lower parts work.

Re: How I implemented my own crypto

#367

Post by [deleted] »

lisper wrote: post #301
tptacek wrote: post #295

Earlier quoted context omitted.

If someone posted a message on HN about doing DIY appendectomies with Arduino-controlled robots and I pointed out that you need to go to med school to do surgeries, you would not in fact be harping on me for not having explained why.

Not at all. If I don't know how to sign up for med school, I can find out by searching for "How do I sign up for med school?" or even "How do I become a doctor?" If I search for "How do I sign up for crypto school" the results are far less helpful.

[deleted]

Re: How I implemented my own crypto

#368

Post by tptacek »

lisper wrote: post #361
tptacek wrote: post #357

Earlier quoted context omitted.

Not only is that not true, it's demonstrably not true: when people write code, they actively want other people to use it. By way of example, the author of the library we're discussing here, "Monocypher", has declared it "ready for production" and has a web page selling its virtues versus libsodium and NaCl. People who write crypto code as a rule are not doing it for their own edification, which is why so many more pe…

> Not only is that not true, What is the antecedent of "that"? I think you read something into what I wrote that I didn't intend.

You said that it's almost certainly the case that people building their own crypto are doing it solely for their own purposes and that people won't even bother to complete their work. Obviously: no.

Re: How I implemented my own crypto

#369

Post by tptacek »

infraruby wrote: post #364
tptacek wrote: post #348

Earlier quoted context omitted.

In the same sense that modern vulnerability research is in large part the study of leveraging the smallest possible memory corruption bug to obtain remote code execution, modern practical cryptanalysis is the study of leveraging the smallest possible unexpected behavior of any sort to full breaks in both confidentiality and integrity. By way of example: you could "weaken" an RNG so that where a construction expects a…

> You could "weaken" a protocol so that attackers can replace an original plaintext with 16 uniform random bits. If the protocol is using CBC mode, you've allowed attackers to recover whole plaintexts. Do you have a link explaining this?

I'm describing the CBC padding oracle attack.

I'm surprised this is the thing you want the link for, and not "1 biased bit destroys the security of a 256 bit nonce where the other 255 bits come from secure random".

Re: How I implemented my own crypto

#370

Post by IncRnd »

jmulho wrote: post #223
dsacco wrote: post #196

Earlier quoted context omitted.

I'm sorry, I don't understand what you're trying to say. Can you clarify? What I am trying to say is that you gain nothing by, say, implementing your own encryption algorithm, using it on a plaintext, then encrypting the resulting ciphertext with a known good implementation of a known good algorithm like AES. That is how I interpreted your previous comment. So - you don't gain anything from that, if that's what you m…

> "If you mean just implementing a known good algorithm on your own (again, like AES) - why? You are overwhelmingly more likely to shoot yourself in the foot" I've never understood this argument. Encryption algorithms are deterministic. If you implement a known good algorithm on your own, and it gets the same outputs given the same inputs, then you are highly unlikely to shoot yourself in the foot. This is not what p…

> Encryption algorithms are deterministic. If you implement a known good algorithm on your own, and it gets the same outputs given the same inputs, then you are highly unlikely to shoot yourself in the foot. This is not what people are talking about when they warn not to roll your own crypto.

That is exactly what people mean by "don't roll your own crypto." If your belief is that you only need to match the same output per input, then your implementation might be an oracle that leaks information.

Crypto people don't say this for job security or to feel important. They say it, because they, themselves, have made mistakes, and they constantly see examples of programs that trivialize both security and cryptography while simultaneously introducing foreseeable bugs and obviously weak crypto.

Post reply on HN