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: <20110107120451.GA22347@hmsreliant.think-freely.org>
Date:	Fri, 7 Jan 2011 07:04:51 -0500
From:	Neil Horman <nhorman@...driver.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	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 Thu, Jan 06, 2011 at 02:13:17PM -0800, Linus Torvalds wrote:
> On Thu, Jan 6, 2011 at 1:39 PM, Herbert Xu <herbert@...dor.hengli.com.au> wrote:
> > On Thu, Jan 06, 2011 at 01:23:19PM -0800, Linus Torvalds wrote:
> >>
> >> Explanations of interface. Code. Who uses it? What are the actual
> >> performance benefits on real code?
> >
> > You snipped out the bit in my reply where I expanded on it:
> 
> You didn't expand on it AT ALL.
> 
> You just mentioned "the interface". I haven't seen WHAT THAT INTERFACE IS!
> 
> How hard is that to understand?
> 
> > Here is the original cover email for the patches:
> 
> Ok, this is more like it. This is roughly what I wanted to see:
> 
> > : Here is a sample hash program (note that these only illustrate
> > : what the interface looks like and are not meant to be good examples
> > : of coding :)
> 
> But I'm still missing the part where you show that there is any actual
> use case that makes sense, and that actually improves performance.
> Maybe it's been posted somewhere else, but the thing is, you're asking
> _me_ to pull, and as a result you need to convince _me_ that this is a
> good idea. So if it's been posted/discussed extensively elsewhere,
> please point to those discussions.
> 
> I really don't like adding interfaces that don't have hard uses
> associated with them. We've done it in the past, and it tends to be a
> morass and a bad idea. That's been true even when the idea has been my
> own, and thus obviously genius-level and clearly the RightThing(tm),
> like "splice()". And it's why I push back on new interfaces when I see
> them.
> 
> 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.

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