Cryptography-Digest Digest #144, Volume #11 Thu, 17 Feb 00 16:13:01 EST
Contents:
Re: Large Floating Point Library? ("Dann Corbit")
Newbie: how do I use blowfish to encrypt C strings ("Dirtbiker")
Re: NIST, AES at RSA conference (David Wagner)
Re: Question about OTPs (Arthur Dardia)
Re: NIST, AES at RSA conference (David Wagner)
Re: Does the NSA have ALL Possible PGP keys? (Will Dickson)
Re: Does the NSA have ALL Possible PGP keys? (Jim)
Re: Question about OTPs (Jim)
Re: OTP practical implementation (Jim)
Re: NIST, AES at RSA conference (John Savard)
Re: NIST, AES at RSA conference (John Savard)
Re: Keys & Passwords. (John Savard)
Re: Question about OTPs (John Savard)
Re: Question about OTPs (John Savard)
Re: Question about OTPs (John Savard)
Re: Question about OTPs (John Savard)
Re: Method to break triple-DES (Mickey McInnis)
Re: RSA Speed (Eric Young)
Free Crypto API - Update [Again] (Tom St Denis)
Re: NSA Linux and the GPL (Paul Koning)
----------------------------------------------------------------------------
From: "Dann Corbit" <[EMAIL PROTECTED]>
Subject: Re: Large Floating Point Library?
Date: Thu, 17 Feb 2000 11:19:15 -0800
"Runu Knips" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Dann Corbit write:
> > C++:
> > MIRACL by Scott [...] Good for several hundred digits. [...] It is free
> > for academic use and has a one time $500 charge for commercial use (last
> > time I looked).
> >
> > QFLOAT by Moshier is very good for up to 50 digits or so. [...]
> >
> > APFLOAT by Tommila and HFLOAT by Arndt are good for thousands of digits,
but
> > require GCC [...]
>
> Well all nice, but ever heard of links ?
Sorry, I'm as lazy as a cat.
;-)
> MIRACL: http://indigo.ie/~mscott/ [commercial, free for
> .edu]
> QFLOAT: <- not found yet ->
> APFLOAT: http://www.jjj.de/mtommila/apfloat/ [free]
> HFLOAT: http://www.jjj.de/hfloat/hfloatpage.html [GPL]
>
> Took me only 5 Minutes to find these, but that where 5 Minutes wasted
> time
> which could have been spared, hmm ? QFLOAT results in many links to
> FORTRAN
> compilers etc, will take a longer while to find the real source...
QFLOAT is by Stephen L. Moshier and can be found at http://www.netlib.org
(among other places)
--
C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
"The C-FAQ Book" ISBN 0-201-84519-9
C.A.P. Newsgroup http://www.dejanews.com/~c_a_p
C.A.P. FAQ: ftp://38.168.214.175/pub/Chess%20Analysis%20Project%20FAQ.htm
------------------------------
From: "Dirtbiker" <[EMAIL PROTECTED]>
Subject: Newbie: how do I use blowfish to encrypt C strings
Date: Thu, 17 Feb 2000 14:11:13 -0500
I have downloaded the blowfish souce code and it looks pretty
straightforward, but I can't figure out how to use the BF_encrypt and
BF_decrypt routines to encrypt large blocks of text that I have in C char
strings like char buff[256]; I don't know how long the text is before hand.
It seems the samples are all encryting arrays of integers, and that's cool
but who cares about encrypting an array of numbers.
If someone could point me to some simple examples it would be greatly
appreciated.
Thanks,
Grady
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: NIST, AES at RSA conference
Date: 17 Feb 2000 10:56:39 -0800
In article <[EMAIL PROTECTED]>,
Bo D�mstedt <[EMAIL PROTECTED]> wrote:
> Suppose that you have a good quality (high security) cipher function
> X that produce pseudo-random bytes as a function of a secret
> cipher key. Append a system that lowers the probability of bytes
> {0,3,65,128,220} a little and then increases the probability
> of the numbers {31,45,68,91,108} a little. The modified
> system may be broken only if X is weak, and will fail almost
> any statistical test.
But this is not a block cipher, this is a special-use primitive.
Recall that the AES process is about general-purpose block ciphers.
------------------------------
From: Arthur Dardia <[EMAIL PROTECTED]>
Subject: Re: Question about OTPs
Date: Thu, 17 Feb 2000 14:30:37 -0500
Dave Hazelwood wrote:
> Surely you mean never reuse a byte "sequence" as opposed to "no"
> byte?
>
> Since there are only 256 different bytes possible in an 8 bit word
> you are not going to get very far beyond sending one short message
> for all time. :))
>
> [EMAIL PROTECTED] (Bill Unruh) wrote:
>
> >In <[EMAIL PROTECTED]> Arthur Dardia <[EMAIL PROTECTED]> writes:
> >
> >In a OTP, no byte of the one time pad should ever be reused in any way.
> >If a byte is used for any purpose, throw it away and never use it again.
> >That is the condition under which a OTP is secure. Anything else and the
> >security proof fails. Of course one may be able to argue that some ways
> >of reusing the byte are still secure enough, but that is a different
> >argument. To be a One Time Pad, the One Time is crucial.
> >
> >
I don't know what you're seeing, but I never wrote that quote.
--
Arthur Dardia Wayne Hills High School [EMAIL PROTECTED]
PGP 6.5.1 Public Key http://www.webspan.net/~ahdiii/ahdiii.asc
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: NIST, AES at RSA conference
Date: 17 Feb 2000 11:01:41 -0800
In article <[EMAIL PROTECTED]>,
John Savard <[EMAIL PROTECTED]> wrote:
> Without [selecting from a large pool of possible ciphers],
> the often raised argument that the
> use of differing ciphers is as strong as the "weakest link" would be a
> serious and effective objection, in my opinion, but the use of
> multiple layers of ciphers addresses that objection.
How does it address that objection?
You're still left with the possibility that the cascade is only as strong
as the weakest cipher, except now it's even worse than before: now your
cipher might be as weak as the weakest cipher *in the entire pool*,
rather than just the weakest of some fixed three ciphers. Increasing
the pool size increases the chances that you have a very weak cipher
in the pool, and thus seems to make this "weakest link" problem worse.
What am I missing?
------------------------------
From: [EMAIL PROTECTED] (Will Dickson)
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: Thu, 17 Feb 2000 19:41:47 GMT
Johnny Bravo <[EMAIL PROTECTED]> wrote:
>On Wed, 16 Feb 2000 00:24:06 GMT, [EMAIL PROTECTED] (Steve K)
>wrote:
>
[snip]
>
>>To the crypto geeks: Contemplate the sage advice of the great W.C.
>>Fields on the subject of trying to wise certain people up. Guys, it
>>can't be done. Either they get interested enough to study and the
>>literature and follow the logic of it, or they don't. You have
>>practically no influence over that choice.
>
> Here is a quote I picked up in another group, "You can not reason a man
>out of a position he did not reach through reason."
Or as Augustus de Morgan put it, "Sir, your ignorance is such that you
know not wherein the problem lies".
Come to that, "Against stupidity, the gods themselves labour in vain"
- an Asimov title, but sounds like a quote from somewhere else to me!
Will.
------------------------------
From: [EMAIL PROTECTED] (Jim)
Crossposted-To: comp.security.pgp,misc.survivalism
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: Thu, 17 Feb 2000 19:48:23 GMT
Reply-To: [EMAIL PROTECTED]
On Thu, 17 Feb 2000 12:01:12 GMT, [EMAIL PROTECTED] wrote:
>> >- It is reasonable to assume that the NSA is able to run very fast and
>> >exhaustive dictionary attacks against the passwords that secure the
>> >private key.
>>
>> That's not quite the same thing as breaking the cipher, is it?
>> If they wanted to do that, why would they bother generating
>> and storing all the keys.
>
>Well, I'm not sure if you've read my answer carefully. I was pointing out
>to the original poster, that it's quite senseless for the NSA to generate
>and store all keys (even if it was possible), just because they can
>obtain *used* keys easily by side-channel attacks.
Yes, of course. Very much more cost-effective than trying either to
break the cipher or discover the key by technical means.
>> >- It is reasonable to assume that the NSA is able to obtain any private
>> >key stored on the harddisk of any individual at home, if he/she is the
>> >specific target of an attack.
>
>> Only by forcing a weak passphrase, or getting the suspect to reveal
>> it.
>
>No, this is absolutely wrong. It is easy to obtain the passphrase by
>installing a keystroke logger or by using Van Eck devices, and it's easy
>to obtain the private key by all different kind of means from physical
>access to the harddisk to Trojan horses / viruses.
Well no. Not 'only by forcing etc.' as you pointed out.
>> They've obtained the keys and passwords of absolutely EVERYONE.
>
>Just above, I've said "..of most PGP users.." Why do you write
>"absolutely EVERYONE"? Can't you read?
>
>> world-wide, who uses PGP. Aw, come on!! Their budget and staffing
>> stretch that far?
>
>That's what I was talking about: You do not need a budget and staffing
>stretched far for this. In fact, *one* single person can write a suitable
>virus or Trojan horse within one or two weeks. It is also trivial to
>launch such tools, and although it poses serious problems for an
>individual to hide the original source of the virus/Trojan horse, this *
>certainly* is not a problem for any of the large government agencies.
So they're going to plant one of these on the computers of 'most PGP
users' ? Ambitious project!
--
Jim,
nordland at lineone.net
amadeus at netcomuk.co.uk
------------------------------
From: [EMAIL PROTECTED] (Jim)
Subject: Re: Question about OTPs
Date: Thu, 17 Feb 2000 19:48:25 GMT
Reply-To: [EMAIL PROTECTED]
On Wed, 16 Feb 2000 16:50:48 -0800, Mark VandeWettering <[EMAIL PROTECTED]> wrote:
>Arthur Dardia wrote:
>
>> Many people attempt to pack CD-ROM's with totally random data; however,
>> then you must tell your recipient which offset to start reading the pad
>> from. So, my question is this: for one message, so that I start at the
>> 30,567,890 byte and the next I start tat the 30,567,889. While this is
>> only one byte off, the ciphertext is totally different; however, how
>> secure is this?
>
>Not secure at all. You've taken one of the very best cryptosystems, and
>turned it into something really trivial.
...and it's not a one-time-pad.
--
Jim,
nordland at lineone.net
amadeus at netcomuk.co.uk
------------------------------
From: [EMAIL PROTECTED] (Jim)
Subject: Re: OTP practical implementation
Date: Thu, 17 Feb 2000 19:48:27 GMT
Reply-To: [EMAIL PROTECTED]
On Thu, 17 Feb 2000 01:52:45 GMT, [EMAIL PROTECTED] (Steve K) wrote:
>On 16 Feb 2000 11:04:19 -0800, Andru Luvisi <[EMAIL PROTECTED]>
>wrote:
>
>Here's something to check out for a one-time pad, all set up & ready
>to go. The authors suggest using a sound card & mike to generate the
>"random" data. I haven't use it myself-- too much hassle, nobody
>local to test it with, etc.-- but if you're after a one time pad I
>think it might be worth trying. Annoying site name and all.
>
>http://www.csuglab.cornell.edu/Info/People/jcr13/HardenedCriminal/main.html
Why a microphone? Far better to feed the soundcard the noise from
an FM radio or TV sound tuned to an unused channel.
--
Jim,
nordland at lineone.net
amadeus at netcomuk.co.uk
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NIST, AES at RSA conference
Date: Thu, 17 Feb 2000 13:11:12 GMT
[EMAIL PROTECTED] (Bo D�mstedt) wrote, in part:
>[EMAIL PROTECTED] (John Savard) wrote:
>..
>>... that a cipher can fail statistical tests and still be secure
>>(with the basic exception of ciphers that expand the input,
>>such that only the expansion - performed after enough of the
>>encryption to produce security - has statistical regularities,
>>which does not apply to AES-format block ciphers) is,
>>essentially, _not_ possible.
>>
>>John Savard (teneerf <-)
>>http://www.ecn.ab.ca/~jsavard/index.html
>
>Suppose that you have a good quality (high security) cipher function
>X that produce pseudo-random bytes as a function of a secret
>cipher key. Append a system that lowers the probability of bytes
>{0,3,65,128,220} a little and then increases the probability
>of the numbers {31,45,68,91,108} a little. The modified
>system may be broken only if X is weak, and will fail almost
>any statistical test.
>Please disregard cases where the modification
>itself would allow an opponent to decide the correct message
>without breaking X.
That is specifically the exception I cited, that a system with
statistical problems _can_ be secure IF it expands the input after
secure encryption was already performed.
You will note that, unless it reverses the good encryption in the
first step, it will _have_ to expand the input in order to have room
to add redundancy.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NIST, AES at RSA conference
Date: Thu, 17 Feb 2000 13:14:22 GMT
[EMAIL PROTECTED] (David Wagner) wrote, in part:
>In article <[EMAIL PROTECTED]>,
>John Savard <[EMAIL PROTECTED]> wrote:
>> Without [selecting from a large pool of possible ciphers],
no, without using triple encryption
>> the often raised argument that the
>> use of differing ciphers is as strong as the "weakest link" would be a
>> serious and effective objection, in my opinion, but the use of
>> multiple layers of ciphers addresses that objection.
>
>How does it address that objection?
>You're still left with the possibility that the cascade is only as strong
>as the weakest cipher, except now it's even worse than before: now your
>cipher might be as weak as the weakest cipher *in the entire pool*,
>rather than just the weakest of some fixed three ciphers. Increasing
>the pool size increases the chances that you have a very weak cipher
>in the pool, and thus seems to make this "weakest link" problem worse.
>What am I missing?
You have it backwards. Terry Ritter is suggesting using a pool of
ciphers, and adding triple encryption to that as a safety precaution
to fix the weakest link problem, not the other way around.
Subject to certain precautions, triple encryption can be expected to
be as strong as the strongest of the three ciphers used (so the 3rd
weakest one in the pool is the worst case) and hoped to be
considerably stronger.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Keys & Passwords.
Date: Thu, 17 Feb 2000 13:20:22 GMT
John <[EMAIL PROTECTED]> wrote, in part:
>This may be a stupid question. Let's assume, for the sake of
>argument, we have found a good encrypter. How important is the
>choice of a password? I have often heard that if you had a
>password like athxa or bthxb, it is not good because there is
>repitition.
It isn't the repeated letters that are the problem. If a password is
used that is a word in the dictionary, it can be guessed very easily,
by a program that tries every word in the dictionary. A sequence of
all lower-case letters is the next thing a password cracker might try.
For encryption, you should really use a pass phrase, not a password,
because even a "good" password doesn't contain enough entropy - there
aren't enough possible values - to match the size of the key used for
encryption.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Question about OTPs
Date: Thu, 17 Feb 2000 13:22:51 GMT
Arthur Dardia <[EMAIL PROTECTED]> wrote, in part:
>So, my question is this: for one message, so that I start at the
>30,567,890 byte and the next I start tat the 30,567,889. While this is
>only one byte off, the ciphertext is totally different; however, how
>secure is this?
Totally insecure, since the two messages can be compared at that
offset, and the fact that (unless the plaintext is random) there will
be a higher-than-normal number of coincidences between the ciphertexts
will allow an attack.
The OTP is a _one-time_ pad, so you must choose offsets that no byte
on the CD-ROM is ever used twice. If you go one byte back, and your
message is more than one byte long, you're using key bytes you used to
encrypt your last message.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Question about OTPs
Date: Thu, 17 Feb 2000 13:25:58 GMT
Tim Tyler <[EMAIL PROTECTED]> wrote, in part:
>Even with a good source of random numbers - and a perfect distribution
>mechanism, without signing - or some better scrambling than XOR provides -
>I don't think the system is at all "perfectly" secure.
>It has about the best possible resistance to cyphertext-only attack,
>that's all.
Well, that's it: it is perfectly secure against a ciphertext-only
attack. (It doesn't just have the best possible resistance, meaning
that some finite but enormous amount of effort could yield the
plaintext in that case.)
But, as you correctly note, it isn't immune to all attacks, such as
bit-flipping.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Question about OTPs
Date: Thu, 17 Feb 2000 13:30:28 GMT
"Dr.Gunter Abend" <[EMAIL PROTECTED]> wrote, in part:
>Is that still true if you compress the plaintexts beforehand?
>Especially if you use a compression algorithm that nearly
>completely removes the redundancy of the original byte streams.
That is sort of the complementary case to the OTP.
The OTP is the "perfect" cipher, in that it can encrypt anything
unbreakably.
Zero-redundancy plaintext, on the other hand, could be encrypted
unbreakably even by a trivial system of encryption, since even if it
was easy to try all possible keys, every key would yield a possible
plaintext.
The point is that the existence of such a case is not an argument
against worrying about making a mistake that totally vitiates the
security of an OTP. And it may also be noted that compression
algorithms that good aren't available for most applications.
But it is true that compression will make a kappa test harder - but
more sophisticated attacks may exist.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Question about OTPs
Date: Thu, 17 Feb 2000 13:32:28 GMT
[EMAIL PROTECTED] (Dave Hazelwood) wrote, in part:
>Surely you mean never reuse a byte "sequence" as opposed to "no"
>byte?
>Since there are only 256 different bytes possible in an 8 bit word
>you are not going to get very far beyond sending one short message
>for all time. :))
You may reuse a byte _value_ if you find it in some other part of your
pad, but you may not use a single byte of the pad twice.
That is: your pad may include the byte value 203 in many places.
But you may never use the 2,803,137th byte in the pad again after
using it once.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Mickey McInnis)
Subject: Re: Method to break triple-DES
Date: 17 Feb 2000 20:32:40 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Johnny Bravo
<[EMAIL PROTECTED]> writes:
|> On Thu, 17 Feb 2000 17:28:31 +0100, "Adam Szewczyk"
|> <[EMAIL PROTECTED]> wrote:
|>
|> >Hello,
|> >
|> >I study computer science at the University of Wroclaw (Poland). Actually I'm
|> >looking for an implementation of a method to break triple-DES (linear and
|> >differential cryptanalysis). If you know where I can find those informations
|> >please let me now.
|>
|> ROTFLMAO.
|>
|> If you ever figure such a thing out, let me know, there are a few banks
|> here in the US with entire too much money.
Actually, I've heard that there was a paper published recently showing
a potentially practical attack on Triple DES that's considerably less
effort than standard key exhaustion against a 112 bit (2xDES) key.
It's some sort of meet-in-the middle attack, and was not too many times
more trials than regular DES by key exhaustion.
If true, and if I recall correctly, it did sound like Triple DES was
significantly less secure than previously thought.
Unfortunately, I don't have a reference. I think it was in the last year
or so that I saw it mentioned, probably on this newsgroup.
|>
|> --
|> Best Wishes,
|> Johnny Bravo
|>
|> "The most merciful thing in the world, I think, is the inability
|> of the human mind to correlate all it's contents." - HPL
--
Mickey McInnis - [EMAIL PROTECTED]
--
All opinions expressed are my own opinions, not my company's opinions.
------------------------------
From: Eric Young <[EMAIL PROTECTED]>
Subject: Re: RSA Speed
Date: Fri, 18 Feb 2000 06:40:03 +1000
Bob Silverman wrote:
> In article <88gngi$uid$[EMAIL PROTECTED]>,
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> > In article <[EMAIL PROTECTED]>,
> > Erik <[EMAIL PROTECTED]> wrote:
> > > I wrote a program to do RSA with a 1100 bit modulus. I use 65537 for
> > > the public key exponent, and the private key exponent is, of course,
> > > near 1100 bits. It works, and encrypting with the public key takes
> > > about a quarter of a second, but decrypting with the private key takes
> > > 43 seconds on a 400 MHz Pentium. Does this seem right?
> Given that encryption with a 16 bit exponent takes 1/4 sec, then
> decrypting with 1100 bits in 43 sec is not wrong.
> However, encrypting should take only a millisecond or so with any
> decent C implementation and decrypting should take take only about .1
> to .3 seconds.
> I suspect that there is a major problem with you exponentiation
> algorithm or your modular multiplication subroutine(s).
With x86 ASM on a 350mhz, I'm currently getting
17ms for encryption and 1ms for decryption.
This is the ball park to aim for. At this point most improvements are
efficiency in coding vs algorithm choices.
The general rule of thumb I've seen is that the private key operation
is about 15 times slower than the public key operation (assuming
montgomery reduction and CRT is being used).
eric
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Free Crypto API - Update [Again]
Date: Thu, 17 Feb 2000 20:50:22 GMT
Once again CryptoBag (or CB for short) was updated because a typo was
found in the Random number generator. The problem was fixed.
Anyways, for those who don't know what CB is, it's my collection of
Cryptographic functions in a nice compact [compiles to around 100kb
with DJGPP] library. It includes functions for public key crypto [make
the keys, export/import, encrypt/decrypt, sign/verify], symmetric
encryption [with a choice of six ciphers], data compression, hashing, a
random number generator and base64 encode/decode routines.
It's entirely free, and the source code is online. There are a
few 'helper' functions to encrypt/sign [etc] files and 'in memory
blocks'.
Already a few people have helped fix bugs here and there, which is nice
since CB is functionally complete. All I ask for is people to review
the code, perhaps find bugs or optimization opertunities.
CB is available on the web at http://www.dasoft.org/peekboo/cb.html and
I can be contacted at '[EMAIL PROTECTED]'.
Thanks for your time,
Tom
[btw I know I have posted before, but there are those who have found CB
from this forum, so I figured they might want to here about updates].
[btwx2, if you have any comments/suggestions at all I would love to
hear from ya.]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: NSA Linux and the GPL
Date: Thu, 17 Feb 2000 15:51:25 -0500
John Savard wrote:
>
> In the latest CRYPTO-GRAM, Bruce Schneier asked:
>
> "Personally, I don't know if the Linux license allows the NSA to
> make a secure version of the operating system if they are not going to
>
> freely distribute the results."
>
> I remember wading through the GPL. What it says is that if you take
> any of the programs distributed under that license, add some of your
> own code to them, you can still charge for the result, but you can't
> use the fact that there is some code in there that you wrote to
> restrict the recipient from freely redistributing the result.
>
> But you certainly can modify Linux for your own use, and decide not to
> distribute the modified version to anyone else at all.
>
> So, while any company producing a "Secure Linux" for the NSA cannot
> prohibit the NSA from freely passing it out to anyone else it feels
> like, the NSA is under no obligation to do so. So, yes, they _can_
> 'get away' with this.
Quite possible. On the other hand, there was a note from one of
the people doing the work recently (on one of the lists where this was
discussed) said that they *would* release the resulting code.
Impressive, if that's for real.
paul
------------------------------
** 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
******************************
