At 12:16 PM 10/17/2002 -0700, Morlock Elloi wrote:
I have a working OTP system on $40 64 Mb USB flash disk on my keychain.
Cute. Is it available? How do you prevent other applications from reading the file off your USB disk, either while your application is using it or some other time? That's one of the big differences between a computerized OTP and a Dead Trees (or Dead Silkworms) OTP, which is much harder for someone or something else to read without you noticing. Since you say that "Used bits are securely deleted", does your application distinguish between using the pad to encrypt and using the pad to decrypt (which are basically the same thing, except for destroying the key bits the second time)?
30Mbs are filled with distilled randomness (two video digitizers at high gain looking into open input noise, compressed first with LZW then again compressed 8:1 by taking only byte parity, then XORed together - takes several hours and passes diehard)
Landon Noll has done some interesting work taking a cheap PC camera and keeping it in the dark. The CCDs try to adjust, and you get noise. Rather than compressing 8:1 using byte parity, I'd recommend using a hash function, such as MD5 or SHA, which means that every bit of the input can tweak any bit of the output.
judging by the current use it will last us for decades for text messages.
That's the Bic Pen model of "you'll lose it before you use it up" :-) If you're using it strictly for session key exchange, that's a lot of sessions (unless you're a big web or email server.) If you're using it for message encryption, it's obviously not much.
I have a working OTP system on $40 64 Mb USB flash disk on my keychain.
Cute. Is it available?
$39 + tax in Fry's.
How do you prevent other applications from reading the file off your USB disk, either while your application is using it or some other time?
I don't care. No one knows about it enough to set a trap in a random PC (and if They do we're in deep shit anyway.) This is the reason for not releasing the (trivial) program. Write your own and let it be your group key ... say, 40-bits worth ? Subverting PGP is far more likely. The only solution would be to have a CPU on the keychain item ... just wait for PDAs to get smaller.
Since you say that "Used bits are securely deleted", does your application distinguish between using the pad to encrypt and using the pad to decrypt (which are basically the same thing, except for destroying the key bits the second time)?
You destroy bits *every* time. The routine that reads bits overwrites them. Messages are fixed size, index into OTP file is a part of the message, each user gets starting offset assigned to avoid synching problems. Yes, there are zillion DoS attacks, but we had none so far. This crypto works only when a crypto programmer is a part of cooperative group, and frankly we don't give a fuck for the rest of the world.
Landon Noll has done some interesting work taking a cheap PC camera and keeping it in the dark. The CCDs try to adjust, and you get noise.
I's suggest a hi-fi video digitizer with analog input. CCDs have dirty randomness.
Rather than compressing 8:1 using byte parity, I'd recommend using a hash function, such as MD5 or SHA, which means that every bit of the input can tweak any bit of the output.
Well, each of 8 bits of byte affect its parity. It's just the different initial block size. But tastes vary.
That's the Bic Pen model of "you'll lose it before you use it up" :-) If you're using it strictly for session key exchange, that's a lot of sessions (unless you're a big web or email server.) If you're using it for message encryption, it's obviously not much.
Did you ever try to type 5 megabytes of text ? Check the size of the text part of your outgoing mail archive. ===== end (of original message) Y-a*h*o-o (yes, they scan for this) spam follows: Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.com
At 10:52 PM 10/17/2002 -0700, Morlock Elloi wrote:
I have a working OTP system on $40 64 Mb USB flash disk on my keychain.
Cute. Is it available?
$39 + tax in Fry's.
I don't mean the disk - there are lots of those. I mean your software. Also, can your tool use floppies instead of USB keys? There are problems with KGB-quality attackers recovering overwritten data which are probably much more serious for disks than flash rom, but they're nearly universal and good shredders work well on them.
How do you prevent other applications from reading the file off your USB disk, either while your application is using it or some other time?
I don't care. No one knows about it enough to set a trap in a random PC (and if They do we're in deep shit anyway.) This is the reason for not releasing the (trivial) program. Write your own and let it be your group key ... say, 40-bits worth ?
USB key disks look like an obvious target for eavesdropping in general. (They're also the best medium for re-inventing the floppy-disk virus:-)
Since you say that "Used bits are securely deleted", does your application distinguish between using the pad to encrypt and using the pad to decrypt (which are basically the same thing, except for destroying the key bits the second time)?
You destroy bits *every* time. The routine that reads bits overwrites them. Messages are fixed size, index into OTP file is a part of the message, each user gets starting offset assigned to avoid synching problems.
You need to use each bit twice - once to encrypt, and once to decrypt. Destroying them after the first use is a bad idea....
On Thu, 17 Oct 2002, Morlock Elloi wrote:
Landon Noll has done some interesting work taking a cheap PC camera and keeping it in the dark. The CCDs try to adjust, and you get noise.
I's suggest a hi-fi video digitizer with analog input. CCDs have dirty randomness.
Most modern USB cams (I use Aiptek APC 400, which is dirt cheap and plug and play under Linux) are CMOS, and have very dirty randomness (switch off jpeg compression, wrap it in aluminum foil, wait a little for the cam to adjust, and make a diff of a few pairs of frames). However, they're more noisy than CCD, and the spatial bias gets killed by the cryptohash.
Rather than compressing 8:1 using byte parity, I'd recommend using a hash function, such as MD5 or SHA, which means that every bit of the input can tweak any bit of the output.
Well, each of 8 bits of byte affect its parity. It's just the different initial block size. But tastes vary.
Actually, you're making a lot of random assumptions in your treatment of the raw video, which is a no-no even in the crypto sham we're engaging in. You'd do much better if you'd just use a SHA-1 on a few lines (or estimate (measure), how many lines you need for some 160 bits of raw entropy, and double that for good measure) of raw video. Imo it might be arguably safe/make sense to throw away a few of highest significant bits which are always zero, and paste the rest together, destilling entropy. However, you can actually lose entropy if your setup is very noisy/has a threshold and you're blindly catting only LSBs. This won't happen if you use SHA-1 blindly on raw video.
Also, can your tool use floppies instead of USB keys?
It's a freakin' C program that works on a file - but carrying a floppy around is so ... ordinary.
There are problems with KGB-quality attackers recovering overwritten data which are probably much more serious for disks than flash rom, but they're nearly universal and good shredders work well on them.
Bits are overwritten by running PRNG output on them 128 times, PRNG being seeded by the data that has just been erased. We use DES in counter mode as PRNG.
You need to use each bit twice - once to encrypt, and once to decrypt. Destroying them after the first use is a bad idea....
Why would sender need to decrypt known plaintext is beyond me ... sender XORs and destroys bits, recipient XORs and destroys bits. Each in their respective dongles, once. ===== end (of original message) Y-a*h*o-o (yes, they scan for this) spam follows: Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/
participants (3)
-
Bill Stewart -
Eugen Leitl -
Morlock Elloi