linux-kernel - Re: [PATCH 01/19] User-space API definition

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: <20100906121708.GA26354@gondor.apana.org.au>
Date:	Mon, 6 Sep 2010 20:17:08 +0800
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	Miloslav Trmac <mitr@...hat.com>
Cc:	Kyle Moffett <kyle@...fetthome.net>, linux-crypto@...r.kernel.org,
	Nikos Mavrogiannopoulos <n.mavrogiannopoulos@...il.com>,
	Neil Horman <nhorman@...hat.com>, linux-kernel@...r.kernel.org,
	David Howells <dhowells@...hat.com>
Subject: Re: [PATCH 01/19] User-space API definition

On Mon, Aug 23, 2010 at 11:37:40AM -0400, Miloslav Trmac wrote:
>
> I can see almost no overlap between the two sets of requirements.  Probably the only common use case is handling session keys (e.g. keys used in a kerberos ticket), which should be stored in the kernel for the duration of the session, made available to each process in the session, and available as keys for kernel crypto.  Such keys will be in the minority, though, and it seems to me the best approach for handling these is to allow key export/import from/to keyring keys in addition to export/import from/to data in userspace: the long-term storage would be handled by the existing keyring API, which stores the key as unformatted binary data, and import into the crypto context would convert the key into the internal representation more suitable for crypto.
> 
> I have seriously considered the keyring API, and this is what I came up with - but I'd love to be shown a better way.

FWIW adding a second key management system to the kernel is
totally out of the question.

If the existing system doesn't work for you, find a way to build
on it so that it does.  Adding a second system that pretty much
does the same thing is unacceptable.

Also, the key management for secret keys that you've added should
not be the only mode offered to the user.  Most people do not need
the separation between key setting and encryption/decryption.

Cheers,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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/