On Sat, 3 Feb 2007, FocusHacks wrote:
Thanks for the information, guys. As far as one-time pads being the
same length as the cleartext, I know how it works. If a spy of days
past had a very long message to encrypt, he may need to use more than
one page of his paper pad. By the same token, if I have a large binary
file to encrypt, but have stored several small files of random data to
use as my pad (and the receiving party has the same files and knows in
which order to utilize them), I would expect a tool to be able to handle
the task. It's not convenient to generate a perfect-length pad file for
every ciphertext message I wish to transmit. Looping a 20k file over a
larger cleartext message would not be OTP, it'd be a simple running key
algorithm that'd be a lot easier to break with simple heuristics.
Sure, it'd be a 20 kilobyte key, a lot less trivial than looping an
eight-letter lowercase word as a key, but it wouldn't be nearly as good
as a genuine OTP.
=====================================
a few CD-Rs can hold plenty of pad/key information. many paper shredders
are advertised as being capable of shredding a CD... has anyone looked
into the feasibility of putting a shredded CD back together?
The reason I'm thinking small files is because on solid state media (for
instance, volatile storage in a PDA), it's easy to securely erase one
file at a time, which is much like burning the piece of paper you just
used. correctly implemented, OTP is both computationally trivial to
perform, yet "perfectly secret", so long as the pad remains secure.
=====================================
it's actually *not* easy to erase one file at a time on PDAs, flash
drives, etc. that discussion was about a week or so ago.
--
...atom
________________________
http://atom.smasher.org/
762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808
-------------------------------------------------
"The proposition that intelligence has any long-term
survival value remains to be demonstrated."
-- Arthur C. Clarke
