Cryptography-Digest Digest #288, Volume #10 Tue, 21 Sep 99 16:13:02 EDT
Contents:
Re: RSA encryption algorithm. (Tom St Denis)
Re: Schrodinger's Cat and *really* good compression (Tim Tyler)
Test ("MERSCH R.")
Re: key exchnages (again ;-) (Peter Gunn)
Re: frequency of prime numbers? (Ellis Dees)
Re: Another bug RE: CryptAPI ("John E. Kuslich")
Re: crypto export rules changing ("Douglas A. Gwyn")
Re: (US) Administration Updates Encryption Export Policy ("Douglas A. Gwyn")
Re: frequency of prime numbers? (Bill Unruh)
Re: Comments on ECC (Medical Electronics Lab)
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: RSA encryption algorithm.
Date: Tue, 21 Sep 1999 18:18:19 GMT
In article <[EMAIL PROTECTED]>,
Jeremy Botha <[EMAIL PROTECTED]> wrote:
> Hi all.
>
> I'm currently trying to code a single-byte-at-a-time RSA encryptor /
> decryptor. Basically, you give it N and the public key (where N is the
> modulus of the public and private keys) and it calculates possible private
> keys, then proceeds to test them. (Yes, this is arb)
>
> My problem is that I'm trying to code this in C/C++, and encryption /
> decryption requires *huge* numbers. I've tried long ints, long long ints,
> and finally in a fit of desperation, doubles. doubles seem to work okay,
> apart from the irritating fact that they loose precision, so when I decrypt
> the cypher it doesn't return to plaintext.
>
> Has anyone here tried anything in a similar vein? If so, I'd appreciate
> some pointers on what I can do to stop the program misbehaving.
You would have to use some large math lib. Micheal Frombeger has a good one
you could use. It's in peekboo as well...
Tom
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Schrodinger's Cat and *really* good compression
Reply-To: [EMAIL PROTECTED]
Date: Tue, 21 Sep 1999 16:22:06 GMT
Patrick Juola <[EMAIL PROTECTED]> wrote:
: In article <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
:>And here we come to Schrodinger's cat. One of the interpretations of
:>quantum mechanics held that a superposed quantum state did not resolve
:>itself into one state until it was exposed to the gaze of a *human
:>observer*.
: Your tense is admirably correct. One of the interpretations *held*; I
: believe it has since been disproved by experiment.
I don't think so. AFAIK, the only experiment capable of disproving the
Copenhagen interpretation involves observing interference effects on
"observers". As observers are macroscopic objects - with correspondingly
high frequencies - such an experiment is less than practical today.
To me, the interpretation appears to be wrong by Occam's rasor, rather
than through negative experimental evidence.
: It's easily possible to set up a mechanism to collaps the wave function
[...]
Hmm, one way of looking at the MWI, is to consider that wave functions
/never/ collapse - all that happens in the example you gave is that the
wave function of the slits and that of the photograph come to cohere.
A "collapsed wave function" may not be exactly the same as "a number of
elements becoming coherent" - from the POV of entities that have not yet
interacted with the system.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
A closed mouth gathers no feet.
------------------------------
From: "MERSCH R." <[EMAIL PROTECTED]>
Subject: Test
Date: Mon, 20 Sep 1999 17:54:00 +0200
Kleines Lexikon der Geheimschriften
A
A5, der Verschl�sselungsalgorithmus (eine Stromchiffrierung) der
Mobiltelefone (GSM). Es wird nur die
Verbindung zwischen Telefon und Basisstation verschl�sselt, der Rest der
Verbindung erfolgt unverschl�sselt. Die
Telefongesellschaft kann daher die Gespr�che abh�ren. Das
Verschl�sselungsverfahren wurde im Internet ver�ffentlicht.
A5 besteht aus drei LFSRs mit den Registerl�ngen 19, 22 und 23. Alle
R�ckkopplungspolynome sind d�nn besetzt. Als
Ausgabe dient die XOR-Verkn�pfung der drei LFSRs. A5 arbeitet mit variabler
Taktsteuerung. Jedes Register wird
abh�ngig von seinem eigenen mittleren Bit getaktet, das mit der invertierten
Schwellenwertfunktion der mittleren Bits aller
drei Register XOR-verkn�pft wird. Gew�hnlich werden in jeder Runde zwei der
LFSRs getaktet.
ABC, engl. Bez. f�r einen der vielen japanischen Codes im 2. Weltkrieg.
AB Cryptoteknik, schwedische Firma von Boris Hagelin.
Abadi, Martin, einer der Entwickler der BAN-Logik.
absolument s�r, frz., engl.: unconditionally secure.
absolute rate of the language, engl., frz.: taux absolu du langage.
Abwehr, Bezeichnung f�r den deutschen milit�rischen Nachrichtendienst
1933-1945, frz.: l�Abwehr; engl.:
German Intelligence Service, secret intelligence service of the German High
Command (cf. Sicherheitsdienst).
Offizielle Bezeichnungen ab 4.2.1938 �Amtsgruppe Abwehr�, ab 1939 �Amt
Ausland/Abwehr� im OKW. Die Abwehr
unterstand seit 1933 dem Kapit�n zur See Patzig, seit 1935 Admiral Wilhelm
Canaris.
AC, Abk. f�r Admirality Code.
acc�s, frz., engl.: login.
accr�didation, frz., engl.: accreditation.
ACM, Abk. f�r Association for Computing Machinery.
Adams, Carlisle, neben Staffort Tavares einer der Entwickler von CAST.
adaptative-chosen-plaintext attack, frz.: attaque � texte en clair choisi
adaptative, attaque � texte en clair
choisi dynamique,
ADFGVX, German Field Cipher, Verschl�sselungsverfahren der OHL im ersten
Weltkrieg (am 5.3.1918
erstmals ADFGX, ab 1.6.1918 dann ADFGVX). Ein f�r seine Zeit
hochkompliziertes Verschl�sselungsverfahren
(20-stellige Transposition, die anschliessend mit einer einfachen
Substitution mit t�glich wechselndem Schl�ssel
�berverschl�sselt wurde) das der franz�sische Kryptanalytiker Georges
Painvin erfolgreich knackte.
Adleman, M. Leonard, einer der RSA-Entwickler. 1994 zeigte Leonard M.
Adleman ein Verfahren zur L�sung
eines NP-vollst�ndigen Problems, wobei er in einem biochemischen Labor
DNS-Molek�le benutzte, um Vermutungen zu
L�sungen des Problems zu repr�sentieren (�L�sung� bedeutet dier �Antwort�
und keine Fl�ssigkeit - mit der
Terminologie wird es schwierig auf diesem Gebiet). Das Problem, das Adleman
l�ste, war ein Beispiel f�r einen
gerichteten Hamiltonischen Weg: Anhand einer Karte, auf der verschiedene
St�dte durch Einbahnstrassen verbunden
sind, sollte ein Weg von Stadt A nach Stadt Z gefunden werden, der alle
St�dte auf der Karte genau einmal durchl�uft.
Jede Stadt wurde durch einen anderen, zuf�llig gew�hlten DNS-Strang aus 20
Basen dargestellt. Mit konventionellen
molekularbiologischen Verfahren synthetisierte Adleman 50 Pikomol (30
Billionen Molek�le) von jedem der
DNS-Str�nge, die eine Stadt darstellen sollten. Genauso wurde jede Strasse
durch einen DNS-Strang aus 20 Basen
dargestellt, diese Ketten aber wurden nicht zuf�llig gew�hlt: Sie wurden so
klug ausgesucht, dass das �Anfangs�-Ende
des DNS-Strangs, das die Strasse von der Stadt P nach Stadt K darstellt
(�Strasse PK�), sich gerne mit dem
DNS-Strang f�r Stadt P und das andere Ende von Strasse PK sich mit Stadt K
verbindet.
Alberti, Leon Battista, Architekt und Sekret�r der P�pste Sixtus IV und
Innozenz VII, Freund von
Pontifikalsekret�r Leonardo Dato, Autor der ersten Abhandlung �ber
Verschl�sselungsverfahren �Trattati in cifra�,
1480.
algorithme, frz., der Algorithmus; engl.: algorithm.
algorithme � empilement, frz., engl.: knapsack algorithm.
algorithme � clef publique, frz., Algorithmus mit �ffentlichem Schl�ssel;
engl.: public-key algorithm.
algorithme � clef r�v�l�e, frz., Algorithmus mit �ffentlichem Schl�ssel;
engl.: public-key algorithm.
algorithme � clef secr�te, frz., engl.: one-key algorithm, single-key
algorithm, secret-key algorithm
symmetric algorithm.
algorithme cryptographique, frz., kryptographischer Algorithmus; engl.:
cipher, cryptographic algorithm.
algorithme de cassage, frz., engl.: cracking algorithm.
algorithme de chiffrement, frz., engl.: encryption algorithm.
algorithme de chiffrement en continu, frz., Stromchiffre, engl.: stream
cipher.
algorithme de chiffrement par blocs, frz., Blockchiffre; engl.: block
cipher.
algorithme de d�chiffrement, frz., Entschl�sselungs-Algorithmus; engl.:
decryption algorithm.
algorithme de hachage s�r, frz., engl.: Secure Hash Algorithm, SHA; Secure
Hash Standard, SHS.
algorithme fort, frz., engl.: computationally secure algorithm, strong
algorithm.
algorithme invuln�rable par calcul, frz., engl.: computationally secure
algorithm, strong algorithm.
algorithme Monte-Carlo de Pollard, frz., engl.: Pollard�s Monte Carlo
algorithm.
algorithme restreint, frz., engl.: restricted algorithm.
Algorithmus, siehe unter kryptographischer Algorithmus.
Algorithmus mit �ffentlichem Schl�ssel, Public-Key-Algorithm,
All-or-Nothing Disclosure Of Secrets, ANDOS, engl.,
Alles-oder-Nichts-Geheimnisenth�llung; frz.: divulgation
tout ou rien de secrets.
Alles-oder-Nichts-Geheimnisenth�llung, engl.: ANDOS,
American Cryptogram Association,
amplification d�erreur, frz., engl.: error extension.
Amtsgruppe Abwehr, siehe unter Abwehr.
Anagramm,
ANDOS, Acronym f�r engl. �All-or-Nothing Disclosure Of Secrets�,
Alles-oder-Nichts-Geheimnisenth�llung; frz.:
divulgation tout ou rien de secrets.
Angewandte Kryptographie, Protokolle, Algorithmen und Sourcecode in C, von
Bruce Schneier, 1996
Addison-Wesley (Deutschland) GmbH, ISBN 3-89319-854-7.
Angriff, eine versuchte Kryptanalyse. Generell lassen sich vier Arten von
kryptanalytischen Angriffen
unterscheiden: Ciphertext-only-Angriff, Known-plaintext-Angriff,
Chosen-plaintext-Angriff und
Adaptive-chosen-plaintext-Angriff. Weitere Angriffsarten sind:
Chosen-ciphertext-Angriff, Chosen-key-Angriff und
Kryptanalyse mit Gewalt.
Angriff mit Brachialgewalt, Brute-Force-Attack, alle Kryptosysteme, ausser
OTP bei unbegrenzten
Ressourcen, k�nnen mit einem ciphertext-only-Angriff gebrochen werden, indem
einfach nacheinander alle denkbaren
Schl�ssel ausprobiert werden und dann nachgesehen wird, ob der entstandene
Klartext irgendeinen Sinn ergibt.
Vergleiche: Kryptanalyse mit Gewalt.
Angriff mit gekauftem Schl�ssel, Kryptanalyse mit Gewalt, durch Bestechung
erlangter Schl�ssel.
Anon, Autor von �Cryptography� in Encyclopaedia Britannica, Vol. 6, 14th
edition, New York and London,
1929.
ANSI, Abk. f�r American National Standards Institute.
ANSI X3.92, erkennt DES 1981 als Standard f�r den privaten Sektor unter dem
Namen DEA an.
Arlington Hall, Hauptquartier der US Army Signal Security Agency.
Asfalia, die griechische �Gestapo� im 2. Weltkrieg.
Association for Computing Machinery, ACM, internationale Organisation der
Computerindustrie. 1994
ver�ffentlichte das US-amerikanische ACM Public Policy Committee einen
ausgezeichneten Bericht �ber die US-Politik
zur Kryptographie. Via Anonymous-FTP von info.acm.org aus
/reports/acm_crypto_study/acm_crypto_study.ps zu
beziehen.
Asymmetrischer Algorithmus, Synonym von Algorithmus mit �ffentlichem
Schl�ssel
(Public-Key-Algorithmus).
Atbash, etwa 650 v.Chr., eines von wenigen hebr�ischen Chiffrierverfahren.
ATS, Abk. f�r �Auxiliary Territorial Service�, rund 150.000 Frauen waren im
2. Weltkrieg den britischen
Landstreitkr�ften zugeteilt. Sp�ter Women�s Royal Army Corps.
attaque, frz., engl.: attack; der Angriff.
attaque � clef choisie, frz., engl.: chosen-key attack.
attaque � texte chiffr� choisi, frz., engl.: chosen-ciphertext attack.
attaque � texte chiffr� seulement, frz., engl.: ciphertext-only attack.
attaque � texte en clair choisi, frz., engl.: chosen-plaintext attack.
attaque � texte en clair choisi adaptative, frz., engl.:
adaptative-chosen-plaintext attack.
attaque � texte en clair choisi dynamique, frz., engl.:
adaptative-chosen-plaintext attack.
attaque � texte en clair choisi statique, frz., engl.: chosen-plaintext
attack.
attaque � texte en clair connu, frz., engl.: known-plaintext attack.
attaque de l�intercepteur, frz., engl.: man-in-the-middle attack.
attaque des anniversaires, frz., Geburtstagangriff; engl.: birthday attack.
attaque par blocs rejou�s, frz., engl.: block replay.
attaque par collisions, frz., engl.: meet-in-the-middle attack.
attaque par dictionnaire, frz., engl.: dictionary attack.
Authentifizierung, neben der Geheimhaltung soll die Kryptographie noch
andere Anspr�che erf�llen
(Authentifizierung, Integrit�t und Verbindlichkeit): Authentifizierung
heisst, es soll dem Empf�nger m�glich sein, die
Herkunft einer Nachricht zu ermitteln; ein Eindringling sollte sich nicht
als andere Person ausgeben k�nnen.
autoclaves, chiffrements, frz.,
auto-r�cup�rant, frz., engl.: self-recovering.
AVA, in der Warschauer Fabrik AVA f�r Radioapparate wurden in den Jahren vor
1940 auch Exemplare der
deutschen Enigma-Chiffriermaschine f�r den polnischen Geheimdienst
nachgebaut (etwa 15 bis 1939).
------------------------------
From: Peter Gunn <[EMAIL PROTECTED]>
Subject: Re: key exchnages (again ;-)
Date: Tue, 21 Sep 1999 16:28:05 +0100
Anton Stiglic wrote:
> I don't fully understand what your goal is? It seems like you
> are just trying to complicat the DH key exchange?
> What is your goal?
Goal is to negotiate a key exchange which is safe from a
Man-In-The-Middle attack by using a shared secret which is
weak ( < 56bits ). If you can do this, you can have secure 2 way
communications over an unsafe network using only a short memorable
password.
EKE does this by encrypting the g^X and g^Y values,
SPEKE uses a generator based on P (the weak shared
secret), etc. I thought I'd try and create my own version.
So, Im using a large safe prime modulous based on P,
and possibly using several smaller concurrent DH
exchanges.
BTW I made a typo, A->B the username as part of the first
message... but I guess you already knew that ;-)
ttfn
PG.
------------------------------
From: Ellis Dees <[EMAIL PROTECTED]>
Subject: Re: frequency of prime numbers?
Date: Tue, 21 Sep 1999 18:36:24 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Donald Welsh) wrote:
>
> I'd like to correct this misconception, if I may. Godel's theorem
> does not say that "there are true statements that cannot be proved".
> It says that there are unprovable statements. These statements are
> neither true nor false.
'This statement has no proof.'
True, but unprovable.
-Az
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Another bug RE: CryptAPI
Date: Tue, 21 Sep 1999 11:09:12 -0700
Your point is SO important.
I fear that most software enthusiasts today have been spoiled by the
high level language tools they use and are not close enough to the
machine upon which their code operates.
Now, modern software IDE's and compilers are powerful and wonderful
tools but they have the same effect that automobiles have on hiking
skills. Using these systems causes us to lose the muscle tone necessary
to navigate our environment.
There are many many useful things that can be accomplished by
understanding how Windows works at the machine or assembler level. Of
course viruses are one aspect of this kind of study but there are
actually important concepts that can be mastered by looking "under the
hood" of the Windows operating system by using a good debugger and
learning software at the assembler level.
Once this is done, you will realize that the crypto API code signing is
a sham. It is so easy to bypass these high level constructs that it
really does not matter what Microsoft or NSA does with respect to keys.
Anyone who understands Windows at this level could immediately extend
the strength of the encryption available in the Crypto API as they can
with the simpler encryption used by Word and Excel. These applications,
for example, are limited to 40 bit keys by a complicated process of
password hashing and key truncation but the process is accessible by
anyone with appropriate knowledge of the Windows API. This means that a
simple program could easily be written to extend the Word and Excel
encryption to 64 bits by merely writing to three locations in memory at
the appropriate time. (The thing would have to pass that "one time
review" and getting Commerce to understand the code would be a
challenge, but it could be done). The CreateProcess() and associated
functions are of particular interest.
To access the routines of the Advapi.dll in this manner should not be
much of a stretch once the dll is loaded under control of the assembly
language programmer.
Today we have a lot of powerful people in Washington making technical
policy judgements who are almost completely ignorant of the facts
involved. I refer to the news conference the other day on crypto export
restrictions. This problem is exacerbated by the fact that many of
todays software engineers have not mastered the required skills to be
able to properly advise policy makers. To assume that a Crypto API
requires code signing to use or alter its strength is like assuming that
your girlfriend is telling you the truth when she tells you she is a
virgin. You need remember the Reagan dictum..."Trust, but verify".
Check out http://www.crak.com/Word8doc.html for information on an
example of this kind of software analysis.
JK
Greg wrote:
> The NSA key overshadows this by a wide distance, but in case
> anyone is interested, I was looking for a way to develop
> strong encryption and making it into a crypto provider DLL.
>
> When I saw the gun registration forms- uh, I mean the crypto
> provider SDK forms- I immediately knew I had to figure a way
> around the Microsoft signature requirement. Anyone who wants
> to do this should use the NSA key approach- substitute your own
> key in place and then load your CPDLL. My approach is far more
> complicated and unnecessary.
>
> Anyway, what I did was figured that applications like bounds checker
> and the api spy that MS documents in their MSDN sample and white
> papers was an approach I would try. What I found was that on
> NT I could inject my crypto DLL into the address space of, say,
> MS Outlook Express. When it called the cryptAPI to encrypt or
> decrypt, I would catch it and redirect it to my DLL instead. And
> this worked. But then I realized that any virus can do the same
> and take a copy of the plain text that is on its way to be
> encrypted and broadcast it over the internet. So I completely
> abandoned my approach to ever develop encryption in a DLL. For
> more information, see www.ciphermax.com and go to the technology
> page.
>
> Again, the NSA key is a far more important find. It totally
> destroys any integrity MS has had- period. Kudos to those
> who made the discovery. Bugs are questionable. The NSA key
> is absolute and total conspiracy on the part of Microsoft to
> perpetrate fraud against its customers.
>
> Everything you need to know how to do this is totally documented
> by Microsoft. I will not supply any source code to anyone because
> I am not in the business of helping manufacture viruses.
>
> --
> Truth is first ridiculed, then violently opposed, and then it is
> accepted as self evident ("obvious").
>
> I love my president... I love my president... I love my president...
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
--
John E. Kuslich
Password Recovery Software
CRAK Software
http://www.crak.com
------------------------------
Crossposted-To: talk.politics.crypto
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: crypto export rules changing
Date: Tue, 21 Sep 1999 16:11:11 GMT
Greg wrote:
> No one will ever be able to have confidence that the software they
> are using has a trap door courtesy of NSA secret requirements if
> it had to pass NSA for a government license.
Nobody who is that paranoid will have such confidence in any case.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: (US) Administration Updates Encryption Export Policy
Date: Tue, 21 Sep 1999 16:29:48 GMT
"SCOTT19U.ZIP_GUY" wrote:
> ... C is good way to comunicate ideas.
I've been using C since near the beginning (and have been on the C
standards committee since the mid-1980s), and have to disagree
with that assertion. C source code, reasonably commented, is
a good way to document a *particular* implementation of some
ideas, but it has practically no power to express abstractions.
And working code has to deal with lots of details that are really
irrelevant to understanding the idea of an algorithm, which is
why "pseudo-code" is often used for such descriptions. E.g.
if no more input
sort input data
find median of input data
for each input data item
if value < median/2 or value > 3*median/2
output item
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: frequency of prime numbers?
Date: 21 Sep 1999 18:14:20 GMT
In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Donald Welsh)
writes:
>I'd like to correct this misconception, if I may. Godel's theorem
>does not say that "there are true statements that cannot be proved".
>It says that there are unprovable statements. These statements are
>neither true nor false.
Well, since the kind of statement Goedel showed was unpro\vable were
refereential statements like
This statement , which can be embeded in the axiomatic system as
statement number y, is unprovable.
Thus if it is unprovable, it is surely true.
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Comments on ECC
Date: Mon, 20 Sep 1999 12:28:48 -0500
Sam Simpson wrote:
>
> I've been reading up on this during the week. It would appear that
> Bruce's skepticism of ECC is shared by a number of very highly
> respected cryptographers (Elgamal, Adleman, Rivest, Lenstra et al).
>
> A great number of comments are available at:
> http://csrc.nist.gov/encryption/186cmts.txt (Some of the comments in
> the document are blatantly partisan - J.Bidzos for example...)
>
> Specifically of interest to me were the comments by Adleman:
>
> "It is correct that I am suspicious of elliptic curve cryptosystems.
> I have never heard an argument which persuaded me that there were
> reasons in principle for believing that the discrete logarithm
> problem
> on elliptic curves is strictly exponential. I suspect that the lack
> of
> a sub-exponential algorithm is merely a matter of neglect and that
> intense scrutiny - which a commercial implementation of an elliptic
> curve cryptosystem might engender - could readily change the
> situation."
> -- Dr. Leonard M. Adleman, Henry Salvatori Professor of Computer
> Science, University of Southern California
>
> Comments?
He may very well be correct. But let's face it, after 200 years
of looking, nobody has *found* a subexponential algorithm! Some of
the smartest mathematicians in the world today are thinking about
this problem, and they haven't found one yet either. So what's the
level of neglect? If we spent US$10e9/year do you think we'd find a
subexponential algorithm?
When Adleman help start the RSA method, the present factoring schemes
did not exist. RSA was far more secure *algorithmicly* 20 years ago
than it is today. ECC is more secure *today* than RSA was 20 years
ago comparing them algorithmicly.
So what's the problem? History and ego mostly. You can't blame a
guy who's developed one of the most widely used crypto methods for
attempting to stomp on the "newcomer". It makes his stuff "obsolete".
That hurts.
One of these days ECC will have competition in PK that will blow it
away because a sub exponential algorithm will have been found. But
for the next 10 to 20 years it will be the more important PK system
since it uses fewer resources to encrypt and forces the attacker to
use more resources to break than any other PK system. Until a
sub exponential algorithm *is* found, why not use it?
As attacks continue on RSA and factoring, it continuously gets
algorithmicly "weaker". There are attacks on ECC which have made
it "weaker" in the same sense, the algorithms require slightly fewer
resources today than they did 3 years ago to crack the same problem.
To switch to something algorithmicly stronger makes economic and
engineering sense. To switch again 10 or 20 years later also
makes sense. It was RSA 20 years ago, it's ECC today and who knows
what it will be 20 years from now (but I'll bet it won't be either
one!).
Now, let's add one more silly conjecture. Suppose that in the
next 5 years a really smart mathematician *proves* that no sub-
exponential algorithm can be found for ECC. How many companies
will be kicking themselves for not switching sooner?
Patience, persistence, truth,
Dr. mike
------------------------------
** 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
******************************
