Cryptography-Digest Digest #215, Volume #13 Fri, 24 Nov 00 00:13:01 EST
Contents:
Re: Entropy paradox (Mok-Kong Shen)
On mutation of crypto algorithms (Mok-Kong Shen)
Re: Entropy paradox (Scott Craver)
Re: Legal issues for hobbiests (Bill Unruh)
Re: Entropy paradox (Bill Unruh)
Re: Entropy paradox (Bill Unruh)
Re: A Simple Voting Procedure (Stanley Chow)
Re: Algorithm and Integer representation questions... ("James")
Re: Entropy paradox ("Matt Timmermans")
[REPOST} Archives ? (Mark Harrop)
Re: Here's one for you CA types (Michael Erskine)
Re: Entropy paradox (John Savard)
Re: New Dynamic Algo + Contest + Doc (David Wagner)
Re: voting through pgp (David A Molnar)
Re: Mode of operation to maintain input size with block ciphers? (David Hopwood)
Re: DES question: Has this ever been proven before? (David Wagner)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Entropy paradox
Date: Thu, 23 Nov 2000 23:01:10 +0100
Matt Timmermans wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > Thus
> > there is no need to (and in fact we can't rigorously)
> > distinguish between 'perfectly unpredictable' vs.
> > 'sufficiently unpredictable' bits or 'provably secure' vs.
> > 'perfectly random' bits.
>
> The only way to read your original post that makes it even close to a
> "paradox" requires this distinction.
>
> Now you're arguing like this:
>
> 1) you start with m random bits;
>
> 2) you use those m random bits to create u bits that are practically
> unpredictable, with m>>u;
>
> 3) unpredictable is the same as random, for all _practical_ purposes;
>
> 4) You then cry "paradox", because randomness is at most preserved by
> deterministic systems, yet you seem to have created random bits out of thin
> air.
>
> The problem is that, while real randomness cannot be amplified created by
> deterministic systems, practical unpredictability _can_. That's why you can
> use a stream cipher for very long messages with a reasonably short key.
>
> You also have a problem with your measurements of "real entropy":
>
> > Now say u = 1000*m and we divide the u bits into 1000 portions
> > each m bits long. How much entropy is in the first portion?
> > How much is in the second etc. portion? How much is this
> > entropy inferior than m (bits)? It seems that a reasonable
> > estimate would be m/1000.
>
> It doesn't work that way. The first m bits _I_look_at_ are truly random. It
> doesn't matter which m bits these are. The remaining bits can be
> deterministically (though impractically) derived from the first ones.
>
> Think of it like forward error correction -- you have an m-symbol message,
> and you generate u "check symbols". Now throw the original m symbols away.
> The entire sequence can be recovered from any m of the check symbols. A
> good PRNG is one that makes this recovery intractable.
>
> Remember that entropy is subjective -- the amount of information carried by
> an event a is -log_2(P(a)). Where does this P() come from? It comes from
> the observer, i.e., the _receiver_ of the message.
>
> A bit is truly random if a God-like observer, who can measure the complete
> state of the universe and then perform an infinite amount of computation
> before determining P(), cannot expect to measure that bit's information
> content at less than 1 bit. True randomness cannot be amplified by
> deterministic systems.
>
> A bit is practically unpredictable if a realistic observer, from which some
> pertinent information about the state of the universe is hidden, and whose
> computational capabilities are restricted, cannot expect to measure that
> bit's information content at less than 1 bit. Practical unpredictability
> _can_ be amplified by deterministic systems.
>
> In short -- God knows what the output of your BBS generator will be, but the
> NSA does not. After receiving the first m bits from your generator, and
> assuming that He doesn't look at the seed, God will measure the entropy of
> the remainging bits as 0 bits/bit, but the NSA will measure it as 1 bit/bit.
> Encryption doesn't work against God, but it does against the NSA (hopefully
> ;-).
But entropy is defined in terms of information. Information
has sense for humans, otherwise it would not be 'information'.
So entropy in my view IS, as you said, indeed somewhat
subjective, though I am afraid there are some who would
object. Now let's assume that there is an appropriate measure
of that. As you claimed, that entropy can be amplified. But
what 'enables' that amplification? Some energy or what?
Thanks.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: On mutation of crypto algorithms
Date: Thu, 23 Nov 2000 23:16:40 +0100
I read today in a newspaper article about a new PC-virus,
probably of Polish origin, that is said to be fairly tricky
and dangerous in a Microsoft environment. This reminds me
once again the issue of whether crypto software shouldn't
be advantageously accorded so much variability that these
are able to mutate, i.e. to deviate from the standard.
A scenario that I could conceive of is that software for
standard block algorithms be accompanied with routines
to investigate the quality of their S-boxes such that
users could do some experimenting to find substitutes of
the standard ones that are almost as good and then compile
their own private versions. In the example of AES, there
is apparently ample opportunity of doing that, there being
only one single S-box in the standard version. It seems
quite likely that one could also profitably conduct some
extensive experiments of the effects of modification of
other components of its rounds. (Cf. the recent thread 'On
introducing non-interoperability'.) If there are lots of
people that are successful in finding mutants, then a
comprehensive catalogue of the relevant parameters of
these could be compiled and published so as to help users
either choosing them as such or finding their own mutants.
We know that in medicine the prevention of e.g. influenza
is very difficult because the virus can quickly mutate and
thus bypass the defense built up through immunization. (On
the other hand, smallpox, apparently failing to mutate
well, has been eradicated from the world, though two
nations still retain specimens for some not very convincing
official reasons.) In our case, it is certainly good to
have a standard algorithm that has been sufficiently long
and carefully analyzed by the acknowledged crypto gurus
and can thus be readily used where interoperability is
unconditionally necessary. But once we have fairly good
confidence in the quality of the standard algorithm, I
don't see big risks in profiting from biology through
employing some obviously very near mutants in environments
where only the two communication partners (alone) need to
have the same version of their encryption algorithm.
M. K. Shen
=================================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: [EMAIL PROTECTED] (Scott Craver)
Subject: Re: Entropy paradox
Date: 23 Nov 2000 22:04:09 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>This is a re-formulation of an issue that I questioned
>previously. Suppose one has m perfectly random bits and
>uses that in some appropriate way to get a BBS generator
>to generate u bits, with u >> m.
There are only 2^m possible values for u.
Each of these strings has probability 1/2^m
(assuming the bits of m are uniform and the BBS
function is 1-to-1), and all other values have
probability zero, so the Shannon entropy is m
bits.
Notice, BTW, that the definition of Shannon
entropy does not depend on the actual values
a random variable takes on, but merely their
probabilities. So if f() is a function that
is 1-to-1, H(X) == H(f(X)). I.e., the "names"
of the variable's outcomes don't matter.
>the u bits are provably secure.
How is a string of bits provably secure?
I suppose you mean that, given the first
u-1 bits, the next bit can not be predicted
any better than randomly, in compute time
that "reasonable."
>that way, i.e. having obtained an amount of additional
>entropy from nothing. How is this apparent paradox to be
>properly explained?
As above, the entropy is still m. Amusingly,
if you are given the first (u-m) bits, the
entropy of the remaining m bits is ... ?
Zero. Because given the first (u-m) bits,
chances are you have completely determined
the BBS generator seed. Just try all 2^m seeds
until you have the one with those (u-m) bits.
>M. K. Shen
-S
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Legal issues for hobbiests
Date: 23 Nov 2000 22:28:58 GMT
In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Mack)
writes:
]It is a complicated mess ... executables are restricted more than
]source code. Source code of publicly available algorithms is not
]restricted only new algorithms.
an algorithm can be both new, and publicly available. It is, I believe
the second which is crucial as far as export law is concerned.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Entropy paradox
Date: 23 Nov 2000 22:33:24 GMT
In <[EMAIL PROTECTED]> Mok-Kong Shen <[EMAIL PROTECTED]> writes:
]I suppose that BBS and its assumptions and proof are known.
Not to me it is not.
]I assume that you do the best so that all the entropy in
]the given m bits are incorporated into the generator. In
]other words, BBS is viewed as a black box with m bits as
]input and u bits as output. Is this concept clear? Or do
]you contend the correctness of the assumptions and/or
]the proof of BBS? Thanks.
Yes, I claim that the proof that this generator is "provably secure"
whatever that means, is either wrong or you are misinterpreting it.
Is BBS supposed to be some real existing system,a nd th proof some real
proof that I can now go and read somewhere? Where?
]M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Entropy paradox
Date: 23 Nov 2000 22:34:52 GMT
In <[EMAIL PROTECTED]> Mok-Kong Shen <[EMAIL PROTECTED]> writes:
>So if BBS generates u bits and I take m bits out of it,
>how much entropy is in there? Thanks.
Who knows. Zero? m? ...?
It depends entirely on what BBS is.
------------------------------
From: Stanley Chow <[EMAIL PROTECTED]>
Subject: Re: A Simple Voting Procedure
Date: Fri, 24 Nov 2000 00:15:39 GMT
David Schwartz wrote:
>
> Stanley Chow wrote:
>
> > Current knowledge in the public domain:
> > There is no known way to achieve (p1 & not p2). There are good
> > evidence that it is impossible, but no proof.
>
[proposed scheme snipped]
>
> Why doesn't this meet 'p1' without providing 'p2'?
You are now claiming to have an existance proof by exhibiting a
scheme with the desired properties. This is the same scheme that
you have been talking about NOT wanting people to rip apart.
What is it that you want?
(BTW, your schemes is far from providing p1 and certainly does
not prevent p2; it also does not have other necessary properties).
> If you think the scheme I suggest cannot be implemented, please suggest
> what the implementation problem is.
Most schemes can be implemented. The question is what desirable
properties are present.
--
Stanley Chow VP Engineering [EMAIL PROTECTED]
Cloakware Corp (613) 271-9446 x 223
------------------------------
From: "James" <[EMAIL PROTECTED]>
Subject: Re: Algorithm and Integer representation questions...
Date: Thu, 23 Nov 2000 20:55:03 -0500
> If you just want to use VBA to exchange secret email with a friend or
> two, I suggest using a secret-key algorithm (RC4 is probably the
> easiest to implement) and agree on a shared secret key offline with
> each friend. Don't bother with RSA which is a heck of a lot more
> complicated than RC4. You can probably modify your XOR app to use
> RC4 and the security should be reasonably good if you're careful
> about the keys.
>
> You might look at the Ciphersaber specification at
> http://ciphersaber.gurus.com since it sound like what you're
> doing is in a similar spirit.
Thanks for the link. How is RC4 security and speed in regards to Blowfish
(for which I've seen VB implementations for)?? Also, I do eventually want
to implement some sort of public key algoithms into this program... I have
seen one RSA implementation for VB (although hideously insecure... the
primes chosen were between 3 and 46340 in order that the VB Long data type
would not overflow when they were multiplied to find N). My biggest problem
is integer representation... but anyway, I was wondering what's out there
for public key cryptography besides RSA and Diffe-Helman key exchanges???
Thanks.
- James
------------------------------
From: "Matt Timmermans" <[EMAIL PROTECTED]>
Subject: Re: Entropy paradox
Date: Fri, 24 Nov 2000 02:12:52 GMT
"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> So entropy in my view IS, as you said, indeed somewhat
> subjective, though I am afraid there are some who would
> object.
Well, there are lots who would object if I said that physical entropy, i.e.,
entropy as in physics, is subjective, but I wouldn't say that here.
As long as we understand that we're talking about entropy as practical
uncertainty, I believe that all of your respondents so far would agree.
> Now let's assume that there is an appropriate measure
> of that. As you claimed, that entropy can be amplified. But
> what 'enables' that amplification? Some energy or what?
> Thanks.
One-way functions enable that amplification. I don't think that I can
visualize "one-wayness" as any sort of quantity or substance.
------------------------------
Date: Fri, 24 Nov 2000 13:36:49 +1100
From: Mark Harrop <[EMAIL PROTECTED]>
Subject: [REPOST} Archives ?
--=====================_5590178==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed
I really am desperate for this info, and am sending it again as
_noone_ answered my original request.
Hi all....
I am doing a Crypto Uni course and would like access to ALL the archives
from this group, preferably as far back as possible.
Is this possible ?
As I am accessing this group via email, I would appreciate
a reply to my email address if possible.
I really hope you can help, and thanks for your time !
Cheers!
Mark Harrop
[EMAIL PROTECTED]<mailto:>
Moderator of the following Programming Lists:
Send a empty message to:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--=====================_5590178==_.ALT
Content-Type: text/html; charset="us-ascii"
<html>
I really am desperate for this info, and am sending it again as<br>
_noone_ answered my original request.<br>
<br>
Hi all....<br>
<br>
I am doing a Crypto Uni course and would like access to ALL the
archives<br>
from this group, preferably as far back as possible.<br>
<br>
Is this possible ?<br>
<br>
As I am accessing this group via email, I would appreciate<br>
a reply to my email address if possible.<br>
<br>
I really hope you can help, and thanks for your time !<br>
<br>
<x-sigsep><p></x-sigsep>
Cheers!<br>
Mark Harrop<br>
<b>[EMAIL PROTECTED]<a href="mailto:"><br>
<br>
</a>Moderator of the following Programming Lists:<br>
<br>
Send a empty message to:<br>
<br>
[EMAIL PROTECTED]<br>
<br>
[EMAIL PROTECTED]<br>
[EMAIL PROTECTED]<br>
[EMAIL PROTECTED]<br>
[EMAIL PROTECTED]<br>
</b></html>
--=====================_5590178==_.ALT--
------------------------------
From: Michael Erskine <[EMAIL PROTECTED]>
Subject: Re: Here's one for you CA types
Date: Thu, 23 Nov 2000 21:47:13 -0500
"William A. McKee" wrote:
>
> It's not ROT13 :)
Thanks, I knew that.
--
Watch your thoughts; they become words.
Watch your words; they become actions.
Watch your actions; they become habits. -- Frank Outlaw
Watch your habits; they become character.
Watch your character; it becomes your destiny.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Entropy paradox
Date: Fri, 24 Nov 2000 02:59:42 GMT
On Thu, 23 Nov 2000 23:01:16 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote, in part:
>But we know we can't detect 'true' randomness. When one
>talks about entropy in crypto, e.g. about entropy in a
>hardware generated sequence, what does one really mean
>by that (since we don't have an exact 'base' of reference)?
We can't detect it from the sequence itself.
But the term 'entropy' still _means_ true randomness. If we don't know
whether or not a sequence is truly random, we don't know its entropy.
Terms have to have specific meanings in order to deduce true
statements from other true statements.
There are other concepts - cryptosecurity, incompressibility - that
have _some_ of the properties of true randomness, but not others.
Those are the applicable concepts when "true randomness" cannot be
determined.
If we confuse the two, then we might think we could use a fancy
algorithm for a conventional cipher that would give real security from
a password short enough to be brute-forced. That doesn't work: the
closest you can come is with algorithms like EKE, that have a
public-key component.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: New Dynamic Algo + Contest + Doc
Date: 24 Nov 2000 04:29:41 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Richard Heathfield wrote:
>I don't know why it is that people feel compelled to devise their own
>cryptographic algorithms. I have felt this compulsion myself, and still
>tinker with my own algorithm, trying to find ways to make it faster/more
>secure/easier to use...
Hey, don't knock it. Trying your hand at cipher design can be a
wonderful learning experience, and it's fun, too...
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: voting through pgp
Date: 24 Nov 2000 04:01:26 GMT
Dan Oetting <[EMAIL PROTECTED]> wrote:
> "Scott Fluhrer" wrote:
>> Actually, the idea of digital coins would seem to fill the bill nicely.
> One Dollar - One Vote! The concept sounds familiar :)
I'm sure I've seen that in a paper somewhere before...oh, wait.
Most of the talk about electronic voting I've seen so far seems to center
on the (very real) problems involved with using home PCs as a client
platform. Some secondary talk on what the requirements for a voting
scheme would be (c.f. other thread here).
What I haven't seen yet is a discussion of electronic voting with
specific reference to the problems in the Florida election.
What are the problems with the Florida election which have the U.S. tied
up in knots right now? Are there problems ones which can be addressed by
electronic voting in some form, or by using cryptographic ideas?
Following the California commission, I'm going to discount electronic
voting from home entirely. When I refer to "electronic voting," I will
mean something like an electronic voting machine connected via a network
to some tabulating agency.
Off the top of my head, the following problems (either alleged or
confirmed) with the Florida election come to mind:
* Election "results" called too early. This is a polling problem
and a news network problem, but it points the way to a potential
voting problem. If we adopt an electronic
voting system which allows for counting as the votes are cast,
we'd have to make sure that the results didn't leak until
after the close of the polls. This might be difficult.
* The infamous "butterfly ballot." This seems a user interface
issue as much as anything else. Which probably means that the
people reading sci.crypt are the last people who should be
involved. :-)
I don't see how electronic voting would be better than a well
designed ballot, unless maybe you have a computer in the voting
booth which reads the names of candidates to you.
* Ballots which are in themselves difficult or impossible to
accurately count.
- Dimpled ballots and half-punched-out chads.
- Ballots with votes for two or 0 candidates.
- Ballots with food stains (John Leo references these in
U.S. News and World Report; I don't know how many
actually exist or if he was being sarcastic)
Again this is a user interface issue, and we don't seem to
need electronic voting, strictly speaking. We can build
mechanical mechanisms which enforce only voting for one
candidate (radio buttons), do not register a vote until
all offices have a vote, etc. There's probably lots of
tricky issues involved, but I don't see that we need
electronic voting. Maybe a system in which the ballot is
marked by a mechanical mechanism and then available for
inspection by the voter before finally being deposited
would work -- but what happens when they silently
malfunction and no one notices?
* Intimidation or unreasonable requirements to vote at the
polling place. For example, there are reports that several
areas of Florida required 3 distinct forms of
state or federal photo ID to vote.
(This seems *extremely* strange to me - in Nevada we just
give a signature...I don't think I even have 3 forms of
"real" photo ID)
I don't see how electronic voting would be any better or
worse than what we have now. I don't see how electronic
voting at home would be any better or worse than absentee
ballots.
* The election was close enough to be influenced by absentee
ballots. Absentee ballots were
- later in arriving than regular votes
- open to new ballots being "found"
- potentially mailed by people not authorized to
mail them to voters
If we rule out electronic voting by home PC, I don't see
a good way to solve this with electronic voting. As for
people introducing fradulent absentee ballots, that seems
to be a problem in creating logs and cross checks.
* Recounts by machine are less reliable than recounts by
hand.
* Recounts may alter ballots, possibly by shaking out chads.
* Hand recounts are the most reliable kind of recount, but
hand recounts cannot be completed before the certification
deadline.
* Counts and recounts are inconsistent with each other, leading
to charges of fraud.
* Ballots just "show up" having been accidentally not submitted
for tabulation on Election Day.
* Ballots can be spoiled or changed during counting.
This seems the really crucial point. The suits before various
courts seem to grow out of disputes over the recounting process.
Produce a better counting and recounting, and we prevent a
second Florida.
(of course, the new system will probably fail spectacularly some
new way. generals fight the last war, Maginot line, and all that)
Electronic voting *may* be a win over paper ballots in this case,
but only if the tallying system can be constructed in such a way
that its workings are publically verifiable. This is the
"transparency" point others have made in other threads: current
paper systems allow everyone to watch the ballots being counted
*and believe that they are watching the ballots being counted.*
An ideal system would have a method of recount which is at least
as reliable as today's hand recounts. It would also have totals
consistent from count to count...
An electronic voting system with voting machines connected
directly to a tabulation center might address the "forgotten
ballots" problem. It would also raise questions about privacy
and transparency which might be addressed via cryptography.
But how to actually implement all this?
This begins to look like a software and hardware engineering
problem. Which is not encouraging.
What other problems were there in the Florida election which I'm
forgetting? and what, if anything, do electronic voting and cryptography
have to address these problems?
Thanks,
-David Molnar
------------------------------
Date: Fri, 24 Nov 2000 04:48:24 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Mode of operation to maintain input size with block ciphers?
=====BEGIN PGP SIGNED MESSAGE=====
[EMAIL PROTECTED] wrote:
> David Hopwood <[EMAIL PROTECTED]> writes:
> > [EMAIL PROTECTED] wrote:
> > > No, CTS is a variant on CBC.
> >
> > CTS can be used for either ECB or CBC mode (and almost any other
> > mode that works on blocks, such as PCBC).
>
> In a way, you're right, although it's a matter of semantics.
>
> CTS encryption is expressed especially simply in terms of CBC:
>
> Pad the last block with zeros, then encrypt the whole thing with CBC
> as usual. Swap the last two blocks, and truncate the new last one.
>
> To do CTS with ECB, you'd encrypt the message as usual, except for the
> last block, where you encrypt the XOR of the plaintext with the
> previous block's ciphertext. Then swap and truncate the last two
> ciphertext blocks.
The only references I've been able to get hold of for CTS are Applied
Cryptography and RFC 2040, both of which only define ciphertext
stealing in CBC mode. However, the additional XOR is not necessary
to make decryption work, so the most obvious way of doing ciphertext
stealing in ECB mode is:
<pre>
P_{n-1} P_n || C'
| |
v v
E_K E_K
| |
v v
C_n || C' C_{n-1}
</pre>
This is fairly academic because there are very few cases where ECB
mode can be safely used, with or without ciphertext stealing.
For PCBC mode, you *could* do this, in order to stick as closely as
possible to the definition of standard PCBC:
<pre>
P_{n-2} P_{n-1} P_n || phi
|----. |----. |
| | | trunc |
v v v v v
-->XOR XOR--->XOR XOR--->XOR
| ^ | ^ |
v | v | v
E_K | E_K | E_K
|----' |----' |
v v v
C_{n-2} C_n || C' C_{n-1}
</pre>
where length(P_n) = length(C_n) as usual, and trunc takes the first
length(P_n) bits of P_{n-1}.
I.e. in general, you can apply ciphertext stealing to any block feedback
mode as long as the feedback does not prevent recovering C'.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOh2e2zkCAxeYt5gVAQFDEAf8CGLL685IOfxtkKrOKe6KwnxiFvEBjxyp
ISzuDPhycewvtMhGidhJwQsrLCNONiGCdCpp5T7rJRNgtSoakX9GSSs5iO3NwK5I
ST2szzVEJ135DVt22z84T++XyZB+zYyi27SvugqJJnOl/gPhu8M7rF65fTNrtHLL
x09xJfSCLPT9VWddXD5S+iML67gqE7GclNMOGb7Om1I6qtKEBB7OIR32+1imh3YF
UaPFjgLMzG0Lm46K+qu451/DgCMSvFPvzmFi4pMKE0c7INcvhwVt+KdbLkbLMQyx
kebc1vIRnzjVJaOJBivTVk6tqWgiMNLcIYhGR3X1klc5O7jN9aepeQ==
=jHtD
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: DES question: Has this ever been proven before?
Date: 24 Nov 2000 04:59:21 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Francois Grieu wrote:
>[EMAIL PROTECTED] (David Wagner) wrote:
>> you could find one (solution) with 2^29 encryptions using
>> birthday paradox techniques.
>
>The idea of using the birthday "paradox" technique is right,
>but the 2^29 figure is wrong and the method not optimum.
Yes! You are absolutely right, of course.
Thank you for noticing, and for correcting my mistake.
I appreciate it.
------------------------------
** 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
******************************
