Re: randomdev entropy gathering is really weak

[Kris Kennaway]

On Fri, 21 Jul 2000, Kris Kennaway wrote:

> > Section 2.1, last paragraph:
> > "If a system is shut down, and restarted, it is desirable to store some
> > high-entropy data (such as the key) in non-volatile memory. This allows
> > the PRNG to be restarted in an unguessable state at the next restart. We
> > call this data the reseed file."

After rereading the paper in more detail, Step 7 of the reseed algorithm
seems not entirely consistent with this: they explicitly refer to writing
out "the next 2k bits of output from the generator to the seed file"
(slightly different terminology, but I couldn't find any other references
to the "seed file")

Another important point is that Yarrow-160 is not useful for generating
keys >160 bits, because of Shannon's theorem and the fact that it uses
SHA-1. You seem to be using a blowfish-based hash function with 256-bit
keysize (do you have a reference for using blowfish in that fashion?), but
the point stands. It seems we would need to use an alternative interface
which either synchronously reseeds with every output to generate stronger
random data, or just taps into the (hashed) entropy pools directly.

This was also a problem with our /dev/urandom (by design), but not with
/dev/random since that tapped the entropy pool directly. Incidentally, it
also looks like a problem with OpenBSD's /dev/arandom which is a stream
cipher (arc4 with 256-bit key) periodically reseeded.

Kris

--
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <[EMAIL PROTECTED]>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: OT: Praise to all you guys!

[John Reynolds]

[ On Friday, July 21, Doug Barton wrote: ]
> 
>   You have no idea how nice it is to hear GOOD news for a
> change.

yes I do ... :) ... I work in a semi-support role at work where I hear lots of
"it's broken" complaints. I know how frustrating it gets sometimes.

> Thank you for taking the time.

No problem. I figured since everything did go so darned smoothly and the system
is SO much speedier, I just had to tip the hat via e-mail. Of course, it did
help to RTFM /usr/src/UPDATING and -stable well in advance of my 3->4
transition though :) 

> Glad you're enjoying it,

:)

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
John Reynolds Chandler Capabilities Engineering, CDS, Intel Corporation
[EMAIL PROTECTED]  My opinions are mine, not Intel's. Running
[EMAIL PROTECTED]  FreeBSD 4.0-STABLE. FreeBSD: The Power to Serve.
http://members.home.com/jjreynold/  Come join us!!! @ http://www.FreeBSD.org/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

RE: randomdev entropy gathering is really weak

[Kris Kennaway]

On Fri, 21 Jul 2000, David Schwartz wrote:

> > You generate a new PGP keypair and start using it. Your
> > co-worker reboots your machine afterwards and recovers
> > the PRNG state that happens to be stashed on disk. He
> > can then backtrack and potentially recover the exact same
> > random numbers that you used for your key.
> 
>   If that is possible, then Yarrow's algorithm is badly broken. It
> should not be possible to run a PRNG backwards without knowing what it
> output. Once it outputs something, the state information neccessary to
> produce that output should be removed by the output process.

Yarrow only reseeds every so often when it has enough entropy accumulated,
and changes its internal key using a "generator gate" every few inputs
(the paper suggests 10). So if you break the state of the algorithm (e.g.
if it were stored on disk after a reboot) you can learn up to 10 previous
PRNG outputs with that key, back to the previous generator gate or reseed.

This issue is common to all PRNGs that don't reseed with every output
value - it's discussed in the Yarrow paper, which you should read :-)

Kris

--
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <[EMAIL PROTECTED]>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: (noperiph:ahc0:0:-1:-1): ... error

[Matthew Jacob]

You'll have to raise issue on freebsd-scsi.

I sent the likely owner of the issue mail, but they don't monitor -current.





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: (noperiph:ahc0:0:-1:-1): ... error

[Richard Todd]

In servalan.mailinglist.fbsd-current you write:

>I am trying to run a recent (as of today) and am seeing the following
>error when I try to boot::

>(noperiph:ahc0:0:-1:-1): SCSI bus reset delivered. 0 SCBs aborted.
>panic: Bogus resid sgptr value 0xbd68609

>(I copied this from the console after the boot failure, there may be
>minor mistakes.)

>This started happening when I started compiling kernels built from
>sources cvsuped around Jul 18.

>I am not sure what is causing these messages. The "noperiph" message
>appears to come from xpt_print_path in /usr/src/sys/cam/cam_xpt.c while
>the panic seems to be written by ahc_calc_residual in
>/usr/src/sys/dev/aic7xxx/aic7xxx.c.  From a quick look at the code, the
>problem is not directly in the code pointed to by the messages.

>I have an Adaptec 2940UW. A much older kernel reports it as 2940 Ultra SCSI adapter>  with  aic7880 Wide Channel A, SCSI Id=7,
>16/255 SCBs. The Bios on the board is version 2.20.0

>I have 4 drives and a UMAX scanner connected to the bus. More details
>available if needed.

I saw something similar, but not identical, when trying to boot a -current
kernel made last night.  I saw the (noperiph...) message you saw.  After that,
the machine didn't panic, but it didn't work very well, either.  It did, after
a few seconds, detect the SCSI tape drive I had (sa0), but failed on detecting
the SCSI disk and CDROM, repeatedly timing out and resetting the bus.  Alas,
I didn't have the presence of mind to write down the exact messages; I'll try
to do that tonight, assuming the bug is still present in the src I'm cvsupping
now.  This was on an SMP box (Tyan Thunder 100GX), with an aic7895 SCSI
controller, and the following three SCSI devices:
sa0 at ahc0 bus 0 target 0 lun 0
sa0:  Removable Sequential Access SCSI-2 device
sa0: 10.000MB/s transfers (10.000MHz, offset 15)
Mounting root from ufs:/dev/da0s2a
da0 at ahc0 bus 0 target 6 lun 0
da0:  Fixed Direct Access SCSI-3 device
da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled
da0: 8761MB (17942584 512 byte sectors: 255H 63S/T 1116C)
cd0 at ahc0 bus 0 target 1 lun 0
cd0:  Removable CD-ROM SCSI-2 device
cd0: 20.000MB/s transfers (20.000MHz, offset 15)
cd0: Attempt to query device size failed: NOT READY, Medium not present




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: missing idea.h ... ?

[The Hermit Hacker]

On Fri, 21 Jul 2000, Will Andrews wrote:

> On Fri, Jul 21, 2000 at 09:14:57PM -0300, The Hermit Hacker wrote:
> > Just tried to compile kde2 after upgrading to the latest 5.0-CURRENT and
> > its reporting:
> > 
> > In file included from /usr/include/openssl/pem.h:66,
> >  from /usr/include/openssl/ssl.h:147,
> >  from https.cc:42:
> > /usr/include/openssl/evp.h:99: openssl/idea.h: No such file or directory
> > 
> > its being included by a system file, so I can't blame the kde2 source for
> > it ... I just set 'MAKE_IDEA' in my make.conf and am doing a new 'make
> > world', but should not having that cause a problem?
> 
> I don't encounter such problems in my KDE 2721 builds.  I build on
> 4.1-RC with full OpenSSL sources.

I just finished a "make world" with MAKE_IDEA enabled in make.conf, and
the idea.h file is now in /usr/include/openssl *shrug*

> BTW: I should have a webpage/ftpsite etc. ready for port test builds
> tomorrow.. bug me if it's not announced soon.  8)

If it helps any, I setup an anoncvs mirror for most of the stuff ... not
sure if it helps any, since you are working off of snapshots, but its
updated every 4hrs from the central repository, and the CVSROOT for it was
announced on kde-devel ...




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: missing idea.h ... ?

[Will Andrews]

On Fri, Jul 21, 2000 at 09:14:57PM -0300, The Hermit Hacker wrote:
> Just tried to compile kde2 after upgrading to the latest 5.0-CURRENT and
> its reporting:
> 
> In file included from /usr/include/openssl/pem.h:66,
>  from /usr/include/openssl/ssl.h:147,
>  from https.cc:42:
> /usr/include/openssl/evp.h:99: openssl/idea.h: No such file or directory
> 
> its being included by a system file, so I can't blame the kde2 source for
> it ... I just set 'MAKE_IDEA' in my make.conf and am doing a new 'make
> world', but should not having that cause a problem?

I don't encounter such problems in my KDE 2721 builds.  I build on
4.1-RC with full OpenSSL sources.

BTW: I should have a webpage/ftpsite etc. ready for port test builds
tomorrow.. bug me if it's not announced soon.  8)

-- 
Will Andrews <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
GCS/E/S @d- s+:+>+:- a--->+++ C++ UB P+ L- E--- W+++ !N !o ?K w---
?O M+ V-- PS+ PE++ Y+ PGP+>+++ t++ 5 X++ R+ tv+ b++> DI+++ D+ 
G++>+++ e-> h! r-->+++ y?


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: randomdev entropy gathering is really weak

[Kris Kennaway]

On Fri, 21 Jul 2000, Mark Murray wrote:

> If you are worried about someone reading the disk of a rebooting box,
> then you need to be worried about console access; if your attacker has
> console, you are screwed anyway.

For most people, yes. But it's like all of the buffer overflows in
non-setuid utilities: they're not security risks for the vast majority of
users, but who's to say there won't be a situation somewhere when it is
one. Better not to take the risk, since it's not necessary here.

Kris

--
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <[EMAIL PROTECTED]>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: randomdev entropy gathering is really weak

[Kris Kennaway]

On Fri, 21 Jul 2000, Mark Murray wrote:

> Section 2.1, last paragraph:
> "If a system is shut down, and restarted, it is desirable to store some
> high-entropy data (such as the key) in non-volatile memory. This allows
> the PRNG to be restarted in an unguessable state at the next restart. We
> call this data the reseed file."

I'm all for storing a sample at shutdown and using it to help seed the
PRNG at startup, but it shouldn't be the only seed used (for example, the
case where the system has never been shut down (cleanly) before and so has
no pre-existing seed file is a BIG corner case to consider since thats how
the system is at the time it first generates SSH keys after a fresh
install).

It might be only an academic vulnerability, but if someone can read your
HD during the time the system is shut down then I'd prefer them not to
know the precise state when the system next starts up again. Yes, if they
can read they can probably also write, but it seems like a mistake when
there's nothing really gained by saving the complete state, as opposed to
an extract.

Kris

--
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <[EMAIL PROTECTED]>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

missing idea.h ... ?

[The Hermit Hacker]

Just tried to compile kde2 after upgrading to the latest 5.0-CURRENT and
its reporting:

In file included from /usr/include/openssl/pem.h:66,
 from /usr/include/openssl/ssl.h:147,
 from https.cc:42:
/usr/include/openssl/evp.h:99: openssl/idea.h: No such file or directory

its being included by a system file, so I can't blame the kde2 source for
it ... I just set 'MAKE_IDEA' in my make.conf and am doing a new 'make
world', but should not having that cause a problem?

Marc G. Fournier   ICQ#7615664   IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: [EMAIL PROTECTED]   secondary: scrappy@{freebsd|postgresql}.org 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

DHCP client problem?

[Nick Sayer]

Something changed very recently in the dhcp client stuff that seems
to have broke my -current machine's ability to be a dhcp client.

The symptom is that I see

ifconfig: netmask 255.255.255.224: bad value

come out of the script invocation, and the ip address does not get
set.

If I echo out the parameters and type in THE EXACT SAME command line
myself, it works just fine. I suspect some sort of bizarre
quoting conspiracy. :-)



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

RE: randomdev entropy gathering is really weak

[David Schwartz]

> You generate a new PGP keypair and start using it. Your
> co-worker reboots your machine afterwards and recovers
> the PRNG state that happens to be stashed on disk. He
> can then backtrack and potentially recover the exact same
> random numbers that you used for your key.

If that is possible, then Yarrow's algorithm is badly broken. It should not
be possible to run a PRNG backwards without knowing what it output. Once it
outputs something, the state information neccessary to produce that output
should be removed by the output process.

Imagine if I have a PRNG in state 0 (which I'll call "S(0)"). It then
outputs a particular 32-bit PRN, called 'A' and is now in a new state S(1).
Now, if one tries to backtrack from S(1) to S(0), one needs to know A. For
every possible 32-bit A that could have been output, there's a different
corresponding S'(0) (state that might have been S(0)). Since the attacker
does not know A, he does not know which S'(0) corresponds to S(0), and hence
cannot backtrack.

Since the people who developed this algorithm are pretty bright, I will
conculde that this is not the case.

DS



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Journaling Filesystem ?

[Thomas T. Veldhouse]

I have been using softupdates since 3.x.  It works pretty well - but
recovery was not as good as ReiserFS - so far.  I didn't quite catch what
the improvements that are underway for current.  What is the difference
between a journal and a snapshot?

Tom Veldhouse
[EMAIL PROTECTED]

- Original Message -
From: Garrett Wollman <[EMAIL PROTECTED]>
To: Thomas T. Veldhouse <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, July 21, 2000 3:04 PM
Subject: Journaling Filesystem ?


> < said:
>
> > Are there plans for something along this line for FreeBSD?  Is there a
> > project underway?
>
> No.  Soft Updates provides most of the benefits without requiring
> changes to the on-disk layout.  See
> .
>
> -GAWollman
>
>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Journaling Filesystem ?

[Garrett Wollman]

< said:

> Are there plans for something along this line for FreeBSD?  Is there a
> project underway?

No.  Soft Updates provides most of the benefits without requiring
changes to the on-disk layout.  See
.

-GAWollman



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: randomdev entropy gathering is really weak

[Mark Murray]

> :Sure; we neet to be appropriately paranoid about that, but let's not
> :get ridiculous. The seed file could certainly use some decent protection,
> :but unfortunately, PC architectures don't come with SIMcards or the like.
> :
> 
> Is it possible to combine the state of the disk based seed with some other
> source of real entropy?  That would redudce the risk of having someone  read
> your disks while the system is shutdown.

I'm working on haresting some more entropy; that should do what you want.
(Things like disk activity, network stack, process tables and so on).

If you are worried about someone reading the disk of a rebooting box,
then you need to be worried about console access; if your attacker has
console, you are screwed anyway.

M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Journaling Filesystem ?

[Thomas T. Veldhouse]

Hello.  I was wondering if there is any work on a Journaling filesystem to
possible replace, or as an alternative to UFS.  I have been following
ReiserFS for Linux quite closely, and I have had the chance to experiment
with it.  It seems to be coming along nicely and the performance is great.
Are there plans for something along this line for FreeBSD?  Is there a
project underway?

This is not the sort of thing I am likely to be able to contribute much code
too (although I would love to give it a shot), so I would volunteer to test
it on my box :)

Thanks,

Tom Veldhouse
[EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: randomdev entropy gathering is really weak

[David Scheidt]

On Fri, 21 Jul 2000, Mark Murray wrote:

:
:Sure; we neet to be appropriately paranoid about that, but let's not
:get ridiculous. The seed file could certainly use some decent protection,
:but unfortunately, PC architectures don't come with SIMcards or the like.
:

Is it possible to combine the state of the disk based seed with some other
source of real entropy?  That would redudce the risk of having someone  read
your disks while the system is shutdown.


David



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: OT: Praise to all you guys!

[Doug Barton]

On Fri, 21 Jul 2000, John Reynolds wrote:

> Bravo, congrats, and many thanks to all developers minor or major

You have no idea how nice it is to hear GOOD news for a
change. Thank you for taking the time.

Glad you're enjoying it,

Doug
-- 
"Live free or die"
- State motto of my ancestral homeland, New Hampshire

Do YOU Yahoo!?




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Current broken in ncurses ?

[Doug Barton]

On Fri, 21 Jul 2000, Ollivier Robert wrote:

> Am I the only one with this ?
> 
> cc -O -pipe -I. -I/src/src/lib/libncurses 
>-I/src/src/lib/libncurses/../../contrib/ncurses/ncurses 
>-I/src/src/lib/libncurses/../../contrib/ncurses/include -Wall -DFREEBSD_NATIVE 
>-DNDEBUG -DHAVE_CONFIG_H -DTERMIOS -I/net/nas/roberto/sidhe/src/src/i386/usr/include 
>-c /src/src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/comp_scan.c -o 
>comp_scan.o
> /src/src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/comp_scan.c: In function 
>`_nc_get_token':
> /src/src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/comp_scan.c:184: 
>`_nc_disable_period' undeclared (first use in this function)
> /src/src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/comp_scan.c:184: (Each 
>undeclared identifier is reported only once
> /src/src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/comp_scan.c:184: for 
>each function it appears in.)
> *** Error code 1
> 
> Stop in /src/src/lib/libncurses.

I just completed a make world here... try the usual cleaning
/usr/obj and make cleandir in src and see if that helps. 

Good luck,

Doug
-- 
"Live free or die"
- State motto of my ancestral homeland, New Hampshire

Do YOU Yahoo!?




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: randomdev entropy gathering is really weak

[Mark Murray]

> You generate a new PGP keypair and start using it. Your
> co-worker reboots your machine afterwards and recovers 
> the PRNG state that happens to be stashed on disk. He 
> can then backtrack and potentially recover the exact same
> random numbers that you used for your key.

Said state is rm'med after use. If you didn't detect the breakin,
your fault for poor intrusion detection. lets put the paranoia
to practical use and detect the breakin, not nitpick the systems
that are supposed to be protected.

M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: randomdev entropy gathering is really weak

[Mark Murray]

> > It is a Yarrow-mandated procedure. Please read the Yarrow paper.
> 
> Actually, it's not. You don not want to save the exact 
> PRNG state to disk, ever. It's not Yarrow mandated 
> procedure but a big security hole. 

Section 2.1, last paragraph:
"If a system is shut down, and restarted, it is desirable to store some
high-entropy data (such as the key) in non-volatile memory. This allows
the PRNG to be restarted in an unguessable state at the next restart. We
call this data the reseed file."

Perhaps "mandated" was a bit strong; "desired" might be better.

> That said, you do not write out the state of the PRNG,
> you write out a couple of blocks of output from which 
> the state cannot be derived. That *is* okay and that's
> what you are doing. 

Writing the 256-bit key would have been OK according to the paper.

> And just for completeness: it's not mandatory to do so.
> I don't know where you read that in the paper.

See above.

> > If they can do that, they have either the console (==root) or they have
> > root. Either way, who cares what they know about your machine, they have
> > the whole darn thing :-O.
> 
> Someone may well compromise your randomness source without 
> you noticing. And read your PGP mail for the coming couple 
> of years because your PGP key was compromised without you 
> noticing. Perfect Trojan horse to write for the FBI, IRS,
> anyone who doesn't like you. Oops.

Sure; we neet to be appropriately paranoid about that, but let's not
get ridiculous. The seed file could certainly use some decent protection,
but unfortunately, PC architectures don't come with SIMcards or the like.

M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Locale issues on -current

[Viren R.Shah]

I installed a recent snapshot of -current (a week ago) and I keep
getting the following warnings:

[vshah@vorpal] /etc> perl
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LC_ALL = (unset),
LC_CTYPE = "en_US",
LANG = (unset)
are supported and installed on your system.



If I set the appropriate env vars, I get:

vorpal# perl -v
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LC_ALL = "C",
LC_CTYPE = "en_US",
LANG = "en_US.ISO_8859-1"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

This is perl, v5.6.0 built for i386-freebsd

Copyright 1987-2000, Larry Wall



Any ideas as to what I need to do? I tried searching the archives with
no success

[If this is more appropriate for -questions, let me know]

Thanks
Viren
-- 
Viren R. Shah, [EMAIL PROTECTED], http://www.rstcorp.com/~vshah/
`Beware the Jabberwock, my son! The jaws that bite, the claws that catch!
 Beware the Jubjub bird, and shun the frumious Bandersnatch!'
  -- Lewis Carroll (Jabberwocky)


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: randomdev entropy gathering is really weak

[Steve Kargl]

Jeroen C. van Gelderen wrote:
> Dan Moschuk wrote:
> > 
> > I don't see how.  If the attacker has physical access to the machine, there
> > are plenty worse things to be done than just reading the state of a PRNG.
> > 
> > If the random device is initialized in single user mode, and the file is
> > then unlink()ed, I don't see any problems with that.
> 
> You generate a new PGP keypair and start using it. Your
> co-worker reboots your machine afterwards and recovers 
> the PRNG state that happens to be stashed on disk. He 
> can then backtrack and potentially recover the exact same
> random numbers that you used for your key.
> 

I don't follow your logic.

A normal boot/shutdown sequence would be:
  (1) power on (or shutdown -r)
  (2) in single-user mode
  (a) read /dev/saved_entropy into buffer
  (b) unlink /dev/saved_entropy
  (c) create /dev/saved_entropy with all zeros
  (d) test contents in buffer against all zeros
  (I)  buffer contents is different from all zeros;
   initialize entropy pool
  (II) buffer contents matches all zeros; use
   a fall-back method.
  (3) go multi-user   
  (4) normal shutdown
  (a) kick everybody off system
  (b) kill off daemons
  (c) umount all partitions except the partition with /dev
  (c) save entropy to /dev/saved_entropy
  (d) umount partition with /dev

After a crash or panic, the system reboots.  Step 2(c) has
left a finger print to test for valid saved entropy.  If all
zeros are found use a suitable fallback method to stir the
entropy.

I don't see how co-worker can do what you suggest.  And, if
he can easily reboot your system, you have other problems to
worry about.

-- 
Steve


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: No /boot/loader

[John Baldwin]

Bruce Evans wrote:
> On Thu, 20 Jul 2000, John Baldwin wrote:
> 
> > No, that's wrong, too.  A normal disk has a proper slice table (slices start
> > on cylinder boundaries and do not contain the MBR, thus leaving the first
>  track
> > cylinder unused).  A truly dedicated disk (disklabel auto ) uses a
>   track
> > ...
> > at all to the drive's geometry.  As with truly dedicated mode, the MBR is
> > actually contained in boot1, but in dangerously dedicated mode we use the
> > slice table hard-coded into the boot code.  This slice table has 1 slice
> > which is 5 blocks long, or 25000k.  The rest of the disk is marked as
> > unused even though it is, in fact, used.  The fact that it works at all is
> > due to brokenness on our part (we don't check that partitions in a disklabel
> > fit in the parent slice) and also results in several hacks in various portions
> > of the code where we have to check for such bogusness and work around it.
> 
> No, that's wrong too :-) .  We a lot of checking that partitions in a
> disklabel fit in the parent slice.  We clip partitions that don't fit in
> various ways for backwards compatibility.
> 
> Bruce

Erm, maybe we clip partitions which aren't dangerously dedicated, but
I've created test dangerously dedicated disks, and we certainly do not
bother to actually change any of the slice information when we do so.
disklabel(8) does for truly dedicated, but libdisk doesn't for dangerously
dedicated.

-- 

John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: randomdev entropy gathering is really weak

[Jeroen C. van Gelderen]

Dan Moschuk wrote:
> 
> | > | 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. :-)
> |
> | That's a bad thing. You don't want someone to be able to examine the exact
> | PRNG state at next boot by looking at your hard disk after the machine has
> | shut down.
> 
> I don't see how.  If the attacker has physical access to the machine, there
> are plenty worse things to be done than just reading the state of a PRNG.
> 
> If the random device is initialized in single user mode, and the file is
> then unlink()ed, I don't see any problems with that.

You generate a new PGP keypair and start using it. Your
co-worker reboots your machine afterwards and recovers 
the PRNG state that happens to be stashed on disk. He 
can then backtrack and potentially recover the exact same
random numbers that you used for your key.

Cheers,
Jeroen
-- 
Jeroen C. van Gelderen  o  _ _ _
[EMAIL PROTECTED]  _o /\_   _ \\o  (_)\__/o  (_)
  _< \_   _>(_) (_)/<_\_| \   _|/' \/
 (_)>(_) (_)(_)   (_)(_)'  _\o_


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: randomdev entropy gathering is really weak

[Jeroen C. van Gelderen]

Mark Murray wrote:
> 
> > > 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. :-)
> >
> > That's a bad thing. You don't want someone to be able to examine the exact
> > PRNG state at next boot by looking at your hard disk after the machine has
> > shut down.
> 
> It is a Yarrow-mandated procedure. Please read the Yarrow paper.

Actually, it's not. You don not want to save the exact 
PRNG state to disk, ever. It's not Yarrow mandated 
procedure but a big security hole. 

That said, you do not write out the state of the PRNG,
you write out a couple of blocks of output from which 
the state cannot be derived. That *is* okay and that's
what you are doing. 

And just for completeness: it's not mandatory to do so.
I don't know where you read that in the paper.

> If they can do that, they have either the console (==root) or they have
> root. Either way, who cares what they know about your machine, they have
> the whole darn thing :-O.

Someone may well compromise your randomness source without 
you noticing. And read your PGP mail for the coming couple 
of years because your PGP key was compromised without you 
noticing. Perfect Trojan horse to write for the FBI, IRS,
anyone who doesn't like you. Oops.

Cheers,
Jeroen
-- 
Jeroen C. van Gelderen  o  _ _ _
[EMAIL PROTECTED]  _o /\_   _ \\o  (_)\__/o  (_)
  _< \_   _>(_) (_)/<_\_| \   _|/' \/
 (_)>(_) (_)(_)   (_)(_)'  _\o_


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

OT: Praise to all you guys!

[John Reynolds]

I just wanted to send this message to -current since I know that you "-current"
developers were the ones primarily responsible for 4-STABLE.

I just recently upgraded my primary box here from 3.5-STABLE to 4.0-R -> 4.1-RC
and notice tons and tons more "snappyness" with the box. It boots faster, I/O
is faster, NFS is faster, the pcm driver is better, everything is faster and I
haven't tripped over a single "show-stopper" yet!

Bravo, congrats, and many thanks to all developers minor or major

-Jr

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
John Reynolds Chandler Capabilities Engineering, CDS, Intel Corporation
[EMAIL PROTECTED]  My opinions are mine, not Intel's. Running
[EMAIL PROTECTED]  FreeBSD 4.0-STABLE. FreeBSD: The Power to Serve.
http://members.home.com/jjreynold/  Come join us!!! @ http://www.FreeBSD.org/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: randomdev entropy gathering is really weak

[Dan Moschuk]

| > | 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. :-)
| 
| That's a bad thing. You don't want someone to be able to examine the exact
| PRNG state at next boot by looking at your hard disk after the machine has
| shut down.

I don't see how.  If the attacker has physical access to the machine, there
are plenty worse things to be done than just reading the state of a PRNG.

If the random device is initialized in single user mode, and the file is
then unlink()ed, I don't see any problems with that.

-Dan


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: make kernel breakage: if_tap

[Udo Schweigert]

On Fri, Jul 21, 2000 at 07:36:46 +0200, Leif Neland wrote:
> Just cvsupped:
> 
> Script started on Fri Jul 21 07:12:56 2000 CEST
> gina/usr/src/sys/compile/GINA # make clean
> ...
> ===> if_tap
> cd: can't cd to /usr/src/sys/modules/if_tap

Here too. src/sys/modules/if_tap is a completely empty dir (in the cvs
tree). Seems a Makefile is missing here (or it should not be tried to build 
a module).

Regards
-- 
Udo Schweigert, Siemens AG   | Voice  : +49 89 636 42170
ZT IK 3, Siemens CERT| Fax: +49 89 636 41166
D-81730 Muenchen / Germany   | email  : [EMAIL PROTECTED]
PGP-2/5 fingerprint  | D8 A5 DF 34 EC 87 E8 C6  E2 26 C4 D0 EE 80 36 B2


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

ncurses breakage

[Ollivier Robert]

Never mind. cvs wasn't apparently able to "cvs update" correctly and I was
using the old Makefile. Weird.
-- 
Ollivier ROBERT -=- Eurocontrol EEC/ITM -=- [EMAIL PROTECTED]
The Postman hits! The Postman hits! You have new mail.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Current broken in ncurses ?

[Ollivier Robert]

Am I the only one with this ?

cc -O -pipe -I. -I/src/src/lib/libncurses 
-I/src/src/lib/libncurses/../../contrib/ncurses/ncurses 
-I/src/src/lib/libncurses/../../contrib/ncurses/include -Wall -DFREEBSD_NATIVE 
-DNDEBUG -DHAVE_CONFIG_H -DTERMIOS -I/net/nas/roberto/sidhe/src/src/i386/usr/include 
-c /src/src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/comp_scan.c -o 
comp_scan.o
/src/src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/comp_scan.c: In function 
`_nc_get_token':
/src/src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/comp_scan.c:184: 
`_nc_disable_period' undeclared (first use in this function)
/src/src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/comp_scan.c:184: (Each 
undeclared identifier is reported only once
/src/src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/comp_scan.c:184: for each 
function it appears in.)
*** Error code 1

Stop in /src/src/lib/libncurses.

-- 
Ollivier ROBERT -=- Eurocontrol EEC/ITM -=- [EMAIL PROTECTED]
The Postman hits! The Postman hits! You have new mail.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: randomdev entropy gathering is really weak

[Mark Murray]

> > 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. :-)
> 
> That's a bad thing. You don't want someone to be able to examine the exact
> PRNG state at next boot by looking at your hard disk after the machine has
> shut down.

It is a Yarrow-mandated procedure. Please read the Yarrow paper.

If they can do that, they have either the console (==root) or they have
root. Either way, who cares what they know about your machine, they have
the whole darn thing :-O.

M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: RSA problem with SSH ...

[The Hermit Hacker]

Great ... I added RANDOMDEV to the wrong kernel config file :(  

Thanks, fixed now ...


On Fri, 21 Jul 2000, Alexander Langer wrote:

> Thus spake The Hermit Hacker ([EMAIL PROTECTED]):
> 
> > Just upgraded to the newest -current, and now can't use SSH:
> > ssh: no RSA support in libssl and libcrypto.  See ssl(8).
> 
> options RANDOMDEV into kernel, or load randomdev.ko
> 
> That solved it for me (though you mentioned it).
> 
> I'M USA_RESIDENT=NO, though.
> 
> Alex
> -- 
> cat: /home/alex/.sig: No such file or directory
> 

Marc G. Fournier   ICQ#7615664   IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: [EMAIL PROTECTED]   secondary: scrappy@{freebsd|postgresql}.org 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: RSA problem with SSH ...

[Alexander Langer]

Thus spake The Hermit Hacker ([EMAIL PROTECTED]):

> Just upgraded to the newest -current, and now can't use SSH:
> ssh: no RSA support in libssl and libcrypto.  See ssl(8).

options RANDOMDEV into kernel, or load randomdev.ko

That solved it for me (though you mentioned it).

I'M USA_RESIDENT=NO, though.

Alex
-- 
cat: /home/alex/.sig: No such file or directory


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

RE: RSA problem with SSH ...

[Reinier Bezuidenhout]

Hi 

I had the same problem ... but in my case I did not have the
RANDOMDEV compiled in ... so I loaded the kld and whala ... it
worked ...


Try loading the KLD .. also check that the lib's actually do
include the RSA stuff (nm  | grep RSA ) might help.

Reinier


On 21-Jul-00 The Hermit Hacker wrote:
> 
> Just upgraded to the newest -current, and now can't use SSH:
> 
> ssh: no RSA support in libssl and libcrypto.  See ssl(8).
> 
> Tried to read the 'ssl(8)' man page, but it comes back as:
> 
>> man 8 ssl
> No entry for ssl in section 8 of the manual
>> man ssl
> No manual entry for ssl
>>
> 
> Did mergemaster and saw the 'MAKE_RSAINTL' setting in
> /etc/defaults/make.conf, so did that and did a new 'make world' ...
> 
> Even saw the note about /usr/ports/security/rsaref and installed that, no
> difference ...
> 
> Read through /usr/src/UPDATING and can't seem to find anything that
> applies other then the mentioning of RANDOMDEV, which I have configured in
> ...
> 
> So ... what am I missing that this missing man page seems to be indicated
> as the answer? :)
> 
> Thanks ...
> 
> Marc G. Fournier   ICQ#7615664   IRC Nick:
> Scrappy
> Systems Administrator @ hub.org 
> primary: [EMAIL PROTECTED]   secondary:
> scrappy@{freebsd|postgresql}.org 
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message

###
# #
#  R.N. Bezuidenhout  NetSeq Firewall #
#  [EMAIL PROTECTED]   http://www.nanoteq.co.za#  
# #
###

--
Date: 21-Jul-00
Time: 13:50:54

This message was sent by XFMail
--


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

RSA problem with SSH ...

[The Hermit Hacker]

Just upgraded to the newest -current, and now can't use SSH:

ssh: no RSA support in libssl and libcrypto.  See ssl(8).

Tried to read the 'ssl(8)' man page, but it comes back as:

> man 8 ssl
No entry for ssl in section 8 of the manual
> man ssl
No manual entry for ssl
>

Did mergemaster and saw the 'MAKE_RSAINTL' setting in
/etc/defaults/make.conf, so did that and did a new 'make world' ...

Even saw the note about /usr/ports/security/rsaref and installed that, no
difference ...

Read through /usr/src/UPDATING and can't seem to find anything that
applies other then the mentioning of RANDOMDEV, which I have configured in
...

So ... what am I missing that this missing man page seems to be indicated
as the answer? :)

Thanks ...

Marc G. Fournier   ICQ#7615664   IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: [EMAIL PROTECTED]   secondary: scrappy@{freebsd|postgresql}.org 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: randomdev entropy gathering is really weak

[Kris Kennaway]

On Wed, 19 Jul 2000, George Michaelson wrote:

> Where for instance do these ideas fit into  the models proposed in 
> 
>   draft-eastlake-randomness2-00.txt
> 
> or the proceeding RFC?

Well, Yarrow is an algorithm which is intended to provide a robust and
secure source of cryptographic-strength random numbers (i.e. suitable for
the purposes described in that draft). I dont think it's specifically
mentioned there, but it's defined and described in a series of papers by
Schneier et al. available on www.counterpane.com.

As for the other parts of that document, it looks like there might be some
useful discussion of entropy sources on commodity PC hardware and the
issues with sampling such sources - I'll have to read it in more detail
(and suggest other interested participants in this discussion also do so,
along with the Yarrow papers). Thanks for pointing it out!

Kris

--
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <[EMAIL PROTECTED]>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: randomdev entropy gathering is really weak

[Kris Kennaway]

On Tue, 18 Jul 2000, Dan Moschuk wrote:

> | 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. :-)

That's a bad thing. You don't want someone to be able to examine the exact
PRNG state at next boot by looking at your hard disk after the machine has
shut down.

Kris

--
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <[EMAIL PROTECTED]>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: randomdev entropy gathering is really weak

[Kris Kennaway]

On Tue, 18 Jul 2000, Dan Moschuk wrote:

> Well, how many other OSs out there allow /dev/random to be written to?

FreeBSD, OpenBSD, NetBSD, Linux...

Kris

--
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <[EMAIL PROTECTED]>




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: kernel compile failure without -O option

[Bruce Evans]

On Wed, 19 Jul 2000, John Polstra wrote:

> In article <[EMAIL PROTECTED]>,
> Hellmuth Michaelis <[EMAIL PROTECTED]> wrote:
> > 
> > In the process of tracing down the problem of the kernel panic when booting
> > a kernel with pcvt enabled, i tried to compile a kernel without the -O
> > option to gcc and got this compile failure (sources from 18.7.2000 9:00 MET):
> > 
> > cc -c -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes 
> >   -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
> >   -fformat-extensions -ansi  -nostdinc -I- -I. -I../.. -I../../../include
> >   -D_KERNEL -include opt_global.h -elf  -mpreferred-stack-boundary=2
> >   -fomit-frame-pointer ../../i386/i386/atomic.c
> > In file included from ../../i386/i386/atomic.c:47:
> > machine/atomic.h: In function `atomic_set_char':
> > machine/atomic.h:106: inconsistent operand constraints in an `asm'
> > machine/atomic.h: In function `atomic_clear_char':
> > machine/atomic.h:107: inconsistent operand constraints in an `asm'
> [...]
> 
> I have seen that same problem recently in a slightly different
> context.  After staring at the code for a very long time, I could
> only conclude that the problem was a bug in gcc.

Me too :-).

I didn't reply to John's private mail about this (sorry), partly because 
the problem seemed to be an old one that I wasn't able to solve before.
The "0" construct apparently doesn't work even with -O for gcc <= 2.8,
so atomic.h is ifdefed to not use it for non-current gcc's, although it
is strictly required for the input-output operands in atomic.h.  There
is also a problem with gcc's handling of volatile objects in atomic.h
(it just pessimizes them).

Bruce



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: No /boot/loader

[Bruce Evans]

On Thu, 20 Jul 2000, John Baldwin wrote:

> No, that's wrong, too.  A normal disk has a proper slice table (slices start
> on cylinder boundaries and do not contain the MBR, thus leaving the first
 track
> cylinder unused).  A truly dedicated disk (disklabel auto ) uses a
  track
> ...
> at all to the drive's geometry.  As with truly dedicated mode, the MBR is
> actually contained in boot1, but in dangerously dedicated mode we use the
> slice table hard-coded into the boot code.  This slice table has 1 slice
> which is 5 blocks long, or 25000k.  The rest of the disk is marked as
> unused even though it is, in fact, used.  The fact that it works at all is
> due to brokenness on our part (we don't check that partitions in a disklabel
> fit in the parent slice) and also results in several hacks in various portions
> of the code where we have to check for such bogusness and work around it.

No, that's wrong too :-) .  We a lot of checking that partitions in a
disklabel fit in the parent slice.  We clip partitions that don't fit in
various ways for backwards compatibility.

Bruce



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: No /boot/loader

[Warner Losh]

In message <[EMAIL PROTECTED]> Leif Neland 
writes:
: 
: 
: On Thu, 20 Jul 2000, Warner Losh wrote:
: 
: > In message <[EMAIL PROTECTED]> Leif 
:Neland writes:
: > : Just to be on the safe side, is there a simple way to see if a disk is
: > : dedicated?
: > 
: > fdisk -s ad0
: > 
: > If there's a slice table, then it will give you a summary report of
: > the slices.  If not it will report an error (and maybe give you a
: > faked up listing).
: 
: I have windows partitions on my disks here, so they can't be dedicated.
: fdisk -s ad[0,1,2] all reports
: invalid fdisk partition found.

Did you do that as root?  All of my windows disks report valid
partitions.

>From my sever:
% fdisk -s da0
/dev/da0: 2231 cyl 255 hd 63 sec
PartStartSize Type Flags
   4:   135841014 0xa5 0x80

>From my laptop:
fdisk -s ad0
/dev/ad0: 559 cyl 240 hd 63 sec
PartStartSize Type Flags
   1:  63 2766897 0x0b 0x00
   2: 2766960 5397840 0xa5 0x80
   4: 8164800  272160 0xa0 0x00

I'm in group operator, so I can read the disks on my own.  The part
type 0xa0 is for the suspend to disk partition in my VAIO.

: Does that mean that a dedicated disk has a slice table, a normal doesn't?

No.  That's backwards.  A dedicated disk has no slice table (a
dangerously dedicated disk, that is), and a "normal" one does have a
slice table.

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message