We've been recently working on what seems like a neat new clock
synchronization protocol, which will hopefully offer proactive security
(recovery from penetrations, see http://www.hrl.il.ibm.com/proactive).
Surprisingly, it also appears a very practical protocol. It has been some
time since I
Sorry folks, but I can't understand where the problem is supposed to be. The
entropy of a pool is a measure of the information about its internal state
that we don't know: which is why in thermodynamics the same name is given to
the logarithm of the number of (invisible) microstates
On Sun, Jul 18, 1999 at 06:09:15PM -0400, Donald E. Eastlake 3rd wrote:
RFC 1750 recommends the Blum Blum Shub generator.
Which is pretty slow- on the order of an RSA public key operation.
A hardware RNG would be the best solution. It won't help the
original poster now, but I think that
David Honig wrote:
Ben suggests using "hashcash" to prevent malicious depletion of the entropy
pool,
where the "hashcash" (hashes that are expensive to compute but cheap to
verify)
becomes the limiting resource instead of the server's MIPS.
This prevents DoS attacks but doesn't solve
bram wrote:
On Mon, 19 Jul 1999, Enzo Michelangeli wrote:
Sorry folks, but I can't understand where the problem is supposed to be. The
entropy of a pool is a measure of the information about its internal state
that we don't know: which is why in thermodynamics the same name is given to
Enzo Michelangeli wrote:
Sorry folks, but I can't understand where the problem is supposed to be. The
entropy of a pool is a measure of the information about its internal state
that we don't know: which is why in thermodynamics the same name is given to
the logarithm of the number of
On Mon, 19 Jul 1999, Ben Laurie wrote:
The brief summary of the above is that it's possible to simply replace
/dev/random with something which doesn't deplete entropy and the problem
will go away. And yes, it is possible to do that in a secure manner.
So what you are saying is that
Hi Folks,
When implementing PGP base encryption, is this implementation MUST use
symetrically Algorithms ?? Is it possible to use only the public/private
key ? I would like more explanation about that! :o)
Best regards,
Hans...
--- begin forwarded text
Date: Mon, 19 Jul 1999 10:51:32 -0400
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
From: Robert Hettinga [EMAIL PROTECTED]
Subject: DCSB: Ari Juels; Outsourcing MicroMint Coins, and X-Cash for
Contingent Financial Instruments
Cc: Ari Juels [EMAIL PROTECTED]
Sender:
Sandy Harris [EMAIL PROTECTED] writes:
/dev/random uses SHA or MD5, so a complete break appears highly unlikely.
But a special-case break, say in circumstances where the input entropy is
temporarily exhausted so the attacker gets a look at N successive results
where the pool does not change,
Bram, the *nix /dev/random code *does* accumulate a pool of 'physical'
(interrupt, interrupt timing) entropy and stirs and extracts bits
via a crypto
secure hash (e.g., MD5 in FreeBSD). And you can easily expand this
pool by modifying the code. But the pool is always finite; therefore
At 03:46 AM 7/19/99 -0400, Enzo Michelangeli wrote:
Sorry folks, but I can't understand where the problem is supposed to be. The
entropy of a pool is a measure of the information about its internal state
that we don't know: which is why in thermodynamics the same name is given to
the logarithm
12 matches
Mail list logo
