Cryptography-Digest Digest #444, Volume #10 Sun, 24 Oct 99 23:13:03 EDT
Contents:
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column ("Trevor
Jackson, III")
Re: compression and encryption (Geoffrey T. Falk)
Re: Weakness in the Rijndael key schedule? (nereid@)
----------------------------------------------------------------------------
Date: Sun, 24 Oct 1999 18:53:41 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Rats. Thinking faster than I can TPYE again...
Please replace "basic wheel" with "basic squeaky wheel".
Sorry.
Trevor Jackson, III wrote:
> Vernon Schryver wrote:
>
> > In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
> >
> > > ...
> > >>How can you point to modems as a good example of the wonders of negotiating
> > >>protocols? I think the politics and sausage warning applies.
> > >
> > >I think the real world applies: We have such modems. We use them.
> > >They work. End of story.
> >
> > That might be the end of a fairy tale or a nightmare, but I
> > thought you were talking about engineering.
> >
> > Modems do not work all of the time. A cipher negotiating protocol that
> > failed as often as modems fail today in real life would not be something
> > I'd want to trust my phone bill to, not to mention something that matters.
> >
> > > ...
> > >I doubt I implied that modem negotiation is "clean." But it *is*
> > >"background," and it *is* negotiation (both sides participate in the
> > >final result), and it *is* "real world" -- it generally works in
> > >practice.
> >
> > The "it generally works in practice" can be said about PPP, only more so.
> > And again, who wants a cipher negotiating protocol that "generally
> > works in practice"?
> >
> > Only salescritters or people with no technical knowledge can claim that
> > either PPP or modems are examples that could cause a working engineer to
> > be enthusaistic about negotiating ciphers. Sane, technically inclined
> > people who look at modems, PPP, or any other "standardized", dynamic
> > negotiating network protocol must be very skeptical of the idea.
>
> Any other? I think not.
>
> You can pick on negotiation failures typically those that evolved over time, which
> usually means layers of kludge upon kludge, sometimes driven by commercial issues
> (PPP), and sometimes driven by technological advances (modems).
>
> OTOH, you have failed to note the cases in which negotiation is so successful that
> it is almost invisible. Consider DECnet. Once a machine is configured there is
> little chance of failure. You hook up the wires and the machine figures out wht
> topology necessary to communicate with other machines. This is a negotiation
> protocol that works.
>
> Note that this class of error, noticing only the problems, is a basic wheel
> approach which causes sampling error.
> There is no alue to this sort of anecdotal horror story. If you want to address
> the topic of negotiating protocols, please produce an issue that you believe will
> be difficult to solve and lead to negotiation failures.
>
> >
> >
> > >Cipher negotiation can be far cleaner -- provided a single selection
> > >mechanism is standardized. If not, then we may see the same sort of
> > >ad hoc stuff we saw with modems.
> >
> > But "ad hoc" modem negotiation was your counter to the 10+ years of
> > public experience with offically standardized, carefully architected,
> > designed and tested PPP.
> >
> > As for "can be cleaner...", those words echo what was said about
> > standardizing the negotiations between wide area routers in the leased-line
> > IETF WG that was merged with the SLIP-replacment WG in about 1987 to form
> > what is now the PPP working group. I think users are better served by
> > the result (PPP) than by the old proprietary protocols, but no one can
> > call PPP clean--at least no one honest and with a clue.
> >
> > Maybe Communism will work the next time it's tried too.
> > But my money is on standards committees behaving like committees.
> >
> > > ...
> > >I would say, "let's not do it like PPP."
> >
> > Exactly how would you do that? The problems with PPP negotiating are not
> > any single technical issue, but the inevitable morass that comes with
> > complicated network stuff in the best possible circumstances.
>
> Not relevant. We aren't faced with "complicated network stuff" or anything
> similar. Anyone adding one or more AES ciphers to an existing multi-cipher
> product already the the problem and a solution. Adding several AES ciphers to an
> existing single-cipher product is no harder than adding a single ("the") AES
> cipher; negotitaion is required. creating a new product is the only case in which
> the requirement to negotiate cipher selection is an issue. Note that this is
> going to be common for reasona of backward compatibility during the
> changeover/upgrade period.
>
> However, there are enough ciphers out there now that I suggest no new product will
> be pure AES. Bruce Schneier indicated that he considered 3DES to be the backup
> for AES. This is probably a reasonable suggestion given the maturity of 3DES and
> the immaturity (*RISK*) of AES. SO even a new product is probably going to have
> to negotiate dynamic cipher selection or support static configuration of cipher
> selection.
>
> You cannot just wish this requirement away. Nor can you ignore the ubiquity of
> the issue and claim that multiple AES selections creates an abnormal condition.
> As discussed above it is probably normal to have multiple ciphers.
>
> >
> >
> > >>I don't understand the "background" bit about cipher negotiating, since
> > >>for all of modems, PPP, and ciphers, until the parties agree, the main
> > >>event cannot work, and that's not exactly "background"
> > >
> > >Indeed, you do not understand the term "background," presumably
> > >because you have not done your homework. I suggest actually reading
> > >messages before disparaging their ideas. You might also look into my
> > >recent article in IEEE Computer:
> > >
> > > http://www.io.com/~ritter/ARTS/R8INTW1.PDF
> > >
> > >or the previous discussion, which I have archived on my pages:
> > >
> > > http://www.io.com/~ritter/NEWS4/LIMCRYPT.HTM
> > >
> > >Here, "background" approximately means "not apparent to the user."
> > >That is just what modem negotiation is about, although we may hear
> > >modems, and need not hear or see cipher negotiation.
> > >
> > >To start any conversation in cipher, it is currently necessary to
> > >acquire common keys. Everyone understands this. So everyone should
> > >be well prepared to understand that we can *also* acquire a cipher
> > >name, or even a cipher itself, in the same way, through the same
> > >channel. This is not a big conceptual leap.
> > >
> > >Once we have a conversation in cipher, we can assign part of it to a
> > >"control channel," where negotiation takes place (generally, although
> > >not necessarily) hidden from the user. That would be "background"
> > >cipher negotiation.
> > >
> > >Because the need is to change ciphers frequently, the desired
> > >negotiation process is not one-time at the start, but rather, a
> > >frequent or continuous process in different messages or sessions.
> >
> > Before repeating your old line yet again, you should do your own homework,
> > which is to actually investigate at least one real, deployed network
> > protocol that does the negotiating of the sort that you say is so easy.
> > And by "investigate," I don't mean merely read some user documentation or
> > repeat your dreams of how things would turn out if only people would listen
> > to you.
> >
> > As for your "background" stuff--take your own advice and read what you
> > are responding to before pontificating about homework. No matter on what
> > "ground" the cipher negotiating is done, once the sender decides to switch
> > to another cipher, data must soon stop flowing until the new cipher has
> > been negotiated. You can call the cipher negotiating "background" if you
> > want, but when the user-data stops flowing the notion is ... strained.
> > When one party decides a new cipher is required, you must fairly soon
> > either use a new cipher or stop moving data. Otherwise think what a bad
> > guy could do.
>
> This is silly. Does Eve live under your bed or in your closet?
>
> >
> >
> > >>...well, not exactly
> > >>for PPP, which, for example has the CCP (comopression) which is supposed to
> > >>be negotiated in parallel with the main NCP's, which can start sending
> > >>data before CCP converges. That is what the PPP implementations I've
> > >>worked on do, but plenty of others don't. Again, theory vs. practice.
> > >
> > >I am a working engineer.
> > >
> > >Theory vs. practice.
> >
> > Shouldn't a working engineer know about the common, existing, widely
> > *practiced* examples of the thing he is proposing? SSL is a closer example
> > than modems or PPP. (I picked PPP because I know more about PPP than
> > SSL.) Do you care to say something about SSL that will convince people
> > that negotiating ciphers is a great idea?
> >
> > > ...
> > >Well, since you are a "real designer," I'll just let you wander on in
> > >your monomanical tirade, while I suggest that we *not* do things like
> > >PPP.
> >
> > The biggest trouble with PPP is that it is a standardized network thing.
> > Network things that are standards are always at least 95% politics, by
> > which I mean everything that comes with design by committee and approval
> > by standards committees. Negotiating ciphers such as you have proposed
> > would necessarily be network things. Your repeated appeals to the word
> > "standardized" mean that they would enjoy the attentions of standards
> > committees.
> >
> > > ...
> > >There is no other possibility, unless you wish to depend upon the
> > >strength of a cipher which explicitly HAS *no* known or guaranteed
> > >strength. Not having strength is not a trivial detail, this is the
> > >essence of the reason for using a cipher.
> >
> > Before complaining of my monomanical tirades, you ought to notice a few
> > of your own ...yes, you and others have pointed out with endless boring
> > repetitions, the truth of the premise of that paragraph, that we have no
> > guarantees, measurements, or even definitions of the true, theoretical
> > strength of any practical cipher. However, as others have tirelessly
> > responded, your claim that automated switching among lots of ciphers is
> > the only alternative to a falling sky does not follow from that premise.
>
> Then pray tell us, what does follow? Your silince is quite loud.
>
> >
> >
> > >The ability to change ciphers offers each of us the power to choose
> > >what cipher we want to use. This means no government organization is
> > >edicting our use, or forcing it through market pressure. We get to
> > >choose what to use, and what not to use, and to change our minds on a
> > >daily basis. That is not a trivial advantage.
> >
> > Yes, it's good to be able to change ciphers. That does not imply anything
> > one way or another about computers negotiating ciphers in real time.
>
> While true I see no problem to real-time cipher negotiation. Sure you can mangle
> the job, but you can also do a good job, in which case it becomes a non-issue.
>
> > >>Other good (i.e. bad) examples of the inevitable perils of negotiating
> > >>besides modems and PPP include TCP and HTTP. Most don't know about
> > >>about MSS/PMTU or window size problems, but most people have seen
> > >>"broken" web pages that don't work on some versons of some browsers.
> > >
> > >Gosh, I think we'll just have to have a complete specification.
> >
> > The equivalent failure mode of negotiated ciphers for a broken web page
> > would be picking ROT26 as the cipher right after ROT13. Or one of
> > the SSL security bugs.
> >
> > The world is full of self-described architects, designers, and inventors.
> > Most are frauds who invent only self-delusions, hot air, snake oil, and
> > promises to finally build a perptual motion machine that will work this
> > time, (and help patent attourneys make the payments on their Mercedes.)
> > The real architects, designers, and inventors not only desgin and invent,
> > but also build real implementations that are useful in real life. So when
> > will we see the implementation of negotiated/varying ciphers that you are
> > building?
> >
> > Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: gtf[@]cirp.org (Geoffrey T. Falk)
Subject: Re: compression and encryption
Date: Sun, 24 Oct 1999 23:47:09 GMT
In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> wrote:
>Geoffrey T. Falk <gtf[@]cirp.org> wrote:
>
>:> The problem that people like you fail to see is that not all encrypted
>:>text is stright ascii it could be word or what ever. A problem that
>:>you totally neglect is that if the user uses bad compression he is
>:>giving information to the attacker independent of the type of file being
>:>compressed since if the file the attacker is looking at can't be
>:>decompressed the attacker imediately knows that the wrong key was
>:>selected.
>
>: The problem you fail to neglect is that with any headerless compression
>: scheme, you can feed in random data, and *something* will come out the
>: output of the decompression algorithm. (What comes out may or may not
>: make any sense, but determining that is another problem altogether.)
>
>Your right - I doubt David "fails to neglect" this ;-)
I was paraphrasing David :-)
>Firstly I doubt that /all/ headerless compression schemes decompress any
>input file to something. All that is needed to prevent this are checksum
>bits in the file - stripping headers may - or may not - remove such
>entities.
I suppose this comes down to a definition of what one means by "headerless."
A header need not be a fixed-format block at the beginning of a file.
Other sorts of regularity in a file can be mathematically equivalent to
this: A checksum bit in the output file would amount to a sort of header.
Whereas, a checksum bit in the input file could be argued not to be
part of the compression algorithm per se.
Clearly we need to agree on what "headerless" means before proceeding with
the discussion.
>David's scheme (in addition to allowing each file to decompress to a vaild
>file, also ensures that each file decompresses to a *unique* file. I've
>recently explained the benefits of this in another thread - and David
>appears to have understood the security benefits from the start.
David's "1-1" criterion is not mathematically necessary. All that is
necessary is to ensure that every file is a valid input file to the
decompressor. If the algorithm is not "1-1" then some input files may
produce infinite-length output files. But this does not help the
attacker, because determining this is equivalent to the halting problem.
>Essentially a compressor which fails to do this is extremely likely to be
>systematically adding data to the file. It /may/ in principle be possible
>to use this added information in an attack much like a known plaintext
>one.
Not necessarily (see above).
>Rather than try and make this difficult, David's compression makes it
>impossible - by ensuring that no data is added to the file at all by
>the compression program.
>
>: And you have to decompress all the way to the end of the input before
>: you can determine whether it represents a finite-length file.
>
>?
>
>If you have a finite size input you need a pretty bizarre decompressor
>to produce an infinite file.
No. To the contrary, it can be proved mathematically that any
deterministic compressor that is not "1-1" (in David's sense) behaves
this way, as long as every file represents a valid input file to the
decompressor. Would you like me to give an outline of the proof?
In practice it is easy to imagine a decompressor that can produce
infinite-length output files. All you need is a pointer that points back
to itself and produces the same block of output over and over.
>You don't even need to decompress *at all* to determine whether it
>represents a finite-length file.
This is wrong. It is easy to make a decompressor does not reject any
input file. But whether a given file produces an infinite amount of data
when run through the decompressor is really the crux of the matter.
Computationally speaking. It comes down to the halting problem,
as I mentioned earlier.
>With some compression schemes you may be able to determine whether the
>file is a valid compressed file from a small fraction of it. As far as
>resisting crypyanalysis goes, this is not good.
That is true, but in the context of the present discussion, when every
file is a valid input file to the decompressor, determining whether the
message is valid can only be guessed with some probability.
>: Thus your "one-to-one" property is essentially of no advantage to an
>: attacker.
>
>Your conclusion does not follow from your premises, and is, in fact, not
>correct :-(
>
>:> This problem fails to even exist if one is using correct one to
>:>one compression.
>
>: Please explain how this is so.
>
>I've tried to do so a couple of times recently. Essentially non
>one-on-one compressors have to choose which of a number of possible
>compressed files an uncompressed plaintext compresses to.
That would be true if David were using "1-1" to mean "1-1". But
he is using it to mean "onto". At least, I never got the sense that
he was using the term as you imply from the above.
>Perhaps you can cite some material from said "real" cryptographers,
>mathematicians or computer-scientists relating to one-on-one compression?
Ok, here goes. The "ideal" compression function for a given probability
model is given as follows: Let P be the set of finite-length ASCII
plaintexts, ordered by their likelihood of occurrence. You can think
of P as the positive integers, with "1" representing the most likely
plaintext, "2" the second most likely, etc. according to the probability
model. The compression consists of replacing the ASCII plaintext with
the corresponding integer. This is a bijective function, hence invertible.
This is also provably the best possible compression algorithm, although
you cannot necessarily implement it in practice given a probability
model.
David's algorithm is a special case of this "ideal" compression
function, according to a particular probability model. Don't ask me
to figure out what the probability model looks like, though.
g.
--
I conceal nothing. It is not enough not to lie. One should strive
not to lie in a negative sense by remaining silent. ---Leo Tolstoy
ADDRESS ALTERED TO DEFLECT SPAM. UNSOLICITED E-MAIL ADS BILLED $500
Geoffrey T. Falk <gtf(@)cirp.org> http://www.cirp.org/~gtf/
------------------------------
From: nereid@
Subject: Re: Weakness in the Rijndael key schedule?
Date: 24 Oct 1999 23:57:34 GMT
Reply-To: [EMAIL PROTECTED]
Tom StDenis said:
>Yak yak yak yak.
>
Was this fo Mr: Fisher or Scott (grin) :@)
-will-
CAUTION: Do not look into laser beam with remaining eye....
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
