All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Stephen D. Williams" <sdw@lig.net>
To: Valdis.Kletnieks@vt.edu
Cc: linux-kernel@vger.kernel.org
Subject: Re: High Quality Random sources, was: Re: SecuriKey
Date: Mon, 12 Jan 2004 01:19:32 -0500	[thread overview]
Message-ID: <40023C74.1010109@lig.net> (raw)
In-Reply-To: <200401120557.i0C5v23e003260@turing-police.cc.vt.edu>

It has puzzled me for a while why it doesn't occur to people that a high 
quality OTP is a high quality source of shared private keys for a good 
symmetric algorithm.  That is a much better use than 1-to-1 XOR.  Sure, 
you're still only as secure as the symmetric algorithm but if you can 
manage distribution of a OTP, you don't have to otherwise worry about 
key management other than walking through the keys so that they are only 
used once.  128MB+ (or 200MB or 1GB)  represents a lot of AES keys.  
With that many, you could just skip around on a non-key aligned random 
point (using your high-quality random source of course ;-) ), transmit 
the point you are using as a key selector, and not worry about avoiding 
reuse management.

PKI is better for many reasons, but it's still interesting that an 
essentially low-tech technique like OTP could be used in a similar way.  
You still have an N^2 key exchange problem that PKI solves.

sdw

Valdis.Kletnieks@vt.edu wrote:

>On Sun, 11 Jan 2004 23:10:47 EST, "Stephen D. Williams" said:
>
>  
>
>>OTP absolutely requires that you share the OTP out of band, i.e. you 
>>twin a capture of random data.  Any transfer makes it as vulnerable as 
>>the transfer method.
>>    
>>
>
>The single most common OTP-related offense of Schneier's "snake oil crypto"
>has got to be the fact it's almost never only used exactly once and then discarded.
>
>So sure you can load 200 meg of OTP into the dongle before you leave the spy agency
>on a mission.  The fun starts when you get to the 201st megabyte of data. :)
>  
>


  reply	other threads:[~2004-01-12  6:29 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-11 15:44 SecuriKey Hunt, Adam
2004-01-11 19:46 ` SecuriKey tabris
2004-01-12  0:39   ` High Quality Random sources, was: SecuriKey Stephen D. Williams
2004-01-12  3:38     ` tabris
2004-01-12  3:47       ` tabris
2004-01-12  4:10         ` Stephen D. Williams
2004-01-12  5:57           ` Valdis.Kletnieks
2004-01-12  6:19             ` Stephen D. Williams [this message]
2004-01-12  4:16     ` Mark Borgerding
2004-01-12 20:37   ` SecuriKey David Schwartz
2004-01-12 21:27     ` SecuriKey Richard B. Johnson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=40023C74.1010109@lig.net \
    --to=sdw@lig.net \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.