Subject: Re: System clock resolution and random numbers
To: None <current-users@NetBSD.ORG>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 05/03/1997 22:45:55
>>> [...] then the encryption/decryption key (the cd was used as a otp)
>>> was simply an offset into the cd's data. cute, eh?
Personally, I don't like this, unless the cd is a write-once CD and a
given piece of the key is destroyed after being used. Leaving the key
accessible to anyone but the intended recipient is a Very Bad Idea.
>> The hard part of this scheme would be secure delivery of the cd's
>> more than the generation of the numbers, I think.
Very true. I can generate strongly random bits at a decent rate by
reading /dev/audio with nothing connected and shoving every few
thousand bits through a message-digest function like md5 or sha;
generating key material is not a problem. Distributing it is.
> One of my crypography texts suggested using a bank of rock and roll
> CD's and XORing the contents of your message with the non-zero
> contents of the CD. You pick the title and the offset and away you
This sounds like a bad idea to me - the bits will be very very far from
random. The only way you'll get any security out of it is if the
entropy of the CD, plus the entropy of your message, is at least one
bit per bit - and even then, you are depending on security through
obscurity, since once your attacker finds out the method, it's just a
question of sliding the message against the CD until sense comes out.
The best OTP scheme of this sort I've heard of is for the "home office"
to generate a diskful of strongly random bits and send a copy with the
"remote" person. Encryption consists of just reading bits, XORing, and
writing them back where they used to be, thereby overwriting that part
of the key. It shares with PGP the elegant property that the field
person _can't_ decrypt data once it's encrypted.
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B