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?
--
/Voland Vadim Belman
To Unsubscribe: sen
In message <[EMAIL PROTECTED]>, Alexander Leidinger w
rites:
>On 18 Jul, Mark Murray wrote:
>
>[using NTP to gather entropy]
>> You forget; a snooper watching your (ether)net has access to nearly
>> all of this information.
>
>I've only seen messages about getting ntp information over a network (s
On 18 Jul, Mark Murray wrote:
[using NTP to gather entropy]
> You forget; a snooper watching your (ether)net has access to nearly
> all of this information.
I've only seen messages about getting ntp information over a network (so
far), and I'm not familiar with crypto/entropy gathering/ntp, so f
In message <[EMAIL PROTECTED]>, Mark Murray writes:
>> >Help me here! :-)
>> >
>> >In your observed sample, what was the white noise amplitude?
>>
>> What do you mean by "amplitude" ? The frequency deviation ?
>> The phase error ?
>
>The standard deviation of all the observation "amplitudes", me
> | (date; dmesg ; sysctl -X; vmstat -i ) > /dev/random
> |
> | Just playing it looks like you might get 4 so bits from the
> | rtc and clk interupt count alone.
> None. Any data that is publically available via userland should not be
> used for cryptography.
The data from sysctl -X and vm
| I think there are other practical issues too. Unless the new libfetch
| fetch supports https this won't work. More to the point, I'd
| guess https needs a working /dev/random to set up the secure
| connection, but we're running fetch to set up /dev/random.
|
| How much entropy can we get from:
| DuH!
|
| NTP is the perfect way to gather entropy at bootup!
|
| Predicting the clock's offset from reality and the two way path to
| the server of choice is impossible, plus if people enable authentication
| later on the packets will be choke full of high-quality entropy.
|
| We need an ent
| >In fact, it would be rather interesting to have a configuration flag which
| >always forces something like an fsck on a file system in order to provide
| >some entropy to the random device. Or some other user-exposed way of
| >providing entropy. I might have some data on disk, or some networ
| 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. :-)
-Dan
To Unsubscribe: send mail to [E
> >Help me here! :-)
> >
> >In your observed sample, what was the white noise amplitude?
>
> What do you mean by "amplitude" ? The frequency deviation ?
> The phase error ?
The standard deviation of all the observation "amplitudes", measured
in bits.
M
--
Mark Murray
Join the anti-SPAM movemen
On Mon, Jul 17, 2000 at 01:16:43PM -0700, Kris Kennaway wrote:
> On Mon, 17 Jul 2000, Mark Murray wrote:
> > > What we really need is this:
> > >
> > > fetch -o http://entropy.freebsd.org/ > /dev/random
> >
> > For this to work, you'll need to encrypt the traffic.
> >
> > fetch -o https://ent
In message <[EMAIL PROTECTED]>, Mark Murray writes:
>> >> I ran a quick & dirty test here on some logfiles: that offset is
>> >> very close to white noise.
>> >
>> >With what amplitude?
>>
>> Depends on the termal environment of your xtal obviously :-)
>
>Help me here! :-)
>
>In your observed sam
> >> I ran a quick & dirty test here on some logfiles: that offset is
> >> very close to white noise.
> >
> >With what amplitude?
>
> Depends on the termal environment of your xtal obviously :-)
Help me here! :-)
In your observed sample, what was the white noise amplitude?
M
--
Mark Murray
Joi
On Tue, 18 Jul 2000, Bruce Evans wrote:
> You must have a fast machine to get 10MB/sec. I see the following speeds
> (using a better reading program than dd; dd gives up on EOF on the old
> /dev/random):
Oops, I misread the rate by 2 orders of magnitude. I get about 100K/sec on
my PPro/233 :-)
> With microsecond timestamps, 64second ntp poll period we are talking
> about approx 10 bits of randomness in the received packet and about
> 3 bits of randomness in the clock difference.
>
> FreeBSD uses nanosecond timestamping (Actually could do nanoseconds
> with 32 bitfractions), but that on
On Sun, 16 Jul 2000, Kris Kennaway wrote:
> On the other hand, doing a dd if=/dev/random of=/dev/null gives me
> infinite "randomness" at 10MB/sec - have the semantics of /dev/random
> changed?
Yes. /dev/random is now just an alias for /dev/urandom (or vice versa).
You must have a fast machine
Thus spake Louis A. Mamakos ([EMAIL PROTECTED]):
> Actually, you could really use this in ntpd(8), rather than just ntpdate.
Hmm, as addition, I agree.
However, I think more people use ntpdate than ntpd, and thus ntpdate
is a good place :)
Alex
--
cat: /home/alex/.sig: No such file or directo
In message <[EMAIL PROTECTED]>, "Jeroen C. van Gelderen" writes
>It's up to the user to decide what security level he needs.
>Both ought to be possible but having an insecure box ought
>to be an explicit decision.
Principle of POLA: The box doesn't come up in a stupid configuration
right after
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.
>
>With what amplitude?
Depends on the termal environment of your xt
> 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.
With what amplitude?
M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org
To Unsubscribe: send mail to [EMA
Poul-Henning Kamp wrote:
>
> In message <[EMAIL PROTECTED]>, "Jeroen C. van Gelderen" writes:
>
> >> People have tried for 30+ years to predict what a quartz xtal
> >> will do next. Nobody expects any chance of success. Add to this
> >> the need to predict the difference between one or more NT
On Mon, 17 Jul 2000 16:27:17 MST, "Kurt D. Zeilenga" wrote:
> Note that there should be no need to cron the job.
You're right. My suggestion to use cron's @reboot was as stupid as they
come. :-)
Sorry,
Sheldon.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-curren
In message <[EMAIL PROTECTED]>, "Jeroen C. van Gelderen" writes:
>> People have tried for 30+ years to predict what a quartz xtal
>> will do next. Nobody expects any chance of success. Add to this
>> the need to predict the difference between one or more NTP servers
>> and your local qartz xtal
Poul-Henning Kamp wrote:
>
> In message <[EMAIL PROTECTED]>, "Jeroen C. van Gelderen" writes
> :
>
> >> Predicting the clock's offset from reality and the two way path to
> >> the server of choice is impossible, plus if people enable authentication
> >> later on the packets will be choke full of
In message <[EMAIL PROTECTED]>, Mark Murray writes:
>> People have tried for 30+ years to predict what a quartz xtal
>> will do next. Nobody expects any chance of success. Add to this
>> the need to predict the difference between one or more NTP servers
>> and your local qartz xtal and I think w
> People have tried for 30+ years to predict what a quartz xtal
> will do next. Nobody expects any chance of success. Add to this
> the need to predict the difference between one or more NTP servers
> and your local qartz xtal and I think we can safely say "impossible".
You can't predict this,
In message <[EMAIL PROTECTED]>, Mark Murray writes:
>> Actually, you could really use this in ntpd(8), rather than just ntpdate.
>> You could crank in the offset and delay samples for each packet
>> received from an NTP peer; this will have the effect of adding into
>> the entropy pool the "noise"
> Actually, you could really use this in ntpd(8), rather than just ntpdate.
> You could crank in the offset and delay samples for each packet
> received from an NTP peer; this will have the effect of adding into
> the entropy pool the "noise" in the latency of the path between you
> and each of yo
In message <[EMAIL PROTECTED]>, "Jeroen C. van Gelderen" writes
:
>> Predicting the clock's offset from reality and the two way path to
>> the server of choice is impossible, plus if people enable authentication
>> later on the packets will be choke full of high-quality entropy.
>
>Please quantif
David Schwartz wrote:
>
> > > Predicting the clock's offset from reality and the two way path to
> > > the server of choice is impossible, plus if people enable authentication
> > > later on the packets will be choke full of high-quality entropy.
> >
> > Please quantify 'impossible'.
>
>
> > Predicting the clock's offset from reality and the two way path to
> > the server of choice is impossible, plus if people enable authentication
> > later on the packets will be choke full of high-quality entropy.
>
> Please quantify 'impossible'.
Impossible as in cannot be done. The
> In message <[EMAIL PROTECTED]>, Alexander Langer writ
> es:
> >Thus spake Poul-Henning Kamp ([EMAIL PROTECTED]):
> >
> >> I have thought about adding a entropy server to my array of weird
> >> servers in my lab. Something like a Geiger counter and a smokedetector
> >> could do wonders.
> >
> >H
Poul-Henning Kamp wrote:
>
> In message <[EMAIL PROTECTED]>, Alexander Langer writ
> es:
> >Thus spake Poul-Henning Kamp ([EMAIL PROTECTED]):
> >
> >> I have thought about adding a entropy server to my array of weird
> >> servers in my lab. Something like a Geiger counter and a smokedetector
> >
Poul-Henning Kamp wrote:
>
> In message <[EMAIL PROTECTED]>, "Louis A. Mamakos" writ
> es:
>
> >In fact, it would be rather interesting to have a configuration flag which
> >always forces something like an fsck on a file system in order to provide
> >some entropy to the random device. Or some o
Kris Kennaway wrote:
>
> On Mon, 17 Jul 2000, Mark Murray wrote:
>
> > > On the other hand, doing a dd if=/dev/random of=/dev/null gives me
> > > infinite "randomness" at 10MB/sec - have the semantics of /dev/random
> > > changed?
> >
> > Yes; remember that what we have here is Yarrow algorithm;
However much I love the idea of people coding in more randomness, I'd get a
better fuzzy feeling if somebody with some cred in the crypto world was sitting
in on this discussion and commenting on the ideas.
Things like 'going out on the network and fetching some random bits via http'
are so utte
Note that there should be no need to cron the job. You
only need to save one set of bits to be used as a seed
for the next startup. And one set of bits SHOULD be
as good as any other.
I suggest you (at boot time):
1: open seed file for read
unlink seed file
use seed file +
On Mon, 17 Jul 2000, Mark Murray wrote:
> > What we really need is this:
> >
> > fetch -o http://entropy.freebsd.org/ > /dev/random
>
> For this to work, you'll need to encrypt the traffic.
>
> fetch -o https://entropy.freebsd.org/ > /dev/random
> ^
>
> If the world knows wha
On Mon, Jul 17, 2000 at 05:08:35PM +0200, Leif Neland wrote:
> On Mon, 17 Jul 2000, Steve O'Hara-Smith wrote:
> > On 17-Jul-00 Poul-Henning Kamp wrote:
> > > NTP is the perfect way to gather entropy at bootup!
> >
> > Only if in reach of an NTP server ?
> >
> If you can't reach a NTP ser
On Mon, 17 Jul 2000 19:33:40 +0200, Mark Murray wrote:
> That is an idea I can use! :-)
See the recently fixed and documented crontab(5) @reboot, in fact. :-)
Ciao,
Sheldon.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
> The reason is not security only, the reason is buggy RNG. Imagine diskless
> keyboard-less and mouse-less slide-show machine with no rc.shutdown hooks
> since it comes with power up and goes down with power down. This machine
> will always start with same picture because RNG have not enough
> You may also want to extend /etc/crontab to periodically save entropy. This would
> help if something unexpected like halt(8) or panic(9) happened.
That is an idea I can use! :-)
M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
On Mon, Jul 17, 2000 at 07:02:50PM +0200, Alexander Langer wrote:
> Thus spake Leif Neland ([EMAIL PROTECTED]):
>
> > If you can't reach a NTP server, you are not connected to the internet. In
> > that case you don't need to worry so much about security...
>
> That is wrong :)
>
The reason is
Thus spake Leif Neland ([EMAIL PROTECTED]):
> If you can't reach a NTP server, you are not connected to the internet. In
> that case you don't need to worry so much about security...
That is wrong :)
Alex
--
cat: /home/alex/.sig: No such file or directory
To Unsubscribe: send mail to [EMAIL
On Mon, 17 Jul 2000, Steve O'Hara-Smith wrote:
>
>On 17-Jul-00 Leif Neland wrote:
>> If you can't reach a NTP server, you are not connected to the internet. In
>> that case you don't need to worry so much about security...
>
>Not clear. I might not be connected at boot time but could well
Maxim Sobolev wrote:
[Charset koi8-r unsupported, filtering to ASCII...]
> Mark Murray wrote:
>
> > Agreed. I have already committed a "persistent" entropy cache that
> > reseeds the random device on reboot.
>
> You may also want to extend /etc/crontab to periodically save entropy.
> This would
On 17-Jul-00 Leif Neland wrote:
> If you can't reach a NTP server, you are not connected to the internet. In
> that case you don't need to worry so much about security...
Not clear. I might not be connected at boot time but could well become
connected later.
--
Steve O'Hara-Smith <[EMAI
On Mon, 17 Jul 2000, Steve O'Hara-Smith wrote:
>
> On 17-Jul-00 Poul-Henning Kamp wrote:
> > NTP is the perfect way to gather entropy at bootup!
>
> Only if in reach of an NTP server ?
>
If you can't reach a NTP server, you are not connected to the internet. In
that case you don't ne
Mark Murray wrote:
> > > I agree that it is not (very) random; however cclock jitter and keystroke
> > > timing can help thwart the bad guys...
> >
> > But do please keep in mind that many of my FreeBSD platforms have neither
> > keyboard or mouse. And for the ones that do, they tend not to get
> What we really need is this:
>
> fetch -o http://entropy.freebsd.org/ > /dev/random
For this to work, you'll need to encrypt the traffic.
fetch -o https://entropy.freebsd.org/ > /dev/random
^
If the world knows what they are, your bits aren't random enough.
M
--
Mark Murr
> > I agree that it is not (very) random; however cclock jitter and keystroke
> > timing can help thwart the bad guys...
>
> But do please keep in mind that many of my FreeBSD platforms have neither
> keyboard or mouse. And for the ones that do, they tend not to get used
> until long after the s
In message <[EMAIL PROTECTED]>, "Steve O'Hara-Smith" writes
:
>
>On 17-Jul-00 Poul-Henning Kamp wrote:
>> NTP is the perfect way to gather entropy at bootup!
>
>Only if in reach of an NTP server ?
Obviously :-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED]
On 17-Jul-00 Poul-Henning Kamp wrote:
> NTP is the perfect way to gather entropy at bootup!
Only if in reach of an NTP server ?
--
Steve O'Hara-Smith <[EMAIL PROTECTED]>
http://sohara.webhop.net/ A Better Way To Focus The Sun
To Unsubscribe: send mail to [EMAIL PROTECTED]
wit
Thus spake Poul-Henning Kamp ([EMAIL PROTECTED]):
> We need an enterprising soul to add an option (default on) to
> ntpdate to write the received packets in toto to /dev/random
> if it exists.
If noone else wants to do it, I could take a look at it.
Little time, though.
Alex
--
cat: /home/ale
In message <[EMAIL PROTECTED]>, Alexander Langer writ
es:
>Thus spake Poul-Henning Kamp ([EMAIL PROTECTED]):
>
>> I have thought about adding a entropy server to my array of weird
>> servers in my lab. Something like a Geiger counter and a smokedetector
>> could do wonders.
>
>HA! Cool!
>
>Do tha
Thus spake Poul-Henning Kamp ([EMAIL PROTECTED]):
> I have thought about adding a entropy server to my array of weird
> servers in my lab. Something like a Geiger counter and a smokedetector
> could do wonders.
HA! Cool!
Do that please!
I mean, seriously.
And an option to sysinstall, where yo
In message <[EMAIL PROTECTED]>, "Louis A. Mamakos" writ
es:
>In fact, it would be rather interesting to have a configuration flag which
>always forces something like an fsck on a file system in order to provide
>some entropy to the random device. Or some other user-exposed way of
>providing entr
> > In message <[EMAIL PROTECTED]>, Mark Murray writes:
> >
> > >getnanotime() is already extensively used;
> >
> > I looked at that use, but as far as I can tell, it is only used as a
> > flag at this time, the bits returned by getnanotime() does not end up
> > in the entropy pool ?
>
> Not t
In message <[EMAIL PROTECTED]>, Mark Murray writes:
>getnanotime() is already extensively used;
I looked at that use, but as far as I can tell, it is only used as a
flag at this time, the bits returned by getnanotime() does not end up
in the entropy pool ?
I'm not dissatisfied about that btw,
> In message <[EMAIL PROTECTED]>, Mark Murray writes:
>
> >getnanotime() is already extensively used;
>
> I looked at that use, but as far as I can tell, it is only used as a
> flag at this time, the bits returned by getnanotime() does not end up
> in the entropy pool ?
Not true; struct entrop
> On Mon, 17 Jul 2000, Mark Murray wrote:
>
> > > On the other hand, doing a dd if=/dev/random of=/dev/null gives me
> > > infinite "randomness" at 10MB/sec - have the semantics of /dev/random
> > > changed?
> >
> > Yes; remember that what we have here is Yarrow algorithm; which is an
> > algori
On Mon, 17 Jul 2000, Mark Murray wrote:
> > On the other hand, doing a dd if=/dev/random of=/dev/null gives me
> > infinite "randomness" at 10MB/sec - have the semantics of /dev/random
> > changed?
>
> Yes; remember that what we have here is Yarrow algorithm; which is an
> algorithm for cryptogr
> ssh-keygen should just block until it gets enough - this is not acceptable
> behaviour if /dev/urandom is returning unseeded data. OpenSSL uses
> /dev/urandom at the moment - I just read a comment in md_rand.c that using
> /dev/random may block, which I didn't think was true.
>
> On the other h
> The problem is that the randomdev stuff should be a delete option, ie. it
> should be built as part of the kernel unless EXPLICITLY excluded, not the
> wrong way around as it is at the moment.
I agree. Any objections?
M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org
To Un
> > The situation is _worse_; the entropy is minimal, and is _very_ attackable.
>
> What's wrong about timers for enthropy (I mean high resolution ones)?
> Really we need only few bytes of enthropy and can use them to seed RNG for the
> first time if no true randomness available. To be joking: M
On Sun, 16 Jul 2000, Mike Smith wrote:
> The problem is that the randomdev stuff should be a delete option, ie. it
> should be built as part of the kernel unless EXPLICITLY excluded, not the
> wrong way around as it is at the moment.
Exactly, randomdev should be compiled-in by default.
On Sun, 16 Jul 2000, Mark Murray wrote:
> > On Sun, Jul 16, 2000 at 08:26:44PM +0200, Mark Murray wrote:
> >
> > > Gotcha - fix coming; I need to stash some randomness at shutdown time, and
> > > use that to reseed the RNG at reboot time.
> >
> > ... and for installations where ssh-keygen is ru
> I found that I always got the same fortune quote after reboot, over and over
> again. It means that /dev/random produce exact the same values after reboot.
> It means that machine timer or keyboard not used for enthropy gathering.
> Using keyboard alone not helps for automatic tasks because it
On Sun, Jul 16, 2000 at 09:42:29PM +0200, Mark Murray wrote:
> > On Sun, Jul 16, 2000 at 08:26:44PM +0200, Mark Murray wrote:
> >
> > > Gotcha - fix coming; I need to stash some randomness at shutdown time, and
> > > use that to reseed the RNG at reboot time.
> >
> > ... and for installations wh
> On Sun, Jul 16, 2000 at 08:26:44PM +0200, Mark Murray wrote:
>
> > Gotcha - fix coming; I need to stash some randomness at shutdown time, and
> > use that to reseed the RNG at reboot time.
>
> ... and for installations where ssh-keygen is run the first time
> the system boots?
The situation i
On Sun, Jul 16, 2000 at 08:26:44PM +0200, Mark Murray wrote:
> Gotcha - fix coming; I need to stash some randomness at shutdown time, and
> use that to reseed the RNG at reboot time.
... and for installations where ssh-keygen is run the first time
the system boots?
--
Bill Fumerola - Network A
> I found that I always got the same fortune quote after reboot, over and over
> again. It means that /dev/random produce exact the same values after reboot.
There were some special instructions for the new random device:
2) If you do not have the randomdev module loaded, ssh will
fail in st
> I found that I always got the same fortune quote after reboot, over and over
> again. It means that /dev/random produce exact the same values after reboot.
> It means that machine timer or keyboard not used for enthropy gathering.
> Using keyboard alone not helps for automatic tasks because it
101 - 173 of 173 matches
Mail list logo
