| Ultrasonik Kovucular |
| Dec 28, 2:14 pm 2010 |
| Tim van der Molen | 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
warnings:
#define va_copy(dst, src) ((dst) = (src))
Because most of the /usr/src/sys/arch/*/include/stdarg.h headers contain
an "#ifdef lint" block, it seems appropriate to add the above macro ...
| Dec 28, 4:59 pm 2010 |
| Theo de Raadt | Re: MD5 Folding in kernel RNG
arc4random_buf_large() is not exported as an API; this is intentional.
If you do arc4random_buf_large() for a small buffer size, say 8, you
are not winning the output performance vs output quality vs system
interactiveness tradeoff in any way. It is a loss in all respects.
2048 was estimated as a knee where it the setup cost for a seperate
RC4 is cheap enough so that PRNG data can be created for independent
kernel threads without contention/holding of the mutex.
This mechanism was ...
| Dec 28, 3:39 pm 2010 |
| brad | 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 2010
Seed used was: 1293569063
------------------
But when I try to use a header from crypto++ in any C++ app. I get these
errors:
# g++ simple.cpp -o simple /usr/lib/libcryptopp.a
In file ...
| Dec 28, 2:00 pm 2010 |
| Stefan Sperling | 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
===================================================================
RCS file: /cvs/src/sbin/swapctl/swapctl.c,v
retrieving revision 1.17
diff -u -p -r1.17 swapctl.c
--- swapctl.c 26 Nov 2007 13:36:33 ...
| Dec 28, 1:36 pm 2010 |
| Kjell Wooding | MD5 Folding in kernel RNG
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, however, I notice we actually fold the MD5 output in
half. From extract_entropy():
MD5Final(buffer, &tmp);
/*
* In case the hash function has some recognizable
* output pattern, we ...
| Dec 27, 6:07 pm 2010 |
| Kjell Wooding | Re: MD5 Folding in kernel RNG
Hi Damien.
But again, we perturb it immediately afterwards, so what good is such
So one would have to guess the MD5 output from the RC4 output in order to
even pull off an attack like this. This kind of complete break would seem...
unlikely... That was what I was getting at with my first query (how would a
Yeah, so without any good reason to truncate it, let's just use the whole
hash, and hence, use all the entropy
There are arc4random_buf () calls in the kernel. Those can use ...
| Dec 28, 2:42 pm 2010 |
| Ted Unangst | Re: MD5 Folding in kernel RNG
First thought would be, in the event that there's a bias in MD5 (bit
12 is set 75% of the time), it would "help"? No, it doesn't.
Maybe if output bit 12 is always the same as input bit 12 and we want
to avoid revealing the input? That would work, assuming the xor bit
is random.
Despite its flaws, MD5 doesn't have any biases I'm aware of and should
have an even distribution of bits, so the fold neither adds anything
nor takes any more away (other than the obvious cut half).
| Dec 27, 9:02 pm 2010 |
| Damien Miller | Re: MD5 Folding in kernel RNG
I'm not aware of it being done elsewhere. Usually the recommendation is
to truncate, rather than fold hash output.
IMO we should reassess the output hash. Something like Whirlpool might be
significantly faster given its large block size.
-d
| Dec 28, 1:48 am 2010 |
| Damien Miller | Re: MD5 Folding in kernel RNG
It gives you knowledge of the collection pool, which is what the very
I don't know; like I said, most cryptographers that I have spoken to prefer
It is used to seed RC4. In the past it used to be used for other things,
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.
-d
| Dec 28, 1:45 pm 2010 |
| Kjell Wooding | 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, is this *ever* used directly, or is it simply the input to the
RC4 generator? In which case, pulling off a preimage attack would be
essentially miraculous.
In any case, if there is not a good reason ...
| Dec 28, 1:08 pm 2010 |
| Kjell Wooding |
| Dec 28, 12:06 am 2010 |
| Nima Hoda |
| Dec 28, 7:19 am 2010 |
| Nima Hoda |
| Dec 27, 7:33 pm 2010 |
| Jason McIntyre |
| Dec 28, 6:56 am 2010 |
