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]

Date:	Sat, 8 Jan 2011 15:23:04 +0200
From:	Nikos Mavrogiannopoulos <nmav@...tls.org>
To:	Neil Horman <nhorman@...driver.com>
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 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
purpose of cryptographic key separation? If long term keys are to be
protected, then it makes sense to support RSA, DSA keys in addition to
symmetric keys (e.g. microsoft only supports assymetric keys for
separation, since symmetric ones are rarely used as long term keys -
[in TLS-PSK]).

Some of these issues are discussed in my report on a user-space crypto
interface that specifically targeted separation and speed at [0].

regards,
Nikos

[0]. https://www.cosic.esat.kuleuven.be/publications/article-1490.pdf
--
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/