Cryptography-Digest Digest #960, Volume #13 Wed, 21 Mar 01 12:13:00 EST
Contents:
Re: What happens when RSA keys don't use primes? (Gene Styer)
Re: What the Hell...Here's what my system can do at it's best... (SCOTT19U.ZIP_GUY)
I was so so right about PGP ... so right when I started writing about PGP and about
one author .... so right ..... ([EMAIL PROTECTED])
This was in 1999 ... I was so right about PGP etc..... although I had know this
since 1993 ... ([EMAIL PROTECTED])
DEA standard S-tables beginner question. ("Yaniv Sapir")
Re: I was so so right about PGP ... so right when I started writing (Frank Gerlach)
Re: How to eliminate redondancy? (SCOTT19U.ZIP_GUY)
Re: How to eliminate redondancy? (moving steadily towards being computer science
terminology) ("Tom St Denis")
Re: OK...dumb question (Taylor Francis)
Re: How to eliminate redondancy? ("Tom St Denis")
Re: I was so so right about PGP ... so right when I started writing about PGP and
about one author .... so right ..... ("Tom St Denis")
Re: DEA standard S-tables beginner question. ("Tom St Denis")
Re: OK...dumb question ("Tom St Denis")
Re: AES encryption speed vs decryption speed (John Worley)
----------------------------------------------------------------------------
Subject: Re: What happens when RSA keys don't use primes?
From: [EMAIL PROTECTED] (Gene Styer)
Date: 21 Mar 2001 15:18:38 -0000
In article <[EMAIL PROTECTED]>, Hard <[EMAIL PROTECTED]> wrote:
>On Wed, 21 Mar 2001 10:40:09 GMT, "Mxsmanic" <[EMAIL PROTECTED]>
>wrote:
>
>>"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
>>news:[EMAIL PROTECTED]...
>>
>>> In my humble understanding this is all a
>>> probability issue. If the chance that the
>>> 'believed' primes being composite is
>>> sufficiently small, then it can be justified
>>> that one takes the risk of the vulnerability.
>>
>>I understand that. I just don't understand exactly what the
>>"vulnerability" actually is. Will the encryption/decryption
>>systematically break? Or will it break only occasionally, for certain
>>plaintexts or ciphertexts? Or will it work fine, but become very
>>vulnerable to cryptanalysis? Or something else?
>>
>
>That is a question I've had, too. You described it well. I wonder if
>any will answer it as clearly as it was posed?
Well, I decided to do a quick test:
p = 15 (ok, I know this isn't prime, but this is only a test...)
q = 7 (we'll let this one be prime)
n = 105
e = 5 (need d relatively prime to 14*6=84)
d = 17 (need d*e==1 mod 84)
using bc:
(10^5) % 105 = 40 (40^17) % 105 = 10
(18^5) % 105 = 93 (93^17) % 105 = 18
So my guess would be that having a non-prime will still work, but that it
would be easier (but not easy) to factor n and thus determine d.
Eugene Styer
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: What the Hell...Here's what my system can do at it's best...
Date: 21 Mar 2001 15:38:25 GMT
[EMAIL PROTECTED] (Keill Randor) wrote in
<[EMAIL PROTECTED]>:
>Hmmmm, sounds about right. Just wait and see if my system hits the
>'net. It's so simple at it's core, and inherantly uncrackable, so
>exactly what they'll make of it I'm not sure... I solved this problem
>from the ground up: I know that my last post was a little, well,
>convoluted, but as I said, that's what it does at it's best, which very
>few people will need, BUT it will always be possible that someone HAS
>worked out an alternative solution, and the one you have isn't the
>'real' one. It's ALL about trust, at the end of the day...
>
>To answer a couple of points, the three parts to the puzzle contained in
>the two paragraphs could literally be ANY part of them, either a word,
>sentence or part, therof. As I said, it's not a challenge, just a demo.
>
I am not sure you anwsered my questions. What part was what in your
example. Does it work for all files or just text. Could you explain
your example!!
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.politics.org.cia,alt.2600,comp.security
Subject: I was so so right about PGP ... so right when I started writing about PGP and
about one author .... so right .....
Date: 21 Mar 2001 15:43:52 GMT
Cryptologists from Czech company ICZ detected serious security vulnerability
of an international magnitude
A bug has been found in worldwide used security format OpenPGP.
http://cryptome.org/pgp-email-flaw.htm
----- Posted via NewsOne.Net: Free (anonymous) Usenet News via the Web -----
http://newsone.net/ -- Free reading and anonymous posting to 60,000+ groups
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.politics.org.cia,alt.2600,comp.security
Subject: This was in 1999 ... I was so right about PGP etc..... although I had know
this since 1993 ...
Date: 21 Mar 2001 15:45:01 GMT
Cryptologists from Czech company ICZ detected serious security vulnerability
of an international magnitude
A bug has been found in worldwide used security format OpenPGP.
http://cryptome.org/pgp-email-flaw.htm
----- Posted via NewsOne.Net: Free (anonymous) Usenet News via the Web -----
http://newsone.net/ -- Free reading and anonymous posting to 60,000+ groups
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email [EMAIL PROTECTED]
------------------------------
From: "Yaniv Sapir" <[EMAIL PROTECTED]>
Subject: DEA standard S-tables beginner question.
Date: Wed, 21 Mar 2001 17:56:23 +0200
Hi all.
I'm totally new to the crypto. field. However, I'm required to implement a
DEA (ANSI X3.92-1981) encryptor/decryptor. My question regards the S1-S8
selection functions. According to the standard, each function takes a 6-bit
input and gives a 4-bit output (the tables are 4 rows by 16 cols - and there
are eight), where bit0 and bit5 choose one of four rows and bit1-bit4 choose
one row member.
Now, is there an analytical way of extracting the tables elements (i.e.,
instead of using look-up tables, I want to calculate the output, based on
the 6-bit input)?
TIA,
Yaniv.
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: I was so so right about PGP ... so right when I started writing
Date: Wed, 21 Mar 2001 17:12:19 +0100
>From the hot air on their communique it looks pretty much like a buffer
overflow :-)
Unfortunately they make a secret out of it...
Good idea btw. Send an encrypted PGP message to somebody, exploit a
buffer overflow and then you got the juice. The receiver can't do
anything, because he/she has to use pgp to verify and decrypt the
message. Use java, forget c++ !
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: How to eliminate redondancy?
Date: 21 Mar 2001 16:08:22 GMT
[EMAIL PROTECTED] (Benjamin Goldberg) wrote in
<[EMAIL PROTECTED]>:
>If you correctly consider (for example) the gzip function, it's domain
>is the set of all files, and it's range is the set of those files
>producable by gzip. It would be incorrect to say that it's range is the
>set of all files. If you consider it's range to be the set of those
>files producable by gzip, then it is a bijective function. If you
>incorrectly consider it's range to be the set of all files, then it
>would appear to not be a bijective function.
If you use the output of the compressor to a general ecnryption
routines that has as its domain the range of all binary files
that for the purposes at hand your gzip was difitely not bijective.
>
>> > If you use definitions other than those that the scientfic community
>> > accepts, you can make any sort of claims you like.
>>
>> Okay, let's find another term for the property David Scott has
>> proposed. To name it "bijective" is confusing and not appropriate, so
>> let's call it "s-bijective" (S in honour of David Scott). But perhaps
>> that is not even necessary because there's already a precise term for
>> this that is established in contemporary mathematics---I'd guess there
>> is.
>
>Yes. A function whose domain and range are the same is a permutation.
>
>> So instead of argueing about names, is there actually someone who has
>> opinions about how and how much overall security an s-bijective
>> compressor would add or not add?
>
>A trivially small amount of security
>
And what makes you so sure it trival. When the main difference
is if you use a poor compressor most of the test keys are tossed
out as beind impossible to use.
>A person who is doing trial decryptions, and has no plaintext
>whatsoever, will be able, if normal, nonpermutative compression is used,
>to be able to use artifacts introduced by the compressor to identify
>correct plaintexts when doing trial decryption. Normal compressors do
>not introduce even one complete known plaintext block, merely a few bits
>of known plaintext here and there, and some distinguishing
>characteristics.
>
>If we take random data, and gzip it, we can distinguish it from random
>simply by looking for the headers. Also, if we decompress a gzipped
>random file, it successfully decompresses. If we attempt to decompress
>a real random file, it is likely to result in CRC errors, or some other
>errors, and abort and fail to decompress.
There are other ways to add athentication and data integrity to
an encrypted file than add a CRC to the compression. The idea is to
hide the real data from an attacker and one way would be not to
tell the attacker he has the correct key when tested or that he
has the correct key when tested. It should be hard for the attacker.
>
>If we compress a random file with a permutative compressor, it will
>hopefully still be indistinguishable from random. Also, if we attempt
>to decompress a random file, there will be no errors, no abort.
>
Actually one would want this for all compressors it just that 99.9
per cent fail this test.
>Thus, you can see how nonpermutative compressors intruduce
>distinguishing characteristics. This kind of distinguishability is very
>very minor, since we normally must have a huge amount of known plaintext
>for most attacks, and it is just as easy/just as difficult to obtain,
>regardless of which type of compressor is used.
It only tales a minor flaw to bring down an encryption system
or do you know anything about the subject. If there a flaw it
should be fixed no matter how minor expecially if its easy to fix.
>
>> What do cryptanalists say about s-bijective compression once they have
>> learned what "s-bijective" is supposed to mean?
>
>Most cryptanalysts ignore David Scott since he acts like a Troll.
>
Well I think most do ignore me. However I do get fan mail from
some who say they are crypto people. It obvious I don't kiss ass
very well like the majority of crypto people. One who thinks BS
is a pompous ass helped me set up my crypto page. But his identity
is secret. He has meet Mr BS and been to several crypto meeting.
I was the kind of person at work that they used to fix things
when they turned to shit. But got little credit for most of my work.
Since I don't play the PR game well.
I do like to poke fun at stiff establishment assholes in all
fields and if I was making new code I might call it TROLL or CRAP
or AES ( for Asshole Encryption System) or something along those
lines.
The only crypto person I know personally ( face to face ) signs
the name "wtshaw" to most of his posts. But I think the community
has written him off as well though he is very nice polite guy.
But he is not in the ass kissing class that most other crypto people
seem to be in yet he knows many of the others and I think is
friendly with them. So he really is the only guy that knows me
well enough to communicate what I am really like to the others
of this closed group.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: How to eliminate redondancy? (moving steadily towards being computer
science terminology)
Date: Wed, 21 Mar 2001 16:11:54 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I think you know my anwser to that but to elighten others I
> will explain what a good sized key is. It is as large as possilbe
> while getting the job done so as to not to cause the user to much
> time waiting.
There are other problems with using million byte keys.
1. Where to get that much good entropy?
2. How to store it securely?
3. Not ideal for portable solutions (i.e smart cards)
> This means for many the keys of scott19u over a million bytes is
> to big for now. But as computers get faster and as memory storage
> devices get more denese and cheaper the length will only go up.
> If you have slow equipment where you need many messages then a
> short key a few 100 bytes might be enough for now. But the longest
> that one can use is the best. I see Rijndael can on theory use
> longer keys than the AES spec will allow. I am not sure how large
> a key AES will say comforms to its needs but most likely 256 bits.
> It would have made more sense to allow it to by used in increments
> to whatever size an application wants to use. Then the free markets
> could decide on what sizes to use. But bureacrats like to nail doors
> closed so that any changes require there blessing. They are very
> short sighted and want control so it will not be open ended as it
> could be from the Rijndael orginal specs. Though I notice BG has
> a version bigger than the apparent AES max.
This is nonsense. For a million byte key, to find it within a day you have
to search
= log2(2^8000000) - log2(86400)
= 8000000 - 16.34
= 7999983.60125630806180675989814431
You have to search about 2^7999983 keys per second for a day.
For the AES "small" 192 bit key this is
= 192 - 16.34
= 175.66
Or 2^175.66 (7.5670924220653909383460011256952e+52) keys per second.
Let's assume a billion computers tackle this ... we have to search 2^145.66
keys per second (7.0474039968712170965466658824079e+43)...
So even with a billion computers searching it takes an enormous search rate
that's certainly impossible for the very forseeable future.
Your argument is nonsense at best.
Tom
------------------------------
From: Taylor Francis <[EMAIL PROTECTED]>
Subject: Re: OK...dumb question
Date: Wed, 21 Mar 2001 10:20:04 -0600
Tom St Denis wrote:
>
>
> To find 'd' from 'e' you have to find the modular inverse modulo lcm(p-1,
> q-1). Most people say modulo (p-1)(q-1) but that's actually just a multiple
> of the group order (both will work but the former may be faster if p-1,q-1
> have factors in common).
>
> The most common method for modular inversion is the extended euclidean
> algorithm which also finds the GCD of the two numbers (two for one ... cool)
How? And what is the 'extended euclidean algorithm' and how does it
work?
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: How to eliminate redondancy?
Date: Wed, 21 Mar 2001 16:25:28 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (Benjamin Goldberg) wrote in
> <[EMAIL PROTECTED]>:
>
> >If you correctly consider (for example) the gzip function, it's domain
> >is the set of all files, and it's range is the set of those files
> >producable by gzip. It would be incorrect to say that it's range is the
> >set of all files. If you consider it's range to be the set of those
> >files producable by gzip, then it is a bijective function. If you
> >incorrectly consider it's range to be the set of all files, then it
> >would appear to not be a bijective function.
>
> If you use the output of the compressor to a general ecnryption
> routines that has as its domain the range of all binary files
> that for the purposes at hand your gzip was difitely not bijective.
Who cares? You have yet to show that it is sufficient condition for
security. I can brute force ANY finite state machine. it's a friggin law
of nature dude.
> >> > If you use definitions other than those that the scientfic community
> >> > accepts, you can make any sort of claims you like.
> >>
> >> Okay, let's find another term for the property David Scott has
> >> proposed. To name it "bijective" is confusing and not appropriate, so
> >> let's call it "s-bijective" (S in honour of David Scott). But perhaps
> >> that is not even necessary because there's already a precise term for
> >> this that is established in contemporary mathematics---I'd guess there
> >> is.
> >
> >Yes. A function whose domain and range are the same is a permutation.
> >
>
> >> So instead of argueing about names, is there actually someone who has
> >> opinions about how and how much overall security an s-bijective
> >> compressor would add or not add?
> >
> >A trivially small amount of security
> >
>
> And what makes you so sure it trival. When the main difference
> is if you use a poor compressor most of the test keys are tossed
> out as beind impossible to use.
Well what's saying your bijective compressor will turn random streams into
ASCII output? They can't always (hence 1-1) so I can reject many 1-1 tests
by just seeing if the output is ASCII text. Duh... I win :-)
> >A person who is doing trial decryptions, and has no plaintext
> >whatsoever, will be able, if normal, nonpermutative compression is used,
> >to be able to use artifacts introduced by the compressor to identify
> >correct plaintexts when doing trial decryption. Normal compressors do
> >not introduce even one complete known plaintext block, merely a few bits
> >of known plaintext here and there, and some distinguishing
> >characteristics.
> >
> >If we take random data, and gzip it, we can distinguish it from random
> >simply by looking for the headers. Also, if we decompress a gzipped
> >random file, it successfully decompresses. If we attempt to decompress
> >a real random file, it is likely to result in CRC errors, or some other
> >errors, and abort and fail to decompress.
>
> There are other ways to add athentication and data integrity to
> an encrypted file than add a CRC to the compression. The idea is to
> hide the real data from an attacker and one way would be not to
> tell the attacker he has the correct key when tested or that he
> has the correct key when tested. It should be hard for the attacker.
Who cares if they know? There is always a way to check your key. And if
the key space is large enough finding it is their biggest problem (not
knowing if it's right).
> >If we compress a random file with a permutative compressor, it will
> >hopefully still be indistinguishable from random. Also, if we attempt
> >to decompress a random file, there will be no errors, no abort.
> >
>
> Actually one would want this for all compressors it just that 99.9
> per cent fail this test.
Because they are efficient codecs?
> >Thus, you can see how nonpermutative compressors intruduce
> >distinguishing characteristics. This kind of distinguishability is very
> >very minor, since we normally must have a huge amount of known plaintext
> >for most attacks, and it is just as easy/just as difficult to obtain,
> >regardless of which type of compressor is used.
>
> It only tales a minor flaw to bring down an encryption system
> or do you know anything about the subject. If there a flaw it
> should be fixed no matter how minor expecially if its easy to fix.
Ahh so we should all use 10kbit RSA keys and trillion bit symmetric keys to
ensure "high security"? Just because you can.... doesn't mean you should!
> >> What do cryptanalists say about s-bijective compression once they have
> >> learned what "s-bijective" is supposed to mean?
> >
> >Most cryptanalysts ignore David Scott since he acts like a Troll.
> >
>
> Well I think most do ignore me. However I do get fan mail from
> some who say they are crypto people. It obvious I don't kiss ass
> very well like the majority of crypto people. One who thinks BS
> is a pompous ass helped me set up my crypto page. But his identity
> is secret. He has meet Mr BS and been to several crypto meeting.
No, most ignore you because your a mean old bastard that has no clue about
what you are talking. You make outrageous claims and arguments and rarely
back them with anything that could be considered a fact. Yes really
cryptographers make mistakes and stupid judgements, yes real systems have
flaws and have been broken. It's how you learn and grow from the experience
that counts. You just keep thumping your crap in this group over and over
and over and over.
> I was the kind of person at work that they used to fix things
> when they turned to shit. But got little credit for most of my work.
> Since I don't play the PR game well.
No, you're just a loser. I fix things and write free code (mainly just C
add-ons and such). I don't expect fame but occasionally I get a thank you
email.
> I do like to poke fun at stiff establishment assholes in all
> fields and if I was making new code I might call it TROLL or CRAP
> or AES ( for Asshole Encryption System) or something along those
> lines.
This is because your an impotent cryptographer. You poke fun at the
professionals because you can't make it yourself.
> The only crypto person I know personally ( face to face ) signs
> the name "wtshaw" to most of his posts. But I think the community
> has written him off as well though he is very nice polite guy.
> But he is not in the ass kissing class that most other crypto people
> seem to be in yet he knows many of the others and I think is
> friendly with them. So he really is the only guy that knows me
> well enough to communicate what I am really like to the others
> of this closed group.
It's one thing to kiss ass and another to just accept peoples research for
what it is. You dismiss all real research because it doesn't fit your
pathetically closed-minded view of the world. There are real world apps
where million byte keys ARE NOT appropriate, or where gbit speeds are
required, etc. You just ignore them because you can't figure out how to
make an efficient, well designed cryptosystem (cipher, etc...).
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: I was so so right about PGP ... so right when I started writing about
PGP and about one author .... so right .....
Date: Wed, 21 Mar 2001 16:26:20 GMT
"Frank Gerlach" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> >From the hot air on their communique it looks pretty much like a buffer
> overflow :-)
> Unfortunately they make a secret out of it...
>
> Good idea btw. Send an encrypted PGP message to somebody, exploit a
> buffer overflow and then you got the juice. The receiver can't do
> anything, because he/she has to use pgp to verify and decrypt the
> message. Use java, forget c++ !
Sorry this is OT but...
JAVA sucks... it's slow, non-portable and gives errors on anything a normal
C compiler would just warn you about. It's hard to develop software for...
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: DEA standard S-tables beginner question.
Date: Wed, 21 Mar 2001 16:27:10 GMT
"Yaniv Sapir" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi all.
>
> I'm totally new to the crypto. field. However, I'm required to implement a
> DEA (ANSI X3.92-1981) encryptor/decryptor. My question regards the S1-S8
> selection functions. According to the standard, each function takes a
6-bit
> input and gives a 4-bit output (the tables are 4 rows by 16 cols - and
there
> are eight), where bit0 and bit5 choose one of four rows and bit1-bit4
choose
> one row member.
>
> Now, is there an analytical way of extracting the tables elements (i.e.,
> instead of using look-up tables, I want to calculate the output, based on
> the 6-bit input)?
Yes that's called boolean decomposition. It was used to make bitsliced
versions of DES. I believe biham et al. have papers on the subject.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: OK...dumb question
Date: Wed, 21 Mar 2001 16:28:46 GMT
"Taylor Francis" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> Tom St Denis wrote:
> >
> >
> > To find 'd' from 'e' you have to find the modular inverse modulo
lcm(p-1,
> > q-1). Most people say modulo (p-1)(q-1) but that's actually just a
multiple
> > of the group order (both will work but the former may be faster if
p-1,q-1
> > have factors in common).
> >
> > The most common method for modular inversion is the extended euclidean
> > algorithm which also finds the GCD of the two numbers (two for one ...
cool)
>
> How? And what is the 'extended euclidean algorithm' and how does it
> work?
Hmm scott was right, why not pick up a free copy of HAC off the web.
When I have to implement these I just read directly from the books (I didn't
memorize em).
it's a good idea to learn how they work... at on time I had an intimate
knowledge of the algorithms used (number theory related) but I haven't used
them in about a year ... so I am a bit rusty.
The euclid algorithms are fairly straight forward though...
TOm
------------------------------
From: John Worley <[EMAIL PROTECTED]>
Subject: Re: AES encryption speed vs decryption speed
Date: Wed, 21 Mar 2001 09:21:49 -0700
Brian Gladman wrote:
> For high speed implementations the encryption and decryption operations are
> about the same in speed terms but key setup for decryption takes a lot
> longer than for encryption.
On highly parallel machines, like IA-64, the additional cost of computing
the decryption keys is less than computing the encryption keys. Encryption keys
require ~90 cycles to compute; computing the decryption keys in parallel adds
~58 cycles. Computing the encryption keys is serialized on the XOR chain (A ^= f(D),
B ^= A, etc.), but once the subkeys are known, the inverse subkey can be computed
with 4 look-ups and 3 xors in parallel with the forward keying.
Thus, the full key table requires 148 cycles to compute. Obviously, this
is implementation is targeted at applications that encrypt repeatedly for
a given key, but the techniques can be applied to key-agile situations.
Regards,
John Worley
[EMAIL PROTECTED]
------------------------------
** 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
******************************
