Re: Secure Data & Communication Project
Available news archives: comp.lang.tcl - comp.lang.python - comp.security.firewalls - sci.crypt - comp.lang.php - comp.lang.javascript
Google
 
Web news.hping.org


sci.crypt archive

Re: Secure Data & Communication Project

From: Matt Mahoney <matmahoney@yahoo.com>
Date: Mon Jun 20 2005 - 00:38:00 CEST

Italy Anonymous Remailer wrote:
> One Time Pad will be one of the functions, e.g. one of the options,
> not the only one. The user shall be able to use whatever crypto
> he/she needs in any given situation. One Time Pad will not be
> implemented in the way you are suggesting here. It will be
> implemented as it should, for example:
>
> create two copies of One Time Pad keys, and the parties will
> initially exchange them face to face, or via trusted third party via
> secure channels, in phisical world. Each time any portion of the key
> material is used, the program will delete that portion from the
> storage. The key material might be saved on a, let's say, USB memory
> stick, or something of that kind, encrypted during transport and
> between uses. Otherwise no portion of the key material will be sent
> via insecure channels before the initial use.
>
> When the key material is used up, the parties shall repeat the
> procedure. Alternatively, just before the key material is being used
> up, instructions can be exchanged between the parties encrypted with
> some of the remaining One Time Pad key material, which could
> establish a procedure between the parties for generating a pool of
> new key material with some generator with the same true random seed
> for both, e.g. a portion of the remaining key material. This new
> pools could be the new pad.

That is not one time pad. Not that it can't be done securely, but you
don't have the theoretical secrecy against an attacker with unlimited
computing power that OTP offers. With unlimited power the attacker can
try all possible seeds (since there are only a finite number of them)
and find the one that decrypts to something sensible. All the wrong
decryptions will look like random data. With OTP all plaintexts are
equally likely, including all the sensible ones, so there is no way to
tell which one is correct. OTP will require a hardware random number
generator for every bit of the keystream.

The scheme you describe could just as well be done with AES in CTR
mode, and all you need to do is exchange keys, not the whole keystream.
 Whichever way you do it, you still need to provide authenication,
because an OTP encrypted message can still be easily tampered with by
flipping bits.

-- Matt Mahoney
Received on Thu Sep 29 21:44:49 2005