Thor Lancelot Simon | 26 Dec 00:27 2015

x86 CPU RNG support, take 2

I've cleaned it up a little and hooked it up as a standard entropy source
per Taylor's comments.  To avoid a pile of largely pointless config glue,
it is an internal source in kern_rndq.c just like the "callout" source.
I think this can probably be used for the onboard RNG on other CPUs as well.

I've also modified the VIA backend -- we now enable the dual noise sources on
newer CPUs, and grab a single RNG buffer without copying.  These ideas
came from .  I've
asked for testers for that part of the patch on port-i386 and port-amd64.

I would appreciate comments from anyone who has time to read the code.

Index: arch/amd64/include/Makefile
RCS file: /Volumes/NB/repo/src/sys/arch/amd64/include/Makefile,v
retrieving revision 1.18
diff -u -p -r1.18 Makefile
--- arch/amd64/include/Makefile	23 Jul 2014 18:19:43 -0000	1.18
+++ arch/amd64/include/Makefile	19 Dec 2015 22:17:36 -0000
 <at>  <at>  -4,7 +4,7  <at>  <at>  INCSDIR= /usr/include/amd64

 INCS=	ansi.h aout_machdep.h asm.h \
 	bootinfo.h bswap.h byte_swap.h \
-	cdefs.h cpu.h \
+	cdefs.h cpu.h cpu_rng.h\
 	disklabel.h \
 	elf_machdep.h endian.h endian_machdep.h \
(Continue reading)

Patrick Welche | 27 Nov 12:02 2014


It seems I have rediscovered the thread started by Nathan in 2005

the hard way.

Opening /dev/crypto, and sending a few MB of data to it via

His conclusion in


  For what it's worth, while working with both sides of /dev/crypto
  (writing some applications and adding a hw-acceleration backend), I've
  developed the strong impression that the /dev/crypto interface is
  something of an afterthought or testing interface, and that the only
  "first class" interface to crypto(4) is the kernel interface.

Any thoughts/plans for /dev/crypto?



Thor Lancelot Simon | 20 Apr 09:18 2014

cprng_fast implementation benchmarks

I have done some benchmarks of various cprng_fast implementations:

	arc4-mtx		The libkern implementation from
				netbsd-current, which uses a spin mutex to
				serialize access to a single, shared arc4

	arc4-nomtx		Mutex calls #ifdeffed out.  What was in
				NetBSD prior to 2012.  This implementation
				is not correct.

	arc4-percpu		New implementation of cprng_fast using percpu
				state and arc4 as the core stream cipher.
				Uses the arc4 implementation from
				sys/crypto/arc4, slightly modified to give an
				entry point that skips the xor.

	hc128-percpu		Same new implementation but with hc128 as the
				core stream cipher.  Differs from what I
				posted earlier in that all use of inline
				functions in the public API has been removed.

	hc128-inline		Percpu iplementation I posted earlier with all
				noted bugs fixed; uses inlines in header file
				which expose some algorithm guts to speed up


	All implementations were modified to rekey every 512MB of output and
(Continue reading)

Thor Lancelot Simon | 18 Apr 22:12 2014

Towards design criteria for cprng_fast()

I would like to offer some observations about the use of cprng_fast()
(once known as arc4random()) in our kernel and, from these, express
what I believe are reasonable design criteria for that function.

O1) cprng_fast() is used in some performance-critical parts of the kernel:

	A) It's used to permute memory mappings

	B) It's used, indirectly, at every program startup, because its
	   output is sucked down by userspace via sysctl() for use by SSP.

	C) It's used to generate initialization vectors for other ciphers,
	   including for use by line-rate crypto accellerators.

	D) It appears that it can be called per-packet by a few parts of
	   the networking stack in some cases -- ALTQ, possibly ip_id.

O2) cprng_fast() is *never* used to encrypt data.

	A) This would seem to imply that IV generation for other ciphers
	   is its most sensitive use.

	B) We can swap out the algorithm underlying cprng_fast() at any
	   time with no compatibility concerns.

O3) cprng_fast() is usually used via cprg_fast32() to generate just 32 bits
    of data at once.

	A) This suggests that whatever algorithm we use, we'll need a way
	   to use it to service short requests efficiently.
(Continue reading)

Lilly Vollmer | 27 Mar 23:00 2014


that God is seen more in

Questa e-mail è priva di virus e malware perché è attiva la protezione avast! Antivirus.

Taylor R Campbell | 30 Sep 09:22 2013

cgd(4) ciphers

The set of ciphers supported by cgd is showing its age.  It would be
nice if cgd supported a block cipher that

(a) has high public confidence,

(b) can be easily implemented without timing side channels;

(c) has 256-bit blocks, so we don't need to worry about birthday
bounds for 128-bit block ciphers on multi-terabyte disks; and

(d) is fast in software without hardware acceleration, because cgd
can't take advantage of AES-NI at the moment and not all the world is
a modern high-end x86 system.

All of the ciphers cgd supports -- Blowfish, 3DES, and AES -- fail
(b), (c), and (d), and Blowfish and 3DES fail (c) and (d) badly, being
very slow 64-bit block ciphers.

The best two candidates that come to mind are Serpent, which fails
only (c) and (d), and Threefish, which seems like a good candidate.
Both were designed to avoid using data-dependent branches and memory
references.  Both have been subjected to thorough scrutiny and were
finalists in NIST competitions.


(Side notes:
- cgd still needs renovation for MP safety and hardware acceleration,
but that's a bigger task than adding one or two new ciphers.
- We could use Threefish tweaks instead of CBC mode, but that would
(Continue reading)

Taylor R Campbell | 17 Jun 05:30 2013

rework rndsink and cprng locking

The attached patch reworks the rndsink(9) abstraction to simplify it
and fix various races, and rework the implementation (but not the
crypto) of cprng(9) in the process.  Comments?

After this, if I find the time, I'd like to (a) rework the cprng(9)
API a trifle to simplify it and make its blocking behaviour clearer,
(b) fix some MP issues in /dev/u?random, (c) rework the locking scheme
for rnd sources and the rnd sample queue, and (d) make it all run in
rump so we can easily have automatic tests for this stuff.
commit 8667a3927cc3d1f46300dbce8a70cd7135f3c2e1
Author: Taylor R Campbell <riastradh <at>>
Date:   Wed Apr 10 20:40:27 2013 +0000

    Rework rndsink(9) abstraction and adapt arc4random(9) and cprng(9).
    - Simplify API.
    - Simplify locking scheme.
    - Add a man page.
    - Avoid races in destruction.
    - Avoid races in requesting entropy now and scheduling entropy later.
    Periodic distribution of entropy to sinks reduces the need for the
    last one, but this way we don't need to rely on periodic distribution
    (e.g., in a future tickless NetBSD).
    rndsinks_lock should probably eventually merge with the rndpool lock,
    but we'll put that off for now.
(Continue reading)

Taylor R Campbell | 4 Sep 00:32 2012

default sshd host keys

(I am not subscribed to these lists, so please cc me in replies.)

If you enable sshd on stock NetBSD 6.0_RC1, then by default on boot
you will get an RSA host key with a 1024-bit modulus, a DSA host key
with 1024/160-bit parameters, and an ECDSA host key from the nistp521
curve.  All this is decided by the defaults specified in
/etc/rc.d/sshd and /etc/defaults/rc.conf.

But these days, 1024-bit RSA moduli and 1024/160-bit DSA parameters
are much too small for comfort[1].  ssh-keygen itself will generate
2048-bit RSA moduli by default, and the only reason that we end up
with 1024-bit RSA moduli is that we set

   ssh_keygen_flags="-b 1024"

in /etc/defaults/rc.conf.  I would like at least to replace this by


so that we get the defaults in ssh-keygen without our having to update
/etc/defaults/rc.conf every time the default key sizes are updated in
ssh-keygen.  Objections?

Going a little further, we could use `ssh-keygen -A' to generate all
the keys, instead of the script in /etc/rc.d/sshd.  However, that's a
bigger change, and I am also nervous about using 1024/160-bit DSA
parameters, which are much too small these days; or even using (EC)DSA
at all, because it requires an entropy source not only for key
generation but also to make signatures.  So if we make any bigger
change, I'd like to discuss using only RSA keys with >=2048-bit moduli
(Continue reading)

Thor Lancelot Simon | 6 Apr 16:59 2012

Kernel entropy pool / cprng race fix

The attached patch should fix a race that exists when an entropy sink
(such as a CPRNG instance that is being reseeded) is destroyed while
it is currently being reseeded.

I've minimally tested it but since the problem is hard to reproduce
I'd appreciate additional testers or additional eyes.

The diff is also at .



Thor Lancelot Simon	                                     tls <at>
  "The liberties...lose much of their value whenever those who have greater
   private means are permitted to use their advantages to control the course
   of public debate."					-John Rawls
? rh
? seed-destroy.diff
? arch/amd64/conf/RNDVERBOSE
? arch/arm/xscale/.iopaau.c.swp
? kern/1
? kern/lastbatch.txt
? kern/separate-mutex.diff
Index: kern/kern_rndq.c
RCS file: /cvsroot/src/sys/kern/kern_rndq.c,v
retrieving revision 1.1
diff -u -r1.1 kern_rndq.c
(Continue reading)

Thor Lancelot Simon | 4 Mar 04:49 2012

OpenSSH/OpenSSL patches to stop excessive entropy consumption

When applied along with revisions 1.10 and 1.11 of libc/gen/arc4random.c,
these patches should stop the excessive entropy consumption observed with
OpenSSH on current and NetBSD 6-branch systems.

I note that the cause of the problem is complex and somewhat amusing.

Let's start from this question: why on earth are there calls to
arc4random_stir() in unexpected places all over the OpenSSH sources?
Before and after every fork, after exec, in the key generation routines --
in places where there are no calls to arc4random() itself and where one
would hope there never had been (particularly for key generation!).

The reason turns out to be that, at some point, OpenSSL (not OpenSSH)
was patched for OpenBSD to make it use libc arc4random() as the source
of startup key material for its own RNG.  In an application like OpenSSH
that does not use the SSL parts of the library and does not call RAND_seed(),
that is the *only* key material for the generator.

I can only guess this was done because OpenSSL was "using too much entropy"
from /dev/random or /dev/urandom.  But the result was that programs like
OpenSSH, which call OpenSSL crypto functions in both halves after fork(),
would get the exact same bytes back from the generator (same primes for
ephemeral RSA or DH keys, same... *shudder*).  The pervasive calls to
arc4random_stir() paper over this problem.

This hack was not applied for NetBSD so OpenSSL continued to draw down
new entropy after every fork-exec OpenSSH performed: one per connection,
at least.  That's a lot of entropy.

The attached patch adjusts OpenSSL so its generator can be explicitly
(Continue reading)

Greg Troxel | 25 Feb 15:42 2012

openssl x509 -hash

Some colleagues have been finding that "openssl x509 -hash" produces
different results on netbsd-5 vs -current (late 2011).  The results are
consistent between i386/amd64.

(The hashes are used as symlinks in a CA directory to allow finding
trust anchor CA certs; we are using a private CA.)

1) Is anyone else seeing this?

2) Is there a notion that these hashes are meant to be computed/used on
a single machine, or are they meant to be broadly portable?  The man
page doesn't explain this very well.