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/
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.
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
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: MD5 of
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
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 hand,
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
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
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 entropy
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
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 entropy.
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 you
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 that please!
I
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:
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]
with
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] |
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 system
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 Murray
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 used
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 need to
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 [EMAIL
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 help if
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 become
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, 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 not
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]
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
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
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 server, you are
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 what they are,
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 +
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
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; which is an
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 other
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
could do
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 that
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 offset
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'.
Impossible as
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 quantify
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 can be
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 can
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
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
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 is
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 where
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 can
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 run the first
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.
101 - 163 of 163 matches
Mail list logo
