Re: A Modern Reappraisal of the One-Time Pad Cipher.



On 2010-05-13, Greg Rose <ggr@xxxxxxxxxxxxx> wrote:
In article <slrnhumecj.ttm.unruh@xxxxxxxxxxxxxxxxxxxxxxx>,
unruh <unruh@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
On 2010-05-12, Simon Johnson <simon.johnson@xxxxxxxxx> wrote:

Realizing a practical-as-possible OTP is an interesting and worthwhile
project. The 'adacrypt' context here is obviously worse than useless.
Somewhat ironic that after all the effort sci.crypt has put into
explaining to the math-deniers the limits of the OTP, we still don't
have an OTP implementation anywhere near as practical as we know how
to build.


I think you nearly got it and went astray on that last paragraph.

The cryptographic community did exactly what you suggested. They built
a workable one-time pad implementation.

It's called a stream-cipher.

Except it is not a one time pad. The key advantage of a OTP is that
every character is completely underivable from an arbitrary number of
previous (or later )characters. this is not true of a stream cypher.
Assuming a 128 bit key, once you have 16 characters you have a very high
probability of predicting all the rest, by exhaustive search of the key
space. Now, whether or not that is practical is irrelevant. It says that
16 characters determine all the rest of the characters.

A minor nit: if the state of the stream cipher is
only 128 bits, time-memory-tradeoff attacks would
be surprisingly efficient, so all modern stream
ciphers have a larger state than keyspace. See the
EStream project for more details on this.

I am not sure that it matters. Given 16 bytes, what is the chance that
more than one key would give those same 16 bytes? If we assume that the
stream produces random bits, then teh probability that the 128 bits
would occur for two different keys would be of order 2^-128.

But I agree that it might require a bit more than 16 bytes to make sure.


But your point remains, that maybe 32 bytes would
allow an efficient brute force attack. 16 might
not be sufficient. The complexity would still be 2^128,
just rainbow tables etc wouldn't help.

Greg.

PS. Isn't it nice to have substantive discussions?
Please stop feeding trolls, everyone.
.



Relevant Pages

  • Re: "Read stuff from a file and chop it up to do stuff" code advice wanted.
    ... ;; OUTPUT: T or NIL ... ;; characters (I think it is Unicode at least! ... a stream and an array to hold characters in temp memory. ... ;; resulting string. ...
    (comp.lang.lisp)
  • Re: java i/o streams graphical representation and more ....
    ... this stream consists classes that are used to read data and also ... characters and writing data in the form of characters. ... OutputStream (byte oriented class for writing data) ...
    (comp.lang.java.programmer)
  • Re: sscanf question
    ... Input characters are taken from a supplied stdio stream (which is ... (The failure is an "input failure" if fgetc() ... would return EOF on ...
    (comp.lang.c)
  • Re: Send string to IP address
    ... "Plain hex" implies something formatted as text, but doesn't answer the question of encoding. ... There's no "just" as far as "an ASCII string" is concerned. ... Characters are not bytes and bytes are not characters. ... Normally you'd create the Writer once at the same time as you create the underlying stream, rather than every time you write some text, obviously. ...
    (comp.lang.java.programmer)
  • Re: A twist on OTP for an outstandingly secure channel?
    ... Imagine an OTP. ... bits would be (assuming 8 bit characters. ... Now imagine that through some miracle the ... compensating to the looser encryption strenght of stream ciphers. ...
    (sci.crypt)