Cryptography-Digest Digest #417, Volume #10 Fri, 15 Oct 99 18:13:04 EDT
Contents:
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column ("Roger
Schlafly")
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
([EMAIL PROTECTED])
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Bob
Silverman)
The Quad. in RC6 (Tom St Denis)
Re: He is back...new "improved" code ("Belldandy")
Re: prime number problem (Bill Unruh)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column ("Trevor
Jackson, III")
Re: fast PSRG ++ A5 question (Ian Goldberg)
Re: He is back...new "improved" code ("Dan Fogelberg")
Re: He is back...new "improved" code ("Dan Fogelberg")
Re: He is back...new "improved" code ("Dan Fogelberg")
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
(DJohn37050)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
(DJohn37050)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (John
Savard)
PHT (Wojciech Laskowski)
Re: How many prime numbers? (Tim Tyler)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Mok-Kong
Shen)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Mok-Kong
Shen)
(fwd) Appeals Court to Review Bernstein Crypto Decision (Mok-Kong Shen)
----------------------------------------------------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Fri, 15 Oct 1999 06:52:02 -0700
Terry Ritter <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> The use of *keys* limits interoperability -- to those who have the
> right keys. We now do arrange to transfer keys as needed. We could
> arrange to transfer the name of the cipher to be used, or even the
> cipher itself.
Yes, having several ciphers is equivalent to having a couple of
extra key bits.
> ... Could Germany and Japan *prove* their ciphers
> were weak in WWII? Would they have been better off changing their
> (broken) ciphers?
Obviously they would have tried to design better ciphers if they knew
their ciphers were being broken. But diversity for the sake of
diversity would not have helped htem much, and might have even
hurt them because the alternative ciphers might be more easily
broken..
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Fri, 15 Oct 1999 15:03:10 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Bruce Schneier) wrote:
> On 10 Oct 1999 21:45:50 GMT, [EMAIL PROTECTED] (DJohn37050) wrote:
>
>>Multiple encryption using different ciphers was also mentioned in my
>>submission to the 2nd AES conference entitled "Future Resiliency: A
>>Possible New AES Criterion" and is available from NIST AES web site.
>
>Yes. In general, I find it uninteresting to talk about encryption
>when there are no constraints. Of course you can use multiple
>encryption using different ciphers, if you have the time/gates/etc.
>Of course it's more secure, as is almost everything if you throw
>enough rounds at it.
>
>Where it really matters, and where real cryptography comes into play,
>is when you have to deal with real-world performance decisions. I
>almost never have clients who can devote an arbitrary amount of
>computing resources to the encryption process. This is why AES is
>important.
Much of this thread has been about cascading ciphers as a way to
increase security. What I find interesting is that only a few months
ago many in this newsgroup thought that this is a bad idea. Cascading
ciphers was politically incorrect; even a top cryptographer I met in
the Second AES conference did not want me to quote him on this matter.
Now it is out in the open, and I think that the unstructured but fast
exchange of ideas in a newsgroup can help to dispel myths. (It
certainly helps when widely reputable people participate in the
discussion.)
The whole point in cascading ciphers, as opposed to adding rounds to a
single cipher, is to mix different kinds of structures and make the
whole beast less sensitive to an unforeseen attack. What this means is
that even after the AES a market will exist for unconventional ciphers.
Who knows, even my Frog algorithm may start hopping again. It is
simple, free, and is certainly very unconventional.
Another common issue in this tread has been about speed. Undoubtedly
there are applications that require extremely high speeds. There are
also many applications where speed is almost irrelevant. Almost all
client applications (working on the end-user's PC) don't require speeds
of encryption over a few megabits per second. IP telephony, for
example, requires only about 10 kbits per second. Contrast this to over
100 Mbits per second that can easily be achieved by the fastest AES
candidates on today's PCs. Using the AES alone for PC based IP
telephony makes little sense.
By the way, public key primitives are considered to be more susceptible
to catastrophic failure than any single symmetric cipher. Here too it
must make sense to use several methods in parallel, particularly with
the high speeds achieved by modern PCs. Unconventional public key
designs anyone? :)
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Fri, 15 Oct 1999 16:09:57 GMT
In article <7u6dgg$[EMAIL PROTECTED]>,
"Roger Schlafly" <[EMAIL PROTECTED]> wrote:
> DJohn37050 <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
<snip>
> > For systems with one alg, they switch over over time.
> >
> > I know that I MUCH prefer the possibilities of scenario B.
>
> Not me.
>
Option B has theoretical appeal, but it would be economically
impossible to put into practice. It wouldn't be that hard to
implement multiple choices in *software* and assign an OID to
transactions so the software can choose the correct algorithm.
But hardware vendors are not going to build AES based devices
with multiple algorithms. There are too many problems with trying to
do so. Especially for embedded devices and low power systems.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: The Quad. in RC6
Date: Fri, 15 Oct 1999 16:09:06 GMT
Ok to sumarize the quad in RC6 is
F(x) = x(2x + 1)
Which has been shown to be a function (multiplication of any variable by a
odd number is a function mod 2^w).
However have any weaknesses been found? What if you change it to
F(x) = x(ax + b)
Where (a, b) are round/key dependant integers (a being even and b being odd
of course)? Would that make it any harder to attack/model? Would it still
be a function (as shown in RC6)?
Is 'ax + b' called an affine transformation ? (Trying to get some
terminology down).
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Belldandy" <[EMAIL PROTECTED]>
Subject: Re: He is back...new "improved" code
Date: Fri, 15 Oct 1999 11:31:15 -0500
can you tell us about his last algorithm? that can be a good place to start.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: prime number problem
Date: 15 Oct 1999 16:30:22 GMT
In <7u6ii8$92$[EMAIL PROTECTED]> [EMAIL PROTECTED] (Shyh-Tyan Liaw) writes:
] What I would like to ask is whether a number ,say
]a, is assumed a prime number after "some prime number
]test". That is to say that "is a number assumed to be
]a prime number if it passes a lot of prime number test
]in a practical use?" If not, is it chosen from some
]specific form, such as 2^(2^m)-1? In short, how to
]generate a prime number in practical?
A prime number is a number with no divisors other than itself. For some
purposes, you may be happy if you are given a number which you have some
confidence (ie probability very close to one) is prime. Then you use a
bunch of independent prime number tests of a putative prime, and if it
passes you accept it. That is what PGP does. PGP will pick a random
number of the appropriate size, test it. if it does not work, choose the
next odd number test it, etc until you find one that passes all the
tests. Youthen use it. You do NOT use some predictable form of number.
However, if you are happy with just some prime, I give you the number 3,
which I can assure you with absolute confidence is a prime.
------------------------------
Date: Fri, 15 Oct 1999 13:13:05 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Patrick Juola wrote:
> In article <[EMAIL PROTECTED]>,
> Trevor Jackson, III <[EMAIL PROTECTED]> wrote:
> >Patrick Juola wrote:
> >> In article <[EMAIL PROTECTED]>,
> >> Trevor Jackson, III <[EMAIL PROTECTED]> wrote:
> >> >
> >> >Any users desiring to communicate will be able to select a mechanism to do
> >> >so. Any analysis dismissing the active participation of the users in the
> >> >dynamic selection of their channel properties from amoug the telephone, fax,
> >> >and email is trivially flawed.
> >>
> >> Nonsense. The Three-Initial-Corp. decides to use XYZ encryption for
> >> all it's communication needs and invests several billion dollars in XYZ-
> >> compliant mailers, routers, telephones, and so forth. The Even-Larger-
> >> Five-Initial-Corp., independently, decides to invest in PQ encryption
> >> and spends similarly huge amounts on its scrambler phone.
> >>
> >> The individual participant/employees of the companies involved are
> >> probably not going to be able to "dynamically select" their encryption
> >> scheme; they will use what's on their desk. And what's going to happen
> >> when ELFIC buys TIC?
> >>
> >
> >Well, the one of the companies, either the one using fax or the one using email,
> >is going to have to change.
>
> ... and the whole *point* of having standards is to minimize and
> reduce the likelihood of this sort of retooling costs.
By this reasoning we should only use telephones and avoid fax and email channels?
After all it would reduce the tooling costs, right?
Any company that wanted to restrict its users to a single channel can do so. They
can prohibit faxes and emails in order to avoid the costs of providing the capability
and to avoid the benefits provided by improved communication.
If, for example, NIST didn't _choose_ a set of ciphers, each getting a binary
up/down, but instead _ranked_ the ciphers for various applications (email, network
transport, financial transactions, data repositories, etc.) it would be possible to
have the best of both worlds. A company could decide to use cipher #1 in each
application where it employed encryption. Everyone would use the same cipher in the
same applicaiton. Serious security would still be available because wise companies
could implement ciphers two and perhaps three in each application environment. If
each company choosing to implement a cipher followed the ranking for the particular
application in question all the companies would choose the same subset to reach the
same depth.
No retooling necessary.
------------------------------
From: [EMAIL PROTECTED] (Ian Goldberg)
Subject: Re: fast PSRG ++ A5 question
Date: 15 Oct 1999 17:25:38 GMT
In article <7u6mot$3jh$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>Which stream cipher or PSRG provide the
>best speed in hardware implementation?
>The security requirement is oriented on
>a block cipher with app: 2^^64 possibilities.
>
>****************
>
>The algorithm A5/1 which is used in GSM
>includes three LFSR.
>The key is 64 bit. In which way the key
>is used. Is the key the initial state of
>the registers or the feedback coefficients.
The initial state of the registers are all 0's. Then the key (and frame
number) is clocked in to _each_ register, one bit per clock. The
feedback taps are fixed.
- Ian
------------------------------
From: "Dan Fogelberg" <[EMAIL PROTECTED]>
Subject: Re: He is back...new "improved" code
Date: Fri, 15 Oct 1999 12:23:57 -0500
Agreed. I will see what I can come up with....
Dan Fogelberg is putting on his Sherlock Holmes hat :-)
Dan Day <[EMAIL PROTECTED]> wrote in message >
> He's stacking the deck by insisting that you operate under
> unrealistically restrictive conditions. He's also giving himself
> a false sense of security if you fail to crack it, because if he
> ever actually put his system into use, an adversary would have
> available far more to work with than you've been given, and your
> failure with a short example says very little about how easy it
> would be for a real-world adversary to overcome his system.
>
------------------------------
From: "Dan Fogelberg" <[EMAIL PROTECTED]>
Subject: Re: He is back...new "improved" code
Date: Fri, 15 Oct 1999 12:22:03 -0500
Last time it was a key repeatedly XOR'd with the plaintext
Belldandy <[EMAIL PROTECTED]> wrote in message
news:7u7kj3$rdd$[EMAIL PROTECTED]...
> can you tell us about his last algorithm? that can be a good place to
start.
>
>
------------------------------
From: "Dan Fogelberg" <[EMAIL PROTECTED]>
Subject: Re: He is back...new "improved" code
Date: Fri, 15 Oct 1999 12:20:05 -0500
Dan Day <[EMAIL PROTECTED]> wrote in message
> Hey, I've got an idea -- go sneak on to your buddy's computer when
> he's not looking, and snarf his program. This should be an excellent
> education for him on the above subjects. When he accuses you of
> "cheating", tell him that you're just using the exact same methods
> that an adversary in the real world would use, and that it's too bad
> he didn't protect his system against such real-world weaknesses,
> as you had urged him to do.
I love it!
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 15 Oct 1999 18:16:08 GMT
Yes, there will be systems which need to choose just one algorithm, no question
about that.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 15 Oct 1999 18:28:17 GMT
Well put Brian.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Fri, 15 Oct 1999 19:07:15 GMT
[EMAIL PROTECTED] (Terry Ritter) wrote, in part:
>It seems odd to me that you know what is on Schneier's mind,
I can only assume that it was something like your proposal he was
criticizing, because such a criticism wouldn't make sense applied to
what Brian Gladman was talking about.
Your proposal at least appeared to have serious weaknesses, the way
people understood it at first. (I certainly grant that you had a right
not to be amused at some of the things that happened as the thread
went along; you clarified some of the details of what you were
proposing as the result of questions, and the response was "how do we
know you didn't just steal the idea our question implied".)
>My experience is that those who
>support the conventional wisdom will avoid anything fundamentally new
>and disturbing at almost any cost. And if you are not part of the
>solution, you are part of the problem.
It's obviously wrong if you jump from "no cipher is proven secure" to
"all ciphers are equally bad". You may rightly protest that you never
jumped to that kind of conclusion, but at times you allowed it to
appear that this was the basis of your multi-ciphering proposal.
The "conventional wisdom" in cryptography, as in other fields, did not
arise simply by whim or prejudice, but came about as the result of
knowledge and experience. That doesn't mean it doesn't have its
limitations and omissions - many of which I feel you have correctly
located, and are attempting to address.
To be "part of the solution", however, one has to be more than a
"voice crying in the wilderness". And that involves paying the
conventional wisdom its due, and recognizing that due.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Wojciech Laskowski <[EMAIL PROTECTED]>
Subject: PHT
Date: Fri, 15 Oct 1999 21:57:03 +0100
Who tell me something about Pseudo-Hadamard Transform? I need know basic
of PHT. Maybe somebody knows any reference to this subject?
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: How many prime numbers?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 15 Oct 1999 19:57:38 GMT
jerome <[EMAIL PROTECTED]> wrote:
: On Wed, 13 Oct 1999 18:22:16 GMT, Tom St Denis wrote:
:>Do we know that for sure? I thought the highest we knew for sure was 10^22
:>or something around there...
: According to www.utm.edu/research/primes, the bigger known prime is
: 2^6972593-1. it is around 10^2098959, so much bigger than 10^22.
This is "the 38'th Mersenne prime". Mersenne primes don't say very much
about the /frequency/ of prime numbers, though.
The log formula was long though to be an overestimate - but it was
subsequently discovered that it dipped beneath the actual frequency of the
primes at some large figure - I presume this point was the one being
referred to.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
He wouldn't recognise subtlety if it hit him on the head.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Fri, 15 Oct 1999 22:26:17 +0200
Roger Schlafly wrote:
>
> Terry Ritter <[EMAIL PROTECTED]> wrote
> > ... Could Germany and Japan *prove* their ciphers
> > were weak in WWII? Would they have been better off changing their
> > (broken) ciphers?
>
> Obviously they would have tried to design better ciphers if they knew
> their ciphers were being broken. But diversity for the sake of
> diversity would not have helped htem much, and might have even
> hurt them because the alternative ciphers might be more easily
> broken..
I suppose it is (generally) assumed in the current discussion that
the top three candidates in the final round of AES contest are
approximately of the same quality, much like the three medalists
in Olympic games.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Fri, 15 Oct 1999 22:26:05 +0200
Roger Schlafly wrote:
>
> You mean because we have feet and meters in the US? To the extent
> this is true, distance measurement is not standardized. It is not an ideal
> situation, as evidenced by the recent crash of the martian probe.
Look at the programming languages. How many ISO standards are there?
And there are potential further candidates for standards in that
field. There are certainly interoperability problems with the
(surprisingly) fairly large number of standard or quasi-standard
programming languages. But the real world appears to be nevertheless
willing to accept the tradeoff involved as far as I am aware.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: (fwd) Appeals Court to Review Bernstein Crypto Decision
Date: Fri, 15 Oct 1999 22:28:05 +0200
[ The following forwarded message was originally posted by Peter
Randle to another group. ]
=======================================
Appeals Court to Review Bernstein Crypto Decision - EPIC Commentary:
The U.S. Court of Appeals for the Ninth Circuit has granted the
Justice Department's motion for rehearing in the closely watched
encryption case Bernstein v. DOJ. The case will be re-argued before
an 11-judge "en banc" panel of the court on December 16 in San
Francisco. On June 21, the Department filed its petition, seeking
to overturn the recent opinion of a Ninth Circuit panel holding
that encryption source code is scientific expression protected by
the First Amendment. The federal appeals court ruled on May 6 that
federal regulations that prohibit the dissemination of encryption
source code violate the First Amendment. The court found that the
regulations are an unconstitutional prior restraint on speech
because they "grant boundless discretion to government officials"
and have "effectively chilled [cryptographers] from engaging in
valuable scientific expression." The case was initiated by
researcher Daniel Bernstein, who sought government permission to
export source code he had written. EPIC was both co-counsel and
coordinator of a "friend-of-the-court" (amicus) brief in the case,
arguing against the government controls on privacy-enhancing
technology. Civil liberties and privacy organizations have
consistently opposed restrictions on the dissemination of encryption
technology, and welcomed the Bernstein decision as a major
breakthrough. The opinion was notable for its recognition of the
threats to privacy that citizens face today and the role of
encryption in protecting information. In seeking the Ninth Circuit's
reconsideration of the case, the Justice Department argued that the
May 6 decision rests on fundamental errors regarding First Amendment
and severability law. As a result of those errors, the panel has
placed the entire encryption export regime in jeopardy. The
potential consequences of repudiating the President's decisions
regarding encryption export controls are grave and far-reaching.
Before the views of the panel majority become the law of this
Circuit, and unrestricted export of encryption products receives
this Court's imprimatur, further review is imperative. The Clinton
Administration has announced that it will release revised
regulations on encryption exports by December 15 -- one day before
the scheduled re-argument in the Bernstein case. It is unclear what
effect those revisions might have on the Bernstein litigation.
Information on encryption export controls, including the text of the
Bernstein decision and the EPIC amicus brief, is available at the EPIC
------------------------------
** 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
******************************
