Cryptography-Digest Digest #428, Volume #10 Mon, 18 Oct 99 18:13:03 EDT
Contents:
Re: accurate decryption ([EMAIL PROTECTED])
Re: Biometric Keys are Possible (Bill McGonigle)
Curious keys in Rijndael ([EMAIL PROTECTED])
panama test vectors (Nikos Mavroyanopoulos)
Re: Bruce Schneier Proves That Secure Cryptography is Impossible (Mok-Kong Shen)
Re: The Quad. in RC6 ([EMAIL PROTECTED])
Re: Strengthening passwords against dictionary attacks ([EMAIL PROTECTED])
Re: Strengthening passwords against dictionary attacks ([EMAIL PROTECTED])
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Bruce
Schneier)
Re: Bruce Schneier Proves That Secure Cryptography is Impossible (Patrick Juola)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Bruce
Schneier)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Bruce
Schneier)
Re: Bruce Schneier Proves That Secure Cryptography is Impossible (Patrick Juola)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Bruce
Schneier)
Re: He is back...new "improved" code ("Belldandy")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: accurate decryption
Date: Mon, 18 Oct 1999 17:31:02 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (wtshaw) wrote:
> In article <[EMAIL PROTECTED]>, eminor54
> <[EMAIL PROTECTED]> wrote:
>
> > This may be slightly off- topic, but I was wondering - how can one
> > defend against this scenario - you have a decrypted mesage
intercepted
> > by someone in authority who wants to accuse you of a crime. They are
> > unable to decrypt the message themselves and of course, you dont
give
> > them the key. However, they then contrive a phony decryption that is
> > incriminating, yet you cant prove to anyone that it's a fake without
> > revealing the true message. What defenses exist in a case like this?
Is
> > it possible to show that the fake message is indeed a fake without
> > revealing the true text?
> >
If the algorithm is determined, for instance DES, then faking a key is
quite difficult. That is if an attacker has the cipher text C and wants
to fake the plaint text P then
P = DES(C) for some decryption key K
In order, to claim your message was something different from the
actual plaintext some K would have to be found that decrypted C
into P. It is likely that no such key exists given the non linear
nature of S boxes.
The attacker could of course claimed you used a custom and weak
algorthim and then decrypt the ciphertext to anything they choose.
Hopefully, that would not fly in court as the 'custom' method could
be attacked by the defense.
As to faking evidence by placing info on your computer. If the
entire drive is encrypted this is a very difficult task without the
key. The attacker could claim all of the drive was encrypted except for
the incriminating piece of course. That could be refuted hopefully.
If the justice system is corrupt, honest jurors must refuse to convict!
--Matthew
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Bill McGonigle)
Subject: Re: Biometric Keys are Possible
Date: Mon, 18 Oct 1999 13:22:54 -0400
In article <[EMAIL PROTECTED]>, Peter Pearson
<[EMAIL PROTECTED]> wrote:
> Of course, there are some bothersome questions like, how much
> you want to rely on the secrecy of a biometric that you show
> to everybody you meet . . .
Most of the good literature I've read (not marketing glossies!) treats a
biometric reading like a user name in a username/password pair system.
Because the biometric reading is non-revokable (you can't change your
fingerprint) it's not a good idea to use it as a password. If it is
compromized, you can never have a password again.
I think when the banks are talking about using iris scanners or
fingerprint scanners in place of a PIN, they're trying to be practical.
It's harder to get someone's fingerprint or eyeball to the scanner than to
pick a number at random from 0000 to 9999. Some of the better scanners
don't work on dead or disembodied eyeballs or fingers.
If you've given your biometric reading to your bank, you'd better not use
that biometric reading as your password elsewhere, unless you explicitly
and totally trust the bank.
You could probably hash a biometric reading with a lower-entropy password
but if the reading is compromised this isn't probably much better than
just the password. Someone smarter can tell me if this assumption is
correct. :)
-Bill
=====
[EMAIL PROTECTED] / FAX: (419) 710-9745
Dartmouth-Hitchcock Medical Center Clinical Computing
------------------------------
From: [EMAIL PROTECTED]
Subject: Curious keys in Rijndael
Date: Mon, 18 Oct 1999 17:48:42 GMT
Hello all,
I have been studying the cipher Rijndael and have noticed a curious fact
about certain keys. I have included a little c++ program at the end to
demonstrate.
For keys whose only difference is in the first byte for Nk= 4 (128
bit key) and Nb = 4 (128 bit block), the XOR of the subkeys is unusual.
In fact, only ten different XOR values are present. If another byte is
changed the number jumps dramatically. If a different Nk or Nb is
chosen the number also jumps.
I would expect two keys that are almost identical to have similar sub
keys but why does a pattern exist for the XOR of the sub keys? It is
interesting to note the sub keys are -not- very similar after the first
few rounds. Also,I would expect the non linear nature of the SubByte
and rotate to destory any coherence after a few rounds.
This 'pattern' seems to hold for any init value not just one where all
the key bytes are equal. The 10 XOR values differ for each combination
of input however. The position of the differences is constant of
course.
Perhaps this could be turned into a differential related key attack.
My thought is that by guessing the 10 XOR values i.e. 2^80 bits, an
attack might be mounted on the two related keys. I have not been able to
create an attack beyond a few rounds but maybe someone more versed in
cryptanlaysis might extend it.
Rijndael is an elegant cipher. It combines (hopefully) security with
ease of implementation in a delightful way. Good luck to Rijndael in
the AES contest.
--Matthew
Here is the program 'xorkey' and some output.
#include <stdlib.h>
#include <string.h>
#include <stdio.h>
#include "rijndael-alg-ref.h"
// see www.esat.kuleuven.ac.be/~rijmen/rijndael/rijndaelref.zip
// For the reference implementation
word8 k[4][MAXKC];
word8 k1[4][MAXKC];
int rijndaelKeySched (word8 k[4][MAXKC], int keyBits, int blockBits,
word8
W[MAXROUNDS+1][4][MAXBC]);
main(int args,char* argv[])
{
int i,j,x;
int initValue = atoi(argv[1]); // set all the bytes of both keys
//equal to this value
memset(k,initValue,sizeof(k)); // random bytes work as well just so
// long a both keys start the same
memset(k1,initValue,sizeof(k));
k1[0][0] = atoi(argv[2]); // change just the first byte of the
// second key
word8 W[MAXROUNDS+1][4][MAXBC];
word8 W1[MAXROUNDS+1][4][MAXBC];
memset(W,0,sizeof(W));
memset(W1,0,sizeof(W1));
rijndaelKeySched (k,128,128,W);
rijndaelKeySched (k1,128,128,W1);
for(i=0;i<11;i++) // 11 sub keys used
for(j=0;j<4;j++)
for(x=0;x<4;x++)
if(W[i][j][x] != W1[i][j][x]) // print only the difference
printf("%02d %02d %02d %03d %03d
%03d\n",i,j,x,W[i][j][x],W1[i][j][x],
W[i][j][x]^W1[i][j][x]);
return 1;
}
This is some partial output for
xorkey 0 1
i j x K K1 Xor
00 00 00 000 001 001
01 00 00 098 099 001
01 00 01 098 099 001
01 00 02 098 099 001
01 00 03 098 099 001
02 00 00 155 154 001
02 00 02 155 154 001
02 03 00 201 152 081
...
09 02 00 216 117 173
09 02 01 185 020 173
09 03 00 226 013 239
10 00 00 180 040 156
10 00 02 035 191 156
10 01 00 239 200 039
10 01 01 146 181 039
10 02 00 091 246 173
10 03 00 203 125 182
10 03 01 017 167 182
10 03 02 207 121 182
10 03 03 142 056 182
For a total of 10 different XOR not including 0
10 001 // the number 001 appears 10 times
8 039
9 081
6 156
9 163
9 173
4 182
9 184
9 231
9 239
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Nikos Mavroyanopoulos)
Subject: panama test vectors
Date: 18 Oct 1999 17:54:49 GMT
I'm looking for test vectors for the panama stream algorithm,
in order to test an implementation. Do you know where to find any?
I can find test vectors only for the hash algorithm.
--
Nikos Mavroyanopoulos
mailto:[EMAIL PROTECTED]
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Bruce Schneier Proves That Secure Cryptography is Impossible
Date: Mon, 18 Oct 1999 21:02:10 +0200
Bruce Schneier wrote:
>
> People memorize phone numbers because they use them regularly.
> Cryptographic keys that are used infrequently will not be memorized so
> easily.
>
> And yes, one can memorize six digits and insert them into a pass
> phrase in some irregular positions, but the average person simply will
> not bother doing so. I agree that you can invent lots of ways to
> create high-entropy pass phrases; I disagree that they will result in
> a population of secure pass phrases.
I certainly can't 'prove' my claim, but I believe that you
underestimate the average IQ of people when you estimate that they
can't even memorize four digit numbers. If people are well informed
of the risk of insecurity resulting from poor pass phrases, they will,
in case the risk involved is sufficiently high, be motivated to follow
good advices. Unfortunately there isn't in my view sufficient effort
being done yet to inform/educate the people in that. Perhaps the time
has yet to come. Analogy for the correlation between risk and
motivation: If I lose my credit card and someone misuses it, I am
liable only to some 100 DM (if I remember the card issuer's conditions
right). That clearly doesn't give me much motivation to very
carefully guard my card. I would have behaved differently, if
I were liable to, say, half of the money lost due to the activity of
the person who misuses the card.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: The Quad. in RC6
Date: Mon, 18 Oct 1999 18:57:28 GMT
In article <7uf41a$eik$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <7uf3g8$ee1$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > I was talking about losing bits of info when doing ax, not x(ax+b).
>
> If I am not mistaken that's what provides the diffusion in this
function.
Yeah, that's where I get a little fuzzy. I'm not sure how the
multiplication is affected by a transform like that. I'm under the
impression that multiplication is affected by the lower bits more than
the higher bits. Therefore, you want to retain as many of the lower
bits as possible. With the original 2x, which is equivalent to x << 1,
you still retain most of the original bits. By adding 1, you are
creating an odd number.
> I.e if you had a=8, b=5 you get
>
> = x * ((x << 3) + 5)
> = x(x<<3) + 5x
>
> IF there were no shift then there would be no diffusion. Of course
this
> diffusion leans towards the upper bits and there are fixed points (as
was
> pointed out in private). I am looking at this as a sbox or linear
transform.
Like I said, I'm not sure. Shift's up to and including 8 probably won't
be too detrimental, if I understand binary multiplication correctly.
You're b will probably have to be picked carefully.
> Some other ideas were
>
> f(x) = x(ax + b) + c
>
> and
>
> f(x) = x(ax + b) >>> c
How about f(x) = x * ((x >>> b) AND 1) where b <= 16? This would
probably have good diffusion and ensure an odd number in the second part
of the multiplication.
>
> Where [a, b, c] are round variant key words. a is even, b is odd and
c is an
> integer. Both would eliminate the f(xxxx0000) = xxxx0000 fixed points
but
> may cause new ones...
>
> This function on it's own is not very secure, the former requires some
> universial bit mangler (i.e the lower bits and higher bits have to mix
with
> equal prob). In the case of RC6 this is accomplished (?) via the
> data-dependant rotations.
This function is used to set up the data-dependant rotations, so your
thinking is backwards if I understand it correctly. The goal of the
quad is to generate 5 bits to be used for the rotate. The results of
the quad are also mixed in with the data using an XOR, however I don't
believe that plays as significant of a role in the security of the
cipher as the data-dependant rotate.
csybrandy
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Strengthening passwords against dictionary attacks
Date: Mon, 18 Oct 1999 19:25:19 GMT
In article <[EMAIL PROTECTED]>,
Thomas Wu <[EMAIL PROTECTED]> wrote:
> Tom St Denis <[EMAIL PROTECTED]> writes:
> >
...
> > Simple as that.
>
> This is vulnerable to dictionary attack [attacker gets R and a,
> and tries passwords P until a == HASH(R + P)]. Any login system
> should work like SRP, SPEKE, or EKE to prevent a dictionary attack.
> --
> Tom Wu * finger -l [EMAIL PROTECTED] for
...
SPEKE at least won't work for a non-interactive scenario. For
example, I am logging into a stand alone NT box. SPEKE requires
two active participants per the paper 'Strong Password-Only
Authenticated Key Exchange' by David Jablon. In my example, the
password must be authenicated from some file on the NT hard drive.
It is my suposition that any such system will be vulnerable to
dictionary attack. One way to prevent or slow such an attack is to
increase the time for password authentication to a 'long' time.
The 'long' time must be guaged by the particular situation but several
seconds per check seems a likely number as per my original post.
Are there any existing protocols that strengthen a password file against
dictionary attack?
--Matthew
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Strengthening passwords against dictionary attacks
Date: Mon, 18 Oct 1999 19:34:44 GMT
In article <7uds4t$9pn$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David Wagner) wrote:
> In article <7ud46d$m9r$[EMAIL PROTECTED]>,
> Solar Designer <[EMAIL PROTECTED]> wrote:
> > 1. Throwing away salt bits results in non-constant check times for
> > different users. This is both inconvenient (some users might have
> > to wait 10 seconds to achieve an average of 5), and dangerous.
Timing
> > attacks might be possible, such as on sniffed encrypted sessions of
> > a user authenticating to such a system. These attacks would reveal
> > several bits of those you've thrown away. This is really bad.
>
> Timing attacks can be prevented by having the server check the
salt-space
> in a random order (chosen anew each time, for each user).
Where is the orginal post? They seem to have come out of order to
deja.com.
Anyway, excellent point on the timing attack. A simple enhancement
would be to search all the salt every time. The time per login would be
about constant that way. Additionally, a timing attack would be
much harder. Of course, when the right value was found a flag would be
flipped. To thwart timing attacks, a flag should be flipped on misses
as well.
Thanks for the feedback. Excellent point.
--Matthew
>
> (It's a good point, though; I haven't seen that attack described
anywhere
> else before.)
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 18 Oct 1999 19:43:56 GMT
On Mon, 18 Oct 1999 08:07:38 -0400, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
>Roger Schlafly wrote:
>
>> Terry Ritter <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]...
>> > Modern "hardware" systems often consist of embedded processors and
>> > "firmware" based in flash. The system itself can be designed to
>> > choose from an array of acceptable ciphers, and also maintain a list
>> > of a cipher *required* in a cipher stack, or *disallowed* due to new
>> > information.
>>
>> Yes, hardware systems could do that. But I am sure that they
>> would rather devote those resources to something more useful,
>> in most cases.
>
>Something "more useful" than averting the possibility that the entire
>device becomes useless?
Yes. There are a zillion things more useful than that. In a
cellphone, for example, voice quality is far more important than
encryption. The system will NEVER be designed to choose from an array
of acceptable ciphers; we can't even get a system designed that has a
single marginally acceptable cipher. In a network hardware switching
box, for example, it is more important to be able to make more
connections than it is to have a choice of algorithms. Cisco would
hate having multiple "must have" algorithms in IPsec. In an embedded
stored-value card, every one of our clients would rather field the
system with lousy encryption than add more complexity (and cost) to
the chip.
It's a weird world out there, but it is the world we need to design
to.
Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Bruce Schneier Proves That Secure Cryptography is Impossible
Date: 18 Oct 1999 15:40:56 -0400
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>Bruce Schneier wrote:
>>
>
>> People memorize phone numbers because they use them regularly.
>> Cryptographic keys that are used infrequently will not be memorized so
>> easily.
>>
>> And yes, one can memorize six digits and insert them into a pass
>> phrase in some irregular positions, but the average person simply will
>> not bother doing so. I agree that you can invent lots of ways to
>> create high-entropy pass phrases; I disagree that they will result in
>> a population of secure pass phrases.
>
>I certainly can't 'prove' my claim, but I believe that you
>underestimate the average IQ of people when you estimate that they
>can't even memorize four digit numbers. If people are well informed
>of the risk of insecurity resulting from poor pass phrases, they will,
>in case the risk involved is sufficiently high, be motivated to follow
>good advices. Unfortunately there isn't in my view sufficient effort
>being done yet to inform/educate the people in that. Perhaps the time
>has yet to come. Analogy for the correlation between risk and
>motivation: If I lose my credit card and someone misuses it, I am
>liable only to some 100 DM (if I remember the card issuer's conditions
>right). That clearly doesn't give me much motivation to very
>carefully guard my card. I would have behaved differently, if
>I were liable to, say, half of the money lost due to the activity of
>the person who misuses the card.
So you're suggesting that keyphrase fraud will only be as common as
other forms of fraud? Um, this doesn't instill confidence....
-kitten
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 18 Oct 1999 19:58:37 GMT
On Thu, 14 Oct 1999 21:33:18 -0400, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
>> By allowing multiple algorithms you are certain to guarantee that there
>> will be some users who can't talk to others.
>
>No. This is an invalid conclusion.
>
>Any users desiring to communicate will be able to select a mechanism to do
>so. Any analysis dismissing the active participation of the users in the
>dynamic selection of their channel properties from amoug the telephone, fax,
>and email is trivially flawed. The same flaw applies to the choice of
>ciphers.
>
>Further, a serious vendor will be able to use the degree of interoperability
>of their products as an advantage of their superior products, thus driving
>inferior products and vendors from the market. This is a Good Thing.
This is a great theory. When is it going to happen in the U.S.
cellphone industry. Phone interoperability is actually something
important, not like security; I can't buy a phone that allows me to
dynamically select among different digital standards, and none of the
serious vendors are moving in this direction.
The theory may be a Good Thing (tm), but it often doesn't work in
practice.
Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 18 Oct 1999 19:54:38 GMT
On 16 Oct 1999 14:24:53 GMT, [EMAIL PROTECTED] (DJohn37050) wrote:
>John,
>On patent rights for the winner(s), NIST has ALWAYS said there may be one or
>more winners. It is only some people who choose to restate what NIST actually
>says to have them saying "NIST will choose a winner." NIST has NEVER said
>something as simple as that.
Correct. I remember Miles saying something like "we will choose
approximately one winner."
Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Bruce Schneier Proves That Secure Cryptography is Impossible
Date: 18 Oct 1999 16:07:16 -0400
In article <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>Bruce Schneier ([EMAIL PROTECTED]) wrote:
>: I agree that it's possible, but I don't think it likely. It's hard
>: enough getting users to remember four-digit PINs. You and I and
>: everyone who reads this newsgroup can remember high-entropy
>: passphrases (maybe a few), but the general populace cannot.
>
>Well, that distinction was omitted in the article. Also, a four-digit PIN
>hasn't been sugar-coated for ease of memorization.
>
>But the question of how much entropy can be in a pass phrase, even one
>memorized by a highly motivated user of PGP, is still a legitimate
>question. I was wondering if someone who had done the math had an opinion,
>because this is a very important user-interface issue.
There is no upper bound on the entropy of a pass-phrase; standard
English has somewhere between 1 and 2 bits per character, depending
on the model. So if you need a 128-bit passphrase, you can simply
memorize a 128-character sentence.
*HOWEVER*, it's not clear to me that the general public will put
up with that much memorization and typing. Even if you force people
to pick long pass phrases, they're likely to pick stereotyped passphrases
such as those that one finds in Bartlett's Quotations, &c. "Tomorrow
and tomorrow and tomorrow creeps at this petty pace from day to day
to the last syllable of recorded time, and all our yesterdays have
lighted fools their way to dusty death" is a great passphrase, nice
and memorable, until you realize that everyone who read _Macbeth_
in high school knows it.
-kitten
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 18 Oct 1999 20:18:53 GMT
On 16 Oct 1999 17:44:34 GMT, David A Molnar <[EMAIL PROTECTED]>
wrote:
>You (or anyone else reading) may want to look at this master's thesis on
>"Self-Describing Cryptography" :
>
>http://ben.adida.net/thesis/
>
>which covers exactly the problem of transferring the description of a
>cipher along with the message it's going to decrypt. Part of the thesis is
>a sample implementation in Java. I can't find the actual code up on the
>site, but presumably one could ask the author for more details.
I've seen proposals for this kind of thing. You can think of it as
the cipher having a secondary key that helps choose among a family of
transformations. Ciphers like this generally have lots of weak
keys--they are as secure as the weakest transformation in the
family--and are usually stronger without the secondary key.
Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: "Belldandy" <[EMAIL PROTECTED]>
Subject: Re: He is back...new "improved" code
Date: Mon, 18 Oct 1999 15:32:24 -0500
Dan Day <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Given that Mr. Fogelberg's friend is clearly still in the cryptographic
> infancy, it seems likely to me that he would have used an easy-to-remember
> passphrase, and not one that would be so unmemorizeable that he would
> have to store it in the computer. For that matter, since he was
> issuing the encrypted message as a challenge, it's possible that he
> didn't even bother to try to remember the passphrase after he
> generated the ciphertext, since he had no interest in actually
> being able to decrypt it himself.
..this might sounds silly but..... have you asked him whether his encryption
is... decryptable? I mean, for all combination of plain text, will his
encryption will definitely decryptable?
------------------------------
** 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
******************************
