> I think we can agree that we disagree. Yes, we agree on that, at least! The problem is, this is supposed to be a matter of fact, not opinion, so there should be one right answer. I suppose it's possible it's still an issue of terminology, but we've exhausted > Though, I will get back to the drawing board and think about the problem > of how to efficiently collect entropy. For *collecting* it, there are two obvious sources that would be very nice to use, I've just never had the courage to dig into the relevant subsystems deep enough to add the hooks. These could be turned on when entropy is required and turned off afterward: 1) The RTC periodic interrupt. This is invariably driven by a separate 32.768 Hz crystal, so the jitter against the main clock oscillator is a useful source. A stadanrd PC RTC can run at up to 8 kHz, and probably deliver a few hundred bits/s. 2) Any available ADCs, especially audio ADCs. A 16-bit or better ADC is a very rich source of entropy. We'd need hook into the audio subsystem which could activate the ADC when needed and, most importantly, guarantee that the data did not go anywhere else. Becasue we can't guarantee that the audio input is quiet when collected, the entropy would have to be estimated a priori rather than deduced from measurements. Some measurements would still be useful as a sanity check to ensure the data isn't digital zero or something. For storing it after collecting it, I still think the current CRC-based scheme is pretty good. Note that cyclical XOR is a special case of this, just using a polynomial of x^4096-1. The good properties of CRCs for detection of hardware-type errors are exactly equivalent to the collision resistance properties desired for an entropy pool. A collision results in an undetected error in the former case, and loss of entropy in the latter. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
