On Thu, 2024-01-25 at 04:24 -0500, Kent Overstreet wrote: > On Wed, Jan 24, 2024 at 10:47:22PM -0500, James Bottomley wrote: > > On Wed, 2024-01-24 at 14:57 -0500, Kent Overstreet wrote: > > > 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; > > > > Neither of which would be insecure ... > > Are you claiming that > > /* Pseudo random number generator from numerical recipes. */ > static inline u32 next_pseudo_random32(u32 seed) > { > return seed * 1664525 + 1013904223; > } > > is a secure RNG? It's the best linear congruence generator for 32 bits, yes; it's straight out of Knuth. However, I assume you picked that one becuase you know it's only used in testing to generate a repeatable series of numbers. The actual prandom_ API is based on an internally seeded linear feedback shift register algorithm. The trick to using PRNGs correctly is 1) knowing you can use them and don't need cryptographic randomness and 2) seeding them correctly, which is where the rust problem came from and which you can't get wrong in Linux because it's done directly from the entropy pool. James
