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 your
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" in the
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, but
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 we can
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 high-quality
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
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 NTP servers
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 [EMAIL
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 xtal obviously
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
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
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
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 only
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 :-)
Right, I finally committed the driver you sent me. let me know if I've
made a mistake and committed the wrong one.
Mike, which Supra modem do you have? I've got a SupraMax 56K modem,
SUP2920 and it gives me a rainforest worth of endpoints, not somethig
that looks like a ACM CD Class device.
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
Join the
On Mon, Jul 17, 2000 at 11:18:17PM -0600, Warner Losh wrote:
In message [EMAIL PROTECTED] "Andrey A. Chernov" writes:
: 2716:
: mtree now NOT follows symlinks by default, old behaviour restored to be
: compatible with rest of *BSD camp. New -L option added to follow
:
Nick Hibma writes:
Right, I finally committed the driver you sent me. let me know if I've
made a mistake and committed the wrong one.
Well, the one you committed doesn't have the notification support I
added, or the serial state bits that are in usbcdc.h. Do you need/want
copies of the one
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 sample, what was the white
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://entropy.freebsd.org/
Well, the one you committed doesn't have the notification support I
added, or the serial state bits that are in usbcdc.h. Do you need/want
copies of the one I've been working on?
Yes, please. I must have them somewhere, but it might be a better idea
to get your latest version.
Looks like
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 movement:
| 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
| 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 network
|
| 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
| 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
| (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 vmstat
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", measured
in bits.
Speaking of manpages, are there any out there for ugen(4), uhid(4) ulpt(4)
that are referenced in the usb(4) man page?
-Charlie
On Tue, Jul 18, 2000 at 11:43:09AM +0100, Nick Hibma wrote:
Well, the one you committed doesn't have the notification support I
added, or the serial state bits
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
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 (so
far),
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: send mail
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?
Your need for random
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:
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)
plus several
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
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 of the
Try this (with a very recent kernel):
cat /dev/audio
It locks up my machine. Also, anything that accesses /dev/audio locks up
my machine, such as mpg123.
- Donn
Copyright (c) 1992-2000 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
In [EMAIL PROTECTED] Archie Cobbs [EMAIL PROTECTED]
wrote:
archie 2000/07/18 15:44:52 PDT
Modified files:
sys/net ethernet.h
Log:
Const'ify parameters to ethers(3) routines as appropriate.
Revision ChangesPath
1.16 +6 -6
Hi All,
I've again been trying to get my sound support working.
The problem I have is the machine panic's (RAM parity error)
whenever I (for instance) play an mp3.
I have a SBLive Value card. The card works fine under W98.
The EMU10K1 is recognized during the probe, but the "sbc"
is not. I
Kent Hauser wrote:
I've again been trying to get my sound support working.
The problem I have is the machine panic's (RAM parity error)
whenever I (for instance) play an mp3.
This is a known problem with the SBLive and machines with ECC memory. So
far no sign of a fix for it.
Jordan, if you
There is one more 'buildworld' problem - in
'src/usr.sbin/ipsend'. The (analogous) patch correct it:
Index: contrib/ipfilter/iplang/iplang_y.y
===
RCS file: /store/CVS/src/contrib/ipfilter/iplang/iplang_y.y,v
retrieving
On 17 Jul 2000, Daniel Berlin+list.freebsd-current wrote:
"Leif Neland" [EMAIL PROTECTED] writes:
I have a Verisign personal certificate (Look me up at Verisign, as Leif
Neland)
This works nicely in Windows (Outlook Express), but I'd like to try using
the same key with openssl to
43 matches
Mail list logo
