Cryptography-Digest Digest #248, Volume #13 Thu, 30 Nov 00 18:13:00 EST
Contents:
Re: keysize for equivalent security for symmetric and asymmetric keys (Bob Silverman)
Re: keysize for equivalent security for symmetric and asymmetric keys (Bob Silverman)
Re: New symmetric-key distribution ("cj")
Re: keysize for equivalent security for symmetric and asymmetric keys (Roger
Schlafly)
Re: keysize for equivalent security for symmetric and asymmetric keys (Bob Silverman)
SAC2001 Call for Papers (Amr Youssef)
Re: keysize for equivalent security for symmetric and asymmetric keys (DJohn37050)
Re: Pentium 4 and modular exponential ([EMAIL PROTECTED])
Re: Pentium 4 and modular exponential ([EMAIL PROTECTED])
Re: Entropy paradox ("Douglas A. Gwyn")
Re: How to find celebrity ("Douglas A. Gwyn")
Re: Public key encryption in Javascript? (Paul Rubin)
Re: Pentium 4 and modular exponential (Paul Rubin)
Re: Public key encryption in Javascript? (Paul Rubin)
Re: How to find celebrity (Andreas Gunnarsson)
Re: A Simple Voting Procedure (Shawn Willden)
Re: New cipher idea (Mok-Kong Shen)
Re: New symmetric-key distribution (John Savard)
Re: hardware RNG's ("Douglas A. Gwyn")
PAK performance (was Re: P/w based authentication and key exchange) ("Michael Scott")
Re: Pentium 4 and modular exponential (Cornelius Sybrandy)
Re: Q: Role of linguistics ("Douglas A. Gwyn")
Re: Are there collisions in DES? ("Douglas A. Gwyn")
Re: Pentium 4 and modular exponential (Paul Rubin)
----------------------------------------------------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: keysize for equivalent security for symmetric and asymmetric keys
Date: Thu, 30 Nov 2000 20:07:40 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> On Wed, 29 Nov 2000 21:30:02 GMT, Bob Silverman <[EMAIL PROTECTED]>
> wrote, in part:
>
> >In a sense, you are trying to compare the difficulty of flying
> >to different galaxies. The greater Magellenic cloud is only 150,000
> >light years away, while M31 is 2 million light years away. Is the
> > latter "harder to reach"? There is no such thing as
>
> >"twice as impossible with forcastable technology".
>
> Yes, but who says the technology around in 100 years from now is all
> going to be forecastable today?
This response is just plain silly. Noone is trying to determine
what will be safe key sizes 100 years from now! We are trying to
do it for the forseeable future.
--
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: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: keysize for equivalent security for symmetric and asymmetric keys
Date: Thu, 30 Nov 2000 20:12:01 GMT
In article <[EMAIL PROTECTED]>,
Richard Heathfield <[EMAIL PROTECTED]> wrote:
<snip>
> Moore's Law. By 2032 (or so), we'll have computers a million times
> faster than today's computers. By 2066, they'll be one million million
> times faster. By around 2100, one single computer will be able to do
the
> work of the batch of computers you describe in the above paragraph.
This is just silly speculation.
(1) Noone is trying to predict 66 years in the future.
(2) No competent computer architect that I know would be willing to
opine that Moore's law will hold until 2032. Remember that:
(a) There are quantum limits to how small one can make gates
(b) The speed of light is finite
--
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: "cj" <[EMAIL PROTECTED]>
Subject: Re: New symmetric-key distribution
Date: Thu, 30 Nov 2000 22:11:40 +0200
Reply-To: "cj" <[EMAIL PROTECTED]>
How about Husmail.com?
cj
"Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
news:8vvggr$q86$[EMAIL PROTECTED]...
>
> <[EMAIL PROTECTED]> wrote in message news:8vvar5$u4m$[EMAIL PROTECTED]...
> > I was curious are there any new symmetric-key distribution techniques
> > being used today? No, asymmetric techniques...just symmetric techniques.
> >
> > I know of:
> > 1) Trusted 3rd party
> > 2) Key-splitting for delivery
> > 3) Physical delivery
> > 4) Kerberos
> Errr, Kerberos is "a trusted 3rd party".
>
> >
> > If you have any others, please fill me in.
>
> How about:
> 5) Joint computation on public/private data to form the symmetric key
(e.g.
> Diffie-Hellman)
> 6) Transport of symmetric key by public key encryption (e.g. as in PGP)
>
> --
> poncho
>
>
>
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: keysize for equivalent security for symmetric and asymmetric keys
Date: Thu, 30 Nov 2000 12:27:49 -0800
Bob Silverman wrote:
> ? ?"twice as impossible with forcastable technology".
> ? Yes, but who says the technology around in 100 years from now is all
> ? going to be forecastable today?
>
> This response is just plain silly. Noone is trying to determine
> what will be safe key sizes 100 years from now! We are trying to
> do it for the forseeable future.
I dunno about you, but I am planning on having my head frozen
and getting a regenerated body in 2250, and I don't want to be
embarrassed by love letters to my mistress^H^H^H^H^H^H^H^Hwife
that I have carefully encrypted. <g>
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: keysize for equivalent security for symmetric and asymmetric keys
Date: Thu, 30 Nov 2000 20:21:40 GMT
In article <[EMAIL PROTECTED]>,
Roger Schlafly <[EMAIL PROTECTED]> wrote:
> DJohn37050 wrote:
> > ANSI X9 mandates that RSA modulus n or DSA field size p be at least
1024 bits
> > and that the ECC subgroup order n be at least 161 bits. Each is
estimated to
> > be around 2**80 ops in complexity and so is appropriate to use with
SHA-1 and
> > 80-bit symmetric keys.
>
> They are bankers. Do they have infinite wisdom?
I agree with you.
This is the group who, when I told them that strong primes added no
security to RSA said: "We want them anyway, they give us a warm fuzzy
feeling, please tell us how to compute them quickly".
--
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: Amr Youssef <[EMAIL PROTECTED]>
Subject: SAC2001 Call for Papers
Date: Thu, 30 Nov 2000 15:49:02 -0500
First Call For Papers (SAC 2001)
-------------------------
Eighth Annual Workshop on Selected Areas in Cryptography to be held at:
Fields Institute, Toronto, Ontario, Canada August 16-17, 2001
Workshop Themes
================
1. Design and analysis of symmetric key cryptosystems.
2. Primitives for private key cryptography, including block and stream
ciphers, hash functions and MACs.
3. Efficient implementations of cryptographic systems in public and
private key cryptography.
4. Cryptographic solutions for web/internet security.
Program Committee
===================
Stefan Brands Zero-Knowledge Systems, Canada
Matt Franklin UC Davis, USA
Henri Gilbert France Telecom, France
Howard Heys Memorial University of Newfoundland, Canada
Hideki Imai University of Tokyo, Japan
Shiho Moriai NTT, Japan
Kaisa Nyberg Nokia Research Center, Finland
Rich Schroeppel Sandia National Lab, USA
Doug Stinson University of Waterloo, Canada
Stafford Tavares Queen's University, Canada
Serge Vaudenay (co-chair) EPFL, Switzerland
Michael Wiener Entrust Technologies, Canada
Amr Youssef (co-chair) University of Waterloo, Canada
Yuliang Zheng Monash University, Australia
Instructions for Authors
=========================
Submissions must consist of an extended abstract of at most 15
double-spaced pages, clearly indicating the
results achieved, their significance, and their relation to other work
in the area. Authors can either email
one copy of a Postscript file to SAC2001@ep .ch or send ten copies of
the extended abstract to
SAC 2001
EPFL - DSC - LASEC
IN- Ecublens
1015 Lausanne - Switzerland
Tel.: +41-21-693-7603
Important Dates
=============
Submission Deadline May 7
Notification of Acceptance June 25
Workshop Dates August 16-17
Deadline for Proceedings September 16
Proceedings
===========
It is intended that the Proceedings will be published by Springer-Verlag
in the Lecture Notes in Computer
Science (LNCS) Series. In order to be included in the Proceedings,
papers must be presented at the Workshop
by one of the authors. As in previous years, the Workshop Record will be
available to participants.
For further information contact:
Serge Vaudenay EPFL [EMAIL PROTECTED]
Amr Youssef University of Waterloo [EMAIL PROTECTED]
Conference web page:
====================
http://lasecwww.epfl.ch/sac2001/
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 30 Nov 2000 21:00:41 GMT
Subject: Re: keysize for equivalent security for symmetric and asymmetric keys
I think that is a misrepresentation of their thinking. The question was, what
happens IF an RSA key is presented in a repudiation case that is able to be
factored in reasonable time using Pollard P+1 or P-1 methods. The real answer
is that it goes before a judge and then who knows what happens. They decided
to address this potential concern by requiring that these factoring methods not
work, as the cost was relatively small.
Don Johnson
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Pentium 4 and modular exponential
Date: Thu, 30 Nov 2000 21:10:27 GMT
Paul Rubin <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] writes:
>> On the other hand, the FPU is slower than the P3. To be fair though,
>> that's countered by the faster clock. You can FADD every clock cycle,
>> and FMUL every other clock cycle. You cannot, however, start them on
>> the same cycle.
> Interesting, thanks. I'd want to use integer instructions for modexp,
> of course.
The integer ops look like they'll probably be better for most
everything, honestly. They have alot lower latency and execute
faster. As to wether the amount of fine tuning you'd need to do to get
the pipelines full compares to other architectures though, I don't
know.
> But the memory access sequence for these convolutions is mostly
> sequential and totally predictable, so it should be ok to use the
> cache prefetch instructions to overlap arithmetic that you're doing
> now with loads of stuff that you're going to need later?
Except that, if memory serves, and this is shooting from the hip this
morning. Intel shrunk the cache size again. For the ALU it doesn't
really matter, for the FPU though, if it's not in the 8k L1 cache, you
pay a big penalty going back to L2. That's probably only an issue
under heavy loads, however.
> Nah, I was just wondering what the prospects were. I have too many
> other things to occupy my time. Thanks for the update.
All in all, it looks like the rest of Intel offerings to me. The only
number crunching they seem really interested in is the types of things
multimedia developers use heavily. Which is, of course, a perfectly
understandable focus in their current market.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Pentium 4 and modular exponential
Date: Thu, 30 Nov 2000 21:17:17 GMT
James Dabbs <[EMAIL PROTECTED]> wrote:
> This situation reminds me of when 386's came out and everyone said the
> performance increase was not so great. Of course everyone was running
> segmented 16-bit apps and it was hard and expensive to find 32-bit tools.
> Well, same thing now. Of course, with IA-64, I can't even see how a C++
> compiler can even make use of the architecture.
I think both the latest Intel offerings are open questions. There
isn't enough software yet to realistically compare them to other
architectures. It may, in fact, never be settled given Intel's gift
for leapfrogging the competition at surprising times.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Entropy paradox
Date: Thu, 30 Nov 2000 20:43:34 GMT
Mok-Kong Shen wrote:
> to generate u bits, with u >> m. We know that (accepting
> certain plausible assumptions) the u bits are provably
> secure.
There is a simple proof that on average at least u-m
bits are predictable from knowledge of the other m.
So probably you're being confused by the sloppy use of
"provably secure". You need to refer to the *specific*
theorem that has been proven in order to figure out
exactly what is meant by that phrase.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: How to find celebrity
Date: Thu, 30 Nov 2000 20:56:01 GMT
Benjamin Goldberg wrote:
> Done properly, each of the first N-1 questions asked eliminated exactly
> one person from the set of people who might possibly be a celebrity.
> There is then exactly one person left, who might or might not be a
> celebrity, and this needs close to 2(N-1) questions to determine if this
> is so (slightly fewer, because some of the questions have already been
> asked).
That is certainly *one* strategy, which one might as well use
in a practical implementation of a solver for instances of the
problem, but the interesting question is whether that is an
*optimal* strategy. This could be specialized into best,
worst, and "typical" case scenarios. (For the last, one
probably one has to make an assumption about the probability
distribution of knowledge among the n individuals.)
Also, what if there are multiple celebrities and the problem
is to identify them *all*.
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Public key encryption in Javascript?
Date: 30 Nov 2000 13:36:50 -0800
If you're trying to do it in perl, just use the Math::BigInt module
that's part of the standard perl distribution (Camel book 2nd ed. p. 460).
Doing a 512-bit modexp in the obvious way with that library takes a
few seconds on a current x86 workstation.
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Pentium 4 and modular exponential
Date: 30 Nov 2000 13:38:00 -0800
[EMAIL PROTECTED] writes:
> Except that, if memory serves, and this is shooting from the hip this
> morning. Intel shrunk the cache size again. For the ALU it doesn't
> really matter, for the FPU though, if it's not in the 8k L1 cache, you
> pay a big penalty going back to L2. That's probably only an issue
> under heavy loads, however.
For modexp, the data objects are 128 bytes each and there should only
be a few of them in play at any step. I think the cache is split 8k/8k I+D
so that should be enough.
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Public key encryption in Javascript?
Date: 30 Nov 2000 13:44:48 -0800
[EMAIL PROTECTED] writes:
> Of course there's many optimizations which I'm sure I missed in the
> arbitrary precision binary add, multiply, subtract and modulo
> functions, but the scarey thing is that I think it works! I hope I
> don't get sued for posting this on usenet... Which, by the way, do you
> suppose this violates any patent/copyright laws?
Certainly it should win some sort of prize ;-). Very cute.
------------------------------
From: Andreas Gunnarsson <[EMAIL PROTECTED]>
Subject: Re: How to find celebrity
Date: Thu, 30 Nov 2000 22:40:59 +0100
On Thu, 30 Nov 2000, Douglas A. Gwyn wrote:
> Also, what if there are multiple celebrities and the problem
> is to identify them *all*.
Assume that there were two celebrities, A and B. Either A knows B in which
case A is not a celebrity, or A does not know B in which case B is no
celebrity.
Therefore there can only be zero or one celebrities according to the
definition.
Andreas
--
Andreas Gunnarsson <[EMAIL PROTECTED]>
Carlstedt Research & Technology
Phone: +46 31 7014268
Mobile: +46 70 4262889
Fax: +46 31 101987
------------------------------
From: Shawn Willden <[EMAIL PROTECTED]>
Subject: Re: A Simple Voting Procedure
Date: Thu, 30 Nov 2000 14:39:22 -0700
David Schwartz wrote:
> > The judge was ultimately overturned on appeal. In the US, you cannot be
> > ordered to reveal your vote.
>
> Yes, nevertheless he successfully ordered three people to reveal their
> votes. Had each of those three people not revealed their votes, they
> would have been thrown in jail. If that's not a case of a 3rd party
> forcing a voter to reveal their vote, I can't imagine what would be.
Actually, he forced them to state *some* vote. Since there's no way the voters or
anyone else could prove whether or not they were telling the truth, there's no way
they could be convicted of perjury. They could be thrown in jail for refusal to
answer (seems like that would be contempt of court, not perjury), but as long as
they gave some reasonable and believable answer (e.g. not "Micky Mouse") who's to
say they're lying?
Shawn.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: New cipher idea
Date: Thu, 30 Nov 2000 22:55:10 +0100
Benjamin Goldberg wrote:
>
> The global variable mask contains coefficients for 8 parallel (using
> SIMD) order 16 primitive polynomials in GF(2)^N.
Questions of ignorance: What is N? In the books I have,
I see only primitive polynomials over GF(p^m) but never
over GF(q)^n. Could you recommend a book (or papers)
that contains good treatment of the latter kind of objects?
Thanks.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: New symmetric-key distribution
Date: Thu, 30 Nov 2000 21:51:46 GMT
On Mon, 27 Nov 2000 21:37:53 -0800, "Scott Fluhrer"
<[EMAIL PROTECTED]> wrote, in part:
>Errr, Kerberos is "a trusted 3rd party".
One could think of Kerberos as having only two parties in it (because
it's hierarchical), or it could simply be listed separately because
it's a technique of particular interest.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: hardware RNG's
Date: Thu, 30 Nov 2000 21:22:15 GMT
Tim Tyler wrote:
> Certainly I think if you describe such biased streams as "random",
> then you are likely to cause confusion in discussions with many people.
Only amateurs who use a term only on the basis of a
vague, fuzzy feeling instead of a precise definition.
The pros are well aware that random processes can
produce biased distributions. That is why when we
mean "uniform random" we say "uniform random": to
make clear when the uniformity is an important
property in the context of the discussion. The
unadorned term "random" covers a wide gamut of
intrinsically imperfectly predictable behavior.
A typical example of a professional definition is
http://www.stats.gla.ac.uk/steps/glossary/probability_distributions.html
wherein it is immediately made clear that a random
variable has an associated probability distribution
or density function; if the function is flat then
we have uniform randomness, but if the function is
anything else (as most functions are!) then the
randomness is not uniform.
------------------------------
From: "Michael Scott" <[EMAIL PROTECTED]>
Subject: PAK performance (was Re: P/w based authentication and key exchange)
Date: Thu, 30 Nov 2000 22:20:45 -0000
"Michael Scott" <[EMAIL PROTECTED]> wrote in message
news:ojcV5.1864$[EMAIL PROTECTED]...
>
> "Thomas Wu" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > "Michael Scott" <[EMAIL PROTECTED]> writes:
> >
> > > Its fun to try and develop such methods. What about this? Choose g and
r
> as
> > > "random" independent generators of prime order q|(p-1). Let s be the
low
> > > entropy mutual secret.
> > >
> > > Alice A=g^a . r^s mod p
> > > Bob B=g^b . r^s mod p
> >
> > The discrete log of r (with base g and mod p) must remain unknown for
this
> > to work, i.e. if an attacker found y such that g^y == r (mod p), he
could
> > carry out an attack.
> >
>
> Of course, but that's not difficult to organise. For example g=3^[(p-1)/q]
> mod p and r=5^[(p-1)/q] mod p. In the unlikely event that either of these
> evaluates as 1, then use another small prime. Now you need to be able to
> solve a discrete log problem to find one from the other.
>
> > In any case, this is slower than PAK, which uses s directly instead of
> > r^s, and doesn't have any security advantage that I can see. The only
> > possible advantage is that you're operating in the q-order subgroup
> > mod p.
> >
>
> Not significantly slower. And in fact as far as I can see from my reading
of
> PAK, it has to "bend over backwards" to get into the q-order subgroup,
and
> this requires an on-line exponentiation by (p-1)/q, which is much greater
> than q (typically), and so requires a lot more work (?). Am I right about
> this?
>
To answer my own question I am right, and PAK is in fact a lot slower. It
requires online exponentiation by (p-1)/q. Commonly p is 1024 bits and q is
160 bits, so this is exponentiation with an 864-bit modulus, and this is of
course more than 5 times slower than if exponents were all 160 bits. In the
PAK-R protocol as described in
http://www.bell-labs.com/user/philmac/pak_view/node3.html
the protocol has been "slightly revised" to cleverly load this large
calculation on just one side of the protocol - Bobs side. But it hasn't gone
away.
Mike Scott
>
> Mike Scott
>
> > > Swap A and B
> > >
> > > Alice calculates key as (B/r^s)^a mod p = g^(xy) mod p
> > > Bob calculates key as (A/r^s)^b mod p = g^(xy) mod p
> > >
> > > Throw in a few hash functions and the odd random oracle, and does this
> work?
> > > Note that if s=0, then this is just Diffie-Hellman.
> > >
> > >
> > > Mike Scott
> >
> > --
> > Tom Wu * finger -l [EMAIL PROTECTED] for PGP
> key *
> > E-mail: [EMAIL PROTECTED] "Those who would give up their
freedoms
> in
> > Phone: (650) 723-1565 exchange for security deserve
> neither."
> > http://www-cs-students.stanford.edu/~tjw/
> http://srp.stanford.edu/srp/
>
>
------------------------------
From: Cornelius Sybrandy <[EMAIL PROTECTED]>
Subject: Re: Pentium 4 and modular exponential
Date: Thu, 30 Nov 2000 17:48:26 -0500
You would have to use SSE 2 in order to get any integer speedups. On
one review site, maybe Toms Hardware, it was stated that the reason he
integer ALU is "double pumped" is to keep up with existing CPU's. The
P4 only really beat an Athlon in two benchmarks and that was due to
chip-specific optimizations. If you just want to use regular x86
optimizaions or you don't feel like paying the ~$1K, you'd be better off
with an Athlon.
csybrandy
Paul Rubin wrote:
> Anyone looked into this? The P4 is getting some bad press at normal
> applications, but it might be a win for modexp. Its ALU runs at 2x
> the clock speed of the rest of the chip, i.e. the 1.5 ghz P4
> (available now for around $1K) runs its ALU at 3 ghz. Also, it has
> yet another MMX extension, this time called SSE2. This lets you use
> the 128-bit SSE registers as a pair of 64-bit long long ints or IEEE
> doubles. What I don't know is whether you can start a pair of
> multiply-adds on every cycle (3 ghz) or what; and you can arrange
> the input data to use it at full speed without overflows.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Q: Role of linguistics
Date: Thu, 30 Nov 2000 21:33:13 GMT
Mok-Kong Shen wrote:
> If I don't err, in the old days knowldege of languages played
> a non-trivial role in cryptanalysis. With modern cryptography,
> which works at the fine level of bits, the significance of
> linguistics to crypto seems to have disappeared completely.
> Could someone confirm this?
No, although source-language characteristics aren't as
important as they once were in cryptanalysis, they still
have ramifications.
> On the other hand, advances in automatic language translations
> etc. suggest that automatic analysis of sentences is nowadays
> without problems and perhaps even certain degree of understanding
> of natural utterences is feasible.
Hardly. Automated understanding of unconstrained natural
languages remains a hard problem that is nowhere near solved.
Note also that many modern plaintexts are not expressed in
natural languages.
> If the domain of discourse is appropriately restricted,
> wouldn't the limited number of sentence structures together
> with default words and eventually in combination with a code
> book be exploitable as a valuable means of preprocessing
> (encoding) of the plaintext before its treatment by a proper
> modern encryption algorithm?
Codebooks have long been used as the inner layer of multiply
encrypting systems, primarily for their compression rather
than their secrecy, although certainly codes have been used
for secrecy (often not as secure as the designer intended).
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Are there collisions in DES?
Date: Thu, 30 Nov 2000 21:36:50 GMT
John Savard wrote:
> Quite possibly. If it could be proven that this could never happen,
> DES would then have a simple structure that could be easily
> cryptanalyzed.
That doesn't make sense. One could *already* proceed on
that assumption, and whether DES then becomes easily
cryptanalyzed should not be hard to determine empirically.
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Pentium 4 and modular exponential
Date: 30 Nov 2000 15:09:39 -0800
Cornelius Sybrandy <[EMAIL PROTECTED]> writes:
> You would have to use SSE 2 in order to get any integer speedups.
Yes, that's correct, the question was about whether there was a gain
to be had by using SSE2.
------------------------------
** 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
******************************
