-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>
> Yes there are. Clock jitter (and absolute clock rate, measured at
> sufficient accuracy) derives from thermal sources and is essentially
> truly random. You can actually see the clock speed up and slow down
> based on the temperature of the syst
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> "Scott G. Miller" wrote:
> > No, not that SHA is leaking information, but that an adversary, knowing
> > the output of the hash (which is present in the data generated) and the
> > input to the hash function (which can be guessed) can calculate the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> "Scott G. Miller" wrote:
> > If you run out of entropy, then there is (at least in theory) a
> > possibility that if an attacker knows the previous output (say from a
> > random number recently generated) than he can might find correlation
> > effec
"Scott G. Miller" wrote:
> Thats the thing. A computer is by definition a deterministic
> machine. There aren't any truely random sources.
Yes there are. Clock jitter (and absolute clock rate, measured at
sufficient accuracy) derives from thermal sources and is essentially
truly random. You ca
> We should take advantage of this relaxation. Only by using their rights
> can citizens retain them. I would hate to see us segregating crypto
> based on legal regulations that are no longer relevant.
Hear! Hear! Of course, I would have said the same thing before the
relaxation, too: one has t
"Scott G. Miller" wrote:
> No, not that SHA is leaking information, but that an adversary, knowing
> the output of the hash (which is present in the data generated) and the
> input to the hash function (which can be guessed) can calculate the next
> state.
The input can't be guessed. It comes fro
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>
> Perhaps someone on this list with more knowledge of cryptography can
> explain why using SHA by itself is not sufficient.
If you run out of entropy, then there is (at least in theory) a
possibility that if an attacker knows the previous output (s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> for crypto.
>
> Why does Yarrow require a block cyper, as opposed to a digest, anyway?
> The /dev/random code in the Linux kernel uses SHA-1, not a block cypher.
Its in the paper... Yarrow uses both a hash function (SHA1) and a block
cipher (3DES
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Can we keep our Crypto branch of the CVS tree out of the US? And avoid
> incredibly lame and paranoid crypto laws? (Yes, i'm an american. bleah.)
So am I. It seems reasonable that one can implement all of Yarrow and
just leave out the hook to the b
On Mon, Apr 17, 2000 at 06:21:15PM -0700, Jeffrey B. Siegal wrote:
> "Scott G. Miller" wrote:
> > Can someone verse me on the current crypto laws regarding putting
> > such code (Probably blow or two-fish) into CVS?
>
> There is a requirements that you notify the US Gov (and provide a URL)
Can we
> The comments in the Linux kernel claim that SHA does not leak
> information. Are you saying that it does, or that it could? The two
> are not the same thing at all. A block cypher could leak information
> (i.e. be flawed), in theory.
The original version of Yarrow did use a hash function rath
As a US resident, I am very happy that the government has relaxed the
rules for crypto export. All that is necessary is to send a single email
to the proper government address informing them that crypto export is
going on from the given address (the sourceforge server). I don't have
the address h
"Scott G. Miller" wrote:
> If you run out of entropy, then there is (at least in theory) a
> possibility that if an attacker knows the previous output (say from a
> random number recently generated) than he can might find correlation
> effects that make further states more guessable. For the curre
The Linux /dev/random driver says:
--->
* Sources of randomness from the environment include inter-keyboard
* timings, inter-interrupt timings from some interrupts, and other
* events which are both (a) non-deterministic and (b) hard for an
* outside observer to measure. Randomness from these
"Scott G. Miller" wrote:
> > Can we keep our Crypto branch of the CVS tree out of the US? And avoid
> > incredibly lame and paranoid crypto laws? (Yes, i'm an american. bleah.)
> So am I. It seems reasonable that one can implement all of Yarrow and
> just leave out the hook to the block cipher. S
awlydick wrote:
> Can we keep our Crypto branch of the CVS tree out of the US?
That would be ok as long as US persons never contribute to it (which
includes providing assistance as well as code). In that case, the
crypto support should be broken out onto a separate project, hosted
outside the US,
"Scott G. Miller" wrote:
> Can someone verse me on the current crypto laws regarding putting
> such code (Probably blow or two-fish) into CVS?
There is a requirements that you notify the US Gov (and provide a URL)
when you post the source code. You can notify by email, I think. I'm
not sure what
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I might take to implementing Yarrow in Java and bootstrapping it into the
RandomSource structure sometime soon, but it requires the use of a block
cipher. Can someone verse me on the current crypto laws regarding putting
such code (Probably blow or tw
18 matches
Mail list logo
