On 04.04.19 14:23, George Spelvin wrote: > Looking over this PRNG code, I wonder how carefully it's been > thought through. The big question is "why have this code in the > erne at all? Can't it just be a user-space feature?" > > SP800-90 and X9.17 both specify CPRNGs with anti-backtracking > protection. At the end of each generate operation is a step which > performs an irreversible transformation on the state so prior output > is irretrievable even if the state is later captured. > > What makes the whole thing tricky is that the standards are written > with the model of a single-threaded application. Mapping this to > a kernel device with multiple simultaneous (mutually distrustful) > users is not entirely obvious. > > Not entirely obvious in two ways: *how* to do it, and *whether* to > do it. Why take something that's a bad fit for the kernel and > jam it in there? > > One issue that jumpsout at me is that the minimal requirement for > providing anti-backtracking to users is that the output is wiped > from kernel buffers after it's copied to userspace, but prng_sha512_read() > doesn't do that. > > More generally, there are several ways to map the generator to > a device driver, and while the chosen one is plausible, there's no > discussion of how it was decided on. > > SP800-90 makes a strong distinction between output from the same > generate operation vs. different generate operations. There are > also separate limits: 2^19 bits max (1024 hashes) per generate > operation, 2^48 generate operations per reseed. > > The question is, should that distinction be made visible to users > of the kernel device? The current code does not; it generates 256 > bytes (4 hashes) at a time and serves all comers from that. When > that runs out (possibly in the middle of a read), it runs a new > generate operation for the rest. > > You could alternatively have each read be a separate generate, or > each open() be a separate generate. But when trying to figure > out what the right thing to do is, I keep not understanding > the use case. What is this code trying to achieve? > Agreed. Maybe you have to take into account the history of this device driver. The original code was introduced about 12 years ago and was based on a hardware implementation of a pseudo random generator conforming to ANSI X9.17 based on 3DES. And with z12 we got a new hardware implementation claimed to conform to the NIST SP 800-90 SHA512 pseudo random generator specification. So I did this rework. I also implemented the first (1 page, SHA256 based) implementation of this entropy stckf seed algorithmus based on experiences and measurements done by our hardware designers in combination with physicists and mathematician. Later there was this finding with the SHA256 which can't be used to hash together 256 bits of entropy. However, as you already pointed out the buffer handling may need some revision. With the latest machine we have an TRNG anyway and this is one of my next jobs to use this hardware TRNG instead of this weird thing with the stckf loop anyway. regards Harald Freudenberger Lat
