undefined | Better HN

0 pointsprogbits4y ago0 comments

> I'm biased, but the spec is supposed to be very accessible to people without a cryptography background. There's a section on who the intended audience is and what assumptions are made about their background. I'd really recommend it.

Certainly! As you can probably tell from my comment I'm not expert and I found it easy to follow.

I just wanted to post a summary for anyone who is interested but doesn't find time to go into details. I know that I myself often read this site on phone and I appreciate similar comments giving a tl;dr on more complex stories.

> There are no "variants" of the entropy source. There is one entropy source interface definition which is designed to scale across the many RISC-V implementation profiles. It's very different to x86/RDRAND which lots of people are used to.

Maybe I phrased it poorly but section "4.2. Entropy Source Requirements" states: "An implementation of the entropy source should meet at least one of the following requirements sets in order to be considered a secure and safe design". It then gives three options, one of which ("4.2.3 Virtual Sources: Security Requirement") states "A virtual source is not a physical entropy source" and "A virtual source traps access to the seed CSR, emulates it, or otherwise implements it without direct access to a physical entropy source.".

My interpretation is that there is indeed a single interface (CSR) however the hardware implementation could be both real physical entropy source or a CSPRNG. And presumably the latter is more likely on low-end devices.

Please let me know if I'm getting this wrong.

0 comments

tialaramex4y ago

> My interpretation is that there is indeed a single interface (CSR) however the hardware implementation could be both real physical entropy source or a CSPRNG. And presumably the latter is more likely on low-end devices.

A CSPRNG doesn't do anything without a seed. If you're actually a VM, your host provides the seed (the "virtual source"), which it chose randomly, and since it is actually your host anyway it has no particular reason to give you a bad seed versus just doing whatever else to sabotage you, so you have to assume the seed is good.

In contrast on physical hardware, there is no seed. If you've got a way to provision genuinely random data to the physical CPU, you don't have a "virtual source" at all. So option 4.2.3 isn't relevant to physical CPUs only to a RISC-V VM.