Cryptography-Digest Digest #219, Volume #12 Thu, 13 Jul 00 10:13:01 EDT
Contents:
Re: General Question on cryptography (John Savard)
multiplier ("Andrew Dunlop")
Re: attack against CBC mode (Serge Vaudenay)
Re: attack against CBC mode (Serge Vaudenay)
Re: Steganographic encryption system (Paul Martin)
Re: Steganographic encryption system (Paul Martin)
Re: multiplier (Mark Wooding)
Re: Bit Shuffling (Runu Knips)
Re: Proposal of some processor instructions for cryptographical applications
("Stefan Monnier " <[EMAIL PROTECTED]>)
Re: General Question on cryptography (SCOTT19U.ZIP_GUY)
Third announcement for ECC 2000 (Alfred John Menezes)
Re: Bit Shuffling (Tom Knight)
Re: Diffie Hellman Primes : Speed Tradeoff Q (DJohn37050)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: General Question on cryptography
Date: Thu, 13 Jul 2000 11:20:31 GMT
On Thu, 13 Jul 2000 04:53:09 GMT, "DW" <[EMAIL PROTECTED]> wrote, in part:
>This is probably a naive question, and is probably addressed in a source
>that I'm not aware of (perhaps someone could direct me to a source), but
>one of the things that's always made me curious about cryptography is
>why can't someone develop a combination of algorithms that no one
>would ever think of in attacking encrypted data?
>Just to give you an example, one might take a plain text, convert it to a
>binary stream, convert that to 32 bit unsigned integers, take the FFT,
>reverse the
>real and imaginary parts, re-order the resulting bitstream by reversing the
>order of every block of n+2 bits, where n is the day of the month modulo
>the day of the week, and finally perform RSA on the result.
>How would one attack data encrypted by such an algorithm? It seems like
>you need to have an idea of the algorithm used and maybe
>even the order, and I don't see how one would guess this? Can you attack
>it mathematically to decrypt it without discovering each algorithmic
>operation after many many several messages have been sent?
You have asked an important question.
Because it is one of the important and basic questions of
cryptography, however, it has been asked before - and answered - as
noted in the other replies you have received.
Most typical attacks on a cipher do rely upon knowledge of the
underlying algorithm. The preliminary stage of determining the
algorithm used has been described for simpler ciphers: thus, by
frequency counts, contact charts, and autocorrelation one can
distinguish between common pencil-and-paper ciphers such as
monalphabetic substitution, Playfair, transposition, and Vigenere.
If someone attacking a message of yours can't even *think of* the
algorithm you are using, your message would be safe. But the keyspace
of ideas like "use FFT" is not really that large. That you are using
RSA would likely provide the _real_ security your message has, and
that part of the algorithm could likely be inferred by the nature of
your previous exchange of keys.
Cryptography as it exists today has been shaped by influential writers
on the subject. Auguste Kerchoffs made a list of six characteristics
the ideal cipher should have. One of them is that a cipher's easily
changeable key - rather than the algorithm itself - should be the
source of its security.
There are good reasons for this. One key can be easily replaced by
another, if someone has made a mistake (i.e. losing their password
which was written down). But if someone finds out your clever secret
algorithm, it takes longer to think of a new idea just as clever. So
the idea is that keys are replaceable, but algorithms should be good
enough that they can be kept around for a while.
John Savard (teneerf <-)
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Andrew Dunlop" <[EMAIL PROTECTED]>
Subject: multiplier
Date: Thu, 13 Jul 2000 12:46:02 +0100
Hi,
I'm looking for a smallish fast multiplier capable of multiplying 512 or
1024 bit numbers for RSA. Does anyone have suggestions for a good method?
thanks
A.
------------------------------
Date: Thu, 13 Jul 2000 13:43:48 +0200
From: Serge Vaudenay <[EMAIL PROTECTED]>
Subject: Re: attack against CBC mode
Doug Kuhlman wrote:
>
> Serge Vaudenay wrote:
> >
> > Research announcement:
> >
> > [...]
>
> Umm...Bruce Schneier mentions this on pages 196-197. "The birthday
> paradox predicts that there will be identical blocks after 2^{m/2}
> blocks, where m is the block size. For a 64-bit block size, that's
> about 34 gigabytes."
>
> Isn't this just what you've said?
>
> [...]
>
> Doug
Bruce refers to another (but similar) problem which is also related
to birthday issues, but against the MAC property of CBC: we can modify
the ciphertext by detecting patterns. If the ciphertext stream is
xayaz where a is a single block, we can consider the ciphertext xaz
or xayayaz, ... The legitimate recipient will decrypt a meaningfull
message which will not be the right one.
Similar properties are also refered in recent papers on CBC-MAC (e.g.
by Bellare et al, FOCS'97). All criticisms we found in usual books
against the CBC mode are related to the MAC property and not to the
confidentiality.
Our attack is not essentially new though (Jim Massey told us that
Martin Hellman had similar comments 20 years ago, and I guess that this
attack has been re-invented several times by several independent
researchers). Our work just aimed to run the experiment and to show
again that current standards are not as secure as what is usually
claimed. Typically, we can have a very good block cipher with 1024-bit
secret keys and still security issues!
Security is not limited by the key size only. It is limited by the
block size as well.
Serge
------------------------------
Date: Thu, 13 Jul 2000 13:46:12 +0200
From: Serge Vaudenay <[EMAIL PROTECTED]>
Subject: Re: attack against CBC mode
Doug Kuhlman wrote:
>
> Serge Vaudenay wrote:
> >
> > Research announcement:
> >
> > [...]
>
> Umm...Bruce Schneier mentions this on pages 196-197. "The birthday
> paradox predicts that there will be identical blocks after 2^{m/2}
> blocks, where m is the block size. For a 64-bit block size, that's
> about 34 gigabytes."
>
> Isn't this just what you've said?
>
> [...]
>
> Doug
Bruce refers to another (but similar) problem which is also related
to birthday issues, but against the MAC property of CBC: we can modify
the ciphertext by detecting patterns. If the ciphertext stream is
xayaz where a is a single block, we can consider the ciphertext xaz
or xayayaz, ... The legitimate recipient will decrypt a meaningfull
message which will not be the right one.
Similar properties are also refered in recent papers on CBC-MAC (e.g.
by Bellare et al, FOCS'97). All criticisms we found in usual books
against the CBC mode are related to the MAC property and not to the
confidentiality.
Our attack is not essentially new though (Jim Massey told us that
Martin Hellman had similar comments 20 years ago, and I guess that this
attack has been re-invented several times by several independent
researchers). Our work just aimed to run the experiment and to show
again that current standards are not as secure as what is usually
claimed. Typically, we can have a very good block cipher with 1024-bit
secret keys and still security issues!
Security is not limited by the key size only. It is limited by the
block size as well.
Serge
------------------------------
From: [EMAIL PROTECTED] (Paul Martin)
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: Steganographic encryption system
Date: 13 Jul 2000 12:08:18 GMT
In article <[EMAIL PROTECTED]>,
phil hunt wrote:
>ObBashBillG:
>I once had a smallish (10 pages) Word document. The file was 100K.
>When I made minor changes to it, it became 200K. When I exported it to
>RTF, it became 2000K.
The 100k expansion sounds like the effects of "fast save on". Many
Word-to-plain-text utilities give erroneous results if you have fast
save (essentially, I suspect, a direct memory dump) turned on.
I can't comment about the RTF version. Despite being plain text,
MS-generated RTF isn't usually human readable.
--
Paul Martin <[EMAIL PROTECTED]>
at home, swap dash to dot to email.
------------------------------
From: [EMAIL PROTECTED] (Paul Martin)
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: Steganographic encryption system
Date: 13 Jul 2000 12:08:19 GMT
In article <[EMAIL PROTECTED]>,
phil hunt wrote:
>> >(2) What's a good private-key cypher algorithm to use?
>>
>> There are certain pitfalls with ciphers in this context. Assuming you use
>> a block cipher, you have to consider the chaining mode.
>What's a chaining mode?
It's where you allow the results of encrypting the previous block
influence the results of encrypting the current block.
>> in terms of a cryptography expert for the prosecution. Showing repeated
>> data which are, say, 64 bits in length and multiples of 64 bits apart would
>> be enough to show that it wasn't random data and that the likely explanation
>> is that it is encrypted data.
>This is infact what blowfish does (I've just checked it). But I thought
>blowfish was a strong cipher? -- obviously I must be wrong somewhere here.
>So how do I get it so it doesn't repeat?
The vulerability here using a cipher in codebook mode (block in + key
-> cipher algorithm -> block out). You need to introduce some
randomness into the input blocks, so that the same data block input
does not generate the same data block in the output.
Usual ways of doing this are to use "salt" values, along with cipher
chaining.
I'd also suggest looking at the Twofish algorithm, from the same people
who thought up Blowfish.
--
Paul Martin <[EMAIL PROTECTED]>
at home, swap dash to dot to email.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: multiplier
Date: 13 Jul 2000 12:10:21 GMT
Andrew Dunlop <[EMAIL PROTECTED]> wrote:
> I'm looking for a smallish fast multiplier capable of multiplying 512
> or 1024 bit numbers for RSA. Does anyone have suggestions for a good
> method?
Old-fashioned long multiplication usually works best for crypto-sized
numbers. The trickier part is modular reduction: division is
complicated and slow, so tricks such as Montgomery reduction are
important. For a useful guide to implementation multiprecision
arithmetic, see chapter 14 of the Handbook of Applied Cryptography,
which you can get from http://www.cacr.math.uwaterloo.ca/hac/.
-- [mdw]
------------------------------
Date: Thu, 13 Jul 2000 14:06:54 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Bit Shuffling
Jayant Shukla wrote:
> [...] I will demonstrate a method to
> shuffle an N-bit data block using an
> N-bit key.
So ?
> This operation is reversible. [...]
All bit transformations are invertible.
> p.s.: I have a patent pending on this.
Hey, another attempt to patent addition.
------------------------------
From: "Stefan Monnier <[EMAIL PROTECTED]>" <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical applications
Date: 13 Jul 2000 08:34:44 -0500
>>>>> "Douglas" == Douglas A Gwyn <[EMAIL PROTECTED]> writes:
> "Stefan Monnier " wrote:
>> Of course, it's never been seriously considered because it would
>> break a whole bunch of C code (since C specifies that sizeof(char)
>> is 1 and people happily cast from integers and pointers all the time).
> Casts are conversions and as such can involve whatever shifts,
> masks, normalizations, etc. are necessary.
I'm sure you know that doing such things when the cast changes an
(int*) into a (char**) is rather difficult.
Stefan
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: General Question on cryptography
Date: 13 Jul 2000 12:41:39 GMT
[EMAIL PROTECTED] (John Savard) wrote in
<[EMAIL PROTECTED]>:
>On Thu, 13 Jul 2000 04:53:09 GMT, "DW" <[EMAIL PROTECTED]> wrote, in part:
>
>>This is probably a naive question, and is probably addressed in a
>>source that I'm not aware of (perhaps someone could direct me to a
>>source), but one of the things that's always made me curious about
>>cryptography is why can't someone develop a combination of algorithms
>>that no one would ever think of in attacking encrypted data?
>
>>Just to give you an example, one might take a plain text, convert it to
>>a binary stream, convert that to 32 bit unsigned integers, take the
>>FFT, reverse the
>>real and imaginary parts, re-order the resulting bitstream by
>>reversing the order of every block of n+2 bits, where n is the day of
>>the month modulo the day of the week, and finally perform RSA on the
>>result.
>
>>How would one attack data encrypted by such an algorithm? It seems like
>>you need to have an idea of the algorithm used and maybe
>>even the order, and I don't see how one would guess this? Can you
>>attack it mathematically to decrypt it without discovering each
>>algorithmic operation after many many several messages have been sent?
>
>You have asked an important question.
>
>Because it is one of the important and basic questions of
>cryptography, however, it has been asked before - and answered - as
>noted in the other replies you have received.
>
>Most typical attacks on a cipher do rely upon knowledge of the
>underlying algorithm. The preliminary stage of determining the
>algorithm used has been described for simpler ciphers: thus, by
>frequency counts, contact charts, and autocorrelation one can
>distinguish between common pencil-and-paper ciphers such as
>monalphabetic substitution, Playfair, transposition, and Vigenere.
>
>If someone attacking a message of yours can't even *think of* the
>algorithm you are using, your message would be safe. But the keyspace
>of ideas like "use FFT" is not really that large. That you are using
>RSA would likely provide the _real_ security your message has, and
>that part of the algorithm could likely be inferred by the nature of
>your previous exchange of keys.
>
>Cryptography as it exists today has been shaped by influential writers
>on the subject. Auguste Kerchoffs made a list of six characteristics
>the ideal cipher should have. One of them is that a cipher's easily
>changeable key - rather than the algorithm itself - should be the
>source of its security.
>
>There are good reasons for this. One key can be easily replaced by
>another, if someone has made a mistake (i.e. losing their password
>which was written down). But if someone finds out your clever secret
>algorithm, it takes longer to think of a new idea just as clever. So
>the idea is that keys are replaceable, but algorithms should be good
>enough that they can be kept around for a while.
>
>John Savard (teneerf <-)
>http://home.ecn.ab.ca/~jsavard/crypto.htm
>
Ok John way to go thats one. What are the next 5?
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS **no JavaScript allowed**
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed ** JavaScript OK**
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction
of the truth."
------------------------------
From: [EMAIL PROTECTED] (Alfred John Menezes)
Subject: Third announcement for ECC 2000
Date: 13 Jul 2000 13:05:57 GMT
==============================================================================
THE 4TH WORKSHOP ON ELLIPTIC CURVE CRYPTOGRAPHY (ECC 2000)
University of Essen, Essen, Germany
October 4, 5 & 6 2000
ECC 2000 is the fourth in a series of annual workshops dedicated to the
study of elliptic curve cryptography and related areas. The main themes
of ECC 2000 will be:
- The discrete logarithm and elliptic curve discrete logarithm problems.
- Provably secure discrete log-based cryptographic protocols for
encryption, signatures and key agreement.
- Efficient software and hardware implementation of elliptic curve
cryptosystems.
- Deployment of elliptic curve cryptography.
It is hoped that the meeting will encourage and stimulate further
research on the security and implementation of elliptic curve
cryptosystems and related areas, and encourage collaboration between
mathematicians, computer scientists and engineers in the academic,
industry and government sectors.
There will be 16 invited lectures (and no contributed talks), with the
remaining time used for informal discussions. There will be both survey
lectures as well as lectures on latest research developments.
SPONSORS:
Certicom Corp.
Communications and Information Technology Ontario
CV Cryptovision
Forschungsverbund Datensicherheit (Minist. SWWF, NRW)
Infineon
MasterCard International
Metris
Mondex International Limited
Siemens AG
University GH Essen
University of Waterloo
ORGANIZERS:
Gerhard Frey (University of Essen)
Steven Galbraith (University of Essen)
Alfred Menezes (University of Waterloo)
Scott Vanstone (University of Waterloo)
CONFIRMED SPEAKERS:
Jan Camenisch (IBM Zurich, Switzerland)
Ronald Cramer (BRICS, Denmark)
Pierrick Gaudry (LIX, France)
Erwin Hess (Siemens, Germany)
Ansgar Heuser (BSI, Germany)
Neal Koblitz (University of Washington, USA)
Robert Lambert (Certicom Corp., Canada)
Arjen Lenstra (Citibank, USA)
Peter Montgomery (Microsoft Research, USA)
Christof Paar (Worcester Polytechnic Institute, USA)
Phil Rogaway (University of California at Davis, USA)
Takakazu Satoh (Saitama University, Japan)
Ernst Schulte-Geers (BSI, Germany)
Igor Semaev (Moscow, Russia)
Nigel Smart (University of Bristol, UK)
Scott Vanstone (University of Waterloo, Canada)
CONFERENCE PROGRAMME
There will be sixteen invited lectures, each of 50 minutes duration
and with 10 minutes of question time. All lectures will be held on
the campus of the University of Essen. The tentative titles of the
lectures are:
Camenisch Group Signature and Identity Escrow Schemes
Cramer Secure Multi-Party Computation from Homomorphic
Threshold Encryption
Gaudry Hyperelliptic Curve Discrete Logarithms
Hess Aspects of Public-Key Cryptosystems in Practice
Heuser Public Key Cryptography from the Point of View of a
National InfoSec Agency
Koblitz Miracles of the Height Function - A Golden Shield
Protecting ECC
Lambert Block Architectures for Cryptographic Hardware
Lenstra The XTR Public-Key System
Montgomery Parallel Block Lanczos
Paar Reconfigurable Hardware in Modern Cryptography
Rogaway Stopping Dictionary Attacks
Satoh Canonical Lifting of Elliptic Curves and p-Adic Point
Counting -- Theoretical Background
Schulte-Geers Collision Search in a Random Mapping: Some Asymptotic
Results
Semaev Discrete Logarithms in Prime Finite Fields for Special
Moduli
Smart Recent Work on Weil Descent
Vanstone The Last Fifteen Years of Public-Key Cryptography
Further details of the programme and lecture room will be given in
the next announcement.
The lectures will begin at 9:00am on October 4 and run through until
the afternoon of October 6.
There will be a social event of some sort on the evening of October 4.
A banquet will be held on the evening of October 5.
There will some limited email facilities.
REGISTRATION
There will be a registration fee this year of DM 200 or $ 100 US
(DM 100 or $ 50 US for students). PLEASE REGISTER AS SOON AS POSSIBLE
AS SPACE IS LIMITED FOR THIS WORKSHOP; REGISTRATION IS ON A
FIRST-COME FIRST-SERVE BASIS. The deadline for registration has been
set to Monday September 4. To register, complete, in full, the
attached REGISTRATION FORM and return it
by e-mail to: [EMAIL PROTECTED]
by mail to: Ms. Karin Rufaut
Institute for Experimental Mathematics
Ellernstrasse 29
45326 Essen
Germany
Phone: +49/201/183-7656(7649)
========================cut from here=================================
ECC 2000 CONFERENCE REGISTRATION FORM
Fullname:
_________________________________________________________
Affiliation:
_________________________________________________________
Address:
_________________________________________________________
_________________________________________________________
_________________________________________________________
_________________________________________________________
_________________________________________________________
E-Mail Address:
_________________________________________________________
Telephone #:
_________________________________________________________
Mark your choice:
Registration Fee: DM 200 / $ 100 US
Student Registration Fee: DM 100 / $ 50 US
(Registration Fee Includes Banquet)
Attending Banquet: Yes / No Vegetarian: Yes / No
Extra Guest Banquet Fee: DM 50 / $ 25 US
Guest Vegetarian: Yes / No
TOTAL REGISTRATION FEE: DM____ / $____ US
PAYMENT MUST BE MADE IN CASH ON ARRIVAL AT THE RECEPTION DESK.
Accommodation (please mark your choice)
( ) I would like to reserve a single- DM 115 per night
room for ___ nights, from ___
to ___ October, 2000 (please fill
in the dates of arrival and
departure).
( ) I would like to reserve a single- DM 130 per night
room with a large bed ("grand lit")
for ___ nights, from ___ to ___
October, 2000.
( ) I would like to reserve a double- DM 75 per person / per night
room for ___ nights, from ___ to
___ October, 2000 and I would like
to share it with _________________ .
( ) I would like to reserve a bed in DM 75 per person / per night
a double-room from ____ to ___
October, 2000 and I'm ready to share
it with another participant of the
conference.
( ) I don't need a hotel room.
The hotel bill should be paid directly at the hotel reception.
=========================cut from here===============================
TRAVEL
Essen is situated approximately 30 km from Duesseldorf International
Airport and about 250 km from Frankfurt Airport.
Participants should plan to arrive on October 3 to be able to attend
the lectures on Wednesday morning.
Duesseldorf Airport to Essen Hauptbahnhof (main station):
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
From any of the terminals take the free airport bus to
the train station (Flughafen bahnhof). From there you can
buy a "zone C" ticket for DM13 and you must remember to
validate (time stamp) the ticket before boarding the train.
There are plenty of trains from this station to Essen HBF.
The Zone C ticket is valid on S-Bahn, RE and IR trains.
If you take an Intercity train then you will have to pay
a higher fare but this can be bought from the conductor on
the train.
Note that there is an airport in Monchengladbach which is also
called "Duesseldorf airport" and which is served by a few smaller
airlines within Europe. One can also get to Essen from this airport
by using the S-bahn, but the journey time is longer (about 2 hours).
Frankfurt Airport to Essen Hauptbahnhof (main station):
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
There is a train (InterCity) which goes directly from Frankfurt/Main
Airport to "Essen Hauptbahnhof". There is one train an hour. the
journey takes approximately 3 hours and costs around DM 100.
An exact timetable for these (and other) trains can be found
at http://bahn.hafas.de/bin/detect.exe/bin/query.exe/en
Tickets may be purchased at the station or on the train.
Another possibility is to take suburban train (S-Bahn) S8 to Mainz
and then change to an Essen train. For "InterCity" trains it is
necessary to pay a DM 7 supplement.
Essen Hauptbahnhof (main station) to the University of Essen:
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
To walk from Essen Hauptbahnhof to the University of Essen takes
around 20-25 minutes. It is also possible to take the
underground train U11 direction "Universitaet Essen"
and get off at the "Universitaet Essen" stop. On the underground
it is necessary to buy a ticket in advance and validate (time stamp)
it either before entering the platform or immediately upon boarding
the train.
Maps of the region, city and university can be found at:
http://www.uni-essen.de/plan/
ACCOMMODATION
There is a limited block of rooms set aside on a first-come first-serve
basis at three mid-range hotels in Essen: "Korn's Hotel", "Europa"
and "Lindenhof". All three hotels are close to both the Essen main station
and the University of Essen and can easily be reached by public transport.
Breakfast is included. We ask you to make your hotel reservations with us.
In all three hotels, the price is DM 115 for a single room and DM 150 for
a double room. "Korn's Hotel" also has single rooms with a large
bed ("grand lit"), the price for these rooms is DM 130 per night. If you
prefer such a room, please indicate on the registration form. If all the
single rooms for DM 115 are booked out, we will automatically reserve
a single room with "grand lit" for DM 130 for you.
The addresses of the hotels and their exact location will be given in
the next announcement.
===========================================================================
------------------------------
Subject: Re: Bit Shuffling
From: Tom Knight <[EMAIL PROTECTED]>
Date: 13 Jul 2000 09:37:00 -0400
This exact instruction has been known for many many years, and was in
the ISA of the Microunity processor, ca. 1994 (along with many other
nice features such as access to the register file in bitwise or
wordwise form, allowing bit transpose).
Log2 (n) of these will allow arbitrary permutation, but it is highly
useful for field extract and dispath in other contexts as well.
The inverse operation (bit scatter, rather than bit gather) is also
useful. I believe the combination of the two operations allows bit
permute in 1/2 log2 (n) ops, but I haven't looked at that wrinkle in
years.
Your patent attorney will tell you that you have a continuing legal
obligation until patent award to disclose prior art which you become
aware of -- you are now aware of some. I have no interest in this
other than the elimination of more invalid patents to keep track of.
[EMAIL PROTECTED] (Jayant Shukla) writes:
> "Adam Durana" <[EMAIL PROTECTED]> writes:
>
> >This is a total rip off of something I posted early in 1999. I called it
> >"slotting" and the only difference between what you present here and what I
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Diffie Hellman Primes : Speed Tradeoff Q
Date: 13 Jul 2000 13:57:23 GMT
And look at IEEE P1363 which discusses all this.
Don Johnson
------------------------------
** 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
******************************
