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] |
On Sun, 16 Jul 2000 01:11:16 +0900, Makoto MATSUSHITA wrote:
Jul 16 00:48:32 martini /kernel: mfs_badop[vop_getwritemount]
Jul 16 00:48:32 martini /kernel: mfs_badop[vop_getwritemount] = 45
I'm using MFS as /tmp filesystem, and this message shows up if I
access to /tmp directory such as
On Sun, 16 Jul 2000 18:41:08 MST, Matthew Jacob wrote:
any reason that we should be seeing these now:
mfs_badop[vop_getwritemount]
mfs_badop[vop_getwritemount] = 45
I suspect that these relate to the import of ffs snapshots. I've mailed
Kirk, and someone else has posted a tentative
sheldonh Have you sent your patch to Kirk McKusick [EMAIL PROTECTED]?
No, not yet. It seems that this change is incoroprated with FFS
snapshots feature, but I cannot decide it's true or not; other
filesystem are modified also (see commitlogs), but mfs is not changed...
Anyway, I'll try to
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
cd /usr/src; make -f Makefile.inc1 hierarchy
cd /usr/src/etc;make distrib-dirs
mtree -deLU -f /usr/src/etc/mtree/BSD.root.dist -p /
mtree: illegal option -- L
usage: mtree [-cdeinrUux] [-f spec] [-K key] [-k key] [-p path] [-s seed]
[-X excludes]
*** Error code 1
To
I did a "make buildworld" then "make installworld", and:
--
Making hierarchy
--
cd /usr/src; make -f Makefile.inc1 hierarchy
cd /usr/src/etc;make distrib-dirs
Does anyone else than me have trouble with ftpd reporting "550 not a
plain file" instead of "550 no such file or directory" when the
requested file does not exist?
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current"
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
"Jordan" == Jordan K Hubbard [EMAIL PROTECTED] writes:
Jordan cd /usr/src; make -f Makefile.inc1 hierarchy
Jordan cd /usr/src/etc;make distrib-dirs
Jordan mtree -deLU -f /usr/src/etc/mtree/BSD.root.dist -p /
Jordan mtree: illegal option -- L
Yep, same for me... I succeed in
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 05:39:12PM +0200, Samuel Tardieu wrote:
I did a "make buildworld" then "make installworld", and:
--
Making hierarchy
--
cd /usr/src; make -f
On Mon, Jul 17, 2000 at 06:18:39PM +0200, Dag-Erling Smorgrav wrote:
Does anyone else than me have trouble with ftpd reporting "550 not a
plain file" instead of "550 no such file or directory" when the
requested file does not exist?
This is on 4.1-RC (built from today's sources which
Hi, I found a weird problem with your new fetch(1).
Please try fetching the following file with both fetch and wget for
comparison:
http://www.hiei.kit.ac.jp/~hitomi/mutt/mutt/manual_ja-1.2i-0.tar.gz
1) Fetching the file with wget
knu@archon[2]% uname -a
...
As far as I can tell the fxp driver doesn't even use the tx_fifo in the
825xxx chips :-)
The 82557-9 have a 2KB internal buffer for transmits. They don't start
transmitting until a programmed threshold is reached - this is to insure
that PCI bus latency doesn't result in the
One thing that I just noticed on the python mailing list is a portable way
of retrieving an ip addy. Why not start using eth0 (unfortunately as they
do in Linuxland) eth1 ... For nic cards instead of fxp0 for an intel,
etc...
The fxp0 way is too hardware and implementation dependant.
To
On Monday, July 17, 2000, Tony Johnson wrote:
One thing that I just noticed on the python mailing list is a portable way
of retrieving an ip addy. Why not start using eth0 (unfortunately as they
do in Linuxland) eth1 ... For nic cards instead of fxp0 for an intel,
etc...
The fxp0 way
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]
One thing that I just noticed on the python mailing list is a portable way
of retrieving an ip addy. Why not start using eth0 (unfortunately as they
do in Linuxland) eth1 ... For nic cards instead of fxp0 for an intel,
etc...
The fxp0 way is too hardware and implementation dependant.
Sorry, I seem to have supplied a wrong URL. Here's the correct one.
http://www.hiei.kit.ac.jp/~hitomi/mutt/manual_ja-1.2i-0.tar.gz
--
/
/__ __
/ ) ) ) ) /
Akinori -Aki- MUSHA aka / (_ / ( (__( @
Ping...
Does anyone know if ms chap v2 will be integrated into -current any
time soon? I need it for pptpclient.
If anyone has any patches they'd like public testing on, I'll volunteer. :)
==ml
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of
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,
Ruslan Ermilov [EMAIL PROTECTED] writes:
On Mon, Jul 17, 2000 at 06:18:39PM +0200, Dag-Erling Smorgrav wrote:
Does anyone else than me have trouble with ftpd reporting "550 not a
plain file" instead of "550 no such file or directory" when the
requested file does not exist?
This is on
No response to this on -stable. The actual error message is:
Disk error 0x1 (lba=0x7004c)
No /boot/loader
Also, on a whim I decided to try running /boot/loader. I got a
message saying that there was a syntax error on line 4, that it was
missing either a close paren or a close
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
Apropos pseudorandom, ssh etc; I hope this is not too off-topic, or can
somebody point in the right direction:
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
"Leif Neland" [EMAIL PROTECTED] writes:
Apropos pseudorandom, ssh etc; I hope this is not too off-topic, or can
somebody point in the right direction:
I have a Verisign personal certificate (Look me up at Verisign, as Leif
Neland)
This works nicely in Windows (Outlook Express), but I'd
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
On Tue, 18 Jul 2000 02:14:23 +0200, "Leif Neland" [EMAIL PROTECTED] said:
I can export the key as a .cer, .p7b or .pfx, but openssl seems to want it
in .pem format.
Of course, you haven't really told us what the format of these things
is, so it's difficult to say.
The ``standard'' export
I've just built a new world on one of my test boxes. The good news is
that the Macronix Ethernet card that I have in it works fine (this is
the one with the MX98715AEC-C chip with the small hash table). The
bad news is that the keyboard is non-functional. This is a GENERIC
kernel with nothing
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
At 17 Jul 2000 23:38:23 +0200,
DES wrote:
I've spent most of the night fixing this and am about to commit the
last changes, so you should be able to cvsup and build working
libfetch and fetch in an hour or two.
Thanks! I could confirm that your changes fixed the problem, and am
happy to see
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
: symlinks. This require manual mtree rebuilding before 'make
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
61 matches
Mail list logo
