headers
Thor Lancelot Simon | 4 Mar 2012 04:49
Picon
Favicon

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)

Permalink | Reply | 12 comments |
headers
Greg Troxel | 25 Feb 2012 15:42
Picon

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.
Permalink | Reply | 1 comment |
headers
Thor Lancelot Simon | 7 Nov 2011 07:22
Picon
Favicon

Patch: rework kernel random number subsystem (*nearly final*)

On Fri, Oct 21, 2011 at 05:15:55PM -0400, Thor Lancelot Simon wrote:
> 
> I have placed a patch at http://www.panix.com/~tls/rnd1.diff which
> implements many changes to the generation and use of randomness
> in the kernel (I previously sent it to these lists directly but
> it seems to be too large).
> 
> It is (most of) the first step in a three step process I envision for major
> overhaul of this subsystem:
> 
> 	1) Provide infrastructure needed to separate entropy
> 	   harvesting from random stream generation.  Clean up
> 	   interfaces between existing kernel components that
> 	   deal with random number generation and consumption.

There's a new patch at http://www.panix.com/~tls/rnd4.diff which
I intend to commit as soon as I find and fix one remaining bug.  This
version of the patch adds some infrastructure the new random/urandom
pseudodevices will need and addresses several nasty race conditions
around rekeying by changing the rndpool mutex from IPL_SOFTCLOCK to
IPL_VM.

It also fixes several miscellaneous bugs (including a severe one in
rnd_add_data that has been around for a long time) and addresses KNF
issues in my previous patches.  There are also a few performance tweaks.

The mutex change to IPL_VM should not have much performance impact as
it's never held during copy in/out and my next set of changes will
eliminate any direct access to the entropy pool (thus any taking of
the mutex) by the pseudodevices -- that is, from userspace consumers.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thor Lancelot Simon | 21 Oct 2011 23:15
Picon
Favicon

Patch: rework kernel random number subsystem


I have placed a patch at http://www.panix.com/~tls/rnd1.diff which
implements many changes to the generation and use of randomness
in the kernel (I previously sent it to these lists directly but
it seems to be too large).

It is (most of) the first step in a three step process I envision for major
overhaul of this subsystem:

	1) Provide infrastructure needed to separate entropy
	   harvesting from random stream generation.  Clean up
	   interfaces between existing kernel components that
	   deal with random number generation and consumption.

	2) Replace all direct read access to the entropy pool with
	   an appropriate random stream generator, keyed from the pool.
	   Clean up the current mess in which the same source files
	   implement the entropy pool and the userspace pseudodevices
	   /dev/random and /dev/urandom.

	3) Replace the entropy pool itself with a more modern design
	   such as Fortuna.

Here are the changes you will find in this patch:

	1) Two new components are provided, "rngtest" (subr_rngtest.c)
	   and "nist_ctr_drbg" (crypto/nist_ctr_drbg).  The rngtest component
	   implements the FIPS 140-2 statistical RNG test.  It is based on
	   work by Greg Rose at Qualcomm.  The nist_ctr_drbg component
	   implements the NIST SP800-90 CTR_DRBG, which uses AES in a
(Continue reading)

Permalink | Reply | 4 comments |
headers
Taylor R Campbell | 27 Nov 2010 03:40
Favicon

[patch] cgd

(I am not subscribed to this list, so please cc me in replies.)

I tried to use cgd yesterday, and was pretty by the man pages and the
use of cgdconfig; I also stumbled across some bugs in cgdconfig.  I am
not a cryptographer, and thus am unqualified to give cryptographic
advice, but I thought it might be worthwhile for the man pages to be a
little clearer on the disk format -- enough to write programs that
read and write it -- and to mention some cryptographic limitations of
cgd.

Attached is a patch to HEAD that fixes some errors in the
implementation and documentation.  However, I eventually gave up on
trying to use cgdconfig[*], so I wrote my own trivial utilities (at
<http://mumble.net/~campbell/tmp/cgdutil-20101127.tgz> for the time
being, for anyone curious) to serve its function, when combined with
external tools such as scrypt <http://www.tarsnap.com/scrypt/>.

Comments?  I would submit a PR for the patch, but, as I said, I am not
a cryptographer, so I am interested more in review on the patch (and
corrections to my misconceptions about cgd, if any) than just in
applying the patch.

[*] Aside from having a usage model that confused me, cgdconfig lacks
    any cryptographic integrity checks -- a passphrased parameters
    file is not actually bound to a particular key, so, for instance,
    if you `cgdconfig -G' up a new parameters file, mistype a
    passphrase, and delete the old one, cgdconfig won't (can't!)
    notice, and your cgd will be lost and gone forever.  In contrast,
    an scrypt file is cryptographically bound to its contents, so
    scrypt can say whether you typed the correct passphrase or not.
(Continue reading)

Permalink | Reply | 13 comments |
headers
Hubert Feyrer | 29 Jan 2010 11:11
Picon
Favicon

Intel QuickAssist support?


According to the Intel website, QuickAssist provides ...

  * "Accelerated performance for demanding applications with Front Side Bus
    attached Field Programmable Gate Array (FSB-FPGA) hardware modules.
  * Agility to migrate from one technology to another with minimum impact
    to applications with Intel QuickAssist Technology Accelerator Abstraction
    Layer (AAL).
  * Support for small form factor accelerators with emerging technology
    codenamed "Tolapai" that combines numerous powerful enabling technology
    on a single chip.
  * Broad sweeping accelerator improvements with protocol and speed
    improvements to PCI Express* 2.0 initially proposed by Intel and IBM
    (called Geneseo*). PCI Express* 3.0 is expected to be the PCI-SIG's
    response to this proposal and will improve accelerator efficiency and
    double delivered bandwidth to 8GT/s."
(Source: http://www.intel.com/technology/platforms/quickassist/index.htm)

In other words: it's a vendor-independent interface that manufacturers of 
hardware crypto acceleration can use to provide hardware crypto, make it 
available via a standard instruction set / driver and thus reduce driver 
development efforts.

I think it would be nice to have such a driver and hook that into 
opencrypto(9).

After looking at the existing code a bit, I think this cold be done as a 
Summer-of-Code project (assuming availability of specs and possibly 
hardware).
(Continue reading)

Permalink | Reply | 1 comment |
headers
Greg A. Woods | 30 Oct 2009 02:20
X-Face
Picon
Favicon

glxsb(4) doesn't appear to be working for me (was: AMD Geode LX Security Block)

["Jared D. McNeill" wrote some time ago:]
> 
> Ok, thanks to a bunch of helpful hints on and off list, here we go:
>
> swcrypto:
>
>   aes-128-cbc 3688.28k 4064.06k 4185.64k 4216.48k 4221.59k
>
> hwcrypto:
>
>   aes-128-cbc 372.70k 1422.76k 5098.58k 13612.23k 26804.31k

I've got NetBSD-4 running here on a PC Engines ALIX.2d3 board.

My dmesg shows:

cpu0: AMD Geode LX (586-class), 498.08 MHz, id 0x5a2
cpu0: features 88a93d<FPU,DE,PSE,TSC,MSR,CX8,SEP>
cpu0: features 88a93d<PGE,CMOV,MPC,MMX>
cpu0: "Geode(TM) Integrated Processor by AMD PCS"
cpu0: I-cache 64 KB 32B/line 16-way, D-cache 64 KB 32B/line 16-way
cpu0: L2 cache 128 KB 32B/line 4-way
cpu0: ITLB 16 4 KB entries fully associative
cpu0: DTLB 16 4 KB entries fully associative
cpu0: 8 page colors
[[....]]
glxsb0 at pci0 dev 1 function 2: revision 0: RNG AES

Open SSL seems to say what I'm told I should expect it to say:
(Continue reading)

Permalink | Reply | 5 comments |
headers
Thor Lancelot Simon | 31 Mar 2009 08:12

VIA C3 probe wrong; VIA C3 AES support broken?

The patch below does four things:

	1) It fixes cpu_probe_c3 so it uses the correct CPU
	   family and thus actually matches C3 and C7 (and possibly
	   Nano) CPUs.

	2) It enables the crypto features of these processors if they
	   are not already enabled.

	3) It attaches the VIA RNG as a source of entropy.

	4) It changes the padlock OCF driver so that it registers
	   as type "software" not type "hardware" and thus doesn't
	   pointlessly suck crypto operations into the kernel -- the
	   PadLock instructions are not privileged and can be used
	   directly by OpenSSL applications via the "padlock" engine.

Unfortunately, the resulting kernel has dysfunctional FAST_IPSEC ESP; it
seems to get both the AES encryption and decryption of packets wrong.
Since the Padlock code hasn't actually been enabled on anyone's
systems in some time (because of the identcpu bug) I suspect it has
not worked for a while.

The same kernel minus options VIA_PADLOCK does ESP fine via the
cryptosoft backend.  I put a bunch of work into this but I am out
of time (have to do actual, you know, "job" type work) so if anyone
can see what's wrong with the VIA AES driver I'd sure appreciate it!

Index: arch/i386/i386/machdep.c
===================================================================
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ted Sykes | 22 Jan 2009 09:28
Picon

Don't know a good place to buy pilz?

Helping people extend their xxxlife! http://xtsgr.paraseagames.com.es/
Permalink | Reply | 0 comments |
headers
Thor Lancelot Simon | 6 Nov 2008 17:00

locking/synchronization changes 4.99.66->now? (broken opencrypto)

Darran Hunt and I have been trying to explain some extremely strange
crashes in opencrypto with 5.0_BETA or recent -current.  With a
DEBUG DIAGNOSTIC LOCKDEBUG kernel, the following test (using the software
backend):

	sysctl -w kern.cryptodevallowsoft=-1
	openssl speed -engine cryptodev -elapsed -evp des-ede3-cbc

will pretty reliably produce a panic on our 4- or 8-cpu amd64 and i386
machines.  The panic is a protection fault when the cv_signal() in
cryptoret() fires.  Further investigation shows that the condvar in
the active request appears to have been freed, and working around that
(by use of cv_valid) lets us get far enough to be reasonably sure that
the containing cryptoreq (the "crp") has been freed but is somehow
still on cryptoreq's queue.  The only other possibility we see (but
think we have mostly ruled out) is a pool allocator problem leading to
overlapping request structures.

Another very odd thing here is that of course the test above produces a
single stream of basically synchronous requests.  There should be little
or no concurrency to create potential problems.

We've been over the code with a fine-tooth comb and are pretty sure there
should be no way for the return queue to be manipulated or the code that
frees requests to be called except under the protection of crypto_mtx.

It is almost as if crypto_mtx weren't mutexing, specifically around the
TAILQ manipulation for the return queue -- it looks like the TAILQ calls
in cryptoret() get a stale TAILQ_HEAD that points at freed data.  We tried
putting membar_sync() before and after the traversal of the TAILQ in
(Continue reading)

Permalink | Reply | 6 comments |
headers
Paula Grassi | 12 Jun 2008 06:11

Uma frase e uma sugestao


 ,

Saudaçoes. Tenho certeza que conhece a frase que diz: "Propaganda e a alma do 
negocio". Por isso estou escrevendo para te lembrar da grande utilidade do email 
marketing para a divulgaçao do seu negocio.

Os   estao a sua disposiçao, mas estao tambem a disposiçao dos seus concorrentes. 
Por isso conquiste primeiro este mercado antes que seja conquistado por outras 
pessoas. Que tal iniciar a sua campanha esta semana?

Cordialmente,
Paula Grassi
http://www.divulgaemails.com
(0xx71)3491-9005 ou (0xx71)9932-0158(24h)
MSN e SKYPE: dvgmail
Permalink | Reply | 0 comments |

Gmane