Cryptography-Digest Digest #214, Volume #13 Thu, 23 Nov 00 17:13:01 EST
Contents:
Re: Entropy paradox ("Matt Timmermans")
Isomorphic Elliptic Curves (J. Rostand)
Q: Pike stream cipher implementations/test vectors? (Roland Kaufmann)
Test, ignore. (Bud Rogers)
Re: My new book "Exploring RANDOMNESS" (Tim Tyler)
Re: Q: fast block ciphers (Tim Tyler)
Re: DES question: Has this ever been proven before? (Paul Crowley)
Algorithm and Integer representation questions... ("James")
Re: A Simple Voting Procedure (Stanley Chow)
Re: Algorithm and Integer representation questions... (Paul Rubin)
Re: A Simple Voting Procedure (David Schwartz)
Re: Entropy paradox (John Savard)
Re: Entropy paradox (John Savard)
Re: Algorithm and Integer representation questions... ("James")
Re: Algorithm and Integer representation questions... (Paul Rubin)
Re: Algorithm and Integer representation questions... (David Schwartz)
Re: My new book "Exploring RANDOMNESS" (Chris Gillespie)
Re: Algorithm and Integer representation questions... (Paul Rubin)
Re: Q: fast block ciphers (Paul Crowley)
Re: Entropy paradox (Mok-Kong Shen)
----------------------------------------------------------------------------
From: "Matt Timmermans" <[EMAIL PROTECTED]>
Subject: Re: Entropy paradox
Date: Thu, 23 Nov 2000 13:40:00 -0500
Reply-To: "Matt Timmermans" <[EMAIL PROTECTED]>
Mok-Kong Shen <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> 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
;-).
------------------------------
From: J. Rostand <[EMAIL PROTECTED]>
Subject: Isomorphic Elliptic Curves
Date: Thu, 23 Nov 2000 19:21:24 GMT
Two very simple questions:
Let E1 and E2 be two elliptic curves over a finite field K (defined as
cubic curves in the projective plane).
1) What is the definition of E1 being isomorphic to E2?
2) What is the relation between that isomorphism and the algebraic
structures of the underlying groups? For example, are the groups of E1
and E2 isomorphic if and only if E1 and E2 are isomorphic?
Thank you.
J. Rostand.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Subject: Q: Pike stream cipher implementations/test vectors?
From: Roland Kaufmann <[EMAIL PROTECTED]>
Date: Thu, 23 Nov 2000 19:49:14 GMT
Hello,
I'm looking for implementations (other than the one from the AC disks)
and/or test vectors for Ross Anderson's stream cipher Pike, but
(pointers to) descriptions (other than Ross' paper and AC) and
information on possible weaknesses would be welcome too.
TIA
Roland
------------------------------
From: Bud Rogers <[EMAIL PROTECTED]>
Subject: Test, ignore.
Date: Thu, 23 Nov 2000 13:34:46 -0600
Test, ignore.
--
Bud Rogers <[EMAIL PROTECTED]> http://www.sirinet.net/~budr/zamm.html
All things in moderation. And not too much moderation either.
------------------------------
Crossposted-To: sci.math,sci.logic
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: My new book "Exploring RANDOMNESS"
Reply-To: [EMAIL PROTECTED]
Date: Thu, 23 Nov 2000 20:04:06 GMT
In sci.crypt [EMAIL PROTECTED] wrote:
: Richard Heathfield <[EMAIL PROTECTED]> wrote:
:> Counter-examples, all of which (IMHO) are relevant to sci.crypt: >
:> "The Art of Computer Programming" - Knuth
:> "The C Programming Language" - Kernighan and Ritchie
:> "Applied Cryptography" - Schneier
:>
:> If any of these /are/ available online, I'd be astonished (and I want
:> the URL!).
: Why would that be surprising ? [...]
Because these books are copyright material, and (AKAIK) not available
free of charge over the internet.
: [...] from your list, at least AC2 and K&R do exist (.htm and .txt,
: respectively). However, for obvious reasons you will have to search a
: bit to get them.
Note that no one has managed to post URLs for the texts of any of the
books in Richard's list. What reason is there to think that searching
for them would not be a complete waste of time?
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Q: fast block ciphers
Reply-To: [EMAIL PROTECTED]
Date: Thu, 23 Nov 2000 20:12:13 GMT
Paul Crowley <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
:> : I would be interested in hearing how one would change a stream cipher
:> : into a block cipher.
:>
:> You could encrypt each block using the stream cypher (as though it was a
:> separate message).
: A block cipher is a very specific kind of cryptographic object; it's not
: just anything which encrypts blocks. If you treat your construction as
: a block cipher it will seem to be very weak.
Well yes - it will probably be what I called "of rather poor quality".
:> It would probably be best to encrypt "in both directions" - or the
:> resulting block cypher may be of rather poor quality.
: I don't understand this - could you explain?
Encrypt the block using the stream cypher. Reverse it (bitwise,
bytewise, or whatever seems most suitable given the properties of the
stream cypher), and feed it through the stream cypher again.
If you don't do something like this (and the stream cypher is not
intrinsically rather blocky) then you don't get any reverse diffusion -
flipping plaintext bits will not affect cyphertext bits earlier in the
block.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: DES question: Has this ever been proven before?
Date: Thu, 23 Nov 2000 20:21:56 GMT
Francois Grieu wrote:
> It can be modified to work (though less efficiently) with say
> 2^32 entries of 2^32 bits. I think it can be modified so that
> only a fraction of this 16GByte memory is RAM (my idea is to keep
> in RAM a list of D,X pairs in a smaller table kept sorted using
> a similar hash-coding tehcnique, then when it fills up to some
> thresold sequentialy scan array A[] on disk, in sync with this
> RAM table to perform the compare and updates). And the algorithm
> can be modified to efficiently use a bitsliced DES implementation.
Better yet, use the techniques of
Paul C. van Oorschot and Michael J. Wiener.
Parallel collision search with cryptanalytic applications.
Journal of Cryptology, 12(1):1-28, 1999.
This finds collisions in a function f() by iterating f(), hugely
reducing memory requirements. If we can avoid using the disk
altogether, it should be much faster.
David Wagner, ISTR you demonstrated this by finding collisions in the
Unix password hashing function. Do you still have source for that, and
is it available online?
cheers,
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: "James" <[EMAIL PROTECTED]>
Subject: Algorithm and Integer representation questions...
Date: Thu, 23 Nov 2000 15:48:01 -0500
I'm thinking about writing a VBA module for outlook that will do reasonably
secure public key encryption. I'm trying to decide on the algorithms to
use. I require that they be free for non-comercial use and would prefer
strong, time tested algorithms. I wondered if there were any suggestions??
I was thinking of using RSA for the public key transfer and Blowfish for the
stream cipher. Any input would be appreciated.
This also brings up another problem. (Maybe a bit OT...) does anyone out
there know methods for representing large integers (the kind needed for RSA)
in any kind of a BASIC language, or could someone point me towards a C or
C++ reference??? Thanks.
- James
------------------------------
From: Stanley Chow <[EMAIL PROTECTED]>
Subject: Re: A Simple Voting Procedure
Date: Thu, 23 Nov 2000 20:52:28 GMT
I am going to make one more try at this.
David Schwartz wrote:
>
> Stanley Chow wrote:
>
> > Incorrect. It would be a poor design IFF the assumptions were
> > indeed incorrect. Since most people think this particular
> > assumption is correct, the design is not poor. One can only
> > build what one knows how to build; not what one wants.
>
> Even if it doesn't result in a poor implementation, the requirements
> are still worse than they would be if they didn't include the
> assumption. This holds even if the assumption is correct. The
> requirements really should include what people actually want out of the
> system and should not include conclusions about what's possible and what
> isn't.
Properties under discussion:
p1) voter can prove, by himself alone, at his sole option, that
his vote is or is not correctly counted
p2) voter can be forced to reveal his vote against his will
Desirability:
The consensus is that p1 is desirable but p2 is not.
Theoretical possiblity:
There is no known proof whether (p1 & not p2) is possible.
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.
Current knowledge in the private/classified domain:
I have not been shot, so I don't know. May be someone in the
NSA knows how. May be you are a nice alien trying to nudge us
further in our technology and/or civilization.
> I'm not saying anything. Really. I just want to know what the
> requirements are, but I want an unbiased view of the requirements. I
> don't want the requirements tainted by what someone thinks is possible
> or not. If it's preferable for a system to have A and to have B but
> mandatory that it not have C, I want the requirements to say that. I
> don't want the requirements to leave out desirable properties A and B
> just because someone thinks that that requires undesirable property C.
> Just state that A is good, B is good, and C is very bad.
What is the point of specifying a Dream System if no one knows how to
build one?
--
Stanley Chow VP Engineering [EMAIL PROTECTED]
Cloakware Corp (613) 271-9446 x 223
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Algorithm and Integer representation questions...
Date: 23 Nov 2000 12:54:38 -0800
"James" <[EMAIL PROTECTED]> writes:
> I'm thinking about writing a VBA module for outlook that will do reasonably
> secure public key encryption. I'm trying to decide on the algorithms to
> use. I require that they be free for non-comercial use and would prefer
> strong, time tested algorithms. I wondered if there were any suggestions??
> I was thinking of using RSA for the public key transfer and Blowfish for the
> stream cipher. Any input would be appreciated.
There are already several PGP plug-in for Outlook. I've heard of some
free ones and of course there's always the commercial one.
> This also brings up another problem. (Maybe a bit OT...) does anyone out
> there know methods for representing large integers (the kind needed for RSA)
> in any kind of a BASIC language, or could someone point me towards a C or
> C++ reference??? Thanks.
Implementing RSA in VB would be hopelessly slow, I'd expect.
For a C/C++ library, try GNU MP, which you should be able to find
through www.gnu.org.
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: A Simple Voting Procedure
Date: Thu, 23 Nov 2000 13:00:33 -0800
Stanley Chow wrote:
> Properties under discussion:
> p1) voter can prove, by himself alone, at his sole option, that
> his vote is or is not correctly counted
> p2) voter can be forced to reveal his vote against his will
>
> Desirability:
> The consensus is that p1 is desirable but p2 is not.
>
> Theoretical possiblity:
> There is no known proof whether (p1 & not p2) is possible.
>
> 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.
The voter is displayed a GUID before he or she votes which he may or
may not write down. He then casts his vote. Immediately after the
election, all the GUIDs are released along with which way they voted. At
the same time the voter votes, he is shown one GUID (that is not his)
that was cast (by someone else) for each other candidate, which he may
or may not write down.
Why doesn't this meet 'p1' without providing 'p2'?
1) Nobody can establish how the voter voted. This is so because there
is no way to compel a person to release his or her own GUID that doesn't
permit him to release one of the other GUIDs he has been shown that
result in thinking he voted some other way.
2) A voter can confirm how he voted. He was shown his GUID before he
cast his vote, so he knows it was his will which determined what that
GUID was paired to. That GUID either is or is not counted under the
candidate the voter chose. The voter can establish this because the list
of GUIDs (and how they voted) is released after the election.
If you think the scheme I suggest cannot be implemented, please suggest
what the implementation problem is.
DS
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Entropy paradox
Date: Thu, 23 Nov 2000 21:07:53 GMT
On Thu, 23 Nov 2000 11:47:19 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote, in part:
>There is no practical way of determining whether a source
>delivers absolutely perfect random bits (though we assume
>m bits for putting up the issue). This means that, if a bit
>sequence is such that no one (including the current mightiest
>opponent) can do prediction, then we can consider that it
>has full entropy.
No.
"...anyone who considers arithmetical means of producing random digits
is, of course, in a state of sin. For, as has been pointed out several
times, there is no such thing as a random number - there are only
methods to produce random numbers, and a strict arithmetic procedure
is of course not such a method."
-- John von Neumann, in the paper "Various Techniques used in
Connection with Random Digits", from "Monte Carlo Method", number 12
in the Applied Mathematics Series published by the National Bureau of
Standards.
True randomness is what entropy refers to; incompressibility,
cryptosecurity, and the like are a distinct concept, another tier
down. Getting the two mixed up causes confusion, hence your 'paradox'.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Entropy paradox
Date: Thu, 23 Nov 2000 21:01:24 GMT
On Wed, 22 Nov 2000 18:38:26 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote, in part:
>If the u bits are very secure, what would the same number
>u of perfectly random bits (we suppose that these are
>obtainable) distinguish themselves from these? They
>are totally equivalent for the practice, aren't they?
Only if a brute-force search over the 2^m possibilities for the m bits
they came from is absolutely impossible.
They're equivalent *for some purposes*.
But while, when m is large enough, you can't work backwards from the u
bits to the m bits in practice, you can always work forwards from the
m bits to the u bits in practice. That's the distinction between the u
bits from the BBS generator, and u perfectly random bits.
So there is no distinction in cryptosecurity, but there IS a
distinction in entropy. Hence, no paradox.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "James" <[EMAIL PROTECTED]>
Subject: Re: Algorithm and Integer representation questions...
Date: Thu, 23 Nov 2000 16:23:34 -0500
Paul Rubin <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "James" <[EMAIL PROTECTED]> writes:
> > I'm thinking about writing a VBA module for outlook that will do
reasonably
> > secure public key encryption. I'm trying to decide on the algorithms to
> > use. I require that they be free for non-comercial use and would prefer
> > strong, time tested algorithms. I wondered if there were any
suggestions??
> > I was thinking of using RSA for the public key transfer and Blowfish for
the
> > stream cipher. Any input would be appreciated.
>
> There are already several PGP plug-in for Outlook. I've heard of some
> free ones and of course there's always the commercial one.
>
> > This also brings up another problem. (Maybe a bit OT...) does anyone
out
> > there know methods for representing large integers (the kind needed for
RSA)
> > in any kind of a BASIC language, or could someone point me towards a C
or
> > C++ reference??? Thanks.
>
> Implementing RSA in VB would be hopelessly slow, I'd expect.
> For a C/C++ library, try GNU MP, which you should be able to find
> through www.gnu.org.
I'm aware of all the downsides of using VBA.... My problem is that the
environment the program is being developed for is extremely restrictive with
system audits hourly. No new software can move onto these PCs. The only
way customization and new functionality can be achieved is through the use
of VBA applications for various "host" applications (like outlook). I've
already implented a simple XORing VBA app for outlook, but I realize that
the encryption could be cracked in a afternoon. GNU MP??? I'll take a
look. Thanks!!
- James
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Algorithm and Integer representation questions...
Date: 23 Nov 2000 13:33:50 -0800
"James" <[EMAIL PROTECTED]> writes:
> I'm aware of all the downsides of using VBA.... My problem is that the
> environment the program is being developed for is extremely restrictive with
> system audits hourly. No new software can move onto these PCs. The only
> way customization and new functionality can be achieved is through the use
> of VBA applications for various "host" applications (like outlook). I've
> already implented a simple XORing VBA app for outlook, but I realize that
> the encryption could be cracked in a afternoon. GNU MP??? I'll take a
> look. Thanks!!
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.
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Algorithm and Integer representation questions...
Date: Thu, 23 Nov 2000 13:36:21 -0800
Paul Rubin wrote:
> 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.
I think RC4 is not safe if you reuse the same key. You might still be
sufficiently safe if you use a series of related keys (for example, a
single key you both agree on, 'mixed' with a string you put in the
subject of the message).
DS
------------------------------
Date: Thu, 23 Nov 2000 21:50:38 +0000
From: Chris Gillespie <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.logic
Subject: Re: My new book "Exploring RANDOMNESS"
Um, is it just me or is that a published version of a Masters/PhD
thesis? The section headings look very much like it. Looks very deep but
not very wide. i.e interesting to those people who know a lot about your
area but not to the decently educated cryto interested man on the
street.
Chris.
[EMAIL PROTECTED] wrote:
> Hi, in December Springer-Verlag London will publish
> my new book "Exploring RANDOMNESS" and it will be
> available first in the UK and three months later
> world wide. Amazon.co.uk is already accepting orders.
> For more information, including the cover of the book,
> its table of contents, and the software for the book,
> see http://www.cs.umaine.edu/~chaitin/ait
> http://www.cs.auckland.ac.nz/CDMTCS/chaitin/ait
> Regards,
> Greg Chaitin
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Algorithm and Integer representation questions...
Date: 23 Nov 2000 13:51:56 -0800
David Schwartz <[EMAIL PROTECTED]> writes:
> I think RC4 is not safe if you reuse the same key. You might still be
> sufficiently safe if you use a series of related keys (for example, a
> single key you both agree on, 'mixed' with a string you put in the
> subject of the message).
Yes, the ciphersaber doc that I posted the link to explains this.
You should never re-use the key for any stream cipher.
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Q: fast block ciphers
Date: Thu, 23 Nov 2000 21:58:47 GMT
Tim Tyler wrote:
> Encrypt the block using the stream cypher. Reverse it (bitwise,
> bytewise, or whatever seems most suitable given the properties of the
> stream cypher), and feed it through the stream cypher again.
>
> If you don't do something like this (and the stream cypher is not
> intrinsically rather blocky) then you don't get any reverse diffusion -
> flipping plaintext bits will not affect cyphertext bits earlier in the
> block.
Many stream ciphers provide no diffusion anyway. Even for those that do
(eg CBC mode), this method is inadequate, for two reasons. The first
reason is to do with internal collisions, and is outlined in my paper on
my "Mercy" large block cipher
(http://www.cluefactory.org.uk/paul/mercy/). The second is CBC specific
and was explained to me in an email from David Wagner in February of
last year: it shows that this method produces insufficient diffusion in
the decryption direction:
> For N blocks, the last two look like this:
>
> L R
> | |
> -->XOR |
> | |
> [DES] | (encryption with K1)
> +---->XOR
> | [DES] (encryption with K1)
> | |
> | [DES] (decryption with K2)
> XOR<----+
> [DES] | (decryption with K2)
> | |
> ---+ |
> | |
> X Y
>
> Feed in ciphertexts (X,Y), (X',Y), (X,Y'), and (X',Y'); the
> right hand sides of the four resulting plaintexts should
> xor to zero, no?
> (This is because R = DES(DES(Y)) XOR DES(X) XOR Y.)
There are a host of other problems with this method. Don't use it; use
one of the constructions referenced in the Mercy bibliography instead.
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Entropy paradox
Date: Thu, 23 Nov 2000 23:01:16 +0100
John Savard wrote:
>
> Mok-Kong Shen<[EMAIL PROTECTED]> wrote:
>
> >There is no practical way of determining whether a source
> >delivers absolutely perfect random bits (though we assume
> >m bits for putting up the issue). This means that, if a bit
> >sequence is such that no one (including the current mightiest
> >opponent) can do prediction, then we can consider that it
> >has full entropy.
>
> No.
>
> "...anyone who considers arithmetical means of producing random digits
> is, of course, in a state of sin. For, as has been pointed out several
> times, there is no such thing as a random number - there are only
> methods to produce random numbers, and a strict arithmetic procedure
> is of course not such a method."
>
> -- John von Neumann, in the paper "Various Techniques used in
> Connection with Random Digits", from "Monte Carlo Method", number 12
> in the Applied Mathematics Series published by the National Bureau of
> Standards.
>
> True randomness is what entropy refers to; incompressibility,
> cryptosecurity, and the like are a distinct concept, another tier
> down. Getting the two mixed up causes confusion, hence your 'paradox'.
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)?
See also my response to Matt Timmermans, where
subjectiveness is mentioned. Thanks.
M. K. Shen
------------------------------
** 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
******************************
