linux-kernel - Re: [PATCH] Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4830014F.9040800@firstfloor.org>
Date:	Sun, 18 May 2008 12:13:35 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Arjan van de Ven <arjan@...radead.org>
CC:	Chris Peterson <cpeterso@...terso.com>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Jeff Garzik <jeff@...zik.org>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
	tpmdd-devel@...ts.sourceforge.net, tpm@...horst.net
Subject: Re: [PATCH] Re: [PATCH] drivers/net: remove network drivers' last
 few uses of IRQF_SAMPLE_RANDOM

> I think the big kicker is the difference between a session key (short
> lived) and a "real" key such as a gpg key that lives for a long time
> and is used for multile sessions and with different users (in crypto
> speak, Alice uses the same random key for Bob, Charlotte and David and
> potentially for a long time). For a session key, urandom is very likely
> an acceptable compromise; there's only so much data it's used for.
> For long term keys I can totally see why /dev/random is used instead.

We don't use it for most long term keys, e.g. ssh host keys. That is
because even on high entropy systems /dev/random usually doesn't work
during distribution installation because the system has not run long
enough to collect significant entropy yet.

See also the distinction between "user controlled visible cryptography"
and "background cryptography" I introduced in a earlier mail on that
topic. gpg can only get away with it because they rely on a high level
of user education (so requiring banging on keys is ok), but that's
not really an option for your normal "everyday background crypto",
including longer term keys.

So yes it's a nice theory, but without using the available randomness
sources always it doesn't work.

Instead I think just both urandom and random should try to rely
on TPMs and other hardware rngs and always get high quality bit noise.

-Andi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/