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

401–409 of 409 posts

Re: How I implemented my own crypto

#401

Post by tptacek »

loup-vaillant wrote: post #384
tptacek wrote: post #376

Earlier quoted context omitted.

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

I'll look up this carry propagation business, but again, this looks like a mundane correctness issue (with possibly tragic consequences), though it is hard to assess without looking at intermediate results (I have). Also, didn't the carry propagation bug reports come with failing tests vectors? Or are they hard to find even if one knows of the bug? > the only thing I care about is the idea that if you pass test vecto…

No, they didn't come with failing test vectors. They're implementation specific.

I'm less worried about Poly1305 --- but then: why would you write your own Poly1305 in C? There's already a fast open Poly1305.

My advice is: go do the research about how these bugs are found and exploited, and then declare your library free of them and "production-ready".

Re: How I implemented my own crypto

#402

Post by tptacek »

tptacek wrote: post #349
baby wrote: post #347

Earlier quoted context omitted.

I can't share this kind of personnal information Thomas. I'm sure you understand! I guess you'll have to take my word for it.

Ok, I'll ask Thomas Pornin myself.

(rereading this, I feel like I should add: 'baby works with Thomas Pornin now.)

Re: How I implemented my own crypto

#403

Post by grymoire1 »

jmulho wrote: post #380
bascule wrote: post #230

Earlier quoted context omitted.

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…

And how do matching test vectors ensure there are no timing attacks? Or memory leaks that disclose private keys?

Re: How I implemented my own crypto

#405

Post by baby »

super-io wrote: post #400
baby wrote: post #131

Earlier quoted context omitted.

Writing your own crypto is the only way to become good at it, or to understand more about crypto. * DJB wrote NaCl * Frank wrote libsodium / libHydrogen * Brian wrote Ring * Thai Duong and Bleichenbacher wrote Tink * Eric Young wrote OpenSSL * Jason Donenfeld wrote Wireguard * Shoup wrote NTL * Emily Stark, Mike Hamburg and Dan Boneh wrote SJCL * Thomas Pornin wrote 6 SSL libraries and then BearSSL * Adam Langley wro…

"libsodium" is just NaCl with autoconf cruft added. NaCl does not use autoconf nor even make. It is not necessary but if someone really feels compelled to use it, why stop them? I have never seen any author or end user comment that they dislike using autoconf, or write alternatives to it. Autoconf is loved by all, isn't it? I think what you could say is that using NaCl in your own software is the only way to get good…

He wrote libhydrogen

Re: How I implemented my own crypto

#406

Post by sn9 »

peterwwillis wrote: post #358
lisper wrote: post #324

Earlier quoted context omitted.

I do sincerely apologize for taking my frustrations out on you, because you have indeed gone above and beyond the call to help make crypto accessible. Nonetheless, I still stand by the substance of my comment: when you (not you specifically, but anyone) say, "You have to know X" you should check that doing a Google search for X yields some reasonable results, and if it doesn't, provide a hint on how to proceed.

> Nonetheless, I still stand by the substance of my comment: when you (not you specifically, but anyone) say, "You have to know X" you should check that doing a Google search for X yields some reasonable results, and if it doesn't, provide a hint on how to proceed. Do you actually believe you are personally entitled to demand special research tips from domain experts?

I don't think it's too much to ask for links to resources.

If it's a common enough remedy that needs linking, you could just write a dedicated blog post describing the recommended resources or whatever and just link to that.

Sometimes the hard part of researching things is knowing what to look for or where to look for it.

Re: How I implemented my own crypto

#407

Post by loup-vaillant »

tptacek wrote: post #401
loup-vaillant wrote: post #384

Earlier quoted context omitted.

I'll look up this carry propagation business, but again, this looks like a mundane correctness issue (with possibly tragic consequences), though it is hard to assess without looking at intermediate results (I have). Also, didn't the carry propagation bug reports come with failing tests vectors? Or are they hard to find even if one knows of the bug? > the only thing I care about is the idea that if you pass test vecto…

No, they didn't come with failing test vectors. They're implementation specific. I'm less worried about Poly1305 --- but then: why would you write your own Poly1305 in C? There's already a fast open Poly1305. My advice is: go do the research about how these bugs are found and exploited, and then declare your library free of them and "production-ready".

> why would you write your own Poly1305 in C?

I originally didn't. But when I noticed it was designed to facilitate 32-bit limbs, I couldn't resist. The result is pretty simple.

I also figured it would perform well, though it currently seems to be 20% slower than Donna (32-bit version). I'll try to find why (I can think of 2 causes: sub-optimal loading code, and crappy data flow in the main carry operation. If it's the latter, I'll use the Donna implementation.)

EDIT: I tweaked the loading code again, it's even faster now. I'm now 7% than poly-donna-32 (and 5% faster than libsodium). My implementation is also simpler. I'm keeping it.

> go do the research about how these bugs are found and exploited,

I'd have to know how.

My first searches turned up no methodology —just instances of such bugs being found. And again, this is just a correctness issue. One just have to prove the whole thing works as intended (even informally). I wouldn't trust myself to do it for curve25519, but poly1305 was doable.

Re: How I implemented my own crypto

#408

Post by peterwwillis »

sn9 wrote: post #406
peterwwillis wrote: post #358

Earlier quoted context omitted.

> Nonetheless, I still stand by the substance of my comment: when you (not you specifically, but anyone) say, "You have to know X" you should check that doing a Google search for X yields some reasonable results, and if it doesn't, provide a hint on how to proceed. Do you actually believe you are personally entitled to demand special research tips from domain experts?

I don't think it's too much to ask for links to resources. If it's a common enough remedy that needs linking, you could just write a dedicated blog post describing the recommended resources or whatever and just link to that. Sometimes the hard part of researching things is knowing what to look for or where to look for it.

You can ask for anything you want. But I wouldn't expect anyone to do work for you just because you demand it.

Give me $100 and I'll send you a link to some good crypto books.

Re: How I implemented my own crypto

#409

Post by the_stc »

pkolaczk wrote: post #397
the_stc wrote: post #198

Earlier quoted context omitted.

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…

Even if you need a real entropy-based RNG, e.g. for key generation, you need to gather entropy once at the beginning to seed the RNG. Then running RNG does not need any more entropy, so your hairdryer trick won't work. A common myth I hear is that "entropy" gets "depleted" during RNG operation, but in fact it does not. You only need enough bits of entropy once at the beginning, equal to the internal RNG state length.

Strong RNG designs re-seed to deal with compromise or poor seeding. That way if an attacker has temporary read access they do not permanently compromise the system going forward. Or if on boot you are in a compromised or low entropy environment the system will improve over time. Perhaps the utility of this is arguable. If an attacker is able to see your private RNG state then it is most likely game over. But it is a cheap operation with little downside and again, designs like Yarrow put considerable time into thinking it through.
Post reply on HN