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 herb...@gondor.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-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
help -- JFCh jchad...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/19] User-space API definition
- Herbert Xu herb...@gondor.hengli.com.au wrote: 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. It does _not_ do the same thing, same as ramfs and file descriptors do not do the same thing although they are both related to files. The kernel keyring service is basically a system-wide data storage service. /dev/crypto needs a quick way to refer to short-lived, usually process-local, kernel-space data structures from userspace. Imagine that instead of thread = clone(..., CLONE_THREAD); you needed to do thread_fd = mkstemp(/proc/XXX); fork(thread_fd); That's how just using the existing keyring would look like. Adapting the existing keyring to match the /dev/crypto use case better would make the keyring API at least 25% larger, and introduce completely different key identification and lifetime semantics for a set of keys. If you can see a way the two can be cleanly integrated, please don't just tell us that we have to do it, tell us how. 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. The key ID is not embedded into encryption operation requests (it uses a struct nlattr), so it would be quite possible to supply the raw key instead. Mirek -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/19] User-space API definition
On Mon, Sep 6, 2010 at 11:50, Miloslav Trmac m...@redhat.com wrote: - Herbert Xu herb...@gondor.hengli.com.au wrote: On Mon, Aug 23, 2010 at 11:37:40AM -0400, Miloslav Trmac wrote: 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. It does _not_ do the same thing, same as ramfs and file descriptors do not do the same thing although they are both related to files. The kernel keyring service is basically a system-wide data storage service. /dev/crypto needs a quick way to refer to short-lived, usually process-local, kernel-space data structures from userspace. The problem with the approach you're proposing is that we then have two entirely separate classes of keys. First we have the existing keyring class, which can be securely and revokably passed between different processes with limited rights, but cannot be handed up to the kernel's cryptoapi. Then we have your new class, which are anonymous keys with a brand new security model (which doesn't even have LSM hooks yet) and which cannot be referenced by name. Another potential issue is that keys are never actually unnamed, in that sense. If encryption keys truly were anonymous then you would find it impossible to reliably decrypt the data on the other end. For example, every RSA private key should be indexed either by the X.509 DN or for bare SSH keys by the public modulus information. Even transient SSL session keys are always put into an SSL session cache by apache or whatever to allow them to be reused across multiple TCP streams! So I would argue that an SSL implementation that uses this should actually create or use a keyring specifically as an SSL session cache (with keys indexed by SSL session ID). It then becomes trivial to share an SSL session cache between 3 independent HTTPS server programs from different vendors, such that the compromise of *any* of the processes would not in any way compromise the security of the session keys. This would be especially true if the session keys are actually generated by a keyring+cryptoapi operation in the kernel. So my recommendation would be to create some new operations of the existing keyring code: (1) If you *really* care about anonymous transient keys that are not identified by an SSL session ID or similar, then add a keyring operation for create an anonymous key in keyring X, where the kernel creates a proper temporary name. An SSL implementation would default to using the process-local keyring, which means that everything would automatically go away on process exit. (2) Add cryptoapi hooks to automatically register keyring key types based on the loaded cryptoapi modules. (3) Add any necessary keyring operations for efficiently performing zero-copy cryptoapi calls using those key types. Cheers, Kyle Moffett -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/19] User-space API definition
On Mon, Sep 6, 2010 at 15:13, Nikos Mavrogiannopoulos n.mavrogiannopou...@gmail.com wrote: On 09/06/2010 08:00 PM, Kyle Moffett wrote: The kernel keyring service is basically a system-wide data storage service. /dev/crypto needs a quick way to refer to short-lived, usually process-local, kernel-space data structures from userspace. The problem with the approach you're proposing is that we then have two entirely separate classes of keys. First we have the existing keyring class, which can be securely and revokably passed between different processes with limited rights, but cannot be handed up to the kernel's cryptoapi. I don't think this is the case. The NCR does not store any keys nor retrieves them. It does delegate the burden of that to userspace application. NCR exports a wrapped version of the key and the userspace application stores it. It could use the keyring to store the keys or could directly store them in the filesystem. Hmm, I'm confused. You say The NCR does not store any keys nor retrieves them, but ~75% of your API is specifically related to storing keys into kernel memory or retrieving them out of kernel memory. Specifically, putting keys into and out of the kernel and passing them around between processes is the *whole point* of the keyring API. So let me ask for some clarification: You talk a lot in the patches about the API itself, but what is the intended *use-case* for NCR? Is it to provide a back-end for code such as enhanced-security OpenSSL libraries? For example, a privileged process would loads a key from disk into the kernel, then fork the unprivileged SSL server process? Is it just a canonical interface for userspace to encrypt or decrypt data using the kernel's CryptoAPI? Cheers, Kyle Moffett -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/19] User-space API definition
- Kyle Moffett k...@moffetthome.net wrote:
On Mon, Sep 6, 2010 at 11:50, Miloslav Trmac m...@redhat.com wrote:
- Herbert Xu herb...@gondor.hengli.com.au wrote:
On Mon, Aug 23, 2010 at 11:37:40AM -0400, Miloslav Trmac wrote:
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.
It does _not_ do the same thing, same as ramfs and file descriptors
do not do the same thing although they are both related to files.
The kernel keyring service is basically a system-wide data storage
service. /dev/crypto needs a quick way to refer to short-lived,
usually process-local, kernel-space data structures from userspace.
The problem with the approach you're proposing is that we then have
two entirely separate classes of keys.
We have two entirely separate classes of files: inodes and file descriptors.
Isn't that only a problem if there is actual duplicate functionality? And is
copy_from_user() really enough reason to share the interface?
Like in the inodes/file descriptors case, the fact that you can read contents
of both does not automatically mean that a single interface for both is the
best option. The naming does suggest that this should be the case here, but
the differences are AFAICS much larger than the commonalities.
Another potential issue is that keys are never actually unnamed, in
that sense.
They are perhaps not unnamed from a global point of view, or from the point
of view of a few functions that directly manipulate the key, but they are quite
anonymous from the process' point of view.
If encryption keys truly were anonymous then you would
find it impossible to reliably decrypt the data on the other end. For
example, every RSA private key should be indexed either by the X.509
DN or for bare SSH keys by the public modulus information.
Why would that be useful? The SSH private key should be only available to
sshd. sshd has loaded the key from a file (_that_ is the key's name, as far
as the system administrator is concerned), and then the key is used only
privately within the sshd process. There is no more reason to have a name
attached to the loaded private key object than there is a reason to have a name
attached to the file descriptor used to read /etc/ssh/sshd_config - the key is
an application-internal object and its user-space identifier is merely a safe
pointer into the kernel.
Actually, in a modularly-designed program, only one component of the program
works with the key, the rest should not even be aware of the existence of the
key, and having a process-wide (or even more general) name for the key can lead
to unintended conflicts. Imagine having the option to give an every file
descriptor a name, automatically replacing earlier file descriptors with the
same name.
Having a well-known name for the sshd host private key is perhaps useful as an
attack this sign :)
Same for public keys - when an application does
public_key = import_from_certificate();
encrypt_data_using(public_key)
it is not interested in sharing the public key object with other processes -
after all, what if another process loaded a different key under the indented
name? Creating a meaningful identifier is about as costly as just importing
the key, anyway.
Even transient SSL session keys are always put into an SSL session cache by
apache or whatever to allow them to be reused across multiple TCP
streams!
The SSL session cache is a quite unusual case.
Also, there is one SSL private key per server DNS name, and one SSL session
cache entry per client-server pair, but there are at least four temporary keys,
for each connection, and there is absolutely no need to name these.
So my recommendation would be to create some new operations of the
existing keyring code:
(2) Add cryptoapi hooks to automatically register keyring key types
based on the loaded cryptoapi modules.
Hm, using a different key type for each cipher would at least allow reusing
add_key()/KEYCTL_{READ,UPDATE}; I didn't think even these could be useful.
So it's better than absolutely hopeless now :)
Thank you,
Mirek
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: crypto_xor
Nikos Mavrogiannopoulos n...@gnutls.org wrote: Hello, I was checking the crypto_xor() function and it is for some reason limited to 32 bit integers. Why not make it depend on the architecture by replacing the u32 with unsigned long? That way 64bit machines should perform xor with less instructions... We could do that, but you'd also need to go through every user to make sure that their alignment requirement is upgraded from 4 to sizeof(unsigned long). Thanks, -- Email: Herbert Xu herb...@gondor.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-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/19] User-space API definition
On Mon, Sep 6, 2010 at 17:11, Nikos Mavrogiannopoulos n.mavrogiannopou...@gmail.com wrote: I suppose you mean the reference to the internal representation of the key. This might be valid for few seconds until the required operation is over. This is not really what I would call storage. The storage and retrieval of keys is being done using two ioctl() the STORAGE_WRAP and STORAGE_UNWRAP. An example of how NCR works: 1. A Process generates an RSA key pair 2. Stores the (encrypted) pair using the STORAGE_WRAP to a file. 3. Another process loads the file, unwraps it using STORAGE_UNWRAP and gets a reference to the key 4. Does an RSA decryption using the key 5. Discards the reference to the key Consider the reference as a file descriptor after you have opened a file (a wrapped key). How do you see keyring being involved in a setup like this? Fundamentally the operations you described are *EXACTLY* the kind of things that I believe the keyring API should support. It does not support them now, but that API is where the described functionality really belongs. Please consider just extending the keyring API to support what you need. For example, assuming that we automatically register 1 keyring key type per algo it should be pretty straightforward. You would want to write a request_key() handler for those key types which can use whatever hardware support is available to automatically generate a new random key or alternatively pass the operation off to the /sbin/request-key process to generate and load one from userspace. The call might take a *long* time to complete, depending on the key type and whether or not there is hardware support. That would allow you to perform the generate an RSA key step in either a trusted request-key process or directly in a piece of hardware, helping to avoid accidental key material leaks from the unprivileged process. Then, you would want KEYCTL_DECRYPT_KEY, and KEYCTL_ENCRYPT_KEY which would use one key to encrypt another into a user buffer (or decrypt a key from a user buffer). These would probably need new LSM hooks and maybe key DAC permission bits. This would implement the STORAGE_WRAP and STORAGE_UNWRAP functionality you want, but it would be extensible to much more than just what NCR needs. I could see this being very useful as an extension to the existing Kerberos or NFS keyring usage. Other potential applications include very secure replacements for the SSH or GPG agent programs. For the final step of actually performing encryption/decryption of user data you would then want generic keyctl() ops for KEYCTL_ENCRYPT and KEYCTL_DECRYPT, which would simply call CryptoAPI with the user-provided input and output buffers. Again, you'd need new LSM hooks, etc. These are very obviously extensible to other applications. It's getting a bit late here, so I apologize if anything I've written above makes particularly little sense, but hopefully I've gotten the gist across. Cheers, Kyle Moffett -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH]crypto/Kconfig update broken web addresses.
Below is a patch to update the broken web addresses, in crypto/* that I could locate. Some are just simple typos that needed to be fixed, and some had a change in location altogether.. let me know if any of them need to be changed and such. Signed-off-by: Justin P. Mattock justinmatt...@gmail.com --- crypto/Kconfig | 16 1 files changed, 8 insertions(+), 8 deletions(-) diff --git a/crypto/Kconfig b/crypto/Kconfig index 1cd497d..925da03 100644 --- a/crypto/Kconfig +++ b/crypto/Kconfig @@ -365,7 +365,7 @@ config CRYPTO_RMD128 RIPEMD-160 should be used. Developed by Hans Dobbertin, Antoon Bosselaers and Bart Preneel. - See http://home.esat.kuleuven.be/~bosselae/ripemd160.html + See http://homes.esat.kuleuven.be/~bosselae/ripemd160.html config CRYPTO_RMD160 tristate RIPEMD-160 digest algorithm @@ -382,7 +382,7 @@ config CRYPTO_RMD160 against RIPEMD-160. Developed by Hans Dobbertin, Antoon Bosselaers and Bart Preneel. - See http://home.esat.kuleuven.be/~bosselae/ripemd160.html + See http://homes.esat.kuleuven.be/~bosselae/ripemd160.html config CRYPTO_RMD256 tristate RIPEMD-256 digest algorithm @@ -394,7 +394,7 @@ config CRYPTO_RMD256 (than RIPEMD-128). Developed by Hans Dobbertin, Antoon Bosselaers and Bart Preneel. - See http://home.esat.kuleuven.be/~bosselae/ripemd160.html + See http://homes.esat.kuleuven.be/~bosselae/ripemd160.html config CRYPTO_RMD320 tristate RIPEMD-320 digest algorithm @@ -406,7 +406,7 @@ config CRYPTO_RMD320 (than RIPEMD-160). Developed by Hans Dobbertin, Antoon Bosselaers and Bart Preneel. - See http://home.esat.kuleuven.be/~bosselae/ripemd160.html + See http://homes.esat.kuleuven.be/~bosselae/ripemd160.html config CRYPTO_SHA1 tristate SHA1 digest algorithm @@ -461,7 +461,7 @@ config CRYPTO_WP512 Whirlpool will be part of the ISO/IEC 10118-3:2003(E) standard See also: - http://planeta.terra.com.br/informatica/paulobarreto/WhirlpoolPage.html + http://www.larc.usp.br/~pbarreto/WhirlpoolPage.html config CRYPTO_GHASH_CLMUL_NI_INTEL tristate GHASH digest algorithm (CLMUL-NI accelerated) @@ -579,8 +579,8 @@ config CRYPTO_ANUBIS in the NESSIE competition. See also: - https://www.cosic.esat.kuleuven.ac.be/nessie/reports/ - http://planeta.terra.com.br/informatica/paulobarreto/AnubisPage.html + https://www.cosic.esat.kuleuven.be/nessie/reports/ + http://www.larc.usp.br/~pbarreto/AnubisPage.html config CRYPTO_ARC4 tristate ARC4 cipher algorithm @@ -659,7 +659,7 @@ config CRYPTO_KHAZAD on 32-bit processors. Khazad uses an 128 bit key size. See also: - http://planeta.terra.com.br/informatica/paulobarreto/KhazadPage.html + http://www.larc.usp.br/~pbarreto/KhazadPage.html config CRYPTO_SALSA20 tristate Salsa20 stream cipher algorithm (EXPERIMENTAL) -- 1.7.2.1 -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
