linux-kernel - Re: Crypto Update for 2.6.38

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: <1294686330.16075.2.camel@Nokia-N900-51-1>
Date:	Mon, 10 Jan 2011 20:05:30 +0100
From:	Dag Arne Osvik <da@...ik.no>
To:	Neil Horman <nhorman@...driver.com>,
	Nikos Mavrogiannopoulos <nmav@...tls.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Herbert Xu <herbert@...dor.hengli.com.au>,
	"David S. Miller" <davem@...emloft.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux Crypto Mailing List <linux-crypto@...r.kernel.org>
Subject: Re: Crypto Update for 2.6.38

> On Sat, Jan 08, 2011 at 03:23:04PM +0200, Nikos Mavrogiannopoulos wrote:
> > On Fri, Jan 7, 2011 at 2:04 PM, Neil Horman <nhorman@...driver.com>
> > wrote:
> > 
> > > > Btw, it doesn't have to be about performance per se. Does this
> > > > allow people to use keys without actually _seeing_ those keys?
> > > > Your example implies that that is not the case, but that's
> > > > actually one of the few reasons to actually support a kernel
> > > > crypto interface - the ability to have private personal keys
> > > > around, but not having to actually let possibly untrusted programs
> > > > see them.
> > > This actually is an indirect feature of this interface.  Using it,
> > > you can open a algorithm socket, select a specific alg, assign a
> > > key, and then pass that socket descriptor over a unix socket to an
> > > another process using an SCM_RIGHTS ancilliary message.  The
> > > receiving process can then use children acceppted from that passed
> > > socket to preform the configured crypto operation without any
> > > knoweldge of the keys used in it.  I can write a demo app if you
> > > like.
> > 
> > Several things have to be considered when extending an interface like
> > that. For example, do the algorithm implementations protect against
> > timing attacks, or keys can be recovered, using them? What is the
> No, the kernel does not implement any protection against timing attacks
> in the algorithms per-se, but preforming a timing attack against a
> kernel crypto operation is going to be near impossible anyway, as
> precise timing measurements are going to get obscured by interupts,
> scheduling jitter, lock contention, and various other factors that will
> make measuring syscall time fairly useless.

Let me just point out that this is not near impossible at all; instead it has already been done more than 6 years ago. And it's not only syscall time that leaks information. One practical example is recovery of a full AES key in a couple of seconds, using cache attacks against an encrypted file system. AES-NI is immune to this kind of attack, but other algorithms typically implemented using lookup tables are at risk.

Dag Arne

--
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/