Cryptography-Digest Digest #242, Volume #13 Wed, 29 Nov 00 17:13:00 EST
Contents:
Re: keysize for equivalent security for symmetric and asymmetric keys (Bob Silverman)
Re: keysize for equivalent security for symmetric and asymmetric keys (Roger
Schlafly)
Are there collisions in DES? ("David C. Barber")
Re: On mutation of crypto algorithms (Mok-Kong Shen)
Re: keysize for equivalent security for symmetric and asymmetric keys
([EMAIL PROTECTED])
Re: SRP - not good enough? (John Savard)
Re: Are there collisions in DES? (John Savard)
RC4 Questions ("James")
Re: keysize for equivalent security for symmetric and asymmetric keys (Bob Silverman)
Re: Public key encryption in Javascript? (John Bailey)
Re: keysize for equivalent security for symmetric and asymmetric keys (Doug Kuhlman)
Re: SRP - not good enough? (Paul Rubin)
Re: A Simple Voting Procedure (David Schwartz)
Re: keysize for equivalent security for symmetric and asymmetric keys
([EMAIL PROTECTED])
Re: keysize for equivalent security for symmetric and asymmetric keys (Bob Silverman)
Re: keysize for equivalent security for symmetric and asymmetric keys (Bob Silverman)
Re: SRP - not good enough? (John Savard)
Re: Are there collisions in DES? (Mok-Kong Shen)
Re: Are there collisions in DES? (Quisquater)
----------------------------------------------------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: keysize for equivalent security for symmetric and asymmetric keys
Date: Wed, 29 Nov 2000 18:59:51 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (DJohn37050) wrote:
> To clarify, I prefer the NIST-supplied numbers over the COST (really
STORAGE)
> model. Recall that ECC and the DSA q value can be broken using TIME
and not
> much storage, but that breaking RSA or DSA p value needs TIME plus
STORAGE for
> the known best method. Recall that hashes and symmetric encryption
can be
> broken using TIME and not much storage. Therefore mapping TIME (to
break sym.)
> to TIME (to break asym.) is straightforward but mapping TIME (to
break sym.) to
> STORAGE (to break RSA) involves more assumptions and is not as
straightforward
> by a long shot as you can imagine.
I *DO NOT* map TIME to STORAGE. I map COST to COST. A different
thing entirely.
> More assumptions means more assumptions
> that might be shown to be wrong in the future.
No. What you are doing is IGNORING the fact that your model makes
HIDDEN assumptions. It assumes that memory is infinite and free.
This assumption is not explicitly stated in the time-only model, but
it is there.
You, in your ignorance, fail to see this.
>
> Another way of looking at it: Do I REALLY want to rely on the current
> difficulty of solving the GNFS matrix needing lots of storage or
might a
It is not JUST the matrix. Each machine that does the sieving requires
massive memory as well. It's just that dealing with the matrix
requires MASSIVE MASSIVE memory. Sieving requires many many machines
each with 100's of gigabytes. The matrix requires 1 machine with
10't to 100's of TERABYTES of memory and even more disk space.
> breakthru occur where one needs less storage.
Red herring. One ALWAYS ignores "possible breakthroughs in algorithms"
because such things are impossible to predict.
> That is, is it more plausible
> that an entirely new alg. might be invented or that an existing alg.
(GNFS) be
> improved? Who knows?
People who work with the algorithm know. It is clear that Don doesn't.
The size of the factor
base and the resulting matrix for GNFS is known both in practice and
theoretically. WHile small incremental improvements in matrix size
may occur, they have no effect *in practice* on the possibility to
break even a 1024-bit key. There are known LOWER BOUNDS on how
small it can be.
And one could turn this "red herring" back on him: Who knows
if a sub-exponential algorithm might be found for breaking
ECDL?? Depending on how practical such an algorithm is, it might
effectively kill EC altogether (if EC keysizes double, EC becomes
slower than RSA/DSA)
When making comparisons one compares using the best KNOWN methods
and does not speculate on future "breakthroughs" (which might apply
equally to both techniques being compared)
But one can choose to use less assumptions (i.e., TIME)
> and therefore have a less chance to be wrong (that is, be more
conservative
> than perhaps might be needed).
You are not using less assumptions. You are just using DIFFERENT
assumptions. I assume that CPU time and SPACE are binding constraints
and that both CPU and MEMORY cost money. You assume that only CPU
time matters *because* memory is unbounded and costs nothing. You
ignore your second assumption.
I suggest readers form their own conclusion.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: keysize for equivalent security for symmetric and asymmetric keys
Date: Wed, 29 Nov 2000 11:10:31 -0800
DJohn37050 wrote:
> I prefer the NIST ECC numbers over ...
> However, no one disputes that a sym op is faster than an
> asym op. so assuming they are equal is conservative.
How can it ever be conservative to assume something that you
know is false?
I object to this reasoning. It can be conservative to assume
the worst about an attacker. But that is not what you are
doing. You assume something about relative speed that you
know is wrong.
------------------------------
From: "David C. Barber" <[EMAIL PROTECTED]>
Subject: Are there collisions in DES?
Date: Wed, 29 Nov 2000 12:17:57 -0700
Are there collisions in DES? What I mean by that is:
1: Can 2 different keys with the same source give the same encrypted
result?
2: Can 2 different sources with the same key give the same encrypted
result?
3: Can 2 different sources (of non-trivial length) with 2 different keys
give the same encrypted result?
4: Does the reduced keyspace of 56-bits contribute to a lack or low
probability of collisions, since the 2^56 keys maps a source into a result
space of 2^64? Would this be a 'feature' of the reduced keyspace that has
not otherwise been explained well IMHO?
I might well have answered this myself if I had dedicated DES hardware, but
my Pentium-II isn't really up to testing all possible cases in a reasonable
length of time.
I am particularly interested in case #1 above, since I've never heard it
proven that every key gives a unique output in the 2^64 result space.
How about other modern ciphers?
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On mutation of crypto algorithms
Date: Wed, 29 Nov 2000 21:03:32 +0100
Tom St Denis wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > An interesting question is how would a scaled-down version
> > of Rijndael compete with DES. My feeling of the gut is that
> > 20 rounds would probably suffice to provide a fairly safe
> > bet.
>
> Irrelevant. Rijndael cannot process 64-bit blocks. The closest thing
> is a 72-bit block.
What hinders a scaling-down to 64 bit blocks?
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: keysize for equivalent security for symmetric and asymmetric keys
Date: Wed, 29 Nov 2000 20:01:49 GMT
I hope I can offer an impartial view (I have an interest in neither RSA
nor Certicom, and my employer makes use of many different technologies
including those supplied by both).
It is far from accepted that a 3Kb public key matches a 128-bit
symmetric key. The perfect counterexample is ECC, where field sizes of
1KB should offer far more security than 128-bit keys.
In terms of who is more correct. I personally prefer the methodology of
Bob Silverman, because at the sizes being dealt in RSA using the best
known factoring algorithm, the dominant factor is the memory. In ECC
it's still a slightly different matter, memory is not as much of an
issue there is compute power. I also firmly believe, and I would say
that it is likely that most of the people involved would agree, in
order to break 1500+bit RSA (or DH), or 250+bit ECC, will require an
advance of the algorithm, so using either should be secure. I am also a
firm believer in not betting the farm on the judgement calls of any
individual (even myself), so my recommendation is to use a minimum of
1500-bit RSA or 256-bit ECC, and go as far beyond that as your compute
level can handle.
Joe
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: SRP - not good enough?
Date: Wed, 29 Nov 2000 20:17:43 GMT
On Wed, 29 Nov 2000 13:32:04 -0500, Philip MacKenzie
<[EMAIL PROTECTED]> wrote, in part:
>What files? No information about the password is stored
>on the user's machine in any of these protocols (PAK, SRP, EKE, etc.).
Maybe I misunderstood the claims for PAK-X. But you're quite right
that since the user knows the password, his machine hardly needs to
store information about it.
But the user's machine might, for example, store information which
corresponds to other information on the host machine in a way
permitting a dictionary attack. This could be done in some protocols
as part of what is needed to protect against a compromise of the host
(or server) machine.
Since the claim for PAK-X, or, now, PAK-RY, was that it was not
vulnerable to server compromise, nothing was mentioned about
vulnerability to compromise of files on the user's computer. I
concluded that meant that problem was not solved; I suppose this means
I was mistaken, and there is nothing on the user's computer to
compromise.
My specific concern, though, is with what was stored on the host
machine for SRP:
a random hash value s,
and the Diffie-Hellman public key A^H(p,s) mod P.
The documentation of SRP refers to a host compromise as requiring an
'expensive dictionary attack', but since for each dictionary entry
tried, the only steps needed are those used in the protocol - hashing
the possible p with s, then deriving a _public_ key from a _private_
key (not the difficult other way around) this isn't comparable to what
EKE does (in its area of security: it requires the password in the
clear on the server, so it's even worse in the case of a server
compromise), so it doesn't, in my estimation, _really_ prevent a
dictionary attack.
PAK, I'll admit, is still a bit beyond my depth. If indeed PAK has
succeeded where SRP failed, without needing to cheat in the way I
proposed (by having a secure server behind the host system) to fulfill
the goals:
given active attacks on the communication system, and compromise of
any files permanently stored on either the user's terminal or the
computational host,
- the overall communications are as secure as regular Diffie-Hellman,
and
- resistance to a dictionary attack on the password is at the EKE
level (a public-key problem has to be cracked for every possible try
of the password)
then congratulations. (And looking at the PAK-RY description, it
doesn't seem there is any kind of verifier stored statically on the
user's computer.)
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Are there collisions in DES?
Date: Wed, 29 Nov 2000 20:23:13 GMT
On Wed, 29 Nov 2000 12:17:57 -0700, "David C. Barber"
<[EMAIL PROTECTED]> wrote, in part:
>1: Can 2 different keys with the same source give the same encrypted
>result?
Quite possibly. If it could be proven that this could never happen,
DES would then have a simple structure that could be easily
cryptanalyzed.
>2: Can 2 different sources with the same key give the same encrypted
>result?
No. Then DES would be a hash function, not a block cipher.
>3: Can 2 different sources (of non-trivial length) with 2 different keys
>give the same encrypted result?
Well, of course. There are 2^64 inputs, and only 2^64 outputs, for
every key, and so the same ones are used as outputs for every key.
Thus, for any encrypted result, there is a source that gives it for
every key.
By non-trivial length, do you mean length of more than one block? If
so, that only matters if you mean something like 'sources that consist
of ASCII text'.
>4: Does the reduced keyspace of 56-bits contribute to a lack or low
>probability of collisions, since the 2^56 keys maps a source into a result
>space of 2^64? Would this be a 'feature' of the reduced keyspace that has
>not otherwise been explained well IMHO?
It reduces the chance by a factor of 1/256.
>How about other modern ciphers?
Most of them let you use keys which start from the block size and go
up, so there will be more collisions.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "James" <[EMAIL PROTECTED]>
Subject: RC4 Questions
Date: Wed, 29 Nov 2000 15:47:20 -0500
After reading the information on the ciphersaber web site, I have a few
questions about RC4.
The site led me to believe that the maximum secure key length was 512 bits
(where the key is the string used to initialize the random number
generator). Is this correct??? Could I use a longer key and not have my
security compromised?
Also, the ciphersaber implemtation suggests appending a fixed number of
random bytes to the end of the key (10), and then placing these random bytes
at the start of the encrypted stream. Doesn't this compromise security???
Is there something I'm missing??
Also, I own a copy of Applied Cryptography, and in the description of RC4 it
states you could make the S array larger.... in the standard algorith, it's
at 8x8, but the book suggested changing this to 16x16, and lengthening the
init period for the sake of speeding up the algorith (you can code 2 bytes
at a time now...) Would this have any affect on the security of the
alogorithm at all?? Would larger sizes be more secure (like 32x32)??
Finally, I was thinking of creating a larger byte pattern using the password
and the password length, and then hashing with SHA to get a final 160-bit
key to encrypt with... is there anything that I should be careful about or
watch out for???
Thanks for the information... I appreciate it.
- James
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: keysize for equivalent security for symmetric and asymmetric keys
Date: Wed, 29 Nov 2000 20:45:02 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (DJohn37050) wrote:
> Let me try to clarify.
> Model A - only count TIME, ignore SPACE considerations. If a new
computer is
> designed with lots of storage, no need to change model. If a new
computer is
> designed with lots of ops (as in quantum), use larger keys but no
need to
> change model.
This model is parameterized by CPU speed. If this changes, the
value of the parameter changes, but the model does not.
> Model B - try to TIME and SPACE costs. If a new computer is designed
with lots
> of storage, model may become invalid.
Similarly:
No, the model does NOT change. The model is parameterized by the
ratio: cost per CPU/cost per Mbyte of memory. The value of this
parameter changes, but the model does not.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (John Bailey)
Subject: Re: Public key encryption in Javascript?
Date: Wed, 29 Nov 2000 20:54:32 GMT
On 28 Nov 2000 18:59:10 -0800, Paul Rubin <[EMAIL PROTECTED]>
wrote:
>[EMAIL PROTECTED] (John Bailey) writes:
>> I believe there is a distinct need for an encryption suite which
>> supports key exchange and for which the source code can be directly
>> inspected by the parties.
>
>If the parties don't trust each other, it doesn't matter whether the
>encryption is any good. The party at the other end of a connection
>can misuse the information regardless of whether the connection is secure.
Whats their mutual trust got to do with it? The concern is the back
door added by the third party cryptographic software supplier, which
enables evesdropping. How about a key exchange which appears to be
Diffie Hellman, but routlinely selects from a limited set of keys. The
code at:
http://www.frontiernet.net/~jmb184/interests/sci.crypt/old_trunk/PAIRMKR.BC
makes pairs, but can easily be set-up to generate pairs for which the
private key can be generated in a straightforward way, knowing the
public key. It doesn't matter that I trust the receiver or he trusts
me. Its the software supplier that is the worry.
If you aren't paranoid, why encrypt?
John
------------------------------
From: Doug Kuhlman <[EMAIL PROTECTED]>
Subject: Re: keysize for equivalent security for symmetric and asymmetric keys
Date: Wed, 29 Nov 2000 14:51:22 -0600
Bob Silverman wrote:
>
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (DJohn37050) wrote:
> >
> > So you picks your model and makes your mapping. I personally favor
> the NIST
> > numbers,
>
> Unstated: "Because I work for Certicom and it is in my company's
> best interest to make RSA keys as large as possible relative to EC
> keys. That way, EC cryptography appears to have much better
> performance".
>
I just feel compelled to point out that Bob Silverman works for RSA, so
you have to take his arguments and numbers with a grain of salt, too.
And don't ask me, because I'm not unbiased on this topic, either.
Doug
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: SRP - not good enough?
Date: 29 Nov 2000 13:06:01 -0800
[EMAIL PROTECTED] (John Savard) writes:
> PAK, I'll admit, is still a bit beyond my depth. If indeed PAK has
> succeeded where SRP failed, without needing to cheat in the way I
> proposed (by having a secure server behind the host system) to fulfill
> the goals:
>
> given active attacks on the communication system, and compromise of
> any files permanently stored on either the user's terminal or the
> computational host,
>
> - the overall communications are as secure as regular Diffie-Hellman,
> and
>
> - resistance to a dictionary attack on the password is at the EKE
> level (a public-key problem has to be cracked for every possible try
> of the password)
This sounds impossible on its face. Suppose you have the files stored
on the host. That means you can simulate the host. Can't you then
just run the protocol as many times as you need to, to guess the
password?
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: A Simple Voting Procedure
Date: Wed, 29 Nov 2000 13:06:16 -0800
Jerry Leichter wrote:
> | > > 3) 3rd party can force voter to reveal the vote
> | > How many times has 3) occurred in the history of the United States?
> | > Zero.
> | Huh? Have you forgotten the case where a Michigan judge
> | ordered ten voters to reveal their mayoral votes under penalty of
> | perjury?
> The judge was ultimately overturned on appeal. In the US, you cannot be
> ordered to reveal your vote.
Yes, nevertheless he successfully ordered three people to reveal their
votes. Had each of those three people not revealed their votes, they
would have been thrown in jail. If that's not a case of a 3rd party
forcing a voter to reveal their vote, I can't imagine what would be.
> BTW, one of the oddities about this case is the futility of the perjury
> penalty. If there is some way to determine how I voted, you don't need
> to ask me. If there is *no* such way, how could you possibly prove
> perjury (unless I answered differently at different times)? Imagine the
> extreme case: We know the *total* for the 10 people was 9 Yes votes and
> 1 No vote. On the stand, all 10 claim they voted No. We know for a
> fact that 9 of them committed perjury - but we can't possibly prove that
> any individual one of them did!
Right. That's precisely the scenario we want to keep. Hence it be very
imporant that a 3rd party can'd match a vote to a voter.
DS
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: keysize for equivalent security for symmetric and asymmetric keys
Date: Wed, 29 Nov 2000 21:09:38 GMT
In article <903geb$91l$[EMAIL PROTECTED]>,
Bob Silverman <[EMAIL PROTECTED]> wrote:
> In article <9034et$tqp$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > it is generally accepted that an asymmetric 3000 bit key has a
> security
> > equivalent to that of a 128 bit symmetric key.
>
> No, it is NOT generally accepted. Why do you think it is???
>
sorry, meant to specify rsa or dh keys.
the 3k number was given by PGP's Phil Zimmermann, when the c-kt builds
began to offer the ability to make larger keys. His quote at the time
was: "There is no advantage for using the keys larger than about 3000
bits. The 128-bit session keys have the same work factor to break as a
3000 bit RSA or DH key. "
{do not have the exact reference, but the quote in its entirety is
displayed in the c-kt builds of pgp, in one of the key generation
windows }
as a practical point, this will make a difference in deciding the key
sizes when using a 256 bit symmetrical session key.
the 15k rsa estimate given is very helpful toward that end,
thanks,
vedaal
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: keysize for equivalent security for symmetric and asymmetric keys
Date: Wed, 29 Nov 2000 21:30:02 GMT
In article <903rad$it2$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <903geb$91l$[EMAIL PROTECTED]>,
> Bob Silverman <[EMAIL PROTECTED]> wrote:
> > In article <9034et$tqp$[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] wrote:
> > > it is generally accepted that an asymmetric 3000 bit key has a
> > security
> > > equivalent to that of a 128 bit symmetric key.
> >
> > No, it is NOT generally accepted. Why do you think it is???
> >
> sorry, meant to specify rsa or dh keys.
>
> the 3k number was given by PGP's Phil Zimmermann, when the c-kt builds
> began to offer the ability to make larger keys. His quote at the time
> was: "There is no advantage for using the keys larger than about 3000
> bits. The 128-bit session keys have the same work factor to break as a
> 3000 bit RSA or DH key. "
(1) Why do you accept this at face value? Phil is not an expert on
this subject.
(2) Why do you go from "Phil Zimmermann says..." to "It is generally
accepted"? On what basis do you make this extrapolation?
Phil is right when he says "same work factor", but "same work factor"
does not mean "equivalent strength".
> the 15k rsa estimate given is very helpful toward that end,
Using a 15K RSA key is worse than ridiculous. Using a 256 bit
AES key is gross overkill as well. I suggest you do the arithmetic
to see how long it will take to break a 128-bit key. You may assume
computers 1 million times faster than existing computers. You may
assume that you have a billion of them available.......
In a sense, you are trying to compare the difficulty of flying
to different galaxies. The greater Magellenic cloud is only 150,000
light years away, while M31 is 2 million light years away. Is the
latter "harder to reach"? There is no such thing as
"twice as impossible with forcastable technology".
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: keysize for equivalent security for symmetric and asymmetric keys
Date: Wed, 29 Nov 2000 21:29:57 GMT
In article <903rad$it2$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <903geb$91l$[EMAIL PROTECTED]>,
> Bob Silverman <[EMAIL PROTECTED]> wrote:
> > In article <9034et$tqp$[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] wrote:
> > > it is generally accepted that an asymmetric 3000 bit key has a
> > security
> > > equivalent to that of a 128 bit symmetric key.
> >
> > No, it is NOT generally accepted. Why do you think it is???
> >
> sorry, meant to specify rsa or dh keys.
>
> the 3k number was given by PGP's Phil Zimmermann, when the c-kt builds
> began to offer the ability to make larger keys. His quote at the time
> was: "There is no advantage for using the keys larger than about 3000
> bits. The 128-bit session keys have the same work factor to break as a
> 3000 bit RSA or DH key. "
(1) Why do you accept this at face value? Phil is not an expert on
this subject.
(2) Why do you go from "Phil Zimmermann says..." to "It is generally
accepted"? On what basis do you make this extrapolation?
Phil is right when he says "same work factor", but "same work factor"
does not mean "equivalent strength".
> the 15k rsa estimate given is very helpful toward that end,
Using a 15K RSA key is worse than ridiculous. Using a 256 bit
AES key is gross overkill as well. I suggest you do the arithmetic
to see how long it will take to break a 128-bit key. You may assume
computers 1 million times faster than existing computers. You may
assume that you have a billion of them available.......
In a sense, you are trying to compare the difficulty of flying
to different galaxies. The greater Magellenic cloud is only 150,000
light years away, while M31 is 2 million light years away. Is the
latter "harder to reach"? There is no such thing as
"twice as impossible with forcastable technology".
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: SRP - not good enough?
Date: Wed, 29 Nov 2000 21:16:34 GMT
On 29 Nov 2000 13:06:01 -0800, Paul Rubin <[EMAIL PROTECTED]>
wrote, in part:
>This sounds impossible on its face. Suppose you have the files stored
>on the host. That means you can simulate the host. Can't you then
>just run the protocol as many times as you need to, to guess the
>password?
Well, the protocol might depend on a large random number calculated at
the beginning. (You don't have access to anything in the host's memory
during the protocol.)
But I thought it was, but apparently I'm wrong, from what was said
about PAK.
So I proposed getting around the problem by 'cheating'.
Essentially: just as the user, at one end, supplies a password, one
can have a special security server - like in Kerberos - that doesn't
have other jobs running it to swipe its password file - supply to the
host computer a key associated with the user at login time.
Then you can't simulate the host, because you don't have the
information the host recieves from the security server, just as you
can't simulate the user's computer, because you don't have the
password the user types in.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Are there collisions in DES?
Date: Wed, 29 Nov 2000 22:46:42 +0100
"David C. Barber" wrote:
>
> Are there collisions in DES? What I mean by that is:
>
> 1: Can 2 different keys with the same source give the same encrypted
> result?
Could you please tell the problems, if there are indeed
some small probabilities of collisions? Thanks.
M. K. Shen
------------------------------
From: Quisquater <[EMAIL PROTECTED]>
Subject: Re: Are there collisions in DES?
Date: Wed, 29 Nov 2000 23:06:16 +0100
Yes. Please read our papers:
J.-J. Quisquater and J.-P. Delescaille: How easy is collision search?
Application to DES (Extended summary). In J.-J. Quisquater and J. Vandewalle,
eds, Advances in Cryptology -- Eurocrypt '89, vol. 434 of Lectures Notes in
Computer Science, Springer-Verlag, pp. 429-434, 1990.
J.-J. Quisquater and J.-P. Delescaille: How easy is collision search. New
results and application to DES. In G. Brassard, ed., Advances in Cryptology
-- Crypto '89, vol. 435 of Lectures Notes in Computer Science, Springer-Verlag,
pp. 408-413, 1990.
In fact, they are more results presented during some rump sessions of CRYPTO.
I hope to put it on my web pages some day.
------------------------------
** 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
******************************
