Re: CARP hash vuln
On Tue, Dec 21, 2010 at 2:23 AM, Fernando Quintero wrote: > some comment? > > http://seclists.org/bugtraq/2010/Dec/200 I'm not able to provide a solution, but this is of course a bug that needs to be fixed. I think claudio@ or henning@ are the right persons to ping... Ciao, David
Re: CARP hash vuln
On Tue, Dec 21, 2010 at 09:34:01AM +0100, David Coppa wrote: > On Tue, Dec 21, 2010 at 2:23 AM, Fernando Quintero > wrote: > > some comment? > > > > http://seclists.org/bugtraq/2010/Dec/200 > > I'm not able to provide a solution, but this is of course a bug that > needs to be fixed. If you look at my commit message from 3 years ago, you'll see that we are well aware of this: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet/ip_carp.c?f=h#rev1.152 If someone comes up with a replay protection that works without the help of synchronized clocks, I'm happy to fix this. OTOH, I'm still not convinced that it's worth the effort to fix a L2-only attack. There's still enough other ways for a DoS on L2.
Solvng the NVIDIA IDE/SATA/AHCI mess
We still have some some issues with SATA/AHCI on NVIDIA chipsets. If you have a machine, could you send me the following information: * dmesg * output of 'pcidump -vxx' * BIOS setting (IDE/SATA/AHCI/RAID) if your BIOS provides that opportunity * short description of any changes (BIOS settings, kernel config) you need to make to get things working. If your machine has the possibility to change the mode of the disk controller in the BIOS, and you're willing to spend some time, please try them all and and send me a report for all of these. Note that this may cause your disk to change from wd* to sd* or the other way around. So you may need to (temporarily) change your /etc/fstab. Thanks, Mark
Re: Solvng the NVIDIA IDE/SATA/AHCI mess
On Tue, 21 Dec 2010 11:27:30 +0100 (CET) Mark Kettenis wrote: > We still have some some issues with SATA/AHCI on NVIDIA chipsets. If > you have a machine, could you send me the following information: > > * dmesg > * output of 'pcidump -vxx' > * BIOS setting (IDE/SATA/AHCI/RAID) if your BIOS provides that opportunity > * short description of any changes (BIOS settings, kernel config) you > need to make to get things working. > > If your machine has the possibility to change the mode of the disk > controller in the BIOS, and you're willing to spend some time, please > try them all and and send me a report for all of these. Note that > this may cause your disk to change from wd* to sd* or the other way > around. So you may need to (temporarily) change your /etc/fstab. > > Thanks, > > Mark > I have an old athlon 64 nvidia board that used to work with 3.8 but last time I tried it (I think 4.6), it wouldn't boot (kernel restart) without disabling usb in the bios. I use OpenBSD on i386 so it's no issue to me but I've no problem running some info gathering etc. but are you wanting to concentrate on the newer boards, possibly being less troublesome and more useful to get working for hardware released in the future?
Re: Solvng the NVIDIA IDE/SATA/AHCI mess
On Tue, Dec 21, 2010 at 11:27:30AM +0100, Mark Kettenis wrote: > We still have some some issues with SATA/AHCI on NVIDIA chipsets. If > you have a machine, could you send me the following information: > > * dmesg > * output of 'pcidump -vxx' > * BIOS setting (IDE/SATA/AHCI/RAID) if your BIOS provides that opportunity > * short description of any changes (BIOS settings, kernel config) you > need to make to get things working. > > If your machine has the possibility to change the mode of the disk > controller in the BIOS, and you're willing to spend some time, please > try them all and and send me a report for all of these. Note that > this may cause your disk to change from wd* to sd* or the other way > around. So you may need to (temporarily) change your /etc/fstab. > > Thanks, > > Mark > Just a note to remind everyone that you can change your fstab to use DUIDs rather than wd* and sd*, thus making it easier to survive the flips between wd and sd when changing BIOS settings. Using wd0 as an example, just 'disklabel -E wd0' and w(rite), q(uit) to put a DUID in your disklabel if it hasn't got one. Then replace all instances of '/dev/wd0x' with .x in your fstab. And away you go. No need to worry about your disk flipping from wd to sd and back. Just did this and it works fine. My fstab now looks like d48d0e3fc1c39531.a / ffs rw,softdep 1 1 d48d0e3fc1c39531.k /home ffs rw,nodev,nosuid,softdep 1 2 d48d0e3fc1c39531.d /tmp ffs rw,nodev,nosuid,softdep 1 2 d48d0e3fc1c39531.f /usr ffs rw,nodev,softdep 1 2 d48d0e3fc1c39531.g /usr/X11R6 ffs rw,nodev,softdep 1 2 d48d0e3fc1c39531.h /usr/local ffs rw,nodev,softdep 1 2 d48d0e3fc1c39531.j /usr/obj ffs rw,nodev,nosuid,softdep 1 2 d48d0e3fc1c39531.i /usr/src ffs rw,nodev,nosuid,softdep 1 2 and changing my bios setting to flip back and forth from wd0 to sd0 has no effect on booting. Ken
Re: Solvng the NVIDIA IDE/SATA/AHCI mess
On Tue, Dec 21, 2010 at 12:53 PM, Kenneth R Westerback wrote: > Just a note to remind everyone that you can change your fstab to > use DUIDs rather than wd* and sd*, thus making it easier to survive > the flips between wd and sd when changing BIOS settings. > > Using wd0 as an example, just 'disklabel -E wd0' and w(rite), q(uit) > to put a DUID in your disklabel if it hasn't got one. Then replace > all instances of '/dev/wd0x' with .x in your fstab. And away > you go. No need to worry about your disk flipping from wd to sd and > back. > > Just did this and it works fine. My fstab now looks like Yeah, I also do this, and it works fine. Otherwise, If I boot my laptop with a pendrive inserted, my softraid crypto volumes go nuts. ciao, david
Change vnd disk name based on mode
When a vnd(4) device is configured the device name is always configured as
vndX, even when it is created as a "safe" vnd (or svndX). This device name
is also used as the name for the disk:
$ vnconfig -c svnd0 /tmp/test
$ sysctl hw.disknames
hw.disknames=sd0:19291b8cb83eb8b8,cd0:,vnd0:
When DUIDs are used we end up mapping back to a device node using the name
of the disk. This means that we always end up using /dev/vnd* even for svnd
disks.
The following diff adds a separate disk name that is populated based on
the mode that the vnd(4) is created with. This means that if you created
a vnd disk then the disk name will be vndX and diskmap(4) will open the
/dev/vnd* devices. Whereas if you created a svnd disk then the disk name
will be svndX and diskmap(4) will open /dev/svnd* devices.
ok?
Index: vnd.c
===
RCS file: /cvs/src/sys/dev/vnd.c,v
retrieving revision 1.103
diff -u -p -r1.103 vnd.c
--- vnd.c 22 Sep 2010 01:18:57 - 1.103
+++ vnd.c 16 Nov 2010 14:37:41 -
@@ -125,6 +125,7 @@ struct pool vndbufpl;
struct vnd_softc {
struct devicesc_dev;
struct disk sc_dk;
+ char sc_dk_name[16];
char sc_file[VNDNLEN]; /* file we're covering */
int sc_flags; /* flags */
@@ -780,6 +781,7 @@ vndioctl(dev_t dev, u_long cmd, caddr_t
return (error);
}
+ /* Set device name. */
bzero(vnd->sc_dev.dv_xname, sizeof(vnd->sc_dev.dv_xname));
if (snprintf(vnd->sc_dev.dv_xname, sizeof(vnd->sc_dev.dv_xname),
"vnd%d", unit) >= sizeof(vnd->sc_dev.dv_xname)) {
@@ -788,6 +790,16 @@ vndioctl(dev_t dev, u_long cmd, caddr_t
return(ENXIO);
}
+ /* Set disk name depending on how we were created. */
+ bzero(vnd->sc_dk_name, sizeof(vnd->sc_dk_name));
+ if (snprintf(vnd->sc_dk_name, sizeof(vnd->sc_dk_name),
+ "%svnd%d", ((vnd->sc_flags & VNF_SIMPLE) ? "s" : ""),
+ unit) >= sizeof(vnd->sc_dk_name)) {
+ printf("VNDIOCSET: disk name too long\n");
+ vndunlock(vnd);
+ return(ENXIO);
+ }
+
/* Set geometry for device. */
vnd->sc_secsize = vio->vnd_secsize;
vnd->sc_ntracks = vio->vnd_ntracks;
@@ -865,7 +877,7 @@ vndioctl(dev_t dev, u_long cmd, caddr_t
vnd->sc_vp, (unsigned long long)vnd->sc_size);
/* Attach the disk. */
- vnd->sc_dk.dk_name = vnd->sc_dev.dv_xname;
+ vnd->sc_dk.dk_name = vnd->sc_dk_name;
disk_attach(&vnd->sc_dev, &vnd->sc_dk);
vndunlock(vnd);
--
"Stop assuming that systems are secure unless demonstrated insecure;
start assuming that systems are insecure unless designed securely."
- Bruce Schneier
Re: allow bioctl to read passphrase from stdin
On Mon, Nov 29, 2010 at 02:22:35PM -0800, Chris Kuethe wrote: >Currently bioctl invokes readpassphrase(3) with RPP_REQUIRE_TTY, which >means that there must be a controlling tty to read the password from. >This diff adds an option (-s) to force bioctl to read the passphrase >from stdin. Without this option existing behavior is maintained. Hello, little improvement of bioctl(8), when using stdin it cannot be used for inital creation of the crypt volume. (there's same info for passfile.) jirib Index: bioctl.8 === RCS file: /cvs/src/sbin/bioctl/bioctl.8,v retrieving revision 1.83 diff -u -p -r1.83 bioctl.8 --- bioctl.81 Dec 2010 19:40:18 - 1.83 +++ bioctl.821 Dec 2010 13:20:39 - @@ -240,6 +240,7 @@ Read the passphrase for the selected cry .Pa /dev/stdin rather than .Pa /dev/tty . +It cannot be used during the initial creation of the crypto volume. .El .Sh EXAMPLES The following command, executed from the command line, would configure
Re: Change vnd disk name based on mode
I've been successfully running with this since Nov 24th. Definately
changes the behavior as advertised and has no issues that I have
seen in my testing, using duid's on svnd(4) on i386.
Penned by Joel Sing on 20101221 6:30.49, we have:
| When a vnd(4) device is configured the device name is always configured as
| vndX, even when it is created as a "safe" vnd (or svndX). This device name
| is also used as the name for the disk:
|
| $ vnconfig -c svnd0 /tmp/test
| $ sysctl hw.disknames
| hw.disknames=sd0:19291b8cb83eb8b8,cd0:,vnd0:
|
| When DUIDs are used we end up mapping back to a device node using the name
| of the disk. This means that we always end up using /dev/vnd* even for svnd
| disks.
|
| The following diff adds a separate disk name that is populated based on
| the mode that the vnd(4) is created with. This means that if you created
| a vnd disk then the disk name will be vndX and diskmap(4) will open the
| /dev/vnd* devices. Whereas if you created a svnd disk then the disk name
| will be svndX and diskmap(4) will open /dev/svnd* devices.
|
| ok?
|
| Index: vnd.c
| ===
| RCS file: /cvs/src/sys/dev/vnd.c,v
| retrieving revision 1.103
| diff -u -p -r1.103 vnd.c
| --- vnd.c 22 Sep 2010 01:18:57 - 1.103
| +++ vnd.c 16 Nov 2010 14:37:41 -
| @@ -125,6 +125,7 @@ struct pool vndbufpl;
| struct vnd_softc {
| struct devicesc_dev;
| struct disk sc_dk;
| + char sc_dk_name[16];
|
| char sc_file[VNDNLEN]; /* file we're covering */
| int sc_flags; /* flags */
| @@ -780,6 +781,7 @@ vndioctl(dev_t dev, u_long cmd, caddr_t
| return (error);
| }
|
| + /* Set device name. */
| bzero(vnd->sc_dev.dv_xname, sizeof(vnd->sc_dev.dv_xname));
| if (snprintf(vnd->sc_dev.dv_xname, sizeof(vnd->sc_dev.dv_xname),
| "vnd%d", unit) >= sizeof(vnd->sc_dev.dv_xname)) {
| @@ -788,6 +790,16 @@ vndioctl(dev_t dev, u_long cmd, caddr_t
| return(ENXIO);
| }
|
| + /* Set disk name depending on how we were created. */
| + bzero(vnd->sc_dk_name, sizeof(vnd->sc_dk_name));
| + if (snprintf(vnd->sc_dk_name, sizeof(vnd->sc_dk_name),
| + "%svnd%d", ((vnd->sc_flags & VNF_SIMPLE) ? "s" : ""),
| + unit) >= sizeof(vnd->sc_dk_name)) {
| + printf("VNDIOCSET: disk name too long\n");
| + vndunlock(vnd);
| + return(ENXIO);
| + }
| +
| /* Set geometry for device. */
| vnd->sc_secsize = vio->vnd_secsize;
| vnd->sc_ntracks = vio->vnd_ntracks;
| @@ -865,7 +877,7 @@ vndioctl(dev_t dev, u_long cmd, caddr_t
| vnd->sc_vp, (unsigned long long)vnd->sc_size);
|
| /* Attach the disk. */
| - vnd->sc_dk.dk_name = vnd->sc_dev.dv_xname;
| + vnd->sc_dk.dk_name = vnd->sc_dk_name;
| disk_attach(&vnd->sc_dev, &vnd->sc_dk);
|
| vndunlock(vnd);
|
|
| --
|
|"Stop assuming that systems are secure unless demonstrated insecure;
| start assuming that systems are insecure unless designed securely."
| - Bruce Schneier
--
Todd Fries .. t...@fries.net
_
| \ 1.636.410.0632 (voice)
| Free Daemon Consulting, LLC \ 1.405.227.9094 (voice)
| http://FreeDaemonConsulting.com \ 1.866.792.3418 (FAX)
| 2525 NW Expy #525, Oklahoma City, OK 73112 \ sip:freedae...@ekiga.net
| "..in support of free software solutions." \ sip:4052279...@ekiga.net
\\
37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A
http://todd.fries.net/pgp.txt
Re: Allegations regarding OpenBSD IPSEC
Hi, I think I might have found two "bugs" in the code of src/sys/dev/rnd.c. I put up a description here. http://bit.ly/hNLDqC Can you please comment on my findings? Thank you! Regards Kurt Knochner http://knochner.com/
Re: Allegations regarding OpenBSD IPSEC
Hi,
upfront: sorry for double posting!! Some people told me, that I should send
my findings directly to the list instead of a link. Sorry if I violated the
netiquette on the list!
So, here we go again (text from the forum where I posted it).
regarding the allegations about a backdoor beeing planted into OpenBSD, I
did a code review myself and I believe that I've found two bugs in the PRNG
code. I'm NOT saying that this is the backdoor or even part of the backdoor.
I'm not even saying, that these two bugs create a weakness in the PRNG
itself, however the two bugs just don't look good and possibly need more
investigation!!
Here we go...
OpenBSD uses arc4random() and arc4random_buf() all over the code to generate
random numbers. This code is defined in src/sys/dev/rnd.c.
Within arc4random() and arc4random_buf() the code flow is like this:
arc4random -> arc4maybeinit -> arc4_stir
arc4_stir() will be called at least every 10 minutes, as a timer is set
within arc4maybeinit() that resets the variable 'arc4random_initialized'
(see below).
> static void
> arc4maybeinit(void)
> {
>
> if (!arc4random_initialized) {
> #ifdef DIAGNOSTIC
> if (!rnd_attached)
> panic("arc4maybeinit: premature");
> #endif
> arc4random_initialized++;
> arc4_stir();
> /* 10 minutes, per dm@'s suggestion */
> timeout_add_sec(&arc4_timeout, 10 * 60);
> }
> }
Now, let's have a look at arc4_stir().
> arc4_stir(void)
> {
> u_int8_t buf[256];
> int len;
>
> nanotime((struct timespec *) buf);
> len = sizeof(buf) - sizeof(struct timespec);
> get_random_bytes(buf + sizeof (struct timespec), len);
> len += sizeof(struct timespec);
>
> mtx_enter(&rndlock);
>if (rndstats.arc4_nstirs > 0)
>rc4_crypt(&arc4random_state, buf, buf, sizeof(buf));
>
>rc4_keysetup(&arc4random_state, buf, sizeof(buf));
>arc4random_count = 0;
> rndstats.arc4_stirs += len;
> rndstats.arc4_nstirs++;
>
>/*
> * Throw away the first N words of output, as suggested in the
> * paper "Weaknesses in the Key Scheduling Algorithm of RC4"
> * by Fluher, Mantin, and Shamir. (N = 256 in our case.)
> */
>rc4_skip(&arc4random_state, 256 * 4);
>mtx_leave(&rndlock);
>
> }
This initializes the RC4 context with some random data, gathered by system
enthropy, that is mainly done by get_random_bytes().
==> Bug #1
HOWEVER: Have a look at the buffer that's beeing used as a seed for the RC4
key setup. It's beeing filled with the random data, BUT at the beginning it
will be filled with just the value of nanotime().
>nanotime((struct timespec *) buf);
>len = sizeof(buf) - sizeof(struct timespec);
>get_random_bytes(buf + sizeof (struct timespec), len);
>len += sizeof(struct timespec);
So, there is a lot of effort in get_random_bytes() to get "real random" data
for the buffer and then the value of nanotime() is prepended to the buffer?
That does not look right. Please consider: this buffer will be used as key
for rc4_keysetup() and thus it should contain unrelated and unpredictable
data.
==> Bug #2
The function rc4_crypt() get's called as soon as rndstats.arc4_nstirs > 0.
This will be the case whenever arc4_stir get's called the second time (by
the timer reset - see above).
>if (rndstats.arc4_nstirs > 0)
>rc4_crypt(&arc4random_state, buf, buf, sizeof(buf));
>rc4_keysetup(&arc4random_state, buf, sizeof(buf));
>arc4random_count = 0;
>rndstats.arc4_stirs += len;
>rndstats.arc4_nstirs++;
HOWEVER, right after the call of rc4_crypt(), we call rc4_keysetup() with
the same 'arc4random_state'. This makes the call to rc4_crypt() useless, as
the data structure will be overwritten again with the init data of the RC4
function.
AGAIN: I'm not saying that this is part of the backdoor nor that it weakens
the PRNG. HOWEVER, this does not look right and leaves some bad feeling for
me!
I think we will need some investigation on the effect of PRNG quality caused
by these two bugs.
Regards
Kurt Knochner
http://knochner.com/
Yahoo! Italia - notizia - 學習右腦圖像記憶法只要1600元!! - Yahoo!奇摩部落格
Return-path: refertofriend-er...@reply.yahoo.com Leslie (con...@yahoo.com) ti ha inviato un articolo Testo del messaggio: ■學習圖像記憶法1600元■ ■保證國立大學師資■ ■東風衛視節目的老師親自錄的■ ■保證完整學習9片VCD還有教材■ ■想了解更多資訊嗎?■ ■請按下面網址進入網站■ PBMS school Eurocup - Treviso imbattuta, ok Cant, no Caserta http://tw.myblog.yahoo.com/pbms-tw2
Re: Allegations regarding OpenBSD IPSEC
On Tue, Dec 21, 2010 at 05:59:33PM +0100, Kurt Knochner wrote:
> Hi,
>
> upfront: sorry for double posting!! Some people told me, that I should send
> my findings directly to the list instead of a link. Sorry if I violated the
> netiquette on the list!
>
> So, here we go again (text from the forum where I posted it).
>
> regarding the allegations about a backdoor beeing planted into OpenBSD, I
> did a code review myself and I believe that I've found two bugs in the PRNG
> code. I'm NOT saying that this is the backdoor or even part of the backdoor.
> I'm not even saying, that these two bugs create a weakness in the PRNG
> itself, however the two bugs just don't look good and possibly need more
> investigation!!
>
> Here we go...
>
> OpenBSD uses arc4random() and arc4random_buf() all over the code to generate
> random numbers. This code is defined in src/sys/dev/rnd.c.
>
> Within arc4random() and arc4random_buf() the code flow is like this:
>
> arc4random -> arc4maybeinit -> arc4_stir
>
> arc4_stir() will be called at least every 10 minutes, as a timer is set
> within arc4maybeinit() that resets the variable 'arc4random_initialized'
> (see below).
>
> > static void
> > arc4maybeinit(void)
> > {
> >
> > if (!arc4random_initialized) {
> > #ifdef DIAGNOSTIC
> > if (!rnd_attached)
> > panic("arc4maybeinit: premature");
> > #endif
> > arc4random_initialized++;
> > arc4_stir();
> > /* 10 minutes, per dm@'s suggestion */
> > timeout_add_sec(&arc4_timeout, 10 * 60);
> > }
> > }
>
> Now, let's have a look at arc4_stir().
>
> > arc4_stir(void)
> > {
> > u_int8_t buf[256];
> > int len;
> >
> > nanotime((struct timespec *) buf);
> > len = sizeof(buf) - sizeof(struct timespec);
> > get_random_bytes(buf + sizeof (struct timespec), len);
> > len += sizeof(struct timespec);
> >
> > mtx_enter(&rndlock);
> >if (rndstats.arc4_nstirs > 0)
> >rc4_crypt(&arc4random_state, buf, buf, sizeof(buf));
> >
> >rc4_keysetup(&arc4random_state, buf, sizeof(buf));
> >arc4random_count = 0;
> > rndstats.arc4_stirs += len;
> > rndstats.arc4_nstirs++;
> >
> >/*
> > * Throw away the first N words of output, as suggested in the
> > * paper "Weaknesses in the Key Scheduling Algorithm of RC4"
> > * by Fluher, Mantin, and Shamir. (N = 256 in our case.)
> > */
> >rc4_skip(&arc4random_state, 256 * 4);
> >mtx_leave(&rndlock);
> >
> > }
>
> This initializes the RC4 context with some random data, gathered by system
> enthropy, that is mainly done by get_random_bytes().
>
> ==> Bug #1
>
> HOWEVER: Have a look at the buffer that's beeing used as a seed for the RC4
> key setup. It's beeing filled with the random data, BUT at the beginning it
> will be filled with just the value of nanotime().
>
> >nanotime((struct timespec *) buf);
> >len = sizeof(buf) - sizeof(struct timespec);
> >get_random_bytes(buf + sizeof (struct timespec), len);
> >len += sizeof(struct timespec);
>
>
> So, there is a lot of effort in get_random_bytes() to get "real random" data
> for the buffer and then the value of nanotime() is prepended to the buffer?
> That does not look right. Please consider: this buffer will be used as key
> for rc4_keysetup() and thus it should contain unrelated and unpredictable
> data.
I don't know the answer to this question, but my guess is that the
buffer is filled by nanotime() to cover the case that
get_random_bytes() does not have enough entropy available, so at least
some non-constant data is used.
>
> ==> Bug #2
>
> The function rc4_crypt() get's called as soon as rndstats.arc4_nstirs > 0.
> This will be the case whenever arc4_stir get's called the second time (by
> the timer reset - see above).
>
> >if (rndstats.arc4_nstirs > 0)
> >rc4_crypt(&arc4random_state, buf, buf, sizeof(buf));
>
> >rc4_keysetup(&arc4random_state, buf, sizeof(buf));
> >arc4random_count = 0;
> >rndstats.arc4_stirs += len;
> >rndstats.arc4_nstirs++;
>
> HOWEVER, right after the call of rc4_crypt(), we call rc4_keysetup() with
> the same 'arc4random_state'. This makes the call to rc4_crypt() useless, as
> the data structure will be overwritten again with the init data of the RC4
> function.
rc4_crypt() changes both the state and the contents of buf, since buf is
used both as source and destination. That buf is used by rc4_keysetup()
to create a new state. So indeed the state is overwritten, but the
contents of buf produced by rc4_crypt() is used to do that. So both
calls serve their purpose.
-Otto
>
> AGAIN: I'm not saying that this is part of the backdoor nor that it weakens
> the PRNG. HOWEVER, this does not look right and leaves some bad feeling for
> me!
>
> I think w
Re: Allegations regarding OpenBSD IPSEC
On Tue, Dec 21, 2010 at 11:59 AM, Kurt Knochner wrote: > This initializes the RC4 context with some random data, gathered by system > enthropy, that is mainly done by get_random_bytes(). > > ==> Bug #1 > > HOWEVER: Have a look at the buffer that's beeing used as a seed for the RC4 > key setup. It's beeing filled with the random data, BUT at the beginning it > will be filled with just the value of nanotime(). Even nanotime is better than all zeros. It's to ensure the seed values changes at least a little, even if there are no random bytes. >>if (rndstats.arc4_nstirs > 0) >>rc4_crypt(&arc4random_state, buf, buf, sizeof(buf)); > >>rc4_keysetup(&arc4random_state, buf, sizeof(buf)); >>arc4random_count = 0; >>rndstats.arc4_stirs += len; >>rndstats.arc4_nstirs++; > > HOWEVER, right after the call of rc4_crypt(), we call rc4_keysetup() with > the same 'arc4random_state'. This makes the call to rc4_crypt() useless, as > the data structure will be overwritten again with the init data of the RC4 > function. buf is an input to rc4_keysetup, not an output.
Re: Allegations regarding OpenBSD IPSEC
> regarding the allegations about a backdoor beeing planted into OpenBSD, I > did a code review myself [...] By the way... It is unfortunate that it required an allegation of this sort for people to get to the point where they stop blindly trusting and instead go audit the code But looked at from the half-glass-full side, it is refreshing to see people trying!
Re: Allegations regarding OpenBSD IPSEC
2010/12/21 Otto Moerbeek
> > So, there is a lot of effort in get_random_bytes() to get "real random"
data
> > for the buffer and then the value of nanotime() is prepended to the
buffer?
> > That does not look right. Please consider: this buffer will be used as
key
> > for rc4_keysetup() and thus it should contain unrelated and
unpredictable
> > data.
>
> I don't know the answer to this question, but my guess is that the
> buffer is filled by nanotime() to cover the case that
> get_random_bytes() does not have enough entropy available, so at least
> some non-constant data is used.
get_random_bytes() calls extract_entropy() which is a a loop around nbytes,
thus get_random_bytes() will most certainly deliver enough entropy.
So, why do we need a nanotime value in front of the buffer? I'm just
thinking about those weaknesses of RC4 if the initial key is not good/strong
enough?
http://www.rsa.com/rsalabs/node.asp?id=2009
But then, this is "just" the initialization of the PRNG and not the
encryption itself, so maybe it has no meaning at all.
> > HOWEVER, right after the call of rc4_crypt(), we call rc4_keysetup()
with
> > the same 'arc4random_state'. This makes the call to rc4_crypt() useless,
as
> > the data structure will be overwritten again with the init data of the
RC4
> > function.
>
> rc4_crypt() changes both the state and the contents of buf, since buf is
> used both as source and destination. That buf is used by rc4_keysetup()
> to create a new state. So indeed the state is overwritten, but the
> contents of buf produced by rc4_crypt() is used to do that. So both
> calls serve their purpose.
yes, you are right! I did not see the changes to buf in rc4_crypt(). Sorry
for that!
But still, why is it done this way?
I compared the implementation of arc4_stir with the one in libc
(src/lib/libc/crypt/arc4random.c). The implementations are somehow
different.
The in libc the rc4 state is only initialized once at the first call of
arc4_stir() and then there are consecutive calls to arc4_addrandom() which
is the equivalent of rc4_crypt(). So, there is a difference in the
implementation. May this is just due to different authors.
First question: Which one is the 'correct' implementation, as proposed in
Applied Cryptography (hint in libc -> arc4random.c)?
Second question: Does it matter if the implementation is different than the
one in Applied Cryptography?
A last thing:
From: src/lib/libc/crypt/arc4random.c
arc4_stir(void)
{
/*
* Discard early keystream, as per recommendations in:
* http://www.wisdom.weizmann.ac.il/~itsik/RC4/Papers/Rc4_ksa.ps
*/
for (i = 0; i < 256; i++)
(void)arc4_getbyte();
arc4_count = 160;
}
The first 256 Bytes will be skipped due to the mentioned paper. Similar code
exists in rnd.c.
/*
* Throw away the first N words of output, as suggested in the
* paper "Weaknesses in the Key Scheduling Algorithm of RC4"
* by Fluher, Mantin, and Shamir. (N = 256 in our case.)
*/
rc4_skip(&arc4random_state, 256 * 4);
mtx_leave(&rndlock);
However here, 1024 bytes (256 * 4) will be skipped. Maybe that's just a
misinterpretation of what a "word" is (byte or integer).
Maybe I'm paranoid and see problems where there are none. But then, this is
part of the crypto code and there should be no open questions about the
implementation details.
Regards
Kurt Knochner
http://knochner.com/
Re: Allegations regarding OpenBSD IPSEC
On Tue, Dec 21, 2010 at 06:51:03PM +0100, Otto Moerbeek wrote:
> On Tue, Dec 21, 2010 at 05:59:33PM +0100, Kurt Knochner wrote:
> > OpenBSD uses arc4random() and arc4random_buf() all over the code to generate
> > random numbers. This code is defined in src/sys/dev/rnd.c.
> > [arc4stir] initializes the RC4 context with some random data, gathered by
> > system
> > enthropy, that is mainly done by get_random_bytes().
> >
> > ==> Bug #1
> >
> > HOWEVER: Have a look at the buffer that's beeing used as a seed for the RC4
> > key setup. It's beeing filled with the random data, BUT at the beginning it
> > will be filled with just the value of nanotime().
> >
> > >nanotime((struct timespec *) buf);
> > >len = sizeof(buf) - sizeof(struct timespec);
> > >get_random_bytes(buf + sizeof (struct timespec), len);
> > >len += sizeof(struct timespec);
> >
> >
> > So, there is a lot of effort in get_random_bytes() to get "real random" data
> > for the buffer and then the value of nanotime() is prepended to the buffer?
> > That does not look right. Please consider: this buffer will be used as key
> > for rc4_keysetup() and thus it should contain unrelated and unpredictable
> > data.
>
> I don't know the answer to this question, but my guess is that the
> buffer is filled by nanotime() to cover the case that
> get_random_bytes() does not have enough entropy available, so at least
> some non-constant data is used.
Wouldn't it be better to XOR this into the data returned from
get_random_bytes(), though? That'd get you optimal entropy in either
case.
Sample diff (which also removes the len variable):
Index: rnd.c
===
RCS file: /usr/cvs/src/src/sys/dev/rnd.c,v
retrieving revision 1.104
diff -u -p -r1.104 rnd.c
--- rnd.c 21 Nov 2010 22:58:40 - 1.104
+++ rnd.c 21 Dec 2010 18:19:35 -
@@ -779,13 +779,14 @@ get_random_bytes(void *buf, size_t nbyte
static void
arc4_stir(void)
{
- u_int8_t buf[256];
- int len;
+ u_int8_t buf[256];
+ struct timespec ts;
+ int i;
- nanotime((struct timespec *) buf);
- len = sizeof(buf) - sizeof(struct timespec);
- get_random_bytes(buf + sizeof (struct timespec), len);
- len += sizeof(struct timespec);
+ get_random_bytes(buf, sizeof(buf));
+ nanotime(&ts);
+ for (i = 0; i < sizeof(ts); i++)
+ buf[i] ^= ((uint8_t *) &ts)[i];
mtx_enter(&rndlock);
if (rndstats.arc4_nstirs > 0)
@@ -793,7 +794,7 @@ arc4_stir(void)
rc4_keysetup(&arc4random_state, buf, sizeof(buf));
arc4random_count = 0;
- rndstats.arc4_stirs += len;
+ rndstats.arc4_stirs += sizeof(buf);
rndstats.arc4_nstirs++;
/*
> > ==> Bug #2
> >
> > The function rc4_crypt() get's called as soon as rndstats.arc4_nstirs > 0.
> > This will be the case whenever arc4_stir get's called the second time (by
> > the timer reset - see above).
> >
> > >if (rndstats.arc4_nstirs > 0)
> > >rc4_crypt(&arc4random_state, buf, buf, sizeof(buf));
> >
> > >rc4_keysetup(&arc4random_state, buf, sizeof(buf));
> > >arc4random_count = 0;
> > >rndstats.arc4_stirs += len;
> > >rndstats.arc4_nstirs++;
> >
> > HOWEVER, right after the call of rc4_crypt(), we call rc4_keysetup() with
> > the same 'arc4random_state'. This makes the call to rc4_crypt() useless, as
> > the data structure will be overwritten again with the init data of the RC4
> > function.
>
> rc4_crypt() changes both the state and the contents of buf, since buf is
> used both as source and destination. That buf is used by rc4_keysetup()
> to create a new state. So indeed the state is overwritten, but the
> contents of buf produced by rc4_crypt() is used to do that.
Yes, that does seem right.
By the way, the arc4random_count variable doesn't seem to be used; is
there a reason not to garbage-collect it?
Joachim
Re: Allegations regarding OpenBSD IPSEC
2010/12/21 Theo de Raadt > > > regarding the allegations about a backdoor beeing planted into OpenBSD, I > > did a code review myself [...] > > By the way... > > It is unfortunate that it required an allegation of this sort for > people to get to the point where they stop blindly trusting and > instead go audit the code without a 'hint' (true or fake), where would you start auditing the code? It's just too much. Now, as I have started with it, I will continue to do so, at least with the crypto code and PRNG code. However, don't get me wrong. I'm neither a cryptographer nor have I ever touched the openbsd code before. I did some patching for BSDI BSD/OS (ages ago), but that's it with my *bsd code contact. > But looked at from the half-glass-full side, it is refreshing to see > people trying! :-) BTW: iTWire mentions, that two bugs have been found in the crypto code. Where can I find details on those bugs? http://www.itwire.com/opinion-and-analysis/open-sauce/43995-openbsd-backdoor-claims-code-audit-begins Regards Kurt Knochner http://knochner.com/
Re: Allegations regarding OpenBSD IPSEC
On Tue, Dec 21, 2010 at 07:45:09PM +0100, Kurt Knochner wrote:
> 2010/12/21 Otto Moerbeek
>
> > > So, there is a lot of effort in get_random_bytes() to get "real random"
> data
> > > for the buffer and then the value of nanotime() is prepended to the
> buffer?
> > > That does not look right. Please consider: this buffer will be used as
> key
> > > for rc4_keysetup() and thus it should contain unrelated and
> unpredictable
> > > data.
> >
> > I don't know the answer to this question, but my guess is that the
> > buffer is filled by nanotime() to cover the case that
> > get_random_bytes() does not have enough entropy available, so at least
> > some non-constant data is used.
>
> get_random_bytes() calls extract_entropy() which is a a loop around nbytes,
> thus get_random_bytes() will most certainly deliver enough entropy.
extract_entropy() does not guarantee the collected bytes will have
enough entropy. Think about situations very early in machine startup,
where the state of things could be predictable.
During multi-user startup OpenBSD will stir the random pool to ensure
this does not happen, but there is a window where rnd(4) might not
have collected enough entropy yet.
For you remarks below I'll have to check some more things, don't have
time for that now.
-Otto
>
> So, why do we need a nanotime value in front of the buffer? I'm just
> thinking about those weaknesses of RC4 if the initial key is not good/strong
> enough?
>
> http://www.rsa.com/rsalabs/node.asp?id=2009
>
> But then, this is "just" the initialization of the PRNG and not the
> encryption itself, so maybe it has no meaning at all.
>
> > > HOWEVER, right after the call of rc4_crypt(), we call rc4_keysetup()
> with
> > > the same 'arc4random_state'. This makes the call to rc4_crypt() useless,
> as
> > > the data structure will be overwritten again with the init data of the
> RC4
> > > function.
> >
> > rc4_crypt() changes both the state and the contents of buf, since buf is
> > used both as source and destination. That buf is used by rc4_keysetup()
> > to create a new state. So indeed the state is overwritten, but the
> > contents of buf produced by rc4_crypt() is used to do that. So both
> > calls serve their purpose.
>
> yes, you are right! I did not see the changes to buf in rc4_crypt(). Sorry
> for that!
>
> But still, why is it done this way?
>
> I compared the implementation of arc4_stir with the one in libc
> (src/lib/libc/crypt/arc4random.c). The implementations are somehow
> different.
>
> The in libc the rc4 state is only initialized once at the first call of
> arc4_stir() and then there are consecutive calls to arc4_addrandom() which
> is the equivalent of rc4_crypt(). So, there is a difference in the
> implementation. May this is just due to different authors.
>
> First question: Which one is the 'correct' implementation, as proposed in
> Applied Cryptography (hint in libc -> arc4random.c)?
> Second question: Does it matter if the implementation is different than the
> one in Applied Cryptography?
>
> A last thing:
>
> From: src/lib/libc/crypt/arc4random.c
>
> arc4_stir(void)
> {
>
>
> /*
> * Discard early keystream, as per recommendations in:
> * http://www.wisdom.weizmann.ac.il/~itsik/RC4/Papers/Rc4_ksa.ps
> */
> for (i = 0; i < 256; i++)
> (void)arc4_getbyte();
> arc4_count = 160;
> }
>
>
> The first 256 Bytes will be skipped due to the mentioned paper. Similar code
> exists in rnd.c.
>
> /*
> * Throw away the first N words of output, as suggested in the
> * paper "Weaknesses in the Key Scheduling Algorithm of RC4"
> * by Fluher, Mantin, and Shamir. (N = 256 in our case.)
> */
> rc4_skip(&arc4random_state, 256 * 4);
> mtx_leave(&rndlock);
>
> However here, 1024 bytes (256 * 4) will be skipped. Maybe that's just a
> misinterpretation of what a "word" is (byte or integer).
>
> Maybe I'm paranoid and see problems where there are none. But then, this is
> part of the crypto code and there should be no open questions about the
> implementation details.
>
> Regards
> Kurt Knochner
>
> http://knochner.com/
Re: Allegations regarding OpenBSD IPSEC
2010/12/21 Joachim Schipper : > + get_random_bytes(buf, sizeof(buf)); > + nanotime(&ts); > + for (i = 0; i < sizeof(ts); i++) > + buf[i] ^= ((uint8_t *) &ts)[i]; I like the idea of using XOR. However, there are two issues: 1.) if nanotime() was called because of not enough random data from get_random_bytes() then you could end up with only the value &ts in buf. Why not use a md5 hash of the time value (better than the plain time value) or better just don't use the time value at all. I think get_random_bytes will allways return enough random data - see my other post. 2.) don't forget to check if sizeof(ts) <= sizeof(buf), otherwise you will create a buffer overrun. Regards Kurt Knochner http://knochner.com/
Re: Allegations regarding OpenBSD IPSEC
2010/12/21 Kurt Knochner : > 2.) don't forget to check if sizeof(ts) <= sizeof(buf), otherwise you > will create a buffer overrun. O.K. this one is not THAT critical, as buf is defined locally as u_int8_t buf[256]; However I tend to make those superflous checks in my code, just to make sure later changes won't break my logic ;-)) Regards Kurt Knochner http://knochner.com/
Re: Allegations regarding OpenBSD IPSEC
2010/12/21 Otto Moerbeek : >> get_random_bytes() calls extract_entropy() which is a a loop around nbytes, >> thus get_random_bytes() will most certainly deliver enough entropy. > > extract_entropy() does not guarantee the collected bytes will have > enough entropy. Think about situations very early in machine startup, > where the state of things could be predictable. O.K. I see... But isn't the value of nanotime() kind of "predictable" as well? Regards Kurt Knochner http://knochner.com/
Re: Allegations regarding OpenBSD IPSEC
On Tue, Dec 21, 2010 at 08:36:35PM +0100, Kurt Knochner wrote: > 2010/12/21 Otto Moerbeek : > >> get_random_bytes() calls extract_entropy() which is a a loop around nbytes, > >> thus get_random_bytes() will most certainly deliver enough entropy. > > > > extract_entropy() does not guarantee the collected bytes will have > > enough entropy. Think about situations very early in machine startup, > > where the state of things could be predictable. > > O.K. I see... But isn't the value of nanotime() kind of "predictable" as well? Yes, predictable, but different for each call. -Otto
Re: Allegations regarding OpenBSD IPSEC
> without a 'hint' (true or fake), Well, the allegations came without any facts pointing at specific code. At the moment my beliefs are somewhat along these lines: (a) NETSEC, as a company, was in that peculiar near-DC business of accepting contracts to do security and anti-security work from parts of the government. (b) For context: 1999-2001 was a period where lots of US govt departments pushed the boundaries, because crypto was moved from DOD to Commerce so that it could be exported "subject to some limits"; the result was that crypto use by private interests was set to explode, and thus many justifications, not just technologies, were being invented to let the US Govt continue wiretapping (they have always been addicted to it). (c) Gregory Perry did work at NETSEC, and interviewed and hired Jason just out of school; by the time Jason started working there Perry had been "evicted" from the company, for reasons unknown. (d) Jason did not work on cryptography specifically since he was mostly a device driver author, but did touch the ipsec layer because that layer does IPCOMP as well. Meaning he touched the data-flow sides of this code, not the algorithms. (e) After Jason left, Angelos (who had been working on the ipsec stack already for 4 years or so, for he was the ARCHITECT and primary developer of the IPSEC stack) accepted a contract at NETSEC and (while travelling around the world) wrote the crypto layer that permits our ipsec stack to hand-off requests to the drivers that Jason worked on. That crypto layer contained the half-assed insecure idea of half-IV that the US govt was pushing at that time. Soon after his contract was over this was ripped out. Soon after this the CBC oracle problem became known as well in published papers, and ipsec/crypto moved towards random IV generation (probably not viable before this, since we had lacked a high-quality speedy PRNG... arc4random). I do not believe that either of these two problems, or other problems not yet spotted, are a result of clear malice. So far the issues we are digging up are a function of the time in history. (f) Both Jason and Angelos wrote much code in many areas that we all rely on. Daily. Outside the ipsec stack. I forwarded the allegation which mentions them, but I will continue to find it hard to point my own fingers at them. Go read my original mail for points (a) - (c). (g) I believe that NETSEC was probably contracted to write backdoors as alleged. (h) If those were written, I don't believe they made it into our tree. They might have been deployed as their own product. (i) If such NETSEC projects exists, I don't know if Jason, Angelos or others knew or participated in such NETSEC projects. (j) If Jason and Angelos knew NETSEC was in that business, I wish they had told me. The project and I might have adjusted ourself to the situation in some way; don't know exactly how. With this view, I do not find Jason's mail to be fully transparent. (k) I am happy that people are taking the opportunity to audit an important part of the tree which many had assumed -- for far too long -- to be safe as it is. > where would you start auditing the code? It's just too much. Actually, it is a very small part of the tree. If we all do our part, it will get better. It still won't be perfect. It is just too big. But we've proven that if we start nibbling at a source tree looking for small bugs or unclear things which need improvement, the results always eventually pay off. So I can't suggest any specific place to start. > Now, as I have started with it, I will continue to do so, at least > with the crypto code and PRNG code. After you sent out your mail, at least 10 people went and studied this code. I've already found a small bug in a totally different side of the random subsystem, and am looking at cleaning up a truly ugly function. That is the best process we can hope for. > > But looked at from the half-glass-full side, it is refreshing to see > > people trying! > > :-) > > BTW: iTWire mentions, that two bugs have been found in the crypto > code. Where can I find details on those bugs? > > http://www.itwire.com/opinion-and-analysis/open-sauce/43995-openbsd-backdoor-claims-code-audit-begins These are the first two bugs which were found. The first one relates to the CBC oracle problem mentioned earlier (it got fixed by angelos in the software crypto stack, but the same problem was ignored in all the drivers jason maintained. Neither Jason nor Angelos were working for NETSEC at that time, so I think this was just an accident. Pretty serious accident). CVSROOT:/cvs M
Re: Allegations regarding OpenBSD IPSEC
2010/12/21 Otto Moerbeek : > Yes, predictable, but different for each call. hm... predictable is not a good term in the domain of a PRNG. However the time value will not be used by itself. It is part of an encrypt operation with itself + buf and a previous RC4 state, at least after the second call to arc4_stir. So, maybe this has no meaning at all. However I would "recommend" to check this very thoroughly before changing any line of that code. Maybe you'll add a weakness by removing the time value. I would recommend to do the follwoing, and I'm trying to do it myself during the next few days. 1.) Rewrite arc4random() and arc4random_buf() to "store" all random values from boot time until the establishment of a few IPSEC tunnels. 2.) Repeat that procedure a few times, i.e. reboot, ipsec, store, reboot, ipsec, store, etc. 3.) Take all those pseudo random value sequences and feed them into the NIST test suite for random values (chi-square, diehard, etc.) 4.) Repeat those steps after the removal of the time value from the code. 5.) Try to interpret the outcome of the NIST tests. Maybe other people (real cryptographers) should help with this last step. Regards Kurt Knochner http://knochner.com/
Re: Allegations regarding OpenBSD IPSEC
> 2010/12/21 Otto Moerbeek : > > Yes, predictable, but different for each call. > > hm... predictable is not a good term in the domain of a PRNG. > > However the time value will not be used by itself. It is part of an > encrypt operation with itself + buf and a previous RC4 state, at least > after the second call to arc4_stir. > > So, maybe this has no meaning at all. However I would "recommend" to > check this very thoroughly before changing any line of that code. > Maybe you'll add a weakness by removing the time value. > > I would recommend to do the follwoing, and I'm trying to do it myself > during the next few days. > > 1.) Rewrite arc4random() and arc4random_buf() to "store" all random > values from boot time until the establishment of a few IPSEC tunnels. > > 2.) Repeat that procedure a few times, i.e. reboot, ipsec, store, > reboot, ipsec, store, etc. > > 3.) Take all those pseudo random value sequences and feed them into > the NIST test suite for random values (chi-square, diehard, etc.) > > 4.) Repeat those steps after the removal of the time value from the code. > > 5.) Try to interpret the outcome of the NIST tests. Maybe other people > (real cryptographers) should help with this last step. HANG ON. Go look at the function random_seed() in /usr/src/etc/rc Then look at when it is called. You are reading the code attempts to make-do in a world without any real entropy (minus a few interrupts) very very early in the boot process. Except in the case of nfs diskless, no network traffic has moved at that time, since no interfaces are up. Please keep that context in mind.
Re: Allegations regarding OpenBSD IPSEC
On Tue, Dec 21, 2010 at 08:27:49PM +0100, Kurt Knochner wrote:
> 2010/12/21 Joachim Schipper :
> > + get_random_bytes(buf, sizeof(buf));
> > + nanotime(&ts);
> > + for (i = 0; i < sizeof(ts); i++)
> > + buf[i] ^= ((uint8_t *) &ts)[i];
>
> I like the idea of using XOR. However, there are two issues:
>
> 1.) if nanotime() was called because of not enough random data from
> get_random_bytes() then you could end up with only the value &ts in
> buf. Why not use a md5 hash of the time value (better than the plain
> time value) or better just don't use the time value at all.
New diff.
Improvements:
- document the "why" of this loop (from Otto's message)
- Instead of XOR'ing the results of nanotime into the buffer, XOR
MD5(time), MD5(time + 1ns), MD5(time + 2ns) etc into the buffer. This
does not increase entropy, but having more-or-less uncorrelated data
in the entire buffer should make attacks more difficult.
Joachim
Index: ../../dev/rnd.c
===
RCS file: /usr/cvs/src/src/sys/dev/rnd.c,v
retrieving revision 1.104
diff -u -p -r1.104 rnd.c
--- ../../dev/rnd.c 21 Nov 2010 22:58:40 - 1.104
+++ ../../dev/rnd.c 21 Dec 2010 20:01:02 -
@@ -779,13 +779,29 @@ get_random_bytes(void *buf, size_t nbyte
static void
arc4_stir(void)
{
- u_int8_t buf[256];
- int len;
+ u_int8_t buf[256], md5_buf[MD5_DIGEST_LENGTH];
+ MD5_CTX md5_ctx;
+ struct timespec ts;
+ int i, j;
- nanotime((struct timespec *) buf);
- len = sizeof(buf) - sizeof(struct timespec);
- get_random_bytes(buf + sizeof (struct timespec), len);
- len += sizeof(struct timespec);
+ get_random_bytes(buf, sizeof(buf));
+
+ /*
+* extract_entropy(), and thus get_random_bytes(), may not actually be
+* very random early in the startup sequence of some machines. This is
+* a desperate attempt to increase the randomness in the pool by mixing
+* in nanotime().
+*/
+ nanotime(&ts);
+ KDASSERT(sizeof(buf) % MD5_DIGEST_LENGTH == 0);
+ for (i = 0; i < sizeof(buf); i += MD5_DIGEST_LENGTH) {
+ ts.tv_nsec = (ts.tv_nsec + 1) % (1000 * 1000 * 1000);
+ MD5Init(&md5_ctx);
+ MD5Update(&md5_ctx, (u_int8_t *) &ts, sizeof(ts));
+ MD5Final(md5_buf, &md5_ctx);
+ for (j = 0; j < MD5_DIGEST_LENGTH; j++)
+ buf[i + j] ^= md5_buf[j];
+ }
mtx_enter(&rndlock);
if (rndstats.arc4_nstirs > 0)
@@ -793,7 +809,7 @@ arc4_stir(void)
rc4_keysetup(&arc4random_state, buf, sizeof(buf));
arc4random_count = 0;
- rndstats.arc4_stirs += len;
+ rndstats.arc4_stirs += sizeof(buf);
rndstats.arc4_nstirs++;
/*
Re: Allegations regarding OpenBSD IPSEC
>"MD5(time), MD5(time + 1ns), MD5(time + 2ns) etc into the buffer. This
does not increase entropy, but having more-or-less uncorrelated data
in the entire buffer should make attacks more difficult."
No. Unless you know something I don't, This is voodoo. To do it once might
add something, but to do it multiple times, with strongly correlated inputs
seems potentially dangerous. Especially since you are XORing them. Does
anyone elsewhere in the cryptographic world do something like this?
Can you prove there are no statistical weaknesses in MD5 for such inputs?
On Tue, Dec 21, 2010 at 1:04 PM, Joachim Schipper <
joac...@joachimschipper.nl> wrote:
> On Tue, Dec 21, 2010 at 08:27:49PM +0100, Kurt Knochner wrote:
> > 2010/12/21 Joachim Schipper :
> > > + get_random_bytes(buf, sizeof(buf));
> > > + nanotime(&ts);
> > > + for (i = 0; i < sizeof(ts); i++)
> > > + buf[i] ^= ((uint8_t *) &ts)[i];
> >
> > I like the idea of using XOR. However, there are two issues:
> >
> > 1.) if nanotime() was called because of not enough random data from
> > get_random_bytes() then you could end up with only the value &ts in
> > buf. Why not use a md5 hash of the time value (better than the plain
> > time value) or better just don't use the time value at all.
>
> New diff.
>
> Improvements:
> - document the "why" of this loop (from Otto's message)
> - Instead of XOR'ing the results of nanotime into the buffer, XOR
> MD5(time), MD5(time + 1ns), MD5(time + 2ns) etc into the buffer. This
> does not increase entropy, but having more-or-less uncorrelated data
> in the entire buffer should make attacks more difficult.
>
>Joachim
>
> Index: ../../dev/rnd.c
> ===
> RCS file: /usr/cvs/src/src/sys/dev/rnd.c,v
> retrieving revision 1.104
> diff -u -p -r1.104 rnd.c
> --- ../../dev/rnd.c 21 Nov 2010 22:58:40 - 1.104
> +++ ../../dev/rnd.c 21 Dec 2010 20:01:02 -
> @@ -779,13 +779,29 @@ get_random_bytes(void *buf, size_t nbyte
> static void
> arc4_stir(void)
> {
> - u_int8_t buf[256];
> - int len;
> + u_int8_t buf[256], md5_buf[MD5_DIGEST_LENGTH];
> + MD5_CTX md5_ctx;
> + struct timespec ts;
> + int i, j;
>
> - nanotime((struct timespec *) buf);
> - len = sizeof(buf) - sizeof(struct timespec);
> - get_random_bytes(buf + sizeof (struct timespec), len);
> - len += sizeof(struct timespec);
> + get_random_bytes(buf, sizeof(buf));
> +
> + /*
> +* extract_entropy(), and thus get_random_bytes(), may not actually
> be
> +* very random early in the startup sequence of some machines. This
> is
> +* a desperate attempt to increase the randomness in the pool by
> mixing
> +* in nanotime().
> +*/
> + nanotime(&ts);
> + KDASSERT(sizeof(buf) % MD5_DIGEST_LENGTH == 0);
> + for (i = 0; i < sizeof(buf); i += MD5_DIGEST_LENGTH) {
> + ts.tv_nsec = (ts.tv_nsec + 1) % (1000 * 1000 * 1000);
> + MD5Init(&md5_ctx);
> + MD5Update(&md5_ctx, (u_int8_t *) &ts, sizeof(ts));
> + MD5Final(md5_buf, &md5_ctx);
> + for (j = 0; j < MD5_DIGEST_LENGTH; j++)
> + buf[i + j] ^= md5_buf[j];
> + }
>
>mtx_enter(&rndlock);
>if (rndstats.arc4_nstirs > 0)
> @@ -793,7 +809,7 @@ arc4_stir(void)
>
>rc4_keysetup(&arc4random_state, buf, sizeof(buf));
>arc4random_count = 0;
> - rndstats.arc4_stirs += len;
> + rndstats.arc4_stirs += sizeof(buf);
>rndstats.arc4_nstirs++;
>
>/*
Re: Allegations regarding OpenBSD IPSEC
> - Instead of XOR'ing the results of nanotime into the buffer, XOR > MD5(time), MD5(time + 1ns), MD5(time + 2ns) etc into the buffer. This > does not increase entropy, but having more-or-less uncorrelated data > in the entire buffer should make attacks more difficult. I do not understand what hashing principle you are basing this on. In essence, md5 doesn't care what is in the buffer, or where it is. Placing it at the front, vs massaging it in by hand... Fundamentally there is no difference... or is there?
Re: Allegations regarding OpenBSD IPSEC
> No. Unless you know something I don't, This is voodoo. To do it once might > add something, but to do it multiple times, with strongly correlated inputs > seems potentially dangerous. Especially since you are XORing them. Does > anyone elsewhere in the cryptographic world do something like this? Yes, there is one other thing that does this. freebsd md5 crypt -- It back-feeds inner state and outer state in loop and data-dependent ways; it is a true miracle. Noone should do that. These Cryptographic primitives are only strongd when they are used exactly as intended.
Re: Allegations regarding OpenBSD IPSEC
On Tue, Dec 21, 2010 at 2:54 PM, Kurt Knochner wrote: > 2.) Repeat that procedure a few times, i.e. reboot, ipsec, store, > reboot, ipsec, store, etc. > > 3.) Take all those pseudo random value sequences and feed them into > the NIST test suite for random values (chi-square, diehard, etc.) You are going to need a buttload of samples for your tests to have any significance, and even then, all you've proven is that the numbers have a good distribution, not that they are unpredictable.
Re: Allegations regarding OpenBSD IPSEC
On Tue, Dec 21, 2010 at 01:33:46PM -0700, Theo de Raadt wrote: > > - Instead of XOR'ing the results of nanotime into the buffer, XOR > > MD5(time), MD5(time + 1ns), MD5(time + 2ns) etc into the buffer. This > > does not increase entropy, but having more-or-less uncorrelated data > > in the entire buffer should make attacks more difficult. > > I do not understand what hashing principle you are basing this on. > > In essence, md5 doesn't care what is in the buffer, or where it is. > Placing it at the front, vs massaging it in by hand... Fundamentally > there is no difference... or is there? This was based on the following intuition, which has very little to do with hashing at all: If our RC4 state is , an attacker may be able to predict *most* of the RC4 state through the first couple of rounds (until sufficiently interferes with the known state). It *seems harder* (but I'm not an expert on this kind of thing!) to predict the first couple of rounds if is hashed (which means that you have to re-do the complete calculation for each possible , which may not necessarily be the case above), and if this hashing is used to distribute the noise over the entire initial state of the cipher (so that no known portion exists). Again, though, this is just intuition, and it's not wise to trust our intuition in this kind of thing. I actually *am* a cryptographer, but I'm quite new at it and a mathematician specializing in a very different area, so don't take this as gospel. (I'd be willing to spend some more time looking into this if we consider it important.) Joachim
Re: Allegations regarding OpenBSD IPSEC
On Tue, Dec 21, 2010 at 3:04 PM, Joachim Schipper
wrote:
> On Tue, Dec 21, 2010 at 08:27:49PM +0100, Kurt Knochner wrote:
>> 2010/12/21 Joachim Schipper :
>> > + get_random_bytes(buf, sizeof(buf));
>> > + nanotime(&ts);
>> > + for (i = 0; i < sizeof(ts); i++)
>> > + buf[i] ^= ((uint8_t *) &ts)[i];
>>
>> I like the idea of using XOR. However, there are two issues:
>>
>> 1.) if nanotime() was called because of not enough random data from
>> get_random_bytes() then you could end up with only the value &ts in
>> buf. Why not use a md5 hash of the time value (better than the plain
>> time value) or better just don't use the time value at all.
>
> New diff.
>
> Improvements:
> - document the "why" of this loop (from Otto's message)
> - Instead of XOR'ing the results of nanotime into the buffer, XOR
> MD5(time), MD5(time + 1ns), MD5(time + 2ns) etc into the buffer. This
> does not increase entropy, but having more-or-less uncorrelated data
> in the entire buffer should make attacks more difficult.
This is way overkill. Just xor the nanotime into the random bytes,
that's all that's "needed".
>
>Joachim
>
> Index: ../../dev/rnd.c
> ===
> RCS file: /usr/cvs/src/src/sys/dev/rnd.c,v
> retrieving revision 1.104
> diff -u -p -r1.104 rnd.c
> --- ../../dev/rnd.c 21 Nov 2010 22:58:40 - 1.104
> +++ ../../dev/rnd.c 21 Dec 2010 20:01:02 -
> @@ -779,13 +779,29 @@ get_random_bytes(void *buf, size_t nbyte
> static void
> arc4_stir(void)
> {
> - u_int8_t buf[256];
> - int len;
> + u_int8_t buf[256], md5_buf[MD5_DIGEST_LENGTH];
> + MD5_CTX md5_ctx;
> + struct timespec ts;
> + int i, j;
>
> - nanotime((struct timespec *) buf);
> - len = sizeof(buf) - sizeof(struct timespec);
> - get_random_bytes(buf + sizeof (struct timespec), len);
> - len += sizeof(struct timespec);
> + get_random_bytes(buf, sizeof(buf));
> +
> + /*
> +* extract_entropy(), and thus get_random_bytes(), may not actually
be
> +* very random early in the startup sequence of some machines. This
is
> +* a desperate attempt to increase the randomness in the pool by
mixing
> +* in nanotime().
> +*/
> + nanotime(&ts);
> + KDASSERT(sizeof(buf) % MD5_DIGEST_LENGTH == 0);
> + for (i = 0; i < sizeof(buf); i += MD5_DIGEST_LENGTH) {
> + ts.tv_nsec = (ts.tv_nsec + 1) % (1000 * 1000 * 1000);
> + MD5Init(&md5_ctx);
> + MD5Update(&md5_ctx, (u_int8_t *) &ts, sizeof(ts));
> + MD5Final(md5_buf, &md5_ctx);
> + for (j = 0; j < MD5_DIGEST_LENGTH; j++)
> + buf[i + j] ^= md5_buf[j];
> + }
>
>mtx_enter(&rndlock);
>if (rndstats.arc4_nstirs > 0)
> @@ -793,7 +809,7 @@ arc4_stir(void)
>
>rc4_keysetup(&arc4random_state, buf, sizeof(buf));
>arc4random_count = 0;
> - rndstats.arc4_stirs += len;
> + rndstats.arc4_stirs += sizeof(buf);
>rndstats.arc4_nstirs++;
>
>/*
Re: Allegations regarding OpenBSD IPSEC
> It *seems harder* (but I'm not an expert on this kind of thing!) to > predict the first couple of rounds if is hashed (which > means that you have to re-do the complete calculation for each possible > , which may not necessarily be the case above), and if > this hashing is used to distribute the noise over the entire initial > state of the cipher (so that no known portion exists). > > Hashing wasn't my objection. Hashing 3 times with data-dependent inputs and XORing them together was.
pf debug states: ioctl interface and state names.
A few things that has me confused ...
1) pf(4) says DIOCSETDEBUG has enum { PF_DEBUG_NONE, PF_DEBUG_URGENT, ...
but these names are not in pfvar.h nor anywhere else in the source tree
(AFAICT). What should the legal values (or names) be?
2) pf.conf(5) says "set debug" can be one of loud, misc, none, or urgent
but if you "set debug loud" in pf.conf and load it the pfctl -sa output
will say "Debug: debug", or if you "set debug misc" it will say "Debug:
notice". It does not say what you set in pf.conf.
3) pfctl(8) -x option lets you set one of emerg, alert, crit, err,
warning, notice, info, or debug. These will show up by their correct
name in pfctl -sa output. They're also valid names in pf.conf so
should they not also be mentioned in pf.conf(5)?
Cheers,
Thomas.
Re: Allegations regarding OpenBSD IPSEC
> This was based on the following intuition, which has very little to do > with hashing at all: > > > It *seems harder* (but I'm not an expert on this kind of thing!) > > > Again, though, this is just intuition, > . Then no offense Jochim - stop suggesting it.. intuition like this is what gets us things like the PHK md5 password scheme. Look at it - fine, but don't make suggestions based on intuition.
Re: Allegations regarding OpenBSD IPSEC
On Tue, Dec 21, 2010 at 01:33:46PM -0700, Theo de Raadt wrote:
> I do not understand what hashing principle you are basing this on.
On closer reflection, neither do I ("MD5 in CTR mode"? Cute, but not
necessarily a good idea). Can we just pretend I never sent that message?
Joachim
Re: Allegations regarding OpenBSD IPSEC
On Tue, Dec 21, 2010 at 12:34:54PM -0700, Theo de Raadt wrote: > [...] > Other more recent commits have come out of this as well. Just go > look at the Changelog .. we're a bit late on the changelog right now, it stops on 5th of december, gonna work on it very soon, sorry for the delay.
Re: Allegations regarding OpenBSD IPSEC
2010/12/21 Ted Unangst : > On Tue, Dec 21, 2010 at 2:54 PM, Kurt Knochner > wrote: >> 2.) Repeat that procedure a few times, i.e. reboot, ipsec, store, >> reboot, ipsec, store, etc. >> >> 3.) Take all those pseudo random value sequences and feed them into >> the NIST test suite for random values (chi-square, diehard, etc.) > > You are going to need a buttload of samples for your tests to have any > significance, and even then, all you've proven is that the numbers > have a good distribution, not that they are unpredictable. yes, that's true. However, it's just a starting point. Do we currently know that they have a good distribution? Is there any documented test for the quality of the PRNG? Regards Kurt Knochner http://knochner.com
Re: Allegations regarding OpenBSD IPSEC
On Tue, Dec 21, 2010 at 4:00 PM, Joachim Schipper wrote: > If our RC4 state is , an attacker may be able to > predict *most* of the RC4 state through the first couple of rounds > (until sufficiently interferes with the known state). > > It *seems harder* (but I'm not an expert on this kind of thing!) to > predict the first couple of rounds if is hashed (which > means that you have to re-do the complete calculation for each possible > , which may not necessarily be the case above), and if > this hashing is used to distribute the noise over the entire initial > state of the cipher (so that no known portion exists). The attacker either knows nanotime or they don't. If they know it, they know md5(nanotime) as well. RC4 is weak sauce and leaks its key in the beginning, but we avoid that by discarding, so there's no way to tell what the initial state is except by guessing. And guessing md5(whatever) is no harder than guessing whatever. The md5 step would only be helpful if the initial key to rc4 were then also used to something *else*, meaning it had some value apart from being the key. But it doesn't.
Re: Improving early randomness (was: Allegations regarding OpenBSD IPSEC)
On Tue, Dec 21, 2010 at 01:24:55PM -0700, Kjell Wooding wrote: > >"MD5(time), MD5(time + 1ns), MD5(time + 2ns) etc into the buffer. This > does not increase entropy, but having more-or-less uncorrelated data > in the entire buffer should make attacks more difficult." > > No. Unless you know something I don't, This is voodoo. To do it once might > add something, but to do it multiple times, with strongly correlated inputs > seems potentially dangerous. Especially since you are XORing them. Does > anyone elsewhere in the cryptographic world do something like this? > > Can you prove there are no statistical weaknesses in MD5 for such inputs? Note, as has been pointed out to me, that the kernel only relies on the entropy of nanotime() until we can get some actual data in, i.e. for a *very* short time. Thus, this whole discussion is probably moot. Of course I can't prove that MD5 works, but there *is* some actual reasoning behind the code I sent: - random XOR anything_uncorrelated is random, so this shouldn't hurt; - the output of MD5(time) and MD5(time + 1ns) should look very different for (practical) hash functions. To the best of my knowledge, no vulnerabilities *of this kind* are known in MD5; - spreading the entropy over the entire key should be preferable to concentrating it in a few bits. That said, the last "should" is not a very strong argument. I'm not aware what others do; certainly, no cryptographer will be happy with a PRNG seeded by a timestamp, so this is not exactly best practice (probably the best we can do at that time, though.) Joachim
Re: Allegations regarding OpenBSD IPSEC
On Tue, Dec 21, 2010 at 2:30 PM, Kurt Knochner wrote: > > yes, that's true. However, it's just a starting point. Do we currently > know that they have a good distribution? Is there any documented test > for the quality of the PRNG? > > Sam from FreeBSD imported my rng tester and hooked it up to FreeBSD's port of OCF. It basically just implements the old FIPS tests, but might save someone some time. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/rndtest/ --Jason L. Wright
Re: Allegations regarding OpenBSD IPSEC
On Tue, Dec 21, 2010 at 07:45:09PM +0100, Kurt Knochner wrote:
> A last thing:
>
> From: src/lib/libc/crypt/arc4random.c
>
> arc4_stir(void)
> {
>
>
> /*
> * Discard early keystream, as per recommendations in:
> * http://www.wisdom.weizmann.ac.il/~itsik/RC4/Papers/Rc4_ksa.ps
> */
> for (i = 0; i < 256; i++)
> (void)arc4_getbyte();
> arc4_count = 160;
> }
>
>
> The first 256 Bytes will be skipped due to the mentioned paper. Similar code
> exists in rnd.c.
>
> /*
> * Throw away the first N words of output, as suggested in the
> * paper "Weaknesses in the Key Scheduling Algorithm of RC4"
> * by Fluher, Mantin, and Shamir. (N = 256 in our case.)
> */
> rc4_skip(&arc4random_state, 256 * 4);
> mtx_leave(&rndlock);
>
> However here, 1024 bytes (256 * 4) will be skipped. Maybe that's just a
> misinterpretation of what a "word" is (byte or integer).
Could be. As I read it in the paper by Fluhrer, Mantin and Shamir, it
means discard 256 bytes, since n = 8 and N = 256. Though some
references (found via wikipedia) suggest to increase the number of
bytes discarded.
-Otto
>
> Maybe I'm paranoid and see problems where there are none. But then, this is
> part of the crypto code and there should be no open questions about the
> implementation details.
>
> Regards
> Kurt Knochner
>
> http://knochner.com/
Re: Allegations regarding OpenBSD IPSEC
2010/12/21 Ted Unangst : > You can analyze the numbers coming out of /dev/arandom if you like, much easier than rewriting the code. > but the scheme basically depends on the security of rc4, which is > still widely used. I realize this is proof by assertion, but if you > could decode an rc4 stream, that'd be a big deal. it's not about beeing able to decrypt rc4. It's about the quality of the PRNG. As I said, I'm not a cryptographer, but quite some of those guys will tell you, that the quality of the PRNG is essential for the quality of the whole encryption system (may it be theroetically or practically exploitable - see the link to the RSA page I posted). So, yes the rc4 scheme is widely used and for sure it's a good way to generate pseudo random numbers. The question is, if the actual code implements it in the right way. In that context I was wondering why the value of nanotime() is prepended to buf and if that could cause any problems. As I said: It can mean absolutely nothing and maybe you guys should not spend too much time on this issue. However personally I will neither trust my feelings nor my programming skills when it's about cryptography. One can't feel or see how code changes influence the produced random values unless they are checked/tested. Regards Kurt Knochner http://knochner.com/
Re: Allegations regarding OpenBSD IPSEC
On Tue, Dec 21, 2010 at 4:30 PM, Kurt Knochner wrote: > yes, that's true. However, it's just a starting point. Do we currently > know that they have a good distribution? Is there any documented test > for the quality of the PRNG? You can analyze the numbers coming out of /dev/arandom if you like, but the scheme basically depends on the security of rc4, which is still widely used. I realize this is proof by assertion, but if you could decode an rc4 stream, that'd be a big deal.
Re: Allegations regarding OpenBSD IPSEC
2010/12/21 Theo de Raadt : > HANG ON. > > Go look at the function random_seed() in /usr/src/etc/rc > Then look at when it is called. so, the current state of the PRNG will be preserved during reboots. Good. That gives some information about system entropy, which will be "good" at all times, except for the very first boot of an installation. See : rnd.c: randomwrite() -> add_entropy_words(); However, arc4_stir will still be called once after every reboot. During its first call, the value of nanotime() will be placed at the beginning of buf, which is then beeing used to init the rc4 context. So, at the first glance it looks like using the value of nanotime() in arc4_stir is not necessary at all, as there will allways be enough system entropy. At least I would XOR the value of nanotime() to buf, instead of just prepending it. MD5 and the like does not seem to be necessary, as buf will allways contain some good random data. Reagards Kurt Knochner http://knochner.com/
Especial Regalos de navidad!
[IMAGE]*Los precio estan expresados en pesos argentinos e incluye IVA. En caso de no querer recibir mas este correo por favor presione AQUI .
Re: Allegations regarding OpenBSD IPSEC
2010/12/21 Kurt Knochner : > instead of just prepending it. MD5 and the like does not seem to be > necessary, as buf will allways contain some good random data. I wanted to say: get_random_bytes() will allways return enough good random values. Reagards Kurt Knochner http://knochner.com/
Re: Allegations regarding OpenBSD IPSEC
> 2010/12/21 Theo de Raadt : > > HANG ON. > > > > Go look at the function random_seed() in /usr/src/etc/rc > > Then look at when it is called. > > so, the current state of the PRNG will be preserved during reboots. That statement is false. > Good. No. You misread the code. > That gives some information about system entropy, which will be > "good" at all times, except for the very first boot of an > installation. See : rnd.c: randomwrite() -> add_entropy_words(); That part is true. But what you said earlier is false. > However, arc4_stir will still be called once after every reboot. > During its first call, the value of nanotime() will be placed at the > beginning of buf, which is then beeing used to init the rc4 context. What else do you think we should use? Where do we invent entropy from when the kernel has only been running for 0.01 of a second? > So, at the first glance it looks like using the value of nanotime() in > arc4_stir is not necessary at all, as there will allways be enough > system entropy. False. On some architectures, some entropy might have been fetched. On some architectures, the system clock might have been read with enough accuracy and random time advancement to provide some unknown. On MOST architectures, the above two are true. On some they are not. Soon after mounting, /etc/rc will load a bucketload more entropy (even on the first boot, I should add, since even the installation process generates that file). > At least I would XOR the value of nanotime() to buf, > instead of just prepending it. MD5 and the like does not seem to be > necessary, as buf will allways contain some good random data. XOR it? Why? Please provide a citation regarding the benefit of XOR'ing feed data before passing it into MD5 for the purpose of PRNG folding. Note, this is the first stage PRNG, and that a second stage kernel-use PRNG is built on top of that the first one, and that a third stage per-process PRNG is built on top of that.
Re: Allegations regarding OpenBSD IPSEC
> On Tue, Dec 21, 2010 at 4:30 PM, Kurt Knochner > wrote: > > yes, that's true. However, it's just a starting point. Do we currently > > know that they have a good distribution? Is there any documented test > > for the quality of the PRNG? > > You can analyze the numbers coming out of /dev/arandom if you like, > but the scheme basically depends on the security of rc4, which is > still widely used. I realize this is proof by assertion, but if you > could decode an rc4 stream, that'd be a big deal. I am so sad. 8 years after the fact, people still forget that our kernel rc4 stream is cut up among hundreds of consumers. Go ahead, do a FIPS check on it. You will be doing a FIPS check on 4096 bytes here, then a gap of unknown length, then 4096 bytes here, then a gap of unknown length, then 4096 bytes here, then a gap of unknown length, After sharing a single pie with 200 people, you are using statistics to claim it had no strawberries on it.
Re: Allegations regarding OpenBSD IPSEC
> 2010/12/21 Kurt Knochner : > > instead of just prepending it. MD5 and the like does not seem to be > > necessary, as buf will allways contain some good random data. > > I wanted to say: get_random_bytes() will allways return enough good > random values. That is completely irrelevant because get_random_bytes() is only used as the *source material* for a RC4-based PRNG. WE HAVE THREE LAYERS OF PRNG.
Re: Allegations regarding OpenBSD IPSEC
> Is there any documented test for the quality of the PRNG? Are you talking about our use of MD5, or our use of RC4? If you are talking about our RC4, then there is; I will put it this way: If our use of RC4 in this exactly-how-a-stream-cipher-works way is bad, then every other use on this planet of steam ciphers is bad, and very broken. We are relying on the base concept. The idea is that you can initialize a stream cipher with near-crap and it will work OK for the way we are using it. If the MD5 stuff we generate is crap, we are still probably more than OK compared to everyone because we are going further, and doing the slice/dice everyone-shares on the RC4 output.
Re: Allegations regarding OpenBSD IPSEC
2010/12/22 Theo de Raadt : >> 2010/12/21 Kurt Knochner : >> > instead of just prepending it. MD5 and the like does not seem to be >> > necessary, as buf will allways contain some good random data. >> >> I wanted to say: get_random_bytes() will allways return enough good >> random values. > > That is completely irrelevant because get_random_bytes() is only used > as the *source material* for a RC4-based PRNG. > > WE HAVE THREE LAYERS OF PRNG. so, you are saying, that the use of nanotime() in arc4_stir() is irrelevant? That would be a result I can accept, as I already said: It could mean nothing.
Re: Allegations regarding OpenBSD IPSEC
2010/12/22 Theo de Raadt : >> Is there any documented test for the quality of the PRNG? > > Are you talking about our use of MD5, or our use of RC4? RC4. > If you are talking about our RC4, then there is; I will put it this > way: If our use of RC4 in this exactly-how-a-stream-cipher-works way > is bad, then every other use on this planet of steam ciphers is bad, > and very broken. We are relying on the base concept. I was just asking if the implementation of the RC4 based PRNG is done correctly and if there has been a test of the quality of the PRNG output. It just looked strange for me to seed the algorithm of the PRNG with a plain time value, though it's just a few bytes at the beginning of a larger block of data. So, if you believe the implementation of the PRNG is correct, there is no need to further analyze this issue. > The idea is that you can initialize a stream cipher with near-crap and > it will work OK for the way we are using it. Right. > If the MD5 stuff we generate is crap, we are still probably more than > OK compared to everyone because we are going further, and doing the > slice/dice everyone-shares on the RC4 output. I did not say, that anything you generate is crap.
Re: Allegations regarding OpenBSD IPSEC
> 2010/12/22 Theo de Raadt : > >> 2010/12/21 Kurt Knochner : > >> > instead of just prepending it. MD5 and the like does not seem to be > >> > necessary, as buf will allways contain some good random data. > >> > >> I wanted to say: get_random_bytes() will allways return enough good > >> random values. > > > > That is completely irrelevant because get_random_bytes() is only used > > as the *source material* for a RC4-based PRNG. > > > > WE HAVE THREE LAYERS OF PRNG. > > so, you are saying, that the use of nanotime() in arc4_stir() is irrelevant? > > That would be a result I can accept, as I already said: It could mean nothing. 12 to 16 bytes of kind-of-known but not really known data are mixed with 256 - (12 to 16) bytes of data to from the initial state of RC4, which is then filtered by dropping the first 256 or 256*4 bytes of data as written in the best paper that exists today. Is it relevant?
Re: Allegations regarding OpenBSD IPSEC
2010/12/22 Theo de Raadt : > 12 to 16 bytes of kind-of-known but not really known data are mixed with > 256 - (12 to 16) bytes of data to from the initial state of RC4, which is > then filtered by dropping the first 256 or 256*4 bytes of data as written > in the best paper that exists today. > > Is it relevant? It's up to you to make that decision. You know the code better than anybody else.
Re: Allegations regarding OpenBSD IPSEC
.. steam ciphers is bad ... Steam has much more entropy than a pseudo-number generator, in which case our implementation is obsolete. -Matt
Re: Allegations regarding OpenBSD's PRNG
[Just been following the discussions on the web archives, so sorry that I'm replying out of the email thread] * MD5 is used all the time in PRNGS. The collisions demonstrated aren't an issue if the attacker has almost no control over the input. * An unauthenticated attacker may be able to sample an almost arbitrary amount of output from your PRNG by making new IPsec connections. As I understand it, each now sends 128 bits or so of output as plaintext over the wire in the IV. :-) * How much of nanotime() is truly unpredictable to an attacker sitting directly on your local network cable? Maybe the bottom 10 bits, at best? * I don't know OpenBSD's does it this way, but if you seed your entropy pool a incrementally few bits at a time, an attacker who learns the internal state one time will be able to keep following it if he can see some output regularly. The strength of the encryption algorithm used to stir it doesn't matter in this attack. The solution requires at least one pool that's re-seeded "catastrophically", i.e. by merging in hundreds of bits at once. The defender has considerable leverage to gain an advantage by making the computations more expensive. * Unless you persist entropy across reboots, you are starting from a known state at boot. * One reason you would want to XOR entropy into the pool is so that any nonrandom bits don't obliterate any randomness that they land on top of (assuming they're independent). Better still, use something like a hash function (or the compression function from one). * If you have to drop KB of output from RC4, you might be better off with a hash function for stirring. Designers use hash functions because their one-wayness is a critical property. RC4 wasn't designed to be a one-way function any more than MD5 was designed to be used in CTR mode as a stream cipher. * Here's a good summary of attacks: http://www.schneier.com/paper-prngs.pdf * People love to design and discuss RNGs. I don't know why. * This is a thoroughly researched area of crypto. Perhaps you might consider using a standard design? (If for no other reason than to save endless discussions?) - Marsh
Re: Allegations regarding OpenBSD's PRNG
Wow. You really are not reading the same code, are you. > [Just been following the discussions on the web archives, so sorry that > I'm replying out of the email thread] > > * MD5 is used all the time in PRNGS. The collisions demonstrated aren't > an issue if the attacker has almost no control over the input. > > * An unauthenticated attacker may be able to sample an almost arbitrary > amount of output from your PRNG by making new IPsec connections. Really? Prove it. > As I > understand it, each now sends 128 bits or so of output as plaintext over > the wire in the IV. :-) Four days ago, if you were using a particular set of hardware drivers, then yes. But the software ipsec stack was fixed for this NINE YEARS AGO. What you just said was utterly careless. > * How much of nanotime() is truly unpredictable to an attacker sitting > directly on your local network cable? Maybe the bottom 10 bits, at best? No. The upper bits are 'more known'. The lower bits are 'less known'. How did you come to your conclusion? > * I don't know OpenBSD's does it this way, but if you seed your entropy > pool a incrementally few bits at a time, an attacker who learns the > internal state one time will be able to keep following it if he can see > some output regularly. The strength of the encryption algorithm used to > stir it doesn't matter in this attack. The solution requires at least > one pool that's re-seeded "catastrophically", i.e. by merging in > hundreds of bits at once. The defender has considerable leverage to gain > an advantage by making the computations more expensive. Except we don't do what you suggest at all. > * Unless you persist entropy across reboots, you are starting from a > known state at boot. We don't save entropy over boots. You are speaking of one specific way of solving this, and we don't do that. You can read the code in /etc/rc and /etc/rc.shutdown. At shutdown, we save a block of OUTPUT from the PRNG. At boot, right after some extremely early system setup, we load that block in as ENTROPY. Let me be exact: We do not save 'raw entropy'. > * One reason you would want to XOR entropy into the pool is so that any > nonrandom bits don't obliterate any randomness that they land on top of > (assuming they're independent). Better still, use something like a hash ^ > function (or the compression function from one). Moments later, a hash function is indeed used. It is called MD5. > * If you have to drop KB of output from RC4, you might be better off > with a hash function for stirring. Designers use hash functions because > their one-wayness is a critical property. RC4 wasn't designed to be a > one-way function any more than MD5 was designed to be used in CTR mode > as a stream cipher. You don't know > * Here's a good summary of attacks: > http://www.schneier.com/paper-prngs.pdf Yes, a wonderful paper about designing a PRNG for ONE consumer. If you had 1000 consumers of PRNG data, would you design a PRNG that way? That is the question which I think OpenBSD asked and proceeded to solve. > * People love to design and discuss RNGs. I don't know why. > > * This is a thoroughly researched area of crypto. Perhaps you might > consider using a standard design? (If for no other reason than to save > endless discussions?) I disagree strongly. The field of research is a total disaster because everyone tries to use ONE PRNG PER PURPOSE. We don't do that. We data-slice one PRNG with ALL CONSUMERS. Everyone else is using standard designs, and as a result they do not provide enough output data, and therefore, they make decisions that consider PRNG output EXPENSIVE, and then use it less. My desktop machine is generating and consuming PRNG in many many layers of the kernel PER PACKET, heck, per keystroke, while other operating systems continue to use sequential IP id's. Please go study what we have done before talking about it.
Re: Allegations regarding OpenBSD IPSEC
2010/12/22 Theo de Raadt : >> so, the current state of the PRNG will be preserved during reboots. > > That statement is false. you're right. As you posted in the other thread, the output of the PRNG is saved during shutdown and that file is loaded as entropy data during startup. > No. You misread the code. I understood the code, just my description of the process was not correct (detailed enough). >> However, arc4_stir will still be called once after every reboot. >> During its first call, the value of nanotime() will be placed at the >> beginning of buf, which is then beeing used to init the rc4 context. > > What else do you think we should use? I don't know. I just wanted to discuss a possible "issue". That's all... > Where do we invent entropy from when the kernel has only > been running for 0.01 of a second? O.K. where do you need ramdom bytes during that state of the kernel? All locations where arc4random* is called in the kernel are these: src/sys/dev/ic/if_wi.c: sc->wi_icv = arc4random(); src/sys/dev/ic/if_wi_hostap.c: arc4random(); src/sys/dev/ic/rt2860.c:uint32_t val = arc4random(); src/sys/dev/softraid_crypto.c: arc4random_buf(sd->mds.mdd_crypto.scr_key, src/sys/dev/softraid_crypto.c: arc4random_buf(sd->mds.mdd_crypto.scr_maskkey, src/sys/dev/usb/if_uath.c: iv = (ic->ic_iv != 0) ? ic->ic_iv : arc4random(); src/sys/dev/usb/ehci.c: /* XXX prevent panics at boot by not using arc4random */ src/sys/dev/usb/ehci.c: islot = EHCI_IQHIDX(lev, arc4random()); src/sys/dev/pci/ubsec.c:arc4random_buf(ses->ses_iv, sizeof(ses->ses_iv)); src/sys/dev/pci/safe.c: arc4random_buf(ses->ses_iv, sizeof(ses->ses_iv)); src/sys/dev/pci/noct.c: arc4random_buf(iv, sizeof(iv)); src/sys/dev/pci/if_iwi.c: arc4random_buf(&data, sizeof data); src/sys/dev/pci/if_ix.c:arc4random_buf(&random, sizeof(random)); src/sys/dev/pci/hifn7751.c: arc4random_buf(ses->hs_iv, src/sys/dev/softraid.c: arc4random_buf(uuid->sui_id, sizeof(uuid->sui_id)); Those in dev/pci are about initializing hardware encryption devices. The rest of the calls (to the level I checked), will need at least the root filesystem to load some config data and then init some stuff (i.e. WEP key generation, etc.). So, until the filesystem is mounted, there is no need for arc4random() in the kernel. After the filesystem has been mounted the entropy data will be loaded from the file. If this is true. Where is the need for the time value in arc4_stir()?? Maybe I'm wrong. If so, please direct me to the code that needs arc4random() before the filesystem has been mounted, maybe EXCEPT the hardware crypto devices. Most certainly those drivers don't need arc4random during kernel init as well. >> So, at the first glance it looks like using the value of nanotime() in >> At least I would XOR the value of nanotime() to buf, >> instead of just prepending it. MD5 and the like does not seem to be >> necessary, as buf will allways contain some good random data. > > XOR it? Why? To fold the plain time value into some other random data returned by get_random_bytes. If it's a bad idea to "stir" or "fold" data that way, why is MD5 used in extract_entropy() to achieve the same goal? > Please provide a citation regarding the benefit of XOR'ing feed data > before passing it into MD5 for the purpose of PRNG folding. I did not say that. I said, that XORing the time value with the data of get_random_bytes() is probably sufficient and that MD5 would not be required.
Re: Allegations regarding OpenBSD IPSEC
> > Where do we invent entropy from when the kernel has only > > been running for 0.01 of a second? > > O.K. where do you need ramdom bytes during that state of the kernel? > All locations where arc4random* is called in the kernel are these: [list of 16] Unfortunately it looks like you missed a hundred or more. > The rest of the calls (to the level I checked), will need at least the > root filesystem to load some config data and then init some stuff > (i.e. WEP key generation, etc.). No, there is much more than that. Processes get started and initialize their libc-based prng's, as well as other state, including address space randomization, stack biasing, etc etc. > So, until the filesystem is mounted, there is no need for arc4random() > in the kernel. Totally false. > After the filesystem has been mounted the entropy data > will be loaded from the file. If this is true. Where is the need for > the time value in arc4_stir()?? You must not be reading the same code I am. > Maybe I'm wrong. If so, please direct me to the code that needs > arc4random() before the filesystem has been mounted Your approach is wrong. > I did not say that. I said, that XORing the time value with the data > of get_random_bytes() is probably sufficient and that MD5 would not be > required. The MD5 is required.
Re: Allegations regarding OpenBSD IPSEC
2010/12/22 Theo de Raadt : >> > Where do we invent entropy from when the kernel has only >> > been running for 0.01 of a second? >> >> O.K. where do you need ramdom bytes during that state of the kernel? >> All locations where arc4random* is called in the kernel are these: > > [list of 16] > > Unfortunately it looks like you missed a hundred or more. Damn, you're right. It seems my grep pattern was "initialized" in the wrong way (maybe not enough entropy from the user) :-)) > No, there is much more than that. Processes get started and > initialize their libc-based prng's, as well as other state, including > address space randomization, stack biasing, etc etc. After adjusting my grep pattern, I found several more locations. A lot of those need the filesystem. However at least one (for sure much more) is indeed calling arc4random while there is no filesystem mounted. So, just forget my "theory"! >> So, until the filesystem is mounted, there is no need for arc4random() >> in the kernel. > > Totally false. True (that it's false). So, I guess the discussion about the use of nanotime() is finished, as there is "common agreement" that it has no influence on the PRNG, right?
Re: Allegations regarding OpenBSD IPSEC
On 21 December 2010 G. 22:59:22 Theo de Raadt wrote:
> Go look at the function random_seed() in /usr/src/etc/rc
And it's definitely worth looking... Patch below.
--
Best wishes,
Vadim Zhukov
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
Index: rc
===
RCS file: /cvs/src/etc/rc,v
retrieving revision 1.345
diff -u -p -r1.345 rc
--- rc 8 Nov 2010 19:44:36 - 1.345
+++ rc 22 Dec 2010 05:25:37 -
@@ -102,14 +102,12 @@ wsconsctl_conf()
random_seed()
{
if [ -f /var/db/host.random -a "X$random_seed_done" = "X" ]; then
- dd if=/var/db/host.random of=/dev/urandom bs=1024 count=64 \
- > /dev/null 2>&1
dd if=/var/db/host.random of=/dev/arandom bs=1024 count=64 \
> /dev/null 2>&1
# reset seed file, so that if a shutdown-less reboot occurs,
# the next seed is not a repeat
- dd if=/dev/urandom of=/var/db/host.random bs=1024 count=64 \
+ dd if=/dev/arandom of=/var/db/host.random bs=1024 count=64 \
> /dev/null 2>&1
random_seed_done=1
@@ -312,7 +310,7 @@ mount -s /var >/dev/null 2>&1
# if there's no /var/db/host.random, make one through /dev/urandom
if [ ! -f /var/db/host.random ]; then
- dd if=/dev/urandom of=/var/db/host.random bs=1024 count=64 \
+ dd if=/dev/arandom of=/var/db/host.random bs=1024 count=64 \
>/dev/null 2>&1
chmod 600 /var/db/host.random >/dev/null 2>&1
else
malloc.3 typo
Hi, This looks like a typo, almost changes the meaning of the sentence: Index: lib/libc/stdlib/malloc.3 === RCS file: /cvs/src/lib/libc/stdlib/malloc.3,v retrieving revision 1.68 diff -u lib/libc/stdlib/malloc.3 --- lib/libc/stdlib/malloc.326 May 2010 08:22:11 - 1.68 +++ lib/libc/stdlib/malloc.322 Dec 2010 06:02:47 - @@ -235,7 +235,7 @@ Unused pages on the freelist are read and write protected to cause a segmentation fault upon access. This will also switch off the delayed freeing of chunks, -reducing random behaviour but detecting double +reducing random behaviour by detecting double .Fn free calls as early as possible. .It Cm G
Re: malloc.3 typo
On Tue, Dec 21, 2010 at 11:08:29PM -0700, Anthony J. Bentley wrote: > Hi, > > This looks like a typo, almost changes the meaning of the sentence: > > Index: lib/libc/stdlib/malloc.3 > === > RCS file: /cvs/src/lib/libc/stdlib/malloc.3,v > retrieving revision 1.68 > diff -u lib/libc/stdlib/malloc.3 > --- lib/libc/stdlib/malloc.3 26 May 2010 08:22:11 - 1.68 > +++ lib/libc/stdlib/malloc.3 22 Dec 2010 06:02:47 - > @@ -235,7 +235,7 @@ > Unused pages on the freelist are read and write protected to > cause a segmentation fault upon access. > This will also switch off the delayed freeing of chunks, > -reducing random behaviour but detecting double > +reducing random behaviour by detecting double > .Fn free > calls as early as possible. > .It Cm G No. I'm trying to express there: you pay a bit (by reducing randomness), but you also gains a bit (earlier detection). -Otto
Re: Allegations regarding OpenBSD IPSEC
On Wed, Dec 22, 2010 at 08:28:51AM +0300, Vadim Zhukov wrote: > # if there's no /var/db/host.random, make one through /dev/urandom ^ > if [ ! -f /var/db/host.random ]; then > - dd if=/dev/urandom of=/var/db/host.random bs=1024 count=64 \ > + dd if=/dev/arandom of=/var/db/host.random bs=1024 count=64 \ ^ > >/dev/null 2>&1 > chmod 600 /var/db/host.random >/dev/null 2>&1 > else
