On Wed, Jan 24, 2024 at 02:43:21PM -0500, James Bottomley wrote: > On Wed, 2024-01-24 at 13:50 -0500, Kent Overstreet wrote: > > > To illustrate the problem with cryptography in rust: just because > > > it's rust safe doesn't mean its correct or bug free. Crypto > > > functions are the most difficult to get right (algorithmically, > > > regardless of memory safety). Look at this Medium report on the > > > top ten bugs in blockchain: > > > > > > https://medium.com/rektoff/top-10-vulnerabilities-in-substrate-based-blockchains-using-rust-d454279521ff > > > > > > Number 1 is a rust crypto vulnerability due to insecure randomness > > > in a random number generating function (note it was rust safe code > > > just not properly checked for algorithmic issues by a > > > cryptographer). > > > > > > The reason for using the kernel functions is that they are vetted > > > by cryptographers and crafted for our environment. > > > > Are you arguing that typical kernel code is more secure than typical > > Rust code? > > For crypto code? Absolutely, that's what the example above showed. > It's pretty much impossible to use an insecure rng in the kernel if you > plug into one of our existing APIs. That's obviously not necessarily > true if you pull a random one from crates.io. > > James I can just as easily use prandom.h instead of random.h in the kernel; this just comes down to Rust not being able to save you from arbitrary logic errors. But all the data we have so far from CVEs and bug reports shows that Rust code is _dramatically_ more secure than any C code, even kernel code.
