Re: MD5 Folding in kernel RNG

> > There are arc4random_buf () calls in the kernel. Those can use the > > arc4random_buf_large() mechanism, can thy not? Or are the requests > typically > > too small? > > arc4random_buf_large() is not exported as an API; this is intentional. > > If you do arc4random_buf_large() for a small buffe

Re: lint and va_copy()

On Tue, Dec 28, 2010 at 6:59 PM, Tim van der Molen wrote: > So, to conclude, what I would like to propose is the following: > * Hide from lint the va_copy() macro in . > * Add a lint-friendly va_copy() macro to > /usr/src/sys/arch/*/include/stdarg.h. Does adding a lint friendly __va_copy to arch

Re: working hotplug for busy devices on mpii(4)

On Wed, Dec 29, 2010 at 11:01:58AM +1000, David Gwynne wrote: > ive had no takers on testing. > > i cant see how raid and sas events will race in the current code, > so i think the 1second sleep to avoid confusion is unecessary. i > will put it in and deal with fallout if it comes up. Works for m

Re: Line-by-line functionality for rev(1)

tail -r

Re: working hotplug for busy devices on mpii(4)

ive had no takers on testing. i cant see how raid and sas events will race in the current code, so i think the 1second sleep to avoid confusion is unecessary. i will put it in and deal with fallout if it comes up. On Fri, Dec 24, 2010 at 11:44:52AM -0500, Kenneth R Westerback wrote: > On Fri, Dec

Line-by-line functionality for rev(1)

Hello all. A few days ago I needed to reverse a few files line-by-line (i.e., make first line become last and vice versa). There was nothing to do that in base, and rev(1) utility only may reverse characters in lines. So I decided to improve rev(1)... here it is. While digging there I realized th

lint and va_copy()

lint currently does not properly handle va_copy(): a statement like "va_copy(ap2, ap);" causes lint to issue warnings like test.c:14: warning: ap2 may be used before set Lint pass2: test.c:14: __va_copy used, but not defined Defining the following macro would be sufficient to prevent these warnin

Re: MD5 Folding in kernel RNG

> > This matters for userspace, but not for the kernel. We only start up one > > RC4 > > instance, so RC4's low key agility doesn't really bother us. > > > > There are arc4random_buf () calls in the kernel. Those can use the > arc4random_buf_large() mechanism, can thy not? Or are the requests typ

Re: MD5 Folding in kernel RNG

Hi Damien. On Tue, Dec 28, 2010 at 1:45 PM, Damien Miller wrote: > On Tue, 28 Dec 2010, Kjell Wooding wrote: > > > How would a preimage attack matter in this case? > > It gives you knowledge of the collection pool, which is what the very > thing the design is supposed to avoid. > But again, we

crypto++ on OpenBSD

Hi Tech, I can compile crypto++ 5.6.1 on OpenBSD 4.8 release i386. It requires gmake (which is a package), but otherwise is a straight forward install. I can then run the cryptest app in 'validation mode' and all tests pass: -- All tests passed! Test ended at Tue Dec 28 15:44:25

Re: MD5 Folding in kernel RNG

On Tue, 28 Dec 2010, Kjell Wooding wrote: > How would a preimage attack matter in this case? It gives you knowledge of the collection pool, which is what the very thing the design is supposed to avoid. > Even if I could pull one off, (i.e. guess the contents of the entropy pool > based on the ou

fix swapctl -A with DUIDs in /etc/fstab

/etc/fstab: 736f610b58fed843.b none swap sw 0 0 # swapctl -A swapctl: 736f610b58fed843.b: No such file or directory With patch below: # swapctl -A swapctl: adding 736f610b58fed843.b as swap device at priority 0 Plug a tiny mem leak while here. ok? Index: swapctl.c

Re: MD5 Folding in kernel RNG

How would a preimage attack matter in this case? Even if I could pull one off, (i.e. guess the contents of the entropy pool based on the output of the hash), we perturb it again right afterwards. Furthermore, how would this be any different than choosing just the upper or lower half? And again, i

Re: Add back-to-indentation (M-m) for mg

> On Mon, Dec 27, 2010 at 7:33 PM, Nima Hoda wrote: > > > On Mon, Dec 27, 2010 at 03:01:57PM -0700, Kjell Wooding wrote: > > > Looks good. Here is a slight cleanup. Essentially, fix alphabetical > > > ordering, change function name : > > > > The patch isn't applying for me. It seems tabs have be

Re: pf debug states: ioctl interface and state names.

On Sun, Dec 26, 2010 at 10:35:02PM +0100, Thomas Pfaff wrote: > On Tue, 21 Dec 2010 22:15:33 +0100 > Thomas Pfaff wrote: > > > 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

Re: MD5 Folding in kernel RNG

On Mon, 27 Dec 2010, Kjell Wooding wrote: > The OpenBSD random number subsystem uses an in-kernel entropy pool. This > data isn't used directly. When entropy is requested, the contents of the > pool are hashed with MD5, and the massaged output used to seed an RC4 PRNG. > > In looking at the code,