Cryptography-Digest Digest #829, Volume #12 Tue, 3 Oct 00 16:13:01 EDT
Contents:
Re: Looking Closely at Rijndael, the new AES (Mok-Kong Shen)
Re: Rijndael: making the "flaw" plainer (Mok-Kong Shen)
Re: Advanced Encryption Standard - winner is Rijndael (Simon Johnson)
Re: Advanced Encryption Standard - winner is Rijndael (Simon Johnson)
Re: Advanced Encryption Standard - winner is Rijndael (David Schwartz)
Re: Authenticating a PIN Without Compromising the PIN (David Schwartz)
Re: Looking Closely at Rijndael, the new AES (David Schwartz)
Re: It's Rijndael (Mok-Kong Shen)
Re: Mr. Zimmermann, Mr. Price when can we expect this feature ? (Tom St Denis)
Re: key management on static system (Tom St Denis)
Re: My Theory... ("Brian Gladman")
Re: On block encrpytion processing with intermediate permutations (Bryan Olson)
Re: Advanced Encryption Standard - winner is Rijndael ("Joseph Ashwood")
Re: key management on static system ("Joseph Ashwood")
Democrats, Republicans, AES... (Albert Yang)
Re: Authenticating a PIN Without Compromising the PIN ("Joseph Ashwood")
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Looking Closely at Rijndael, the new AES
Date: Tue, 03 Oct 2000 21:23:40 +0200
John Savard wrote:
>
> As it happens, because of attacks faster than brute force, increasing
> the number of Rijndael rounds as the length of the key increases was
> needed. But also in general, it makes more sense to leave the number
> of rounds fixed with changes to the key size - but it is _vitally
> necessary_ to increase the number of rounds if the block size
> increases.
I don't yet quite understand the inherent reason of need of
more rounds as the length of key increases. One could set
part of the longer key to zero and so get an effective
key that is short, isn't it? (That would mean that no more
rounds are needed.) Thanks.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Rijndael: making the "flaw" plainer
Date: Tue, 03 Oct 2000 21:23:47 +0200
[EMAIL PROTECTED] wrote:
>
[snip]
> Just as I was surprised that a differential attack was found against
> Blowfish with its key-dependent S-boxes (I would have thought duplicate
> entries, although a weakness, would not be detectable) I am surprised that
> Rijndael has been subjected to differential attacks at all, however, since
> having the Byte Sub in line is a considerable source of strength compared
> to a conventional Feistel cipher.
What do you mean by 'having the Byte Sub in line'? (You
have said that 'The Byte Sub step corresponds roughly to the
f-function'.) Thanks.
M. K. Shen
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Crossposted-To: alt.security.scramdisk
Subject: Re: Advanced Encryption Standard - winner is Rijndael
Date: Tue, 03 Oct 2000 19:08:27 GMT
In article <8rd3tn$23u$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> > [EMAIL PROTECTED] (Jeff Moser) wrote in
> > <8rcrtl$90p$[EMAIL PROTECTED]>:
> >
> > >> Not really. If they want a real contest. Make a 10k doucument
> > >> encrypted with a secret key. And offer someone 10 million dollars
> > >> state and federal government tax fee if they can decrypt it
> > >> it in a years time. Will they do that. Hell no someone might
> > >> break it. And they don't want anyone to break it.
> > >
> > >If you're smart enough to break the cipher, you sure as hell
wouldn't
> > >take the 10 million. That is peanuts compared to what you could
make
> if
> > >you knew that you could break all "secure" documents of the future
> for
> > >~20 years.
> > >
> > >Jeff
> > >
> > >
> > >
> >
> > That is your guess. I think someone smart enough to break the
cipher
> > would take the 10 million. Becasue once it gets out how it was done
> > you may not make a dime. There is also the chance you could be
> teminated
> > by some accident arranged by a 3 letter agency. So taking the money
> > with everyone aware may be the safest option.
>
> What if the attack is private and I can steal debit PIN's for the next
> 10 years....
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
Nice, if a 3 letter agency doesn't find out. Of course, when then do,
you will be promptly 'deleted'.
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Crossposted-To: alt.security.scramdisk
Subject: Re: Advanced Encryption Standard - winner is Rijndael
Date: Tue, 03 Oct 2000 19:06:00 GMT
In article <8rd3tn$23u$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> > [EMAIL PROTECTED] (Jeff Moser) wrote in
> > <8rcrtl$90p$[EMAIL PROTECTED]>:
> >
> > >> Not really. If they want a real contest. Make a 10k doucument
> > >> encrypted with a secret key. And offer someone 10 million dollars
> > >> state and federal government tax fee if they can decrypt it
> > >> it in a years time. Will they do that. Hell no someone might
> > >> break it. And they don't want anyone to break it.
> > >
> > >If you're smart enough to break the cipher, you sure as hell
wouldn't
> > >take the 10 million. That is peanuts compared to what you could
make
> if
> > >you knew that you could break all "secure" documents of the future
> for
> > >~20 years.
> > >
> > >Jeff
> > >
> > >
> > >
> >
> > That is your guess. I think someone smart enough to break the
cipher
> > would take the 10 million. Becasue once it gets out how it was done
> > you may not make a dime. There is also the chance you could be
> teminated
> > by some accident arranged by a 3 letter agency. So taking the money
> > with everyone aware may be the safest option.
>
> What if the attack is private and I can steal debit PIN's for the next
> 10 years....
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Crossposted-To: alt.security.scramdisk
Subject: Re: Advanced Encryption Standard - winner is Rijndael
Date: Tue, 03 Oct 2000 12:16:20 -0700
jungle wrote:
>
> read again my press note, it is there ...
>
> additionally it is in Published in the January 2, 1997 issue of the Federal
> Register: DEPARTMENT OF COMMERCE National Institute of Standards and Technology
> [Docket No. 960924272-6272-01] RIN 0693-ZA13 document ...
>
> "It is intended that the AES ... algorithm capable of protecting sensitive
> government information ..."
I see no evidence that the U.S. government ever reached the conclusion
that Rijndael is not suitable for protecting classified information.
Again, can you produce any evidence for this claim?
DS
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Authenticating a PIN Without Compromising the PIN
Date: Tue, 03 Oct 2000 12:27:46 -0700
Guy Lancaster wrote:
>
> If it's possible, how could a protocol authenticate a user's
> PIN without revealing information that would make it
> relatively easy to determine the actual PIN value?
One trivial way is to have each unit have a shared secret with the
server. When I enter my PIN into the unit, it sends the server its unit
ID any my PIN encrypted with its shared secret (the PIN should be padded
before being encrypted). The server uses the unit ID to lookup the
shared secret and then decrypt the PIN and checks it.
There is nothing useful anyone can do with the unit ID and the
encrypted PIN. That's all that's sent over the wire.
DS
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Looking Closely at Rijndael, the new AES
Date: Tue, 03 Oct 2000 12:23:35 -0700
Mok-Kong Shen wrote:
>
> John Savard wrote:
> >
> > As it happens, because of attacks faster than brute force, increasing
> > the number of Rijndael rounds as the length of the key increases was
> > needed. But also in general, it makes more sense to leave the number
> > of rounds fixed with changes to the key size - but it is _vitally
> > necessary_ to increase the number of rounds if the block size
> > increases.
>
> I don't yet quite understand the inherent reason of need of
> more rounds as the length of key increases. One could set
> part of the longer key to zero and so get an effective
> key that is short, isn't it? (That would mean that no more
> rounds are needed.) Thanks.
The inherent reason for more rounds as the key gets longer can be
explained both simply and completely. I'll use two simple explanations.
;)
Simply, people who use longer keys need stronger ciphers to match the
strength of the key. If you're using a 56-bit key, you might as well use
DES.
Basically, a cyptanalytic attack is useless if it's more work to attack
the cipher than guess the key by brute force. So suppose you have a
cryptanalytic attack that can break a 12-round cipher in 2^64 steps.
With a 56-bit key, the 12 rounds are adequate. It's easier to guess the
key by brute force than use the attack. No suppose someone wants to use
a 128-bit key. At this point, you need more rounds because it's now
easier to attack the cipher than guess the key.
DS
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: It's Rijndael
Date: Tue, 03 Oct 2000 21:44:48 +0200
David Crick wrote:
>
> lcs Mixmaster Remailer wrote:
> [..]
> > Rijndael appears to be a compromise between security and efficiency.
> > This leaves us in an unhappy and uncomfortable position. It may well be
> > that Twofish and perhaps Serpent continue to be widely used alternatives
> > to AES.
>
> Assuming you don't want to interact with the US Government, you
> and your parties may use whatever crypto you feel safe with.
>
> And if you require a FIPS, 3DES is and will be available to you.
I conjecture that 3DES will continue to stay for a quite
long time. For analogy, see the programming language Cobol.
M. K. Shen
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,alt.security.scramdisk
Subject: Re: Mr. Zimmermann, Mr. Price when can we expect this feature ?
Date: Tue, 03 Oct 2000 19:29:40 GMT
In article <8rd7ef$5e1$[EMAIL PROTECTED]>,
Simon Johnson <[EMAIL PROTECTED]> wrote:
> In article <8rd3gg$1ri$[EMAIL PROTECTED]>,
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> > In article <[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] (Rich Wales) wrote:
> > > "pgp651" wrote:
> > >
> > > > Mr. Zimmermann, Mr. Price when can we expect this feature?
> > > > After RSA patent hoopla is over, isn't now the time to
> > > > implement 4k RSA keys into PGP v262?
> > >
> > > I don't work for NAI and can't speak for them, but I wouldn't hold
> my
> > > breath waiting for NAI to release =any= updates to PGP 2.6.2.
This
> > > version of PGP is over four years old, and (for better or worse)
> they
> > > have gone on to newer versions.
> > >
> > > If anyone is going to modify PGP 2.6.2 (or, more appropriately,
the
> > > bug-fixed international version, 2.6.3ia) to accommodate larger
> keys,
> > > it will presumably be a third party not connected to NAI.
Actually,
> > > I believe some groups have already done this. Have you checked
out
> > > the CKT version, for example?
> >
> > Why the hell would you use a RSA key over 1024 bits anyways?
> >
> > Are people plain stupid, paranoid or know something I dont?
> >
> > Tom
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
> >
> Well, i suppose its all about how long you want you're secret to
> last. Wether its nessary to have a key so large that it couldn't be
> cracked before the heat death of the universe depends on the
> application obviously.
>
> Having said this though, I think i agree with you though, using keys
> bigger than 1024-bit is equal in stupidity to iterating DES 128 times.
> It reduces performance so much, its not worth using.
Another way to view this is
"That like saying a 192 bit key is weak compared to a 256-bit
(symmetric) key"...
DES 128 times would be bad, it would have to be 129 des... hehehe
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: key management on static system
Date: Tue, 03 Oct 2000 19:28:27 GMT
In article <[EMAIL PROTECTED]>,
"Jason R. Coombs" <[EMAIL PROTECTED]> wrote:
> I've read high and low. I've read the HAC regarding key management,
I've
> read through this newsgroup, and I don't see how to address my
issue. I
> suspect it's either an impossible problem or an unsolved problem. In
any
> case, here it is.
>
> We have a software system that we wish to distribute on a CD. It has
a
> database that's potentially fairly large. This database contains
> highly-propriatary information, and so must be protected with very
good
> secrecy. So, I see before me many cryptographic algorithms, but all
require
> some sort of password or secret key.
>
> Our difficulty lies in that we would like to distribute this key on
the CD,
> but have it more-or-less inaccessible to anyone but the program. Is
there a
> well-known mechanism for protecting such a key?
>
> Perhaps better would be to ask how systems such the OS protect the
keys to
> the encrypted file system... or how they protect the user's private
keys. I
> believe I essentially want to solve the same problem.
>
> Any direction is appreciated.
Not only what you want is impossible but it's the goal of a lot of
misguided companies. Like another poster said, send out NDA's.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: My Theory...
Date: Tue, 3 Oct 2000 20:42:17 +0100
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:8rd30n$1ag$[EMAIL PROTECTED]...
> In article <8rcu3k$i91$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Thomas Pornin) wrote:
> > According to Tom St Denis <[EMAIL PROTECTED]>:
> > > So what? The primary concern is security, not speed.
[snip]
> > The AES contest showed that the community knows how to design secure
> > ciphers, we had 15 of them; the choice is merely marketing: the point
> > of a standard is that people use it, so the winner had to be the most
> > popular. Hence Rijndael.
>
> True, but remember that those subtle flaws in Rijndael parallel the
> flaws in using a 56-bit DES key 30 years ago.
It is hard to see the reduction of the DES key from 64 to 56 bits as subtle
but I agree that it was :-)
Brian Gladman
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: On block encrpytion processing with intermediate permutations
Date: Tue, 03 Oct 2000 19:38:59 GMT
Mok-Kong Shen wrote:
> Bryan Olson wrote:
> >
> > Mok-Kong Shen wrote:
> > > Each session uses a (different) secret seed for the PRNG.
> > > (I use effectively more key material, as said in a previous
> > > follow-up.)
> >
> > Does your method requires a separate secure channel for
> > transporting the per-message keys? How do the sender
> > and receiver know which key to use?
>
> They get the material with the same channel at the
> same time. Send some longer material, one part for the
> encryption key, the other part for the seed. That
> seed is for the whole session, which may consist of
> a number of messages.
So the scheme is only appropriate when a new key will be transported
for each session? Note that a conventional block cipher and
chaining mode can support arbitrarily many sessions and messages
with a single key.
> > [...]
> > > > Hard to sell exposing the key as a good thing.
> > >
> > > Sorry, the above sentence is difficult for me (foreigner)
> > > to understand.
> >
> > Hard to take that seriously.
>
> Does that constitute a concrete answer that I requested
> (see the part you snipped)?? (A yes/no is anyway needed.
> And some explanations.)
What is needed is a serious attempt to understand the material.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Advanced Encryption Standard - winner is Rijndael
Date: Tue, 3 Oct 2000 12:32:35 -0700
Crossposted-To: alt.security.scramdisk
> But let me then ask a related question. Is there any good public domain
info
> (speculative or otherwise) discussing what would make currently available
> algorithms (e.g., Rijndael, its AES rivals, Blowfish, and so forth)
> *unsuitable* for secrecy levels of confidential and up?
Before I go in depth on this, first let me say that I have no clearance
level designated by the government (at least none that I am aware of), I
have no relationship with the government, and all statements made in here
are guesses that I have made, the accuracy or lack thereof is an artifact of
lack of knowledge.
Lack of trust. Also because the NSA trusts it's own internal designs, and
has less trust in the outside world, they add the protection of obscurity.
They can afford to do that because they have a very large number of
presumedly great mathematicians dedicated to doing the NSA's bidding.
Outside of that we can make guesses based on what has been published, for
example with the publication of KEA and Skipjack there cam information that
the combination is a type II member of a class of fucntions that includes
type I algorithms also. I'm fairly certain that the requirements go
something like:
Key space: 2^128 - 2^256 (probably given specifically for each design)
Differential: 2^120 - 2^200
Linear: 2^120 - 2^200
Complexity : whatever
Attack X (which we haven't found yet): 2^100-2^160
etc
Feeling: The CO must feel that it is good
I'm sure there are other requirements that I just haven't put in, and the
limits are probably tightened to taylor the design for a specific purpose.
For example the presidents phone book (with associated personal notes) would
be protected by a "minimal" cipher, and something like Rijndael would
doubtless be usable. However the book of America's deepest darkest secrets
would doubtless be covered by something very substantial, missing the
maximum acceptable values by very small amounts. It would also not surprise
me if there is a group that is used basically as an algorithm oracle, and
several other groups that examine the oracle output, these now well analyzed
ciphers would then be stored until a project came along requiring those
particulars, very similar design to the public worlds Engineering-QA
relationship.
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: key management on static system
Date: Tue, 3 Oct 2000 12:48:05 -0700
I just wanted to ex[and a bit on the "no can do" remark.
You are sending this program into a potentially completely hostile
environment. In this environment the attacker can do any of the following
and anything else they can think of:
examine/copy/change the memory of the program while it's running
examine/copy/change the code of the program while it's running
examine/copy/change the values stored on disk
examine/copy/change your encryption keys (under the first 2 lines)
rewind/replay all or parts of the program
write a new program that makes use of all/part/none of the information
gleened from the above
So an attacker can examine your program very carefully, examine and copy the
keys you use (no matter how well protected, excluding hardware), and make
use of those heys in any way they see fit. Possibly if you use hardware it
may be possible, but that's not what you asked.
Joe
"Jason R. Coombs" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I've read high and low. I've read the HAC regarding key management, I've
> read through this newsgroup, and I don't see how to address my issue. I
> suspect it's either an impossible problem or an unsolved problem. In any
> case, here it is.
>
> We have a software system that we wish to distribute on a CD. It has a
> database that's potentially fairly large. This database contains
> highly-propriatary information, and so must be protected with very good
> secrecy. So, I see before me many cryptographic algorithms, but all
require
> some sort of password or secret key.
>
> Our difficulty lies in that we would like to distribute this key on the
CD,
> but have it more-or-less inaccessible to anyone but the program. Is there
a
> well-known mechanism for protecting such a key?
>
> Perhaps better would be to ask how systems such the OS protect the keys to
> the encrypted file system... or how they protect the user's private keys.
I
> believe I essentially want to solve the same problem.
>
> Any direction is appreciated.
>
> Jason
>
>
------------------------------
From: Albert Yang <[EMAIL PROTECTED]>
Subject: Democrats, Republicans, AES...
Date: Tue, 03 Oct 2000 20:02:05 GMT
Don't get me wrong, I think Rijndael is a great algorithm, the designers
are very good, and have good pedigree to prove it... BUT...
First, I have to say that AES isn't like picking the next president of
the United States (It's more important than that!!!) And as is such, I
feel that NIST should have errored on the side of conservatism. This
shouldn't be a "my algorithm is better than yours because I got the most
press coverage!" type of thing, or the counterpart of it "Mr. BS put
backdoors in everything, all the fish based algorithms are breakable by
the government, so says me Mr. Scotty too Hotty"... This is about
security, and which algorithm has the highest security margain within
the confines of fitting into small devices.
What I would have done is this, kept only the ones with "high level of
security margain" and thrown out the rest. This takes into
consideration, inheritance, pedigree, structure, "new math" etc..
(Security was the first criteria right?)
Second, I would have seen if any of them have problems fitting into
smartcards etc...
Third, I would have seen which one(s) were the easiest to analyse, as I
think most agree that the true strength of an algorithm lies in how much
it has been tested and it's ability to resist attacks...
Also, one of the comments from (Was it Lars?) said that nothing in
Rijndael looks "random", that everything looked somewhat linear in
format... So I expect to see some serious linear attacks on Rijndael in
the next few weeks.
Now here's the magic question:
Suppose that within the 90 day public comment period, someone breaks 10
round Rijndael... what then? Since NIST has already said their views
concerning a "hot backup", then where do we go from there? Restart the
proposal? Use twofish, or Serpent, or RC6 or MARS? What?
I think within the next 5 years, we will see a break against 10 round
Rijndael, and given the fact that the NIST didn't even ask the standard
to be Rijndael @ 16 rounds, I think it's a big mistake...
BTW, FWIW, I think the debates on this forum is much better than the
political one tonight...
Albert
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Authenticating a PIN Without Compromising the PIN
Date: Tue, 3 Oct 2000 12:59:41 -0700
There are several different models in use.
The 3 basic types are exemplified by SecurId, Normal Smartcards, Arcot
Cards.
Using a SecurId type token it is possible to have the token generate an
output that depends on the current time and the pin (probably via a hash).
This requires revealing the pin to the token, which has physical security
Normal Smartcards, you input a PIN into the unit, the unit checks that pin
internally against what is necessary to unlock the unit, on success a
private key becomes avilable that can be used for further identification,
using any number of known methods. The related public key can be widely
known.
Arcot Cards, this one is probably closer to what you were looking for. In an
Arcot card you have to values of import, X = camouflage(private key), and Y
= 3DES(public key). For authentication, the software retrieves a challenge,
you enter your pin into the software, the software uses your pin to reveal
the private key to itself, and using the private key signs the challenge,
the signed challenge and Y are sent to the server, the server decrypts Y to
reveal your public key, and verifies the signature. If the signature
verification succeeds the user knows the pin.
Each method has it's own advantages, SecurId does not take any costly public
key operations. Normal Smartcards can be used to verify yourself to a
computer without having to worry about the computer compromising your PIN.
And arcot cards can not be physically lost (as as new one can be downloaded
fairly simply because there is little associated risk). Of course there are
other methods, you can as proposed use PAK, or SRP, or EKE, or SPEKE, or any
other zero knowledge proof between a client and server, each with it's
associated advantages and disadvantages. Depending on your requirements you
could even use the hash of the pin as a secret key for a DH exchange, but
the key search could still be performed (by iterating through the keys until
you had a collision with the public key).
Joe
"Guy Lancaster" <[EMAIL PROTECTED]> wrote in message
news:8rd6d8$4a9$[EMAIL PROTECTED]...
> If it's possible, how could a protocol authenticate a user's
> PIN without revealing information that would make it
> relatively easy to determine the actual PIN value?
>
> PINs are commonly used to authenticate users of trusted
> machines but is there any way that they can be secure for
> use over untrusted networks? I'm beginning to think that
> the answer is no.
>
> Here's a scenario. We want to allow authorized users of a
> service to access that service over an untrusted network
> such as the Internet. We provide a small device that can
> connect via this network. These devices are not keyed
> to specific users and are readily accessible. Our server
> needs to authenticate the user but we cannot guarantee that
> the connection won't get redirected by a third party to
> another server for the purposes of gaining unauthorized
> access to our system. Thus our device needs to provide
> information that allows us to authenticate the user but
> does not allow an attacker's server to be able to determine
> the shared secrets.
>
> The problem is that PINs must be short (i.e. a few digits)
> which makes it all too easy for a computer to exhaustively
> search for the correct value given sufficient information to
> know when it has the correct value. I can find no way of
> authenticating a PIN without revealing enough information to
> crack it. Am I wrong?
>
> Guy
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
** 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
******************************
