Re: cer/b7b/pfc -> pem

[Leif Neland]

On 17 Jul 2000, Daniel Berlin+list.freebsd-current wrote:

> "Leif Neland" <[EMAIL PROTECTED]> writes:
> 
> > I have a Verisign personal certificate (Look me up at Verisign, as Leif
> > Neland)
> > 
> > This works nicely in Windows (Outlook Express), but I'd like to try using
> > the same key with openssl to generate crypted (to myself) or signed
> > messages.
> > 
> > I can export the key as a .cer, .p7b or .pfx, but openssl seems to want it
> > in .pem format.
> > 
> 
> What does the p7b file look like?
> 
> And the .cer file, and the .pfx file?
> 
> Are any of them ascii, with a "BEGIN PKCS7" or "BEGIN CERTIFICATE"
> line?
> 
With crl2pcks7 I can convert the p7b and cer to a pem, which contain BEGIN
PKCS7 ,  random characters,  and END PKCS7

I can't use this to encrypt with, smime wants "BEGIN CERTIFICATE"

Leif



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

Re: cvs commit: src/sys/net ethernet.h

[Nickolay Dudorov]

There is one more 'buildworld' problem - in 
'src/usr.sbin/ipsend'. The (analogous) patch correct it:

Index: contrib/ipfilter/iplang/iplang_y.y
===
RCS file: /store/CVS/src/contrib/ipfilter/iplang/iplang_y.y,v
retrieving revision 1.1.1.6
diff -b -u -r1.1.1.6 iplang_y.y
--- contrib/ipfilter/iplang/iplang_y.y  2000/05/24 02:14:18 1.1.1.6
+++ contrib/ipfilter/iplang/iplang_y.y  2000/07/19 04:59:38
@@ -48,7 +48,7 @@
 #include "ipf.h"
 #include "iplang.h"
 
-#ifndef __NetBSD__
+#if !defined(__NetBSD__) && ! defined(__FreeBSD__)
 extern struct ether_addr *ether_aton __P((char *));
 #endif
 
> In <[EMAIL PROTECTED]> Archie Cobbs <[EMAIL PROTECTED]> 
>wrote:
>> archie  2000/07/18 15:44:52 PDT
>> 
>>   Modified files:
>> sys/net  ethernet.h 
>>   Log:
>>   Const'ify parameters to ethers(3) routines as appropriate.
>>   
>>   Revision  ChangesPath
>>   1.16  +6 -6  src/sys/net/ethernet.h
> 
>   This breaks 'buildworld' in the 'lib/libpcap'.
> 
>   The next patch seems to correct the error.
> 
>   N.Dudorov
> 
> Index: contrib/libpcap/nametoaddr.c
> ===
> RCS file: /store/CVS/src/contrib/libpcap/nametoaddr.c,v
> retrieving revision 1.6
> diff -b -u -r1.6 nametoaddr.c
> --- contrib/libpcap/nametoaddr.c  2000/01/30 00:43:34 1.6
> +++ contrib/libpcap/nametoaddr.c  2000/07/19 04:02:27
> @@ -366,7 +366,7 @@
>  }
>  #else
>  
> -#if !defined(sgi) && !defined(__NetBSD__)
> +#if !defined(sgi) && !defined(__NetBSD__) && !defined(__FreeBSD__)
>  extern int ether_hostton(char *, struct ether_addr *);
>  #endif
>  
> 
> 


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

Re: SBLive (value)

[Frank Mayhar]

Kent Hauser wrote:
> I've again been trying to get my sound support working.
> The problem I have is the machine panic's (RAM parity error)
> whenever I (for instance) play an mp3.

This is a known problem with the SBLive and machines with ECC memory.  So
far no sign of a fix for it.

Jordan, if you read this, please email me the address to send the memory
stick.  I'll contribute it to the cause.  (I'll need a receipt, though. ;-)
-- 
Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/
Exit Consulting http://store.exit.com/


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

SBLive (value)

[Kent Hauser]

Hi All,

I've again been trying to get my sound support working.
The problem I have is the machine panic's (RAM parity error)
whenever I (for instance) play an mp3.

I have a SBLive Value card. The card works fine under W98.

The EMU10K1 is recognized during the probe, but the "sbc"
is not. I have pci/pcm/sbc enabled in the kernel.
"cat /dev/sndstat" shows the emu10k1 ready and willing.

Any thoughts? 


Thanks.
Kent


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

Re: cvs commit: src/sys/net ethernet.h

[Nickolay Dudorov]

In <[EMAIL PROTECTED]> Archie Cobbs <[EMAIL PROTECTED]> 
wrote:
> archie  2000/07/18 15:44:52 PDT
> 
>   Modified files:
> sys/net  ethernet.h 
>   Log:
>   Const'ify parameters to ethers(3) routines as appropriate.
>   
>   Revision  ChangesPath
>   1.16  +6 -6  src/sys/net/ethernet.h

This breaks 'buildworld' in the 'lib/libpcap'.

The next patch seems to correct the error.

N.Dudorov

Index: contrib/libpcap/nametoaddr.c
===
RCS file: /store/CVS/src/contrib/libpcap/nametoaddr.c,v
retrieving revision 1.6
diff -b -u -r1.6 nametoaddr.c
--- contrib/libpcap/nametoaddr.c2000/01/30 00:43:34 1.6
+++ contrib/libpcap/nametoaddr.c2000/07/19 04:02:27
@@ -366,7 +366,7 @@
 }
 #else
 
-#if !defined(sgi) && !defined(__NetBSD__)
+#if !defined(sgi) && !defined(__NetBSD__) && !defined(__FreeBSD__)
 extern int ether_hostton(char *, struct ether_addr *);
 #endif
 


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

Lockups with recent PCM commits?

[Donn Miller]

Try this (with a very recent kernel):

cat /dev/audio

It locks up my machine.  Also, anything that accesses /dev/audio locks up
my machine, such as mpg123.

- Donn


Copyright (c) 1992-2000 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #0: Tue Jul 18 18:45:36 EDT 2000
[EMAIL PROTECTED]:/usr/src/sys/compile/CUSTOM
Timecounter "i8254"  frequency 1193182 Hz
CPU: Pentium/P55C (166.45-MHz 586-class CPU)
  Origin = "GenuineIntel"  Id = 0x543  Stepping = 3
  Features=0x8001bf
real memory  = 62914560 (61440K bytes)
avail memory = 57487360 (56140K bytes)
Preloaded elf kernel "kernel" at 0xc03bd000.
Preloaded userconfig_script "/boot/kernel.conf" at 0xc03bd09c.
Intel Pentium detected, installing workaround for F00F bug
seq0-63: Midi sequencers.
md0: Malloc disk
npx0:  on motherboard
npx0: INT 16 interface
pcib0:  on motherboard
pci0:  on pcib0
pci0:  at 0.0
isab0:  at device 1.0 on pci0
isa0:  on isab0
atapci0:  port 
0xd000-0xd00f,0xd400-0xd403,0xd800-0xd807,0xe000-0xe003,0xe400-0xe407 irq 11 at device 
1.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
ed0:  port 0xb800-0xb81f irq 10 at device 10.0 on 
pci0
ed0: address 00:c0:df:ed:0b:17, type NE2000 (16 bit) 
pci0:  at 19.0 irq 11
vga0:  at port 0x3c0-0x3df iomem 0xa-0xb on isa0
sc0:  on isa0
sc0: VGA <16 virtual consoles, flags=0x200>
fdc0:  at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
atkbdc0:  at port 0x60,0x64 on isa0
atkbd0:  flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
sio2 at port 0x3e8-0x3ef irq 4 on isa0
sio2: type 16550A
mse0:  at port 0x23c-0x23f irq 3 on isa0
mpu0: reset failed.
ppc0:  at port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on isa0
ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/16 bytes threshold
ppi0:  on ppbus0
lpt0:  on ppbus0
lpt0: Interrupt-driven port
plip0:  on ppbus0
unknown:  can't assign resources
unknown:  can't assign resources
unknown:  can't assign resources
unknown:  can't assign resources
sbc1:  at port 0x220-0x22f,0x388-0x38b,0x330-0x331 irq 5 drq 1,0 on isa0
pcm0:  on sbc1
midi1:  on sbc1
midi2:  on sbc1
ad0: 3093MB  [6704/15/63] at ata0-master using UDMA33
ad1: 1040MB  [2114/16/63] at ata0-slave using WDMA2
acd0: CDROM  at ata1-master using WDMA2

Re: randomdev entropy gathering is really weak

[George Michaelson]

Where for instance do these ideas fit into  the models proposed in 

draft-eastlake-randomness2-00.txt

or the proceeding RFC?

-George

--
George Michaelson |  DSTC Pty Ltd
Email: [EMAIL PROTECTED]|  University of Qld 4072
Phone: +61 7 3365 4310|  Australia
  Fax: +61 7 3365 4311|  http://www.dstc.edu.au




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

Re: randomdev entropy gathering is really weak

[Paul Herman]

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 clients are being treated as
> >untrusted (consider public terminals) and server has some critical
> >information on it.
> 
> Nobody talked about relying on *only* NTP for entropy, quite the 
> contrary in fact.

Just to quickly jump in (and out) here, I recall a thread that went on
for weeks in sci.crypt at the beginning of this year about the same
thing.  Before you all reinvent the wheel (and make this thread any
longer), I would suggest sauntering on over to dejanews.

For those who were patient enough to get past the usual banter, it was
quite enlightening, indeed.  They certainly have more of a clue about
these things than I would ever hope to have.

(Yes, they also talked about using NTP servers for gathering entropy.)

-Paul.




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

Re: randomdev entropy gathering is really weak

[Vadim Belman]

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
> >untrusted (consider public terminals) and server has some critical
> >information on it.
> 
> Nobody talked about relying on *only* NTP for entropy, quite the 
> contrary in fact.

This I understand. 8) Ok, I've gotten the answer from the thread,
somehow missed it before.

-- 
/Voland Vadim Belman


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

Re: randomdev entropy gathering is really weak

[Poul-Henning Kamp]

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 clients. At least some of the clients are being treated as
>untrusted (consider public terminals) and server has some critical
>information on it.

Nobody talked about relying on *only* NTP for entropy, quite the 
contrary in fact.

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


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

Re: randomdev entropy gathering is really weak

[Vadim Belman]

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 solution.
> 
> 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 clients. At least some of the clients are being treated as
untrusted (consider public terminals) and server has some critical
information on it.

-- 
/Voland Vadim Belman


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

Re: randomdev entropy gathering is really weak

[Poul-Henning Kamp]

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 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 solution.

This is about making a FreeBSD machine as good as we can in the
standard case.


--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


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

Re: randomdev entropy gathering is really weak

[Vadim Belman]

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 to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: randomdev entropy gathering is really weak

[Poul-Henning Kamp]

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), and I'm not familiar with crypto/entropy gathering/ntp, so forgive
>me if I ask a stupid question, but does everyone also think about those
>systems which have a more or less precise clock attached (e.g. GPS or
>atomic clocks which sync the system clock via nptd)? 

The reason why ntp is interesting is that we compare the received data
with our unpredictable local clock.  It is the result of this comparison
which is good entropy bits.

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


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

Re: randomdev entropy gathering is really weak

[Alexander Leidinger]

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 forgive
me if I ask a stupid question, but does everyone also think about those
systems which have a more or less precise clock attached (e.g. GPS or
atomic clocks which sync the system clock via nptd)? And what are the
numbers for this solution (for those people which are interested in
numbers to be their own judge)?

Bye,
Alexander.

-- 
   Reboot America.

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = 7423 F3E6 3A7E B334 A9CC  B10A 1F5F 130A A638 6E7E



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

Re: [usb-bsd] Re: USB modems

[Charles Anderson]

Speaking of manpages, are there any out there for ugen(4), uhid(4) & ulpt(4)
that are referenced in the usb(4) man page?

-Charlie
On Tue, Jul 18, 2000 at 11:43:09AM +0100, Nick Hibma wrote:
> > Well, the one you committed doesn't have the notification support I
> > added, or the serial state bits that are in usbcdc.h. Do you need/want
> > copies of the one I've been working on?
> 
> Yes, please. I must have them somewhere, but it might be a better idea
> to get your latest version.
> 
> > Looks like umodem.c didn't make it into conf/files, either.
> 
> Fixed (NOTES as well).
> 
> Man pages, we will need those as well. Anyone?
> 
> Nick
-- 
Charles Anderson[EMAIL PROTECTED]

No quote, no nothin'


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

Re: randomdev entropy gathering is really weak

[Poul-Henning Kamp]

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.

OK, then the answer is: "a couple of bits"

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


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 Malone]

> | (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 -i vary quite a lot with time
and would be difficult to guess in their entrieity, even given the
their values at some later date. While any piece of data from these
commands isn't hard to guess, the idea is to take a few bits of
each of them.

I don't claim this produces hundreds of bits of entropy, but I'd
expect it to produce ten or twenty bits, even if you are given the
output of these from some stage shortly in the future.

I note from Mark's comments that writing stuff to /dev/random
doesn't change /dev/random's notion of how much entropy it has,
but does reseed the generator - so what we're talking about here
is the entropy of the seed - or how difficult to guess it is. He
does mention a very similar way of reseeding to the above:

(ps -gauxwww; netstat -an; dmesg; vmstat -c10 1) > /dev/random

David.


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]

| 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 from:
| 
|   (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.

-Dan


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]

| 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 enterprising soul to add an option (default on) to
| ntpdate to write the received packets in toto to /dev/random
| if it exists.
| 
| If somebody does this, I will spear-head the effort of getting it
| into the ntpv4 sources (Hmm, don't  I have a commit bit there
| already ?  Can't remember...)

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

-Dan


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]

| >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
| >operations which can be performed to help seed the entropy pool.
| 
| What we really need is this:
| 
|   fetch -o http://entropy.freebsd.org/ > /dev/random
| 
| with a bunch of volounteers providing random bits to people in need.
| 
| 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.

If you wanted to have some fun with this, you could do a rc5-like distributed
client, feeding random bits to a server, and pulling down new bits every
so often!

-Dan


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

-Dan  


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]

> >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: http://www.cauce.org


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

Re: USB modems

[Nick Hibma]

> Well, the one you committed doesn't have the notification support I
> added, or the serial state bits that are in usbcdc.h. Do you need/want
> copies of the one I've been working on?

Yes, please. I must have them somewhere, but it might be a better idea
to get your latest version.

> Looks like umodem.c didn't make it into conf/files, either.

Fixed (NOTES as well).

Man pages, we will need those as well. Anyone?

Nick

--
[EMAIL PROTECTED]
[EMAIL PROTECTED]  USB project
http://www.etla.net/~n_hibma/



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 Malone]

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/ > /dev/random
> >  ^
> > 
> > If the world knows what they are, your bits aren't random enough.
> 
> Plus you need to authenticate (and obviously trust) your entropy server
> and the data stream to make sure they're not actually someone else feeding
> you zeros.

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 from:

(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.

David.


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

Re: randomdev entropy gathering is really weak

[Poul-Henning Kamp]

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 noise amplitude?

What do you mean by "amplitude" ?  The frequency deviation ?
The phase error ?

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


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

Re: USB modems

[Mike Meyer]

Nick Hibma writes:
> Right, I finally committed the driver you sent me. let me know if I've
> made a mistake and committed the wrong one. 

Well, the one you committed doesn't have the notification support I
added, or the serial state bits that are in usbcdc.h. Do you need/want
copies of the one I've been working on?

Looks like umodem.c didn't make it into conf/files, either.

> Mike, which Supra modem do you have? I've got a SupraMax 56K modem,
> SUP2920 and it gives me a rainforest worth of endpoints, not somethig
> that looks like a ACM CD Class device.

It's a SupraExpress 56K USB. I believe the SupraMax 56K is documented
as not being an ACM CD device. I've think I've set things up and
cleared my plate enough that I can work on the problem I've been
seeing.

I'm also curious about is whether anyone else using USB modems for ppp
is using userland ppp, or if they're all using kernel ppp.

Re: HEADS UP, mtree defaults returns back to original

[Andrey A. Chernov]

On Mon, Jul 17, 2000 at 11:18:17PM -0600, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> "Andrey A. Chernov" writes:
> : 2716:
> : mtree now NOT follows symlinks by default, old behaviour restored to be 
> : compatible with rest of *BSD camp. New -L option added to follow 
> : symlinks. This require manual mtree rebuilding before 'make world'
> 
> Is this still needed?

The last sentence is not needed.

-- 
Andrey A. Chernov
<[EMAIL PROTECTED]>
http://ache.pp.ru/


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]

> >> I ran a quick & dirty test here on some logfiles: that offset is
> >> very close to white noise.
> >
> >With what amplitude?
> 
> Depends on the termal environment of your xtal obviously :-)

Help me here! :-)

In your observed sample, what was the white noise amplitude?

M
--
Mark Murray
Join the 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: USB modems

[Nick Hibma]

Right, I finally committed the driver you sent me. let me know if I've
made a mistake and committed the wrong one. 

Mike, which Supra modem do you have? I've got a SupraMax 56K modem,
SUP2920 and it gives me a rainforest worth of endpoints, not somethig
that looks like a ACM CD Class device.

Nick

On Wed, 28 Jun 2000, Mike Meyer wrote:

> Warner Losh writes:
> > In message  Bob Bishop writes:
> > : Can anyone give a quick synopsis of the current status of support for USB
> > : modems? TIA
> > They aren't supported yet.  There's at least one group that might be
> > working on them.  The value of supporting them is well known.  Take
> > care in your purcahse of a usb modem because some of them expect an
> > isochronous audio stream...
> 
> Nick (and I, for that matter) have a umodem.c that works, for some
> definition of "works". It seems to work fine on USR USB modems. On the
> Supra I bought (because it was easily available), it works for dialout
> and makes PPP connections, but outgoing IP connections fail under an
> indeterminate set of conditions. It's not clear where the problem is -
> I'll be investigating it as soon as I once again have free time (a
> couple of weeks).
> 
> Nick has indicated he was going to try this version and commit it, but
> it hasn't happened yet.
> 
>
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 

--
[EMAIL PROTECTED]
[EMAIL PROTECTED]  USB project
http://www.etla.net/~n_hibma/



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, Bruce Evans wrote:

> You must have a fast machine to get 10MB/sec.  I see the following speeds
> (using a better reading program than dd; dd gives up on EOF on the old
> /dev/random):

Oops, I misread the rate by 2 orders of magnitude. I get about 100K/sec on
my PPro/233 :-)

> old /dev/random  on P5/1335K/sec
> old /dev/urandom on P5/133  244K/sec
> old /dev/random  on Celeron 366 overclocked to 5.5*9525K/sec
> old /dev/urandom on Celeron 366 overclocked to 5.5*95   970K/sec
> new /dev/*random on Celeron 400 overclocked to 6.0*75   270K/sec

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

[Mark Murray]

> With microsecond timestamps, 64second ntp poll period we are talking
> about approx 10 bits of randomness in the received packet and about
> 3 bits of randomness in the clock difference.
> 
> FreeBSD uses nanosecond timestamping (Actually could do nanoseconds
> with 32 bitfractions), but that only adds about 4 bits to the clock
> difference due to the clock frequency end interrupt hardware.

So the attacker is down to 17 bits == 128k guesses. Now that is good
entropy, but we need to know what the attacker can see inside the
packet etc. How else can he reduce his keyspace?

> No, it is not policy to try to get as many random bits as we can
> by default.  It would be policy to *not* do so for some obscure
> principle of scientific purity.

Pray explain?

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

[Bruce Evans]

On Sun, 16 Jul 2000, Kris Kennaway wrote:

> On the other hand, doing a dd if=/dev/random of=/dev/null gives me
> infinite "randomness" at 10MB/sec - have the semantics of /dev/random
> changed?

Yes.  /dev/random is now just an alias for /dev/urandom (or vice versa).

You must have a fast machine to get 10MB/sec.  I see the following speeds
(using a better reading program than dd; dd gives up on EOF on the old
/dev/random):

old /dev/random  on P5/1335K/sec
old /dev/urandom on P5/133  244K/sec
old /dev/random  on Celeron 366 overclocked to 5.5*9525K/sec
old /dev/urandom on Celeron 366 overclocked to 5.5*95   970K/sec
new /dev/*random on Celeron 400 overclocked to 6.0*75   270K/sec

Bruce



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

Re: randomdev entropy gathering is really weak

[Alexander Langer]

Thus spake Louis A. Mamakos ([EMAIL PROTECTED]):

> Actually, you could really use this in ntpd(8), rather than just ntpdate.

Hmm, as addition, I agree.

However, I think more people use ntpdate than ntpd, and thus ntpdate
is a good place :)

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


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