3 ms·

This is neat. The ever-present admonition against rolling one's own crypto lurks in the back of my mind, though. It is not my intent here to impugn Bunnie's com

This is neat. The ever-present admonition against rolling one's own crypto lurks in the back of my mind, though. It is not my intent here to impugn Bunnie's competence, though I do wonder if he's run the design or implementation past any cryptographers to try to verify that the design or implementation are sound, and don't subtly break critical assumptions vital to the security of the algorithm.

pinewurst 5y ago
But he’s not rolling his own crypto - in an algorithm sense - purely trying to speed the execution of an existing algorithm which can be easily validated against other existing implementations
- korethr 5y ago
  Sure, but is it not possible that a hardware acceleration, if not also proven correct, could subtly undermine an otherwise valid software implementation? I do not assert that this is the case generally, nor particularly here -- I would be quite happy to be wrong about this. But if there's one thing I've taken from my admittedly minor study of crypto is that the most trivial of details can be critically important, and failure to get a detail exactly correct can compromise an entire algorithm and anything built thereupon. I would love to see hardware acceleration for ed25519, just like there's been hardware acceleration for AES. It could help drive adoption of an algorithm that is less fiddly and easy to get wrong than RSA, and maybe in another 15 years, I'd be able to purchase IT equipment that supports ed25519 and not just hardware accelerated RSA and AES.
  - not2b 5y ago
    Correctness alone is not sufficient. A crypto implementation also has to avoid introducing side channels. He describes how he avoids introducing a timing side channel (can't have any conditional branches that depend on the data) so it seems he took care to get that part right.
bunnie 5y ago
The admonition runs through my mind all the time, too. I'm not qualified to implement Curve25519 entirely from scratch. But, the good news is that this accelerates certain primitives within a Rust crate that was written by a cryptographer I personally know and trust; I think she's done a good job with the validation and test vectors, and she's been meticulous on documentation. The theory is that as long as I don't break her tests, I'm probably OK. I did bump into some corner cases for correctness that might be extremely hard to catch in a random vector test bench, which I've noted in the post, but I do have some synthetic vectors that try to make sure I don't have a problem. I also tried hard to make sure I didn't introduce any new timing side channels; since all the ops are constant-time, hopefully I'm safe there. So, I'm fully aware that I'm not perhaps the best qualified person in the world to build this. However, as I had mentioned elsewhere, my attempt to get source code from several research groups who have built such blocks met with no success. And also knowing how the silicon industry works, any "secure microcontroller" group peddling you some secret sauce closed source cryptoblocks likely were not designed to any level of scrutiny I would be satisfied with. Given the options of no acceleration, dubious closed source blocks, or trying to roll my own, I went with the latter, but with copious amount of documentation so that hopefully people smarter than me will have an easy time to review it for errors. As a side note, in terms of things that I did implement for this system that should be cause for worry, I'd personally say the TRNG is the most worrisome, because TRNGs are full of scary footguns that are very exploitable. Then I'd worry about the AES instructions in the RISC-V core, the Curve25519 engine, and the SHA hardware accelerator in that order. I didn't write the AES instructions or the SHA accelerator, but I also haven't done a thorough review of them for things like timing side channels. I only rank the AES instructions as slightly more worrisome because I know those were implemented by a CPU architect without much input from cryptographers, whereas the SHA block comes from Google's OpenTitan project, which I would /hope/ was thoroughly reviewed but then again I'm just relying on the G-brand. There is something comforting, though, to be able to know the provenance of your crypto primitives.

pinewurst 5y ago

But he’s not rolling his own crypto - in an algorithm sense - purely trying to speed the execution of an existing algorithm which can be easily validated against other existing implementations

korethr 5y ago
Sure, but is it not possible that a hardware acceleration, if not also proven correct, could subtly undermine an otherwise valid software implementation? I do not assert that this is the case generally, nor particularly here -- I would be quite happy to be wrong about this. But if there's one thing I've taken from my admittedly minor study of crypto is that the most trivial of details can be critically important, and failure to get a detail exactly correct can compromise an entire algorithm and anything built thereupon. I would love to see hardware acceleration for ed25519, just like there's been hardware acceleration for AES. It could help drive adoption of an algorithm that is less fiddly and easy to get wrong than RSA, and maybe in another 15 years, I'd be able to purchase IT equipment that supports ed25519 and not just hardware accelerated RSA and AES.
- not2b 5y ago
  Correctness alone is not sufficient. A crypto implementation also has to avoid introducing side channels. He describes how he avoids introducing a timing side channel (can't have any conditional branches that depend on the data) so it seems he took care to get that part right.

bunnie 5y ago

The admonition runs through my mind all the time, too. I'm not qualified to implement Curve25519 entirely from scratch. But, the good news is that this accelerates certain primitives within a Rust crate that was written by a cryptographer I personally know and trust; I think she's done a good job with the validation and test vectors, and she's been meticulous on documentation. The theory is that as long as I don't break her tests, I'm probably OK. I did bump into some corner cases for correctness that might be extremely hard to catch in a random vector test bench, which I've noted in the post, but I do have some synthetic vectors that try to make sure I don't have a problem. I also tried hard to make sure I didn't introduce any new timing side channels; since all the ops are constant-time, hopefully I'm safe there. So, I'm fully aware that I'm not perhaps the best qualified person in the world to build this. However, as I had mentioned elsewhere, my attempt to get source code from several research groups who have built such blocks met with no success. And also knowing how the silicon industry works, any "secure microcontroller" group peddling you some secret sauce closed source cryptoblocks likely were not designed to any level of scrutiny I would be satisfied with. Given the options of no acceleration, dubious closed source blocks, or trying to roll my own, I went with the latter, but with copious amount of documentation so that hopefully people smarter than me will have an easy time to review it for errors. As a side note, in terms of things that I did implement for this system that should be cause for worry, I'd personally say the TRNG is the most worrisome, because TRNGs are full of scary footguns that are very exploitable. Then I'd worry about the AES instructions in the RISC-V core, the Curve25519 engine, and the SHA hardware accelerator in that order. I didn't write the AES instructions or the SHA accelerator, but I also haven't done a thorough review of them for things like timing side channels. I only rank the AES instructions as slightly more worrisome because I know those were implemented by a CPU architect without much input from cryptographers, whereas the SHA block comes from Google's OpenTitan project, which I would /hope/ was thoroughly reviewed but then again I'm just relying on the G-brand. There is something comforting, though, to be able to know the provenance of your crypto primitives.