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

371–380 of 409 posts

Re: How I implemented my own crypto

#371

Post by tptacek »

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…

I've found that a good motivation for writing learning-only "throwaway" crypto code is as models for writing attack code; you don't even have to throw the code away, just publish it with the exploit.

But then, I'm a believer that everyone should learn crypto by breaking it, and clearly not everyone agrees with me.

Re: How I implemented my own crypto

#372

Post by [deleted] »

marcosdumay wrote: post #228
ZoFreX wrote: post #179

Earlier quoted context omitted.

Game companies are a great example because: 1) they invest 6 or 7 figures in this (piracy prevention is big money) 2) they still get it wrong 3) they not only get it wrong, they get in wrong in ways that teenagers still in high school can break, let alone the NSA

The fact that piracy prevention can not be solved does not help them.

[deleted]

Re: How I implemented my own crypto

#373

Post by lisper »

tptacek wrote: post #368
lisper wrote: post #361

Earlier quoted context omitted.

> 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.

I wrote "almost certainly the same is true of crypto" meaning that almost certainly very few people actually want to implement crypto (just as very few people actually want to build airplanes) for any reason, and so the desire to do so serves as a pretty effective filter to eliminate "random people" doing it.

Of those few who want to do it, some will want to do it for personal reasons and some will want to do it for commercial reasons, just as in aviation.

Re: How I implemented my own crypto

#374

Post by loup-vaillant »

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…

> Improper carry propagation is an example of the kind of security vulnerability for which there are no test vectors

I beg your pardon?

Some tests vectors from the RFC are designed specifically to handle some overflow that if handled improperly will give you the wrong results. I have checked, this hits the relevant paths. Or were you talking about something else?

By the way, I haven't attempted to implement curve25519 field arithmetic myself, that would have been suicide (compared to curve25519, Poly1305 is a piece of cake). It all comes from ref10, minus the left shift UB it had.

> which this author's previous post claimed as a security feature.

Here's my current view on security: correct software is secure, period. Vulnerable software is incorrect, period.

Which means that anything that helps assert correctness is a security feature. Test vectors, sanitisers, static analysis, Valgrind… are all security tools, and passing any one of them increases confidence in the product, thus making it more secure. Add enough of these, and confidence gets close enough to 100% that we can deem it ready for production.

So, yeah, test vectors are a security feature. Laughably insufficient by themselves, but still necessary to assert the security of a crypto suite.

> Had he asked, I'd further claim that not having dumb C bugs is also table stakes for cryptography

Yeah, sorry about that. I assumed the same, but I thought Valgrind had me covered at the time —oops. Using sanitisers on Monocypher has been quite the eye opener. I didn't realise how dangerous I used to be.

I still have my doubts, by the way. While I would gladly trust Monocypher with my data by now, I don't dare openly recommending it over Libsodium just yet. That may have to wait for a serious external audit.

Re: How I implemented my own crypto

#375

Post by dahart »

defen wrote: post #366
dahart wrote: post #312

Earlier quoted context omitted.

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

Yeah, that's a great point, security requires that you understand the insides of any dependencies, and treating any part as a black box is a bad idea.

I think performance critical code sometimes shares this particular side of engineering and it's inability to fit into the easy patterns and abstractions we usually prefer.

Re: How I implemented my own crypto

#376

Post by tptacek »

loup-vaillant wrote: post #374
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…

> Improper carry propagation is an example of the kind of security vulnerability for which there are no test vectors I beg your pardon? Some tests vectors from the RFC are designed specifically to handle some overflow that if handled improperly will give you the wrong results. I have checked, this hits the relevant paths. Or were you talking about something else? By the way, I haven't attempted to implement curve2551…

I feel like I'm reading you again claiming that the test vectors for an algorithm in the standards documents constitutes a battery of security tests for the algorithm. That's not the case; I think 'lisper will tell you the same thing, despite being much more on your side of this issue than I am. Test vectors are an implementation aid and mostly intended for interop.

And yes, I believe I'm talking about a more complicated class of bugs than you are. For instance: OpenSSL's algorithm implementations pass test vectors (OpenSSL is FIPS certified, too). But OpenSSL has had recent carry propagation bugs.

I am not concerned about your use of C, or about the presence of memory corruption bugs in your library. If I was going to harp on about that, I'd also have to go after everyone who's written a Markdown library. My concern is that the kinds of things you say you've done to ensure the security of your cryptography don't address real cryptographic vulnerabilities.

You may have done other things and I just haven't read about them! I don't really care about your library one way or the other; the only thing I care about is the idea that if you pass test vectors and Valgrind is OK with your binary, you're probably OK. No!

Re: How I implemented my own crypto

#377

Post by charleslmunger »

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…

They are deterministic, but timing attacks are a big deal. There were lots of practical key extraction attacks on RSA with nothing but timing, even on a network.

You can also do things like forget input validation in ways that reveal key material, or reuse a nonce or IV in a way that breaks the whole system.

Re: How I implemented my own crypto

#378

Post by infraruby »

tptacek wrote: post #369
infraruby wrote: post #364

Earlier quoted context omitted.

> 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".

> I'm describing the CBC padding oracle attack.

Ah! Wouldn't that be "attackers can replace an original ciphertext with two chosen blocks"?

> 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".

IIRC the link for that is in your hiring post!

Re: How I implemented my own crypto

#379

Post by mrb »

ktta wrote: post #36

I'm amazed that the reference implementation of Argon2 had a bug. So that means anyone who deployed Argon2 today didn't really use Argon2 (I'm being pedantic), but something else? libsodium also got it wrong, so that brought down my opinion of it being a trusted and well-reviewed library. Now the question is, will they continue to use the same implementation or move to the fixed code?

Those who deployed Argon2 must have deployed the reference implementation, therefore the code became the de facto standard. Khovratovich confirmed in https://github.com/P-H-C/phc-winner-argon2/issues/183#issuec... that the code is the de facto standard and the spec will be edited to reflect this.

libsodium implemented the same behavior simply because it reused the Argon2 reference implementation.

Re: How I implemented my own crypto

#380

Post by jmulho »

bascule wrote: post #230
jmulho wrote: post #223

Earlier quoted context omitted.

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

Just because an AES implementation matches the test vectors does not make it correct or safe. Here is an excellent visual depiction of several different AES implementations, many of which do not run in constant time: https://cr.yp.to/mac/variability1.html Implementing AES with variable time secret-dependent operations can leak the key. There are much bigger and more terrifying subtleties to implementing crypto correc…

> "Just because an AES implementation matches the test vectors does not make it correct or safe."

Actually, this does make it correct. Whether or not it is safe depends on the application. For example, I sent my friend Bob some cyphertext that I calculated by hand with a pencil and paper using the AES algorithm. I sent it via my trusted courier Eve. It took four hours for me to do the calculation. At the last minute I started to second guess my math so I double checked it against a respected crypto library. It was fine, so I handed it off to Eve. I am pretty sure that in this application my choice to calculate the answer by hand was exactly as safe as if I had just used the library. In fact, I am so sure (given that the answers were identical), that just as Eve was walking out the door, enroute to Bob, I pulled her close and whispered in her ear: "Eve, be very careful with this cyphertext, it took me four hours to create it."

Post reply on HN