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
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 worl
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 se
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
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 c
< 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 format is something called PKCS#12. You can
use `openssl pkcs12' wi
> 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;
"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),
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 ge
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 +
"Akinori -Aki- MUSHA" <[EMAIL PROTECTED]> writes:
> Hi, I found a weird problem with your new fetch(1).
Actually, it's not as simple as I thought. It's a bug in the HTTP
server that runs on www.hiei.kit.ac.jp, which triggers a misfeature of
fetch(1), which causes it to fail to properly work aroun
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 cur
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 i
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
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
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 / (_ / ( (__( @
> 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 dependa
> 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
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
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 Uns
...
> >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
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
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 equi
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
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
> "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 succ
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
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" i
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-dir
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 Unsub
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
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 em
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 p
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
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
70 matches
Mail list logo
