Cryptography-Digest Digest #446, Volume #10 Mon, 25 Oct 99 05:13:04 EDT
Contents:
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Vernon
Schryver)
Re: NAI version of PGP secure? (Gurripato)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 24 Oct 1999 09:52:33 -0600
In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
> ...
>>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.
>
>Cipher negotiation is not in itself cryptographic.
If cipher negotiation is not critical to keeping secrets, then there is
no reason to do it. The 1st Amendment lets anyone claim that a failure in
cipher negotiating could not possibly compromise security, but no one who
has dealt with real life security protocols will believe it. It is an
egregious offense against the dictum that theory and practice are not the
same to imply that cipher negotiating would never open any security holes.
> It can and should
>occur under the current cipher(s) and should be a straightforward
>selection. ...
That's what they all said about PPP selecting MTU's, IP addreses,
and authentication schemes, TCP doing PMTU discovery, and SSL.
>Cipher negotiation is not the same situation as modem negotiation.
>Since modem negotiation is in fact used in practice to make dynamic
>connection-by-connection negotiated decisions, it shows that this is
>in fact practical in deployed systems.
I have never said or even implied that cipher negotiating is impossible.
My original example, PPP, shows that negotiating things is possible.
The issue is whether in practice you can design and deploy a cipher
negotiating system that would not make people run away screaming.
Haven't you noticed the signature "SSL isn't" of one author here?
How will your cipher negotiating protocol be certain to not only
avoid all of SSL's problems, but also all possible new problems?
> ...
>>>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"?
>
>PPP is not cipher negotiation.
It is at best intellectually dishonest to say that PPP is so different
from cipher negotiating that the PPP experience is irrelevant. In both
PPP and cipher negotiating, all that the computers do is agree on some
parameters. Moreover, as I've mentioned, one of the biggest real life
negotiating problem areas in PPP has been the negotiation of authentication
protocol, picking among PAP, MD5 CHAP, MS-CHAP (which involves MD4 and
DES), and MS-CHAPv2 (ditto, except I think they use MD5 also or instead).
"MD4", "MD5", and "DES" refer to the familiar hash and encryption
functions. One PPP peer says "let's try X", for X=its preferred
authentication algorithm. The other peer says either "ok" or "no, instead
let's use Y." The first says either "ok, let's use Y", or shuts down or
restricts the link to traffic not needing authentication. Isn't that
exactly what you envision for cipher negotiating?
Read the forthcoming edition of James Carlson's PPP book in which he
describes some of the many ways the PPP authentication negotiation fails
in real life. In theory and in the RFC's, of course, it's perfect.
> ...
>Just what is it that you don't get about requesting a cipher, then
>receiving an answer, yes, no, or a suggested alternative, all of which
>occurs in the error-corrected data? It is fine to be wairy of new
>ideas, but this seems somewhat OTT.
My point is that "requesting an X, then receiving an answer, yes, no or
suggested alternative"
- is an idea is anything but new or untried.
- is exactly PPP Configure-Requests, Configure-Naks, and Configure-Acks.
- it is nothing like what occurs in "error-corrected data", except as
I might explain things to someone with no idea of or interest in
negotiating things or CRC's, forward error codes, and ARQ.
> ...
>The whole basis for cipher selection is very clean.
That is statement, like others of yours in support of cipher negotiating,
is like what the fellow who advocates extremely long keys says about his
code and ciphers. It is at best an expression of a hope.
> ...
>And just what standards committee would that be, exactly?
If you negotiate your ciphers for the purpose of protecting IP (including
IPv6) data, the IETF would ensure it is involved eventually. If you move
down a layer, you would get the ITU or an ad hoc committee like the ATM
Forum or an official committee such as IEEE 802.3 or ANSI x.3. If you go
up, say to protect HTTP, you'll be involved with the W3C or the IETF.
In real life, whether you or I like it or not (I don't), if you are talking
about a multi-vendor protocol, you will have standards committees involved.
Have you not noticed where the next version of SSL is being done?
If you use cipher negotiating to protect voice data, you'll find the CLEA
forcing equipment vendors to get your protocol sanctioned by a standards
committee to avoid fines for failing to include enough wire tapping. (See
the recent big noises in the "raven" mailinglist of the IETF in which the
IETF is trying to avoid getting involved in putting more tapping facilities
into IP. The on-line press has been filled with reports of that circus.)
>>> ...
>>>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.
>
>Negotiating a cipher can be and should be distinct from using any
>particular cipher. This is not a complicated network stuff, but a
>simple selection protocol quite comparable to what two people would do
>if they were discussing which cipher to use on the phone.
Exactly the same theory is said still about all of PPP.
Only salescritters and the clue challenged believe it.
Much of PPP negotiating is for small numbers, with one peer proposing a
value, and the other saying either "ok" or "let's do X instead." Almost
all of the rest of PPP negotiating consists of one peer saying "let's do
Z" and the peer saying either "yes" or "no". That's simpler than
your cipher negotiating, but it also has lots of real life problems.
> ...
>I have presented the example that modems do in fact in practice
>negotiate their state, today, in mass fielded systems. I am sorry if
>you have trouble with your modems, but I have used modems from home
>since the early 80's, we typically still do use modems from home
>several times a day, and considering that they are working on lines
>designed for voice and not data, they generally work well, and in fact
>much better than they used to.
And I have mentioned that I have been dealing with modems since the 1960's.
that modem negotiating is at best ugly under the covers (as you agreed),
that modems still sometimes fail to negotiate (as you agreed), and that
the modem protocol war continues as demonstrated by the still unwinding
v.90 battle.
Who is going to be using your cipher negotiating protocol before it matures
like modem protocols, before it works "much getter than [it] used to."
Personally, I'll be keeping data I care about under other schemes a while
longer than that.
As evidence that cipher negotiating could not escape standards committees,
note that major modem protocols for the last 10 years have involved the
worst of standards committees, the ITU.
> ...
>>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.
>
>OK, what could a bad guy do? The conversation is under cipher, the
>negotiation is under cipher, and if the cipher takes several exchanges
>to change, then it does. If there is no alternative cipher, there can
>be no agreement, and so no change. If one party insists that a change
>occur, and no change is possible, then, obviously, communication
>stops. What is hard about this?
If the initial cipher is absolutely secure, then there is no reason to
ever change it or negotiate anything.
You necessarily assume that the bad guys can break some ciphers. If
the bad guy has a real-time break of a cipher you happen to use for
a while, he can keep you from switching.
For a real life example of the problems of negotiating ciphers, "what is
hard about" SSL?
> ...
>No, I only wish to say that cipher negotiation is realistic and
>possible in real systems; it can hardly be opposed out of hand as
>"impossible" technology.
I've not seen anyone claim negotiating ciphers is "impossible." Nothing
I have said could be honestly interpreted as claiming impossibility.
After all, I've been talking about real life protocols that mostly work.
What I have been saying is that the inevitiable complications of
cipher negotiating are inevitably both large and problematic.
Worse, those inevitiable problems will include breaks in security.
>Changing ciphers is a great idea if we want to complicate any attack
>which requires the accumulation of ciphertext from a particular
>cipher. If, as we expect, opponents cannot distinguish the ciphers
>from their ciphertexts, they simply do not have the basis for most
>types of described attacks. I would call this a worthwhile motive for
>the modest additional complexity required to automatically switch
>ciphers.
I agree changing ciphers is an interesting idea. However, at best you
demonstrate traits unbecoming a "practicing engineer" when you describe
negotiating ciphers as "modest additional complexity." Good engineers
don't pronounce on things they know nothing about, and they don't lie
about things they do know about.
>That is not the only motive, however. Another good motive is to make
>the secure communications path resilient against the known failure of
>our favorite ciphers. Only if the systems can automatically move to
>new ciphers can we hope to avoid massive disruption from the failure
>of something which cannot be guaranteed in an engineering sense.
That conclusion is your thesis. You have not proven it.
> ...
>In my experience, many "standardized" technologies in fact start out
>as ad-hoc standards, and it is this genesis and the desire to stay
>with the mistakes of the past which -- as much as anything -- mark the
>problem.
In my experience, which has brushed against language as well as network
standards and committees, the predecessor to the standards committee
product is invariably smaller, cleaner, and more robust.
What standards committees do is no more or less "ad hoc" than what any
other committee, group, or individual does. There are no formulas for
producing protocols. They are all "ad hoc," but some are more informed
by past experience.
>The virtually universal practice in both hardware and software is to
>hack out a solution and ship it, with minimal thought given to
>consequences.
Maybe where you do your engineering, but not where I've been doing mine
for the last 30+ years.
> But "thought" is just what is going on here.
No, what is going on here is standard netnews, talk with very little
throught, and no significance.
Name a single protocol that has ever been designed in a netnews group.
Not even NNTP managed that trick.
> Only if
>we get a reasonable concensus about *what* need be done will it *then*
>make sense to try to standardize *how* that will be done.
I insist on considering at least sketches of "how" simultaneously with
"what." The worst protocol standards (e.g. the ISO OSI suite or MAP and
TOP) are created by committees deciding "what" before and independent of
"how."
Regardless, the only concensus that matters in the real world is among
what I think of as "practicing engineers" (people who actually build
things) and their customers. There is not a quorum of either for
considering negotiating ciphers.
> ...
>>>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.
>
>I doubt that I have ever said any such thing. I do not say that
>switching among ciphers is the only possible solution.
You said "There is no other possibility" in the words quoted above your
claim that you did not say that.
> ...
>The security advantages which accrue from "automated switching" among
>locally-approved ciphers are many and broad. ...
No one disagrees with that.
The trouble is that you go from that true statement to claims that
negotiating ciphers is easy, safe, and non-fattening. I think it is none
of those. I've designed and implemented more than 1 or 2 protocols since
my first simplistic hack that made two computers talk to each other over
phone lines in the 1960's, and merely implemented a lot more.
> ...
>>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.
>
>First of all, I think your use "real time" is confusing. When we talk
>about "real time operating systems" we mean systems which have defined
>worst-case performance characteristics.
I wish "real time operating systems" had something to do with "defined
worst-case performance characteristics," but by 10 or 15 years ago,
"defined" had been replaced by "rarely violated, we think." Now you must
demand "hard realtime" to get more than a prayer and a salescritter
promise.
> But I see no need for any
>such limitation on negotiation. Certainly cipher negotiation would
>"real time" in the sense that negotiation information would flow
>during message time, but *not* in the sense that it had to be
>accomplished before the next message could occur.
I carefully did not say "before the next message could occur," but
intentionally wrote "fairly soon."
>And any system which will benefit non-computer types must operate
>virtually on its own, with minimal setup and maintenance. In
>particular, it must be easy to stop using a particular cipher. If
>cipher changing is not the normal mode of operation, that is quite
>unlikely to work smoothly when needed.
Replace "cipher" with any of the parameters negotiated with PPP or SSL,
and I've heard those words many times. I'm not saying they are wrong,
but that in practice they do not imply what you wish they did, that
negotiating will work smoothly merely because it is central, and as
proof, I've pointed to many real life examples.
> ...
>We don't normally depend upon *perfect* software, because we cannot
>assure any such thing. Consequently, some implementations -- even of
>the best ciphers -- *will* have bugs. Having frequent cipher changes
>at least takes us out of a buggy implementation into some other
>implementation fairly quickly.
You could make money as a stand-up comedian for the IETF PPP Working
Group with lines like that. I'm serious; you would get big laughs
from people who have designed and built negotiating computer protocols by
saying that negoiating necessarily gets you out of anything quickly.
>>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.)
>
>Well, the world is *also* full of people who hack something together
>and then call themselves architects or designers; I like to think that
>there is something more involved. And while I can hardly speak for
>all those you have indicted here, I suppose we would all like to be
>more successful than we are.
>
>In cryptography, I have a well-documented 10-year history of
>publication in ink on paper, fundamental patents, and lately web page
>publications. You can read my papers on my pages. You can read how I
> ...
Have you implemented any of your ideas in commercial products?
>>The real architects, designers, and inventors not only desgin and invent,
>>but also build real implementations that are useful in real life.
>
>Since when did *you* get to decide what makes a "real" designer or
>inventor? I would say that, with respect to true scientific
>innovation, it is the argument that matters, and *only* the argument.
Nonsense! Outside of math, arguments are mere hot air. Even the purest
of theoreticians depend on experimentalists for validation. Besides
sci.cript is about enginnering instead of science or math, despite the
netnews hierarchy, and as you and others have implicitly been saying for
months in rants about the lack of theory of cipher strength.
No, don't bother pointing at the occassional elementary number theory or
complexity notion. I spent too many years in math graduate school to be
overawed by such things, especially when so many authors here get them
wrong.
>>So when
>>will we see the implementation of negotiated/varying ciphers that you are
>>building?
>
>I have some rather complete designs. But as I see it, there is little
>point in attempting to field such a product in an environment where
>"real" designers still think that cryptanalysis tells us that a
>standardized cipher must be strong, so we don't really need all this
>fancy cipher-change stuff. Perhaps things will change in a year or
>two.
To distinguish oneself from legions of cranks, all of whom have "rather
complete designs" for antigravity machines, FTL drives, perpetual motion
machines, and many other wonderful things, one must produce working
implementations that other people can test drive.
Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]=NOSPAM (Gurripato)
Subject: Re: NAI version of PGP secure?
Date: Mon, 25 Oct 1999 06:26:48 GMT
On Mon, 25 Oct 1999 08:06:31 +0400, "Sergey Kuznetsov"
<[EMAIL PROTECTED]> wrote:
>
>Adam Durana <[EMAIL PROTECTED]> wrote
>
>> think of the NSA, an institution with a lot of computing power maybe even
>> the institution with the most computing power in the world.
>
>Good example of how wasting people's money american goverment. What for NSA
>needs computing superpower, if they cannot to break even 128-bit key. And
>in order to read messages encrypted with PGP, not needed any supercomputer.
>
"Even to break a 128-bit key" is an enormous task, don�t
underestimate it. And remember that many people do not use 128 bits.
If people are still fool enough to use RC4-40 bits or DES, the NSA
will be deligthed to prove them wrong (without telling them, of
course).
------------------------------
** 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
******************************
