Cryptography-Digest Digest #306, Volume #14 Mon, 7 May 01 00:13:01 EDT
Contents:
Re: LUCIFER (John Savard)
Re: My algorithm and problem. (Mark Wooding)
Re: GF(2^W) sboxes timings (Mark Wooding)
Re: GF(2^W) sboxes timings ("Tom St Denis")
Re: My algorithm and problem. ("Tom St Denis")
Re: LUCIFER (Boris Kazak)
Re: free en/decryption library (Bill Unruh)
Re: Secure Digital Music Initiative cracked? (David Hopwood)
Re: LUCIFER (DJohn37050)
Re: LUCIFER ("Douglas A. Gwyn")
ECC question ("Tom St Denis")
Re: SRP attack? (David Wagner)
Re: LUCIFER (David Wagner)
Re: LUCIFER (David Wagner)
Re: Tiny s-boxes (David Wagner)
Re: LUCIFER (John Savard)
Re: 3x4 grid of triangular numbers (Benjamin Goldberg)
Re: Best encrypting algoritme (SCOTT19U.ZIP_GUY)
Re: research on polymorphic crypto/Best Possible Privacy? (SCOTT19U.ZIP_GUY)
Re: Cryptanalysis Question: Determing The Algorithm? (wtshaw)
Re: Cryptanalysis Question: Determing The Algorithm? (wtshaw)
Re: Best encrypting algoritme (wtshaw)
Re: free en/decryption library ("Jeffrey Walton")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: LUCIFER
Date: Sun, 06 May 2001 22:54:14 GMT
On Sun, 6 May 2001 21:55:54 +0200, "Henrick Hellstr�m"
<[EMAIL PROTECTED]> wrote, in part:
>I guess this is a permutation in map notation (rather than cyclic
>decomposition notation)
Of course, it is much simpler to state that a word should be formed
consisting of
bit 10 of the original word, followed by
bit 21 of the original word, followed by...
than to use a notation related to advanced mathematics.
Basically, because the S-boxes combine together four bits into a
single output, and because this permutation is strictly within the
f-function, the cyclic nature of the permutation was considered
largely irrelevant.
John Savard
http://home.ecn.ab.ca/~jsavard/
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: My algorithm and problem.
Date: 6 May 2001 23:18:15 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
> Also your effect key space is only 2pi anyways. Try cos(i + 2npi) the
> cosine is the same for all values of 'n' and fixed 'i'.
No cigar, Tom. 2\pi doesn't have interesting common factors with any
integers.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: GF(2^W) sboxes timings
Date: 6 May 2001 23:25:33 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
> Using the code below I timed the function F(X) = X^7 in GF(2^32). It takes
> about 2465 cycles on my Athlon Tbird to perform this function given random
> inputs.
>
> Just FYI :-) Of course I might be able to optimize the code better but I
> doubt it since GCC makes fairly decent code.
Pick better algorithms. Remember that squaring is linear in F_{2^n}: do
this with 8x16 bit lookup tables (or larger, if you have the stomach).
There's no advantage that I can see in choosing a dense polynomial, so
choose a sparse one to make reduction faster. Then use Karatsuba's
multiplication algorithm (which works particularly nicely, since there
aren't any carries during the addition).
I think it's still too slow to be of much real interest.
-- [mdw]
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: GF(2^W) sboxes timings
Date: Sun, 06 May 2001 23:28:58 GMT
"Mark Wooding" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> > Using the code below I timed the function F(X) = X^7 in GF(2^32). It
takes
> > about 2465 cycles on my Athlon Tbird to perform this function given
random
> > inputs.
> >
> > Just FYI :-) Of course I might be able to optimize the code better but
I
> > doubt it since GCC makes fairly decent code.
>
> Pick better algorithms. Remember that squaring is linear in F_{2^n}: do
> this with 8x16 bit lookup tables (or larger, if you have the stomach).
> There's no advantage that I can see in choosing a dense polynomial, so
> choose a sparse one to make reduction faster. Then use Karatsuba's
> multiplication algorithm (which works particularly nicely, since there
> aren't any carries during the addition).
Well reduction is just xor in this field... I never thought of using the
luts though...
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: My algorithm and problem.
Date: Sun, 06 May 2001 23:30:03 GMT
"Mark Wooding" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> > Also your effect key space is only 2pi anyways. Try cos(i + 2npi) the
> > cosine is the same for all values of 'n' and fixed 'i'.
>
> No cigar, Tom. 2\pi doesn't have interesting common factors with any
> integers.
Yeah I realized that about 20mins after I posted. Still my other notes are
worthy... like portability, key size, etc..
Tom
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: LUCIFER
Date: Sun, 06 May 2001 23:35:05 GMT
Ryan Sorensen wrote:
>
> I would appreciate it if someone could point me to a paper outlining LUCIFER.
>
> I've read the "Cryptography and Computer Privacy" article, but that wasn't
> directly on LUCIFER.
> If the only way I can find a paper on it, specifically "LUCIFER, A
> Cryptographic Algorithm", is by purchasing the back issue of Cryptologia,
> let me know.
>
> Any other resources regarding LUCIFER would be appreciated as well.
>
> --Ryan Sorensen
==================================
Why not try some actual implementations?
Log on to <http://www.rpini.com>,
choose Insecure Browsing,
click on CryptoCD, then navigate to:
</pub/cryptocd/source/cyphers/lucifer>
You will find at least 3 different "C" versions.
Best wishes BNK
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: free en/decryption library
Date: 6 May 2001 23:59:27 GMT
In <[EMAIL PROTECTED]> Frank Uepping <[EMAIL PROTECTED]> writes:
>Hi,
>I am new with en/decryption and I am looking for a free and open
>en/decryption C/C++ library that compiles with gcc and C++ Builder.
Try cryptlib
http://www.cs.auckland.ac.nz/~pgut001/cryptlib/
Also remember that implimenting the algorithm is only part of
implimenting crypto. You need to keep a number of ohter issues in mind
as well.
>From the introduction:
cryptlib is a powerful security toolkit which allows even inexperienced
crypto programmers to easily add encryption and authentication
services to their software. The high-level interface provides anyone
with the ability to add strong security capabilities to an application
in as little as half an hour, without needing to know any of the low-level
details which make the encryption or authentication work. Because
of this, cryptlib dramatically reduces the cost involved
in adding security to new or existing applications.
(Note Not sure what you want to do with this. IF it is to be used in a
large commercial project, then it is no longer free. See the web page
for more information.)
------------------------------
Date: Mon, 07 May 2001 00:53:39 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Secure Digital Music Initiative cracked?
=====BEGIN PGP SIGNED MESSAGE=====
Volker Hetzer wrote:
> Roger Schlafly wrote:
> > The suppressed paper is online. Read it while you can.
> > http://cryptome.org/sdmi-attack.htm
> > http://www.wired.com/news/politics/0,1283,43353,00.html
>
> Not anymore. Did anyone get it?
Of course. It's now mirrored here:
http://www.users.zetnet.co.uk/hopwood/crypto/sdmi/sdmi-attack.zip
The RIAA and SDMI consortium don't seem to have learnt anything from
the failure to suppress DeCSS. You'd think they were trying to set
themselves up as the bad guys.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOvXjtTkCAxeYt5gVAQFkMQgAs7xvFsaraQtmX3p1j3c2Cq7xBs+cHQcg
CIMrD0B0WY73366i7SMoZhvd2bdMdRbBw7KBIIw6Mpen5vvrfGoK4rC1/ZdUHX4P
/VJnypijIFmk0Eh8Qdog4W02tw7kMbEL0ldLomjt/VqbImMEC2n+0zPYm+nInOEI
Id2Ctgma8QIGCQo705Pz4bxZr/lfcQ099lUeNNm4sWGn3HdE5f3C4aQvxcXiEUAf
zkbB1SOREIrSclOHd6Eos5bVNgdDINB4bAFvCAH0KNccu24wxuz1gUKVk6QS5I/F
HyNjrlsVeJww14aHZNsB53e8uKHlV841B1gDZJx6sxzfFDePpqIr+Q==
=JNte
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 07 May 2001 00:47:17 GMT
Subject: Re: LUCIFER
Get the Sci Am article.
Don Johnson
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: LUCIFER
Date: Mon, 07 May 2001 00:59:22 GMT
Ryan Sorensen wrote:
> I would appreciate it if someone could point me to a paper outlining
> LUCIFER.
The most accessible (with help from a good library) is probably
Horst Feistel's article "Cryptography and Computer Privacy" in
Scientfic American, v.228 n.5 (May 1973) pp.15-23. There was an
IBM Technical Report on Lucifer, but at NSA's urging it was withheld
from the general public. There was also a 12-page PR piece in the
IBM Research Reports series, v.7 n.4 (1971) titled "Data Privacy -
Cryptology and the computer at IBM Research" by M. B. Girdansky.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: ECC question
Date: Mon, 07 May 2001 01:07:06 GMT
I was just wondering about subtracting two points...
Let's say you have the points P=(x1,y1) and Q=(x2,y2). If you wanted P-Q
would you simply do P+(-Q) where -Q is (x2,-y2)?
Would something like nP - kP (say k=n) be the point at infinity? Basically
I am toying with the idea of an attack based on guessing the multiplicand
and subtracting. It's nothing serious just toying with the math.
Too much to learn, so little time.... hehehehe
--
Tom St Denis
---
http://tomstdenis.home.dhs.org
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: SRP attack?
Date: 7 May 2001 02:20:09 GMT
Michael Scott wrote:
>In fact a masquerading server, Stevie, can eliminate two candidate passwords
>P1 and P2 at once.
My vague sense is that this might actually be fairly common for
these type of protocols (although I'm not too sure about it).
Anyway, I don't view it as a problem: The main reason to use a
protocol like SRP is to force a would-be password-guesser to go
online, so that you can rig the server with a mechanism that locks
out the attacker after too many failed attempts to log in. The
attack you described will only be interesting in this setting if
the server-threshold is between N and N/2, where N is the number
of guesses needed to find the user's password, and this doesn't
sound too likely.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: LUCIFER
Date: 7 May 2001 02:21:16 GMT
Ryan Sorensen wrote:
>I'm looking for a formal writeup/outline/design of [Lucifer].
See Biham and Shamir's book _Differential cryptanalysis of the
data encryption standard_: I think they give a description there.
(I could be wrong, though.)
Beware: There are two different ciphers that seem to go by the
same name "Lucifer".
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: LUCIFER
Date: 7 May 2001 02:23:41 GMT
Henrick Hellstr�m wrote:
>[...] Why wasn't it a single cycle transposition?
Is there any reason why the cycle structure of the permutation
should matter cryptographically in this setting? I can't think
of any at the moment, but maybe I'm missing something.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Tiny s-boxes
Date: 7 May 2001 02:28:38 GMT
Tim Tyler wrote:
>I thought that it was generally accepted. The idea is that the
>probability of choosing a weak, linear s-box (if choosing at random) is
>high when the box size is small, and becomes vanishingly small when the
>box size becomes large. Other desirable s-box characteristics (except
>small implementation size :->) also improve with the number of box inputs.
>
>You're perfectly correct to say that large s-boxes are unlikely to be
>"perfect" (in terms of maximum non-linearity, etc), but - so the
>thinking goes - if you make them large enough the differences
>from the ideal really don't matter, and testing them is of little
>practical benefit.
I think that's a very nice summary (at least, as far as my
limited knowledge of the field is concerned).
If the fact that random S-boxes are probably not "perfect" disturbs
you, one might observe that most block ciphers are very unlikely to
be perfect, either, yet this doesn't seem to be a security issue.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: LUCIFER
Date: Mon, 07 May 2001 02:34:38 GMT
On Mon, 07 May 2001 00:59:22 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote, in part:
>Ryan Sorensen wrote:
>> I would appreciate it if someone could point me to a paper outlining
>> LUCIFER.
>The most accessible (with help from a good library) is probably
>Horst Feistel's article "Cryptography and Computer Privacy" in
>Scientfic American, v.228 n.5 (May 1973) pp.15-23.
True, but it describes simply the principles behind LUCIFER, and does
not give correct implementation details. The illustrative example it
gives has a confusion/diffusion structure, but contains no hint of a
Feistel round.
Thus, it does not describe the actually implemented cipher, as
described in the Cryptologia paper cited.
John Savard
http://home.ecn.ab.ca/~jsavard/
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Crossposted-To: rec.puzzles,alt.math.recreational,sci.math
Subject: Re: 3x4 grid of triangular numbers
Date: Mon, 07 May 2001 02:55:47 GMT
Ed Pegg Jr wrote:
>
> My puzzle of the week -- Make a 3x4 grid so that triangular numbers
> read across and down.
>
> Gauss proved that any number can be represented as the sum of at most
> 3 triangular numbers. I took a look at how to express 2001 with three
> triangular numbers, and there were lots of answers:
>
> {{2001,2,9,62}, {2001,6,20,59}, {2001,6,44,44}, {2001,7,34,52},
> {2001,9,35,51}, {2001,9,39,48}, {2001,10,10,61}, {2001,10,28,55},
> {2001,11,14,60}, {2001,12,17,59}, {2001,14,24,56}, {2001,14,30,53},
> {2001,14,41,45}, {2001,16,25,55}, {2001,20,30,51}, {2001,21,39,44},
> {2001,24,36,45}, {2001,25,34,46}, {2001,34,37,37}, {2001,35,35,38}}.
>
> Are there any large numbers with a low number of triangular
> representations?
>
> I also took a look at Life developments on other sites in my weekly
> update.
How difficult is it to break a large number into 3 triangular numbers?
Could this concievably be made into an authentification scheme?
server and client both have secret s.
client wishes to prove to server it has s, without sending it in the
clear.
(1) server generates random nonce r, sends it to client.
(2) server & client generate s' = make_big_int(hash(s, r))
(3) client finds a triangular triplet (a,b,c) which sums to s'
cleint sends (a,b) to server.
(4) server calculates Tc = s' - T(a) - T(b), and tests if Tc is a
triangular number.
For example, suppose the hash of the secret and the nonce were 2001 ;)
In step (3) the client finds (a,b,c) = (14,24,26) and send (14,24) to
the server. Since 2001-T(14)-T(24) results in a triangular triplet, the
server decides that the client knows the secret s.
I don't believe that there is enough information in (a,b) to reconstruct
the number s', so the question becomes, can step (3) be done in a
reasonably small amount of time for large s', and are there few/many
false positives (ie, if an attacker makes up an (a,b) pair, what are the
odds that they actually are part of a valid triangular triplet
decomposition of s')?
Could someone direct me to Gau�'s proof that any number can be
decomposed into the sum of 3 triangular numbers?
--
Shift to the left, shift to the right, mask in, mask out, BYTE, BYTE,
BYTE !!!
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best encrypting algoritme
Date: 7 May 2001 03:06:18 GMT
[EMAIL PROTECTED] (Tom St Denis) wrote in
<QThJ6.31704$[EMAIL PROTECTED]>:
>
>"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> [EMAIL PROTECTED] (Tom St Denis) wrote in
>> <gDgJ6.31116$[EMAIL PROTECTED]>:
>>
>>
>> >Show me a system where the value '1' (eigith bits) will map to four
>> >different +10 byte messages and I will send you 100,000$. (Assuming
>> >all of the entropy of the four messages is in the single byte). You
>> >make no sense. How can you encrypt different length messages to the
>> >same size ciphertext (except for padding upwards) when a) the
>> >ciphertext is smaller and b) the amount of entropy in the ciphertext
>> >is less than the plaintext.
>>
>> I doubt the honesty of your comment. But if you were capable of
>> following the thread "BENNY and the MTB". Its very possible. Its a
>> matter of fact that one could encrypt more then 256 probable messages
>> to a one byte output file. THe output file only having the "11111111"
>> pattern in it.
>
>Hmm if the output is always constant how do you tell one message from
>another?
The point is this Tom its not so much the size of the output file
its the keyspace. If done correctly you and take a one byte file
with a fixed value. Assume its the output value. Assume crypto system
is my conditional compressor using A-Z and '_" that followed by
matts BICOM.
if you decrypt that single one byte fixed message "11111111"
with Matts BICOM and then deompress with my adapticve conditional
compressor. Your get 2**256 seperate message only in the character
set of the condition file. Most of the file will exceed 20 characters
in length.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: research on polymorphic crypto/Best Possible Privacy?
Date: 7 May 2001 03:17:40 GMT
[EMAIL PROTECTED] (Mark G Wolf) wrote in
<9d4htd$2qlq$[EMAIL PROTECTED]>:
>
>Yes, let this be the last post. That was a response to someone implying
>they felt sick for being part German, so it takes on a slightly
>different "color" being out of context. And yes being white I often
>feel unfairly labeled as a "hater", it seems a very popular thing to do
>nowadays. I've even been race baited in my place of employment. Why I
>don't know. It seems people have a need to find if not outright create
>through constant harassment and stalking dragons they can slay. It can
>be very profitable they say. Those kinds of people can be hated for
>justifiable reasons. Of course the best way to deal with them is
>through the courts. There needs to be sweeping privacy reform in our
>legal system, including criminal prosecution and jail time for egregious
>offenders. But this OT, so enough said.
Your the one jumping to conclutions. I am proud being part german
and am enjoying a german beer this very minute. What pissed me off
was the crappy cipher. Trying to bluff its way into being something
good by claiming it was german. It sucks and no real german would want
to associate his name with it. But of course like any race they have
there portion of retards. I personelly think its best to be mixed the
hybrid races have a built in genetic superiority and fewer retards.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Cryptanalysis Question: Determing The Algorithm?
Date: Sun, 06 May 2001 21:22:10 -0600
In article <V63J6.24331$[EMAIL PROTECTED]>, "Tom St Denis"
<[EMAIL PROTECTED]> wrote:
> Hmm I can write an app to brute force any cryptosystem. That's just the
> laws of FSMs.
Easy to say but might be extremely difficult to do. If the key setup is
time consuming, brute force is not very effective.
--
Mother Nature always gets her revenge.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Cryptanalysis Question: Determing The Algorithm?
Date: Sun, 06 May 2001 21:30:10 -0600
In article <9d34ea$n62$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Paul Schlyter) wrote:
> In article <[EMAIL PROTECTED]>,
> wtshaw <[EMAIL PROTECTED]> wrote:
>
> >
> > Wrong. There is a infinite number of algorithms. I know of maybe a
> > thousand and many are not talking at all.
>
> If you include the weak and the not well-tested algorithms -- yes!
> However, most of those algorithms can be cracked in ways much more
> efficient than brute force key search.
>
Most is an interesting word, not sure that it means much here. Aside from
obvious cousin associations with bad incestious results, lesser algorithms
can be compounded to produce new algorithms of any complexity. It can be
a snowball-from-hell problem to determine what contributing algorithms are
involved.
--
Mother Nature always gets her revenge.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Best encrypting algoritme
Date: Sun, 06 May 2001 21:36:45 -0600
In article
<[EMAIL PROTECTED]>, Paul
Crowley <[EMAIL PROTECTED]> wrote:
> Rijndael, at any key length, will certainly never be the weakest link
> of your system, and is the correct choice since it is on the way to
> becoming a national and hopefully an international standard. Remember
> to use an appropriate chaining mode.
When Rijndael is combined with a chaining mode, it is no longer Rijndael.
To measure the strength of an algorithm means no window dressing should be
fudged into the process.
--
Mother Nature always gets her revenge.
------------------------------
Reply-To: "Jeffrey Walton" <[EMAIL PROTECTED]>
From: "Jeffrey Walton" <[EMAIL PROTECTED]>
Subject: Re: free en/decryption library
Date: Mon, 7 May 2001 00:06:04 -0400
I wasn't aware those books provided libraries and APIs for Cryptographic
Services.
I have two of them, but they must be less recent than your versions. Better
get on Amazon or Bookpool :)
On the serious side, I'd like to see a nice WIN32 BigInt package. I've
looked at a few out of academia (Linux/Unix), but got discouraged on the
port.
| "Tom St Denis" <[EMAIL PROTECTED]> wrote in message
| news:0EgJ6.31123|$[EMAIL PROTECTED]
|
| "Frank Uepping" <[EMAIL PROTECTED]> wrote in
| message news:[EMAIL PROTECTED]...
| > Hi,
| > I am new with en/decryption and I am looking for a free and open
| > en/decryption C/C library that compiles with gcc and C Builder.
|
| May I suggest... READ A TEXT ON THE SUBJECT FIRST!!!!!!!!!!!!!!
|
| (Applied Crypto, Handbook of Applied Crypto and Neal Koblitz's "A course
in
| number theory and Cryptography" come to mind).
| Tom
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
