Re: attacking a re-used OTP // is it possible if it is changed with a random key each time ?



Kristian Gjøsteen wrote:
Terry Ritter <ritter@xxxxxxxxxxxxxxxxxxx> wrote:
Kristian Gjøsteen wrote:
Terry Ritter <ritter@xxxxxxxxxxxxxxxxxxx> wrote:
http://www.ciphersbyritter.com/GLOSSARY.HTM

I urge any reader to look at the AES entry and the Blum-Blum-Shub
entry before using this glossary as a relevant source.

I urge the same thing, without limiting the issue to
just those entries.

If you want the mechanics of AES, that is widely
available elsewhere. Instead, I chose to concentrate
on the delusion that modern block ciphers implement
the handwave model of a keyed permutation.

I cannot imagine any cryptographer, and I've never run into anyone
else, who suffer's from that delusion. Your arguments are pointless
and irrelevant.

(The accepted security definition is that the family of permutations
defined by a block cipher should be indistinguishable from the
family of random permutations.)

Unfortunately, cryptography in practice does not
follow the academic model where something can
simply be asserted and then believed if someone
else cannot prove otherwise. In cryptography it is
necessary to look for potential problems before it
is possible to prove that they are problems.

The fact that conventional block ciphers are confined
to an almost infinitesimal keyspace compared to "the
family of random permutations" should be disturbing.
For one thing, it means that we cannot rely on what
we might anticipate from the handwave model. In fact
this is the basis for realizing that it only takes a few
known plaintexts to identify a correct key, once we
get that close. And while we may not be able to
exploit this weakness now, I find it a great deal more
relevent than mere distinguishability.


The BB&S entry provides excellent background.

Your arguments lack any connection to practical reality. You argue
that a test on the initial state should be carried out to prevent
short periods.

Correct so far.


For a 1024 bit modulus, such short periods occur
with probability 1/2^1022 when safe primes are used. In the real
world, such events never happen. In fact, anyone can trivially
factor the modulus with probability roughly 1/2^512 simply by
guessing, at which point any security guarantee offered by the BBS
proof is null and void. (I haven't calculated the probability that
BBS starts in a short cycle for random primes, but it is certainly
very, very small.)

Surely even you can recognize that your argument
is statistical only. It does not attempt to convince
that no weakness exists, but simply that this
weakness is very rare. But I doubt that every user
or designer necessarily feels supported by that.
I expect that the design intent expressed by using
such a slow and awkward RNG is to achieve proven
freedom from all possible weakness. The BB&S
proof does not guarantee that, but the existance of
an unfixed known posible problem does guarantee
otherwise.

It is possible to eliminate this one admittedly rare
form of weakness at minimal cost. I argue that
allowing any easily fixed known problem to go
out unrepaired is an indication of unprofessionalism.
Many, many problems must be addressed and
handled in a real cryptographic system. Failure
to address any of those indicates a general lack of
attention and poor cryptographic implementation
that may be more significant in other areas.


You worry and write at length about irrelevant problems. Anyone who
reads your glossary without previous background may end up severely
confused about what cryptography is about, and what the real problems
in cryptography are.

On the contrary, anyone who reads the current
cryptographic literature has those problems.
Those are not due to the Glossary, but instead
cryptography itself not functioning as a science.

In particular, the one time pad has been broken in
practice several times. One of those times is
known as VENONA, and has been documented in
some detail by NSA, because OTP cipher failure
lead to the controversial death by execution of the
Rosenbergs right here in the US of A.

This documented OTP failure is the failure of the
"unbreakable OTP" model to reflect reality. Normal
sciences fix their models. Cryptography does not.

Neither the OTP nor BB&S issues deliver much
insight about cipher weakness (except, I guess,
to OTP advocates). Instead, these insights are
about the nature of the field of cryptography, and
the difference between academic results and
practical needs.

However, some "real problems in cryptography"
spring from the fact that cryptanalysis is unable to
prove that any particular cipher has no weakness.
That means any particular cipher we use may be
weak, despite extensive academic chattering.
Unlike most manufactured things, cipher strength
cannot be tested and verified before shipment.
Simply using a cipher for a long time does mean
we can trust it.

At issue is the "single point of failure"
represented by a single cipher. Other fields
identify potential problems and add redundancy.
While that does not guarantee to solve all
possible problems, it does function in practice
to vastly reduce the effects of possible failure.

Redundancy can be added to ciphers by
following the Shannon "algebra of secrecy
systems" into multiple encryption. The failure
to do this as standard cryptographic practice
is the same as the failure of an airplane
manufacturer to add redundancy to parts
whose failure could cause the downing of a
plane. That is the state of cryptography today.

---
Terry Ritter 1.4MB Crypto Glossary
http://www.ciphersbyritter.com/GLOSSARY.HTM

.



Relevant Pages

  • Techincal Error in Steven Levys "Crypto"
    ... reading its version of the story of Horst Feistel, ... as the source quoted in Bruce Schneier's _Applied Cryptography_ for the ... A block cipher that performs the ... author Steven Levy, ...
    (sci.crypt)
  • Re: Weakness of Feistel ciphers
    ... insist it's a flaw in the Feistel network? ... To make a cipher random, some randomness must be put into it. ... SPNs use more than a few rounds as well. ... Because if you had two clues about cryptography this thread would not ...
    (sci.crypt)
  • Re: Crypto Mini-FAQ
    ... may be superceded by Practical Cryptography, ... easy to make a cipher that can't be broken from a sample message, ... : Q: How large should my keys be? ... : Q: Will quantum computers make all this crypto obsolete? ...
    (sci.crypt)
  • Re: Novelist thanks the group
    ... as a ringing endorsement of the Administration's cryptography policy as ... non-historical cryptography novel - making a modern cipher breakable ... ending - like that of Rainbow Six - lacked moral tone. ... Usenet Zone Free Binaries Usenet Server ...
    (sci.crypt)