4 ms·

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

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

tptacek 9y ago
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!
- loup-vaillant 9y ago
  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 vectors and Valgrind is OK with your binary, you're probably OK. No! Definitely agree. Even test vectors + safe Rust aren't enough. Which is why I added random comparison tests with libsodium (for every possible length input between 0 and a couple times the size of the block), and property based tests. I'm still a bit uneasy about carry propagation in Poly1305, but I really checked the hell out of my code.
  - tptacek 9y ago
    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".
    - loup-vaillant 9y ago
      > 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.

tptacek 9y ago

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!

loup-vaillant 9y ago
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 vectors and Valgrind is OK with your binary, you're probably OK. No! Definitely agree. Even test vectors + safe Rust aren't enough. Which is why I added random comparison tests with libsodium (for every possible length input between 0 and a couple times the size of the block), and property based tests. I'm still a bit uneasy about carry propagation in Poly1305, but I really checked the hell out of my code.
- tptacek 9y ago
  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".
  - loup-vaillant 9y ago
    > 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.