On Sun, Jul 30, 2000 at 01:25:18AM -0400, Jeroen C. van Gelderen wrote:
>Hmm, maybe the complainers should provide proof that they do
>need more than 2^256 complexity. Makes it easier for us,
>proponents ;-/
How about creating one-time pads?
That said, in Applied Cryptography, Schneier makes th
Mark Murray wrote:
>
> > Mark already stated that in *practicality*, Yarrow-BF-cbc-256 1.0
> > (I guess that's the proper name for this :-) is complex enough and
> > generates good enough ouput. If you /really/ want to make the attack
> > on it much harder, how about this: if you're going to rea
> On Sun, 30 Jul 2000, Mark Murray wrote:
>
> > This is a reversion to the count-entropy-and-block model which I have
> > been fiercely resisting (and which argument I thought I had sucessfully
> > defended).
>
> Actually, I was waiting for your reply to Jeroen's question about changing
> the se
On Sun, 30 Jul 2000, Mark Murray wrote:
> This is a reversion to the count-entropy-and-block model which I have
> been fiercely resisting (and which argument I thought I had sucessfully
> defended).
Actually, I was waiting for your reply to Jeroen's question about changing
the semantics of the r
> > EG, by having it such that Yarrow state perturbations happen often
> > enough that each read is "guaranteed" to be associated with at least
> > one and preferably more.
>
> Can you give me an idea how this would work, at least with e.g.
> pseudocode annotation of the current code? I'm curiou
On Sun, 30 Jul 2000, Mark Murray wrote:
> > How does entropy gathering at a high enough rate solve this
> > particularly?
>
> EG, by having it such that Yarrow state perturbations happen often
> enough that each read is "guaranteed" to be associated with at least
> one and preferably more.
Can
> How does entropy gathering at a high enough rate solve this
> particularly?
EG, by having it such that Yarrow state perturbations happen often
enough that each read is "guaranteed" to be associated with at least
one and preferably more.
M
--
Mark Murray
Join the anti-SPAM movement: http://www.
> > Do not commit anything to the /dev/random device, please, without running
> > it by me.
>
> I was not planning on it. You really should take a look at the bugfixes,
> though; reading buffer sizes of >8 bytes but not-8-byte-multiple should
> do it. There's also the ioctl handler which you ne
On Sun, 30 Jul 2000, Mark Murray wrote:
> This is a reversion to the count-entropy-and-block model which I have
> been fiercely resisting (and which argument I thought I had sucessfully
> defended).
>
> My solution is to get the entropy gathering at a high enough rate that
> this is not necessar
On Sun, 30 Jul 2000, Mark Murray wrote:
> > Content-Disposition: attachment; filename="yarrow_blocking.patch"
>
> Brian:
>
> I want to take a different approach to this one.
>
> Do not commit anything to the /dev/random device, please, without running
> it by me.
I was not planning on it. Yo
> Content-Disposition: attachment; filename="yarrow_blocking.patch"
Brian:
I want to take a different approach to this one.
Do not commit anything to the /dev/random device, please, without running
it by me.
M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org
To Unsubscribe: s
> Mark already stated that in *practicality*, Yarrow-BF-cbc-256 1.0
> (I guess that's the proper name for this :-) is complex enough and
> generates good enough ouput. If you /really/ want to make the attack
> on it much harder, how about this: if you're going to read 1024 bits
> of entropy from
Brian Fundakowski Feldman wrote:
>
> On Mon, 24 Jul 2000, Jeroen C. van Gelderen wrote:
>
> > > > What I meant with that point is that the user may get, say an extra few
> > > > hundred bits out of it with no new entropy before the scheduled reseed
> > > > task kicks in.
> > >
> > > How does he
On Mon, 24 Jul 2000, Jeroen C. van Gelderen wrote:
> > > What I meant with that point is that the user may get, say an extra few
> > > hundred bits out of it with no new entropy before the scheduled reseed
> > > task kicks in.
> >
> > How does he know which bits are which? His analysis task just
On Wed, 26 Jul 2000, void wrote:
> How does OpenBSD handle this issue? Anyone know?
It looks like they have four different kernel-exported random-number
generators:
#define RND_RND 0 /* real randomness like nuclear chips */
#define RND_SRND1 /* strong random source
How does OpenBSD handle this issue? Anyone know?
--
Ben
220 go.ahead.make.my.day ESMTP Postfix
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Mark Murray wrote:
[...]
> > > Asynchonous reseeding _improves_ the situation; the attacker cannot force
> > > it to any degree of accuracy, and if he has the odds stacked heavily against
> > > him that each 256-bits of output will have an associated reseed, it makes
> > > his job pretty damn diff
On Mon, 24 Jul 2000, Jeroen C. van Gelderen wrote:
> 1. The overhead will probably be insignificant. One doesn't
>use such vast amounts of random numbers.
True, but the effect on slow CPUs for a single read may be signfificant.
We'll have to see.
> 2. At least the generator gate can be opti
Kris Kennaway wrote:
>
> On Sun, 23 Jul 2000, Jeroen C. van Gelderen wrote:
>
> > > Well, a simple scheme which doesn't seem to suffer from any of the
> > > vulnerabilities discussed in the schneier papers is to accumulate entropy
> > > in a pool, and only return output when the pool is full. i.
On Sun, Jul 23, 2000 at 03:06:34PM +0200, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Stefan `Sec` Zehl writes:
> >With the current approach it has a 256bits key. This is, in my eyes, not
> >good. Although yarrow is nice, It's suited for any kind of key
> >generation.
>
> The first
> http://www.counterpane.com/pseudorandom_number.html
>
> Cryptlib is described here:
>
> http://www.cs.auckland.ac.nz/~pgut001/cryptlib/
Thanks!
> > Asynchonous reseeding _improves_ the situation; the attacker cannot force
> > it to any degree of accuracy, and if he has the odds stacked heavi
On Sun, 23 Jul 2000, Jeroen C. van Gelderen wrote:
> > Well, a simple scheme which doesn't seem to suffer from any of the
> > vulnerabilities discussed in the schneier papers is to accumulate entropy
> > in a pool, and only return output when the pool is full. i.e. the PRNG
> > would either block
On Sun, 23 Jul 2000, Mark Murray wrote:
> > There are two other models which rate "pretty well-designed" in the Yarrow
> > paper: the cryptlib and PGP PRNGs. I don't know what their properties are
> > right now (the cryptlib one is described in the paper on PRNG
> > cryptanalysis).
>
> Do you ha
> 5. Yarrow was designed as a better replacement for most any
>PRNG by a couple of bright cryptographers. Can you do
>better than that?
Nope, I agree. Ignore my previous objections.
DS
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" i
Kris Kennaway wrote:
>
> On Sun, 23 Jul 2000, Mark Murray wrote:
>
> > > > > This design tradeoff is discussed in section 4.1 of the paper.
> > > >
> > > > Tweakable.
> > >
> > > Doing a reseed operation with every output is going to be *very*
> > > computationally expensive.
> >
> > Tradeoff. W
David Schwartz wrote:
>
> > > /dev/random should block if the system does not contain as much
> > real entropy
> > > as the reader desires. Otherwise, the PRNG implementation will be the
> > > weakest link for people who have deliberately selected higher levels of
> > > protection from cryptograp
In message <[EMAIL PROTECTED]>, Stefan `Sec` Zehl writes:
>Assume I want to encrypt a message by XOR'ing with randomness.
>
>If I then exchange my keys securely, the message is uncrackable.
>
>With the current approach it has a 256bits key. This is, in my eyes, not
>good. Although yarrow is nice,
Poul-Henning Kamp <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]>, Kri
> s Kennaway writes:
> >On Sun, 23 Jul 2000, Poul-Henning Kamp wrote:
> >
> >> Obviously, if you need more randomness than a stock FreeBSD system
> >> can provide you with, you add hardware to give you more randomn
> > The acknowlegment that I am looking for is that the old, simple "gather
> > entropy, stir with hash, serve" model is inadequate IMO, and I have not
> > seen any alternatives.
>
> There are two other models which rate "pretty well-designed" in the Yarrow
> paper: the cryptlib and PGP PRNGs. I
On Sun, 23 Jul 2000, Mark Murray wrote:
> > > > This design tradeoff is discussed in section 4.1 of the paper.
> > >
> > > Tweakable.
> >
> > Doing a reseed operation with every output is going to be *very*
> > computationally expensive.
>
> Tradeoff. What do you want? Lightning fast? Excessive
> On Sun, 23 Jul 2000, Mark Murray wrote:
>
> > Erm, read 4.1 again :-). The paragraph that begins "One approach..." is
> > the old approach. It is also the approach that you are advocating.
> >
> > The next paragraph "Yarrow takes..." is Yarrow, and the current
> > implementation.
>
> "The str
> > > This design tradeoff is discussed in section 4.1 of the paper.
> >
> > Tweakable.
>
> Doing a reseed operation with every output is going to be *very*
> computationally expensive.
Tradeoff. What do you want? Lightning fast? Excessive security? Balance
it out.
> > > Well, I don't see a way
> On Sun, 23 Jul 2000, Poul-Henning Kamp wrote:
>
> > Obviously, if you need more randomness than a stock FreeBSD system
> > can provide you with, you add hardware to give you more randomness.
>
> This won't help if it's fed through Yarrow.
*BTTT!* Wrong. A good hardware RNG when fed at a h
> > > Obviously, if you need more randomness than a stock FreeBSD system
> > > can provide you with, you add hardware to give you more randomness.
> >
> > This won't help if it's fed through Yarrow.
>
> *BTTT!* Wrong. A good hardware RNG when fed at a high-enough rate
> through Yarrow can ea
In message <[EMAIL PROTECTED]>, Kri
s Kennaway writes:
>On Sun, 23 Jul 2000, Poul-Henning Kamp wrote:
>
>> Obviously, if you need more randomness than a stock FreeBSD system
>> can provide you with, you add hardware to give you more randomness.
>
>This won't help if it's fed through Yarrow.
Nobod
On Sun, 23 Jul 2000, Mark Murray wrote:
> Erm, read 4.1 again :-). The paragraph that begins "One approach..." is
> the old approach. It is also the approach that you are advocating.
>
> The next paragraph "Yarrow takes..." is Yarrow, and the current
> implementation.
"The strength of the first
On Sun, 23 Jul 2000, Poul-Henning Kamp wrote:
> Obviously, if you need more randomness than a stock FreeBSD system
> can provide you with, you add hardware to give you more randomness.
This won't help if it's fed through Yarrow.
> In other words, and more bluntly: Please shut up now, will you
> This is basically the model I am advocating for /dev/random. It's also the
> alternative "basic design philosophy" described in the yarrow paper.
Erm, read 4.1 again :-). The paragraph that begins "One approach..." is
the old approach. It is also the approach that you are advocating.
The next
In message <[EMAIL PROTECTED]>, Kri
s Kennaway writes:
>On Sat, 22 Jul 2000, Jeroen C. van Gelderen wrote:
>
>> I agree that you need long RSA keys ... but the real
>> discussion isn't really about key length but rather about
>> the overall complexity of attacking the key:
>
>Okay, using RSA key
On Sun, 23 Jul 2000, Mark Murray wrote:
> > Okay, using RSA keys wasn't the best example to pick, but Yarrow also
> > seems easy to misuse in other cases: for example if you want to generate
> > multiple 256-bit symmetric keys (or other random data) at the same time,
> > each additional key after
On Sun, 23 Jul 2000, Mark Murray wrote:
> By your own admission, the old system was bad; yet you still want
> ${it}? You'd like to see a programmer with less experience than
> Schneier come up with a more secure algorithm than him?
The old implementation was bad. The class of algorithm is not, a
On Sun, 23 Jul 2000, Mark Murray wrote:
> Your are missing the point that it is not possible to get more than
> the ${number-of-bits-ofrandomness} from any accumulator or PRNG. You
> have to draw the line somewhere; The current implementation has it
> at 256.
Uhh..a PRNG which hashes entropy sam
> Okay, using RSA keys wasn't the best example to pick, but Yarrow also
> seems easy to misuse in other cases: for example if you want to generate
> multiple 256-bit symmetric keys (or other random data) at the same time,
> each additional key after the first won't contain any additional entropy,
> The core of my complaint is that even though our old PRNG did crappy
> entropy handling, we used to have such a method, which is now gone. I'd
> like to see yarrow hang off /dev/urandom and have /dev/random tap directly
> into the entropy pool (perhaps a third pool separate from Yarrow's
> fast/
> The core of my complaint is that even though our old PRNG did crappy
> entropy handling, we used to have such a method, which is now gone. I'd
> like to see yarrow hang off /dev/urandom and have /dev/random tap directly
> into the entropy pool (perhaps a third pool separate from Yarrow's
> fast/
> On Sat, 22 Jul 2000, Mark Murray wrote:
>
> > > So what it if I want/need 257 bits? :-)
> >
> > Read them. You'll get them. If you want higher quality randomness than
> > Yarrow gives, read more than once. Do other stuff; play. Don't get stuck
> > in the "I have exhausted the randomness pool"
> > /dev/random should block if the system does not contain as much
> real entropy
> > as the reader desires. Otherwise, the PRNG implementation will be the
> > weakest link for people who have deliberately selected higher levels of
> > protection from cryptographic attack.
> I don't want to reh
On Sat, 22 Jul 2000, Jeroen C. van Gelderen wrote:
> I agree that you need long RSA keys ... but the real
> discussion isn't really about key length but rather about
> the overall complexity of attacking the key:
Okay, using RSA keys wasn't the best example to pick, but Yarrow also
seems easy
Kris Kennaway wrote:
>
> On Sat, 22 Jul 2000, Jeroen C. van Gelderen wrote:
>
> > You don't care in practice, 256 bits are unguessable.
>
> Actually, I do..that's the entire point of using long keys.
I agree that you need long RSA keys ... but the real
discussion isn't really about key length
On Sat, 22 Jul 2000, Jeroen C. van Gelderen wrote:
> You don't care in practice, 256 bits are unguessable.
Actually, I do..that's the entire point of using long keys.
> If you do care, you load a different random module :-)
The core of my complaint is that even though our old PRNG did crappy
e
On Sat, 22 Jul 2000, Mark Murray wrote:
> > So what it if I want/need 257 bits? :-)
>
> Read them. You'll get them. If you want higher quality randomness than
> Yarrow gives, read more than once. Do other stuff; play. Don't get stuck
> in the "I have exhausted the randomness pool" loop; Yarrow d
> /dev/random should block if the system does not contain as much real entropy
> as the reader desires. Otherwise, the PRNG implementation will be the
> weakest link for people who have deliberately selected higher levels of
> protection from cryptographic attack.
I don't want to rehash this thre
> From the Yarrow paper:
> ``Yarrow's outputs are cryptographically derived. Systems that
> use Yarrow's
> outputs are no more secure than the generation mechanism used.''
>
> We currently have Yarrow-256(Blowfish); wanna make it Yarrow-1024? I could
> make it so.
>
> M
> --
> Mark Murray
> On Fri, 21 Jul 2000, Mark Murray wrote:
>
> > Section 2.1, last paragraph:
> > "If a system is shut down, and restarted, it is desirable to store some
> > high-entropy data (such as the key) in non-volatile memory. This allows
> > the PRNG to be restarted in an unguessable state at the next res
Kris Kennaway wrote:
>
> On Fri, 21 Jul 2000, Mark Murray wrote:
>
> > Section 2.1, last paragraph:
> > "If a system is shut down, and restarted, it is desirable to store some
> > high-entropy data (such as the key) in non-volatile memory. This allows
> > the PRNG to be restarted in an unguessab
Kris Kennaway wrote:
>
> On Sat, 22 Jul 2000, Mark Murray wrote:
>
> > Lots of references: Schneier's "Applied Cryptography" talks about
> > using Good Hashes for crypto and Good Crypto for hashes. Schneier's
> > site at www.counterpane.com will give you plenty.
>
> I havent been able to get my
> On Sat, 22 Jul 2000, Mark Murray wrote:
>
> > Because of Yarrow's cryptographic protection of its internal state, its
> > frequent reseeds and its clever geneation mechanism, this paradigm is
> > less important - the output is 256-bit safe (Blowfish safe) for any size
> > of output[*]. When you
On Sat, 22 Jul 2000, Mark Murray wrote:
> Because of Yarrow's cryptographic protection of its internal state, its
> frequent reseeds and its clever geneation mechanism, this paradigm is
> less important - the output is 256-bit safe (Blowfish safe) for any size
> of output[*]. When you read 1000 b
> > The differnce with the old system and Yarrow is yarrow's self-recovery
> > property; Yarrow screens its internal state from the ouside world
> > very heavily, and provides enough perturbation of it from its
> > copious :-) entropy harvesting to keep the state safe from compromise.
>
> Yeah, I
On Sat, 22 Jul 2000, Mark Murray wrote:
> Lots of references: Schneier's "Applied Cryptography" talks about
> using Good Hashes for crypto and Good Crypto for hashes. Schneier's
> site at www.counterpane.com will give you plenty.
I havent been able to get my hands on Applied Cryptography, but I
> After rereading the paper in more detail, Step 7 of the reseed algorithm
> seems not entirely consistent with this: they explicitly refer to writing
> out "the next 2k bits of output from the generator to the seed file"
> (slightly different terminology, but I couldn't find any other references
> I'm all for storing a sample at shutdown and using it to help seed the
> PRNG at startup, but it shouldn't be the only seed used (for example, the
> case where the system has never been shut down (cleanly) before and so has
> no pre-existing seed file is a BIG corner case to consider since thats
On Fri, 21 Jul 2000, Kris Kennaway wrote:
> > Section 2.1, last paragraph:
> > "If a system is shut down, and restarted, it is desirable to store some
> > high-entropy data (such as the key) in non-volatile memory. This allows
> > the PRNG to be restarted in an unguessable state at the next resta
On Fri, 21 Jul 2000, David Schwartz wrote:
> > You generate a new PGP keypair and start using it. Your
> > co-worker reboots your machine afterwards and recovers
> > the PRNG state that happens to be stashed on disk. He
> > can then backtrack and potentially recover the exact same
> > random numb
On Fri, 21 Jul 2000, Mark Murray wrote:
> If you are worried about someone reading the disk of a rebooting box,
> then you need to be worried about console access; if your attacker has
> console, you are screwed anyway.
For most people, yes. But it's like all of the buffer overflows in
non-setui
On Fri, 21 Jul 2000, Mark Murray wrote:
> Section 2.1, last paragraph:
> "If a system is shut down, and restarted, it is desirable to store some
> high-entropy data (such as the key) in non-volatile memory. This allows
> the PRNG to be restarted in an unguessable state at the next restart. We
> c
> You generate a new PGP keypair and start using it. Your
> co-worker reboots your machine afterwards and recovers
> the PRNG state that happens to be stashed on disk. He
> can then backtrack and potentially recover the exact same
> random numbers that you used for your key.
If that is
> :Sure; we neet to be appropriately paranoid about that, but let's not
> :get ridiculous. The seed file could certainly use some decent protection,
> :but unfortunately, PC architectures don't come with SIMcards or the like.
> :
>
> Is it possible to combine the state of the disk based seed with
On Fri, 21 Jul 2000, Mark Murray wrote:
:
:Sure; we neet to be appropriately paranoid about that, but let's not
:get ridiculous. The seed file could certainly use some decent protection,
:but unfortunately, PC architectures don't come with SIMcards or the like.
:
Is it possible to combine the st
> You generate a new PGP keypair and start using it. Your
> co-worker reboots your machine afterwards and recovers
> the PRNG state that happens to be stashed on disk. He
> can then backtrack and potentially recover the exact same
> random numbers that you used for your key.
Said state is rm'me
> > It is a Yarrow-mandated procedure. Please read the Yarrow paper.
>
> Actually, it's not. You don not want to save the exact
> PRNG state to disk, ever. It's not Yarrow mandated
> procedure but a big security hole.
Section 2.1, last paragraph:
"If a system is shut down, and restarted, it i
Jeroen C. van Gelderen wrote:
> Dan Moschuk wrote:
> >
> > I don't see how. If the attacker has physical access to the machine, there
> > are plenty worse things to be done than just reading the state of a PRNG.
> >
> > If the random device is initialized in single user mode, and the file is
>
Dan Moschuk wrote:
>
> | > | Gotcha - fix coming; I need to stash some randomness at shutdown time, and
> | > | use that to reseed the RNG at reboot time.
> | >
> | > What about saving the state of the RNG and re-reading it on bootup? That
> | > will allow Yarrow to continue right where it left
Mark Murray wrote:
>
> > > What about saving the state of the RNG and re-reading it on bootup? That
> > > will allow Yarrow to continue right where it left off. :-)
> >
> > That's a bad thing. You don't want someone to be able to examine the exact
> > PRNG state at next boot by looking at your h
| > | Gotcha - fix coming; I need to stash some randomness at shutdown time, and
| > | use that to reseed the RNG at reboot time.
| >
| > What about saving the state of the RNG and re-reading it on bootup? That
| > will allow Yarrow to continue right where it left off. :-)
|
| That's a bad thi
> > What about saving the state of the RNG and re-reading it on bootup? That
> > will allow Yarrow to continue right where it left off. :-)
>
> That's a bad thing. You don't want someone to be able to examine the exact
> PRNG state at next boot by looking at your hard disk after the machine has
On Wed, 19 Jul 2000, George Michaelson wrote:
> Where for instance do these ideas fit into the models proposed in
>
> draft-eastlake-randomness2-00.txt
>
> or the proceeding RFC?
Well, Yarrow is an algorithm which is intended to provide a robust and
secure source of cryptographic-stren
On Tue, 18 Jul 2000, Dan Moschuk wrote:
> | Gotcha - fix coming; I need to stash some randomness at shutdown time, and
> | use that to reseed the RNG at reboot time.
>
> What about saving the state of the RNG and re-reading it on bootup? That
> will allow Yarrow to continue right where it left
On Tue, 18 Jul 2000, Dan Moschuk wrote:
> Well, how many other OSs out there allow /dev/random to be written to?
FreeBSD, OpenBSD, NetBSD, Linux...
Kris
--
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <[EMAIL PROTECTED]>
To Unsubscribe: send mail
> >If the attacker is on your computer (he us a user, say), he might know
> >a lot about the current frequency of your xtal. He can also get the same
> >(remote) time offsets as you. What does that give him? Not much, but it
> >could reduce the bits that he needs to guess. By how much? I don't
> >
> : If the attacker is on your computer (he us a user, say), he might know
> : a lot about the current frequency of your xtal. He can also get the same
> : (remote) time offsets as you. What does that give him? Not much, but it
> : could reduce the bits that he needs to guess. By how much? I don't
> The trick here is to actually measure the quality of our entropy.
> I have asked Markm to provide us with some kernel option which can
> be used to get a copy of the entropy so we can study the quality
> off it.
I have something that is _very_ crude, and definitely not
commitworthy, but it is u
> In message <[EMAIL PROTECTED]> Peter Dufault writes:
> : > The reason why ntp is interesting is that we compare the received data
> : > with our unpredictable local clock. It is the result of this comparison
> : > which is good entropy bits.
> :
> : Is the resolution of thermal sensors on many
In message <[EMAIL PROTECTED]>, Mark Murray writes:
>[ A whole bunch of sane stuff removed ]
>
>> It certainly would be better than nothing and would be a decent source
>> of randomness. It would be my expectation that if tests were run to
>> measure this randomness and the crypto random tests w
In message <[EMAIL PROTECTED]> Mark Murray writes:
: The randomness is good, no doubt; I worry about how accessible that
: randomness is to an attacker?
That's a good thing to worry about.
: If the attacker is on your computer (he us a user, say), he might know
: a lot about the current frequenc
In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
: A geiger counter and a smoke-detector would be *so much* cheaper
: and give more bits per second :-)
Agreed. And a lot less hassle. A *LOT* less hassle. :-)
: >It certainly would be better than nothing and would be a decent source
: >
[ A whole bunch of sane stuff removed ]
> It certainly would be better than nothing and would be a decent source
> of randomness. It would be my expectation that if tests were run to
> measure this randomness and the crypto random tests were applied,
> we'd find a fairly good source.
The rando
In message <[EMAIL PROTECTED]>, Warner Losh writes:
>Another good source would be if you had a Cesium clock and a GPS
>receiver. The delay due to atmospherics is another good source of
>random data. This varies +- 25ns and is highly locale dependent. One
>can measure this variance down to the
In message <[EMAIL PROTECTED]> Peter Dufault writes:
: > The reason why ntp is interesting is that we compare the received data
: > with our unpredictable local clock. It is the result of this comparison
: > which is good entropy bits.
:
: Is the resolution of thermal sensors on many new motherb
In message <[EMAIL PROTECTED]> Alexander Leidinger writes:
: systems which have a more or less precise clock attached (e.g. GPS or
: atomic clocks which sync the system clock via nptd)? And what are the
: numbers for this solution (for those people which are interested in
: numbers to be their own
In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
: In message <[EMAIL PROTECTED]>, Mark Murray writes:
: >> No, he doesn't have access to the offset from the machines local clock.
: >>
: >> I ran a quick & dirty test here on some logfiles: that offset is
: >> very close to white noise.
:
On Wed, 19 Jul 2000, Steve O'Hara-Smith wrote:
>
> On 19-Jul-00 Peter Dufault wrote:
> > Is the resolution of thermal sensors on many new motherboards and
> > CPU high enough to get thermal randomness?
>
> The voltage sensors have some noise too (maybe not enough).
>
Fan speed too.
On 19-Jul-00 Peter Dufault wrote:
> Is the resolution of thermal sensors on many new motherboards and
> CPU high enough to get thermal randomness?
The voltage sensors have some noise too (maybe not enough).
--
Steve O'Hara-Smith <[EMAIL PROTECTED]>
http://sohara.webhop.net/ A
> The reason why ntp is interesting is that we compare the received data
> with our unpredictable local clock. It is the result of this comparison
> which is good entropy bits.
Is the resolution of thermal sensors on many new motherboards and
CPU high enough to get thermal randomness?
Peter
--
Where for instance do these ideas fit into the models proposed in
draft-eastlake-randomness2-00.txt
or the proceeding RFC?
-George
--
George Michaelson | DSTC Pty Ltd
Email: [EMAIL PROTECTED]| University of Qld 4072
Phone: +61 7 3365 4310| Australia
Fax: +61 7 3
On Tue, 18 Jul 2000, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Vadim Belman writes:
>
> > I mostly agree, but let's put it other way. A rare situation with a
> >local network with no external connection, no NTP servers. Just a server(s)
> >plus several clients. At least some
On Tue, Jul 18, 2000 at 07:03:37PM +0200, Poul-Henning Kamp wrote:
> > I mostly agree, but let's put it other way. A rare situation with a
> >local network with no external connection, no NTP servers. Just a server(s)
> >plus several clients. At least some of the clients are being treated as
In message <[EMAIL PROTECTED]>, Vadim Belman writes:
>> This is about making a FreeBSD machine as good as we can in the
>> standard case.
>
> I mostly agree, but let's put it other way. A rare situation with a
>local network with no external connection, no NTP servers. Just a server(s)
>plu
On Tue, Jul 18, 2000 at 06:43:40PM +0200, Poul-Henning Kamp wrote:
> > And what if no network at all?
>
> Your need for random bits are quite a bit less urgent in that case.
>
> Remember: This is not about getting industry strength unbeatable
> crypto. If you want that, you buy a hardware
In message <[EMAIL PROTECTED]>, Vadim Belman writes:
>On Mon, Jul 17, 2000 at 04:14:50PM +0200, Poul-Henning Kamp wrote:
>
>> >> NTP is the perfect way to gather entropy at bootup!
>> >
>> >Only if in reach of an NTP server ?
>>
>> Obviously :-)
>
> And what if no network at all?
Y
1 - 100 of 173 matches
Mail list logo
