Path: cactus.org!milano!radar!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!
+ rpi!sarah!newserve!newserve!consp04
From: consp04@bingsuna.bingsuns.cc.binghamton.edu (Dan Boyd)
Newsgroups: sci.crypt
Subject: Re: Braided streams
Message-ID:
Date: 23 Jun 91 16:52:19 GMT
References: <1991Jun23.042445.9676@elevia.UUCP>
Sender: usenet@newserve.cc.binghamton.edu (Mr News)
Organization: State University of New York at Binghamton
Lines: 156
In-Reply-To: alain@elevia.UUCP's message of 23 Jun 91 04: 24:45 GMT
Nntp-Posting-Host: bingsuna.cc.binghamton.edu
In article <1991Jun23.042445.9676@elevia.UUCP>
alain@elevia.UUCP (W.A.Simon) writes:
> At best, you will match a plaintext and a key to a given ciphertext,
> but you will have achieved no progress whatsoever towards breaching
> the security of the link, because a) you knew and expected the
> plaintext, b) the key it does allow you to extract won't be used
> right away, but at an undetermined time in the futur, depending on
> the available store of key material, and on the volume of traffic,
> c) you have no certitude that the known plaintext was in fact sent
> at that particular time, since you can retrieve it from any other
> traffic intercept just as well anyway.
You don't understand what a known-plaintext assumption is.
It means, "Not only do I know that they sent this message though the
pipeline at some time, I also know when." It means you know where
they enciphered that plaintext.
With your system, that means you can recover the key stream
for that stretch of the message.
> To breach the security, you would have to hit on a correct plaintext
> and key combination and keep hitting correctly until you intercept
> the portion of message where the compromised key starts being used.
> A tall order.
No, you don't have to keep hitting correctly. You can just
hop along trying the key stream you found until you find a place where
you start recovering plaintext with it again. You could go along for
days until it matches again, but you would eventually find a match.
>
> > Simon goes on to various elaborations, in particular using multiple
> > key bits to select one of many input streams. As he himself
> > notes, this will exhaust the key stream rapidly. So he has to
> > fall back on various tricks for expand- ing the key stream. He
> > won't pin himself down to any one technique - he lets the
> > client choose. This is pointless: Cryptographers always
> > assumes that the opponent knows EVERYTHING about the system
> > except for the key, again because history has shown that that's
> > the only safe assumption.
>
> I don't, so far, provide a satisfying key management system.
> I do provide a channel for doing it. That's also part of the
> novelty. I may not have to "pin myself down", since any
> system that uses a fully secure seed, may be used to generate
> a fully secure sequence, as long as the choice of algorithm
> used to expand the seed is itself dependant on the key. In
> other words, if I have a hundred different algorithms that
> can generate a string of 0's and 1's that's longer than the
> string needed to provide the seed and to specify the choice
> of algorithm, and I do that often enough during a communication,
> I am home free. Example: if I send, through the key management
> stream, a token saying "use the nth prime number" and a token
> specifying the value of n, I can generate a string that's long
> enough to defeat the key exhaustion phenomenon, but short enough
> so I can move on to "use the number of ways we can arrange n
> objects taken p at a time", followed by tokens for n and p, then
> I can go on to "use the nth Fibonacci number"... you get
> the drift.
You're breaking the fundamental assumptions here. All these
many different ideas for getting sequences of numbers are part of the
SYSTEM, not part of the key. You have to assume that the enemy knows
what those tokens mean. When you send a token through saying 'use the
Nth prime number' you have to assume the enemy knows what that token
means.
> And it is all done under key control. If a hundred is not high
> enough we can find many more sequences, algorithms and combinations
> thereof to satisfy the needs of even lrw.
An analyst of your system has to assume that the enemy knows
what the sequences, algorithms and combinations are, because they're
not part of the KEY, they're part of the SYSTEM.
> You are confusing a book, the text of which educated guesses
> can be made about, and files containing random garbage, which
> you could try to grok out until you are blue in the face.
Your idea of 'random garbage' is incorrect. Random number
generators don't generate real random numbers. They generate numbers
that don't have any pattern that's obvious to the naked eye, but their
numbers are really no more random than the sequence 1 2 3 4 5 ...
because any random number generator you write in software is going to
be deterministic once you know the seed.
People can grok out pseudorandom numbers more easily than they
can invert DES or factor large primes. That's why one-time-pads
(XORing with random (thermal, quantum-mechanical) noise that is
exchanged beforehand) are only useful if you use REAL random noise,
not something generated by software. Somebody can figure out what
your software is doing and duplicate it!
> [Network traffic encryption] is one area where the side
> effects of the braid shine. The more traffic, the more
> confusion because every bit of traffic adds to the
> incertitude.
No, every bit of traffic brings us closer to the point where
you are reusing key material. We watch your net for a long time and
sometime we're going to get a piece of known plaintext (count on it).
We will know that a particular stretch of ciphertext holds a
particular stretch of plaintext. Which means we can recover the key
you used for that piece of plaintext. Now we know a piece of your
key.
But we know more more than this -- we can guess what came next
in the plaintext based on the stretch we know. So we can get a little
more of your key out.
So then we keep trying that stretch of recovered key against
everything that comes though the net. Eventually we hit a point where
that key comes around again in your key-rotation sequence, and we're
reading more, different plaintext. We can again guess what came next
in the plaintext, with some degree of accuracy, which means we can
again recover some more key material. We keep going on like this,
accumulating key material.
> And the ciphertext being longer (by an amount
> that varies according to the statistical profile of the
> key) than the plaintext, this is HARD work for the
> opposition.
It's not NP-hard. It's not hard enough to make it unfeasible.
> > (Jerry Leichter) I don't remember which cryptographer first
> > stated that he would never accept a new cryptosystem from
> > anyone who had not already broken a strong one, but this is (in
> > some form) generally accepted in the cryptographic community.
>
> Some great people have said a number of equally self serving
> things in the past. I try to avoid adopting this kind of
> inbred thinking.
>
You're calling this statement self-serving. You're calling
the cryptographic community inbred. You're arguing emotionally here.
This doesn't inspire confidence.
The trouble with your system is that you don't do anything
that's not recoverable by the enemy. I think even without the key the
system is crackable, since the enemy can watch for those tokens you
use to switch sequences with.
Any particular key, in your system, is vulnerable to a
chosen-plaintext attack.
What does the ciphertext look like if I send a block of nulls?
And what does it look like if I send, with the same key, a
block where all the bits are 1?
What can you do with the resulting stream?
-- Dan
--
Daniel F. Boyd
consp04@bingvaxu.cc.binghamton.edu
CONTACT ALIENS BOTH BENEVOLENT AND EVIL!
DON'T STIR OR DISTURB THE RICE!
210526315789473684
Also, if you wait too long, the pumpkin comes. -- mdchaney@iubacs