Re: A twist on OTP for an outstandingly secure channel?

"Jean-François Michaud" <cometaj@xxxxxxxxxxx> wrote in message
news:1168194101.627854.183090@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Joseph Ashwood wrote:
"Jean-François Michaud" <cometaj@xxxxxxxxxxx> wrote in message
news:1168152424.282238.67270@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Am I missing anything?

Yes you are. You are missing that there are no "magnitudes beyond ...
'unbreakable'.

I would have to disagree. In this particular context, I perceive that
there is a degree of unbreakability.

We're not talking bullet-"proof" vests, unbreakable means quite simply
unbreakable, in particular it means indistinguishability. Given 2 possible
plaintexts it is impossible to distinguish one from the other, with any
higher likelihood that simply examining the plaintexts without the
ciphertext. No processing can improve on this, so any additional processing
is a waste of effort.

Actually, slight shift of
perspectvie, unbreakability is probably incorrectly used in this
context. What we mean to say is that the OTP doesn't reveal additional
information as to what the cleartext can be. It is possible to brute
force say a 128 bit OTP relatively quickly (not for us of course). but
you will end up with 2^128 possible decryption, the larger the key, the
more difficult the brute force method becomes and the more potential
decrypted text you will have to crack your head open over to try and
extract a relevant context.

The problem is not getting all the possible plaintexts, the problem is
determining which of the possible plaintexts is correct. Maybe it would be
of use for you to read up on the unicity distance, a fundamental concept in
understanding in depth why OTP is perfectly secure.

I wouldn't. I would say that arbitrarily creating a situation where 2
pRNGs
are needed is a waste of space,

Yeah, but thats your particular take on it, I don't share your idea in
this regard ;-).

and that attempting to exchange keys covered
by that will gain you no more than a single bit of extra cover.

How do you come to this conclusion?

In bruteforcing 2 pRNGs with key length K, it will cost 2^K+2^K == 2^(K+1)
time instead of 2^K time, that bruteforce will reveal the newly exchanged
key. As a result you have gained at most 1 bit


This bring
the entire situation precisely back to where it began, except that it
takes
several times as much processing power to run the cipher.
Joe

If your previous conclusion is true, maybe. Can you elaborate?

You are consuming at least double the random bits, therefore you need to
generate at least double the random bits, therefore you need to at least
double the computation power, for effectively no gain.
Joe


.

Relevant Pages

  • Re: A twist on OTP for an outstandingly secure channel?
    ... You are missing that there are no "magnitudes beyond ... ... In this particular context, I perceive that ... plaintexts it is impossible to distinguish one from the other, ... force say a 128 bit OTP relatively quickly. ...
    (sci.crypt)
  • Re: How can I get mouse shortcuts to work in Excel
    ... The Intermediate window is from the Visual Basic Editor. ... There is no right click menu (context menu missing). ... > Hi Dave, Thanks for the response. ...
    (microsoft.public.excel.setup)
  • Get(RecordNumber) already, please!!!
    ... in the table but that produced the same junky result. ... "If you specify the context for the current calculation, ... suckier and suckier as time went on. ... I don't even care what it is I'm missing here - surely ...
    (comp.databases.filemaker)
  • question about ucontext_t and friends
    ... Where *context is a pointer to a `struct ucontext', ... Concerning the 'missing members' in ucontext_t, ... alter things in uc_mcontext (machine context) ?? ... incidah njs (dot) netlab cz ...
    (freebsd-arch)
  • Re: [PATCH 1/2] Traffic control cgroups subsystem
    ... which doesn't execute in the context of the sending ... Or am I missing something? ... You claimed "In the most common case, the packet is not queued before ...
    (Linux-Kernel)