[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: a comment/question on perfect forward secrecy
>However, master keys may not be the only secrets whose compromise
>can compromise old message traffic. Suppose that a pseudo-random
>number generator is used to generate the key agreement keys.
>Does anyone know if this problem has been considered at all when looking
>at perfect forward secrecy?
Yes. I consider random number generation to be the Achilles heel of
all these schemes, and I've given mine a lot of thought. The random
number generator in my current code was inspired by PGP, but with some
tricks of my own.
In my NOS code (a TCP/IP operating environment for DOS in which I've
been prototyping this stuff) I maintain an internal random number
generator state that is continually "churned" by keyboard strokes and
other random external events. That is, whenever you hit a key (for any
purpose -- there's a direct hook into the keyboard driver) while the
program is running, the scan code and the PC's real time clock (~1 us
count rate) are concatenated with the previous generator state and
hashed through MD5. The result becomes the new generator state.
Whenever I need to generate random data, I hash the current state
along with a counter. The output becomes 16 bytes of random data that
I give to the user (e.g., a Diffie-Hellman routine). If the user needs
more, I increment the counter and rehash as needed.
In essence, I maintain a "reservoir" of entropy, adding to it whenever
I can and drawing from it as needed. Assuming the reservoir is
reasonably full when I start, I can continue to generate random data
even without the addition of additional entropy at the cost of
degenerating from theoretical randomness (can't guess the sequence
even with unlimited computer power) to practical randomness (can't
guess the sequence without enough computing power to invert MD5).
One not-quite-resolved problem is an unattended system that never sees
any keyboard activity. A security gateway, for example. I do try to seed
the generator state at startup with a few tricks:
1) hashing all of main memory, including Ethernet and disk buffers,
BIOS data, etc
2) Reading the 1uS time-of-day count in a tight CPU loop and hashing the
results. On some (but not all) machines that use separate crystals to
clock the CPU and the TOD clocks, you'll get a fairly random-looking
dither in the increment between successive clock reads. This doesn't work
for all PCs, though, especially the newer ones that generate all their
clocks from a single crystal and a PLL synthesizer.
I do need to add a few more tricks I've heard about, e.g., timing
floppy disk and/or hard disk accesses, and perhaps hashing cleartext
packets. And it probably wouldn't hurt to save the random state on
disk when shutting down so I can use it as yet another source of
entropy when starting up, much like PGP's randseed.bin file.
Phil
Follow-Ups:
References: