Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API
Hi Stephan, >>> The last round of reviews for AF_ALG akcipher left off at an impasse >>> around a year ago: the consensus was that hardware key support was >>> needed, but that requirement was in conflict with the "always have a >>> software fallback" rule for the crypto subsystem. For example, a private >>> key securely generated by and stored in a TPM could not be copied out for >>> use by a software algorithm. Has anything come about to resolve this >>> impasse? >>> >>> There were some patches around to add keyring support by associating a key >>> ID with an akcipher socket, but that approach ran in to a mismatch >>> between the proposed keyring API for the verify operation and the >>> semantics of AF_ALG verify. >>> >>> AF_ALG is best suited for crypto use cases where a socket is set up once >>> and there are lots of reads and writes to justify the setup cost. With >>> asymmetric crypto, the setup cost is high when you might only use the >>> socket for a brief time to do one verify or encrypt operation. >>> >>> Given the efficiency and hardware key issues, AF_ALG seems to be >>> mismatched with asymmetric crypto. Have you looked at the proposed >>> keyctl() support for crypto operations? >> we have also seen hardware now where the private key will never leave the >> crypto hardware. They public and private key is only generated for key >> exchange purposes and later on discarded again. Asymmetric ciphers are >> really not a good fit for AF_ALG and they should be solely supported via >> keyctl. > > Thanks for the reminder. I have looked at that but I am unsure about whether > this one covers asym crypto appropriately, too. > > The issue is that some hardware may only offer accelerators without a full > blown RSA siggen/ver logic (that pulls in PKCS or OAEP or others). How do you > propose to cover raw primitives with keyctl? where is such a hardware? And what is the usage of it? Look at what we are using asymmetric crypto for at the moment. It is either for sign and verify with secure boot etc. Or it is for key exchange purposes. The asymmetric crypto is a means to an end. If it is not for certification verification, then it for is creating a symmetric key to be used with a symmetric cipher. We have the the asymmetric_keys subsystem for representing the nature of this crypto. Also the list of asymmetric ciphers is a lot smaller than the symmetric ones. What raw primitives? When we are using for example ECDH for Bluetooth where you need to create a pairwise symmetric key, then what you really want from the cryptographic primitives is this: 1) Create public/private key pair 2) Give public key to applications and store the private key safely 3) Retrieve public key from remote side and challenge 4) Compute key exchange magic (like DH) from remote public key 5) Tell the key generator to throw away the private key So I do not want to load any private key into the kernel. I want the kernel to give me a public key and allow me to feed the key exchange primitive with the remote public key. This is clearly not AF_ALG. We had this discussion during the KPP design and I made it clear multiple times that this is totally different. This is clearly keyctl area of interfaces since the main operation is key generation. I am not saying that keyctl is perfect just yet, but we are working on it. We however have to accept that it is more suitable than AF_ALG. You will never have stream based data feed into an asymmetric cipher. That is what stream ciphers are for. Regards Marcel
Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API
Am Freitag, 11. August 2017, 07:13:30 CEST schrieb Marcel Holtmann: Hi Marcel, > > > > The last round of reviews for AF_ALG akcipher left off at an impasse > > around a year ago: the consensus was that hardware key support was > > needed, but that requirement was in conflict with the "always have a > > software fallback" rule for the crypto subsystem. For example, a private > > key securely generated by and stored in a TPM could not be copied out for > > use by a software algorithm. Has anything come about to resolve this > > impasse? > > > > There were some patches around to add keyring support by associating a key > > ID with an akcipher socket, but that approach ran in to a mismatch > > between the proposed keyring API for the verify operation and the > > semantics of AF_ALG verify. > > > > AF_ALG is best suited for crypto use cases where a socket is set up once > > and there are lots of reads and writes to justify the setup cost. With > > asymmetric crypto, the setup cost is high when you might only use the > > socket for a brief time to do one verify or encrypt operation. > > > > Given the efficiency and hardware key issues, AF_ALG seems to be > > mismatched with asymmetric crypto. Have you looked at the proposed > > keyctl() support for crypto operations? > we have also seen hardware now where the private key will never leave the > crypto hardware. They public and private key is only generated for key > exchange purposes and later on discarded again. Asymmetric ciphers are > really not a good fit for AF_ALG and they should be solely supported via > keyctl. Thanks for the reminder. I have looked at that but I am unsure about whether this one covers asym crypto appropriately, too. The issue is that some hardware may only offer accelerators without a full blown RSA siggen/ver logic (that pulls in PKCS or OAEP or others). How do you propose to cover raw primitives with keyctl? Ciao Stephan
Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API
Am Freitag, 11. August 2017, 02:48:37 CEST schrieb Mat Martineau: Hi Mat, > > AF_ALG is best suited for crypto use cases where a socket is set up once > and there are lots of reads and writes to justify the setup cost. With > asymmetric crypto, the setup cost is high when you might only use the > socket for a brief time to do one verify or encrypt operation. To me, the entire AF_ALG purpose is solely to export hardware support to user space. That said, if user space wants an accelerator, a socket would be opened once followed by numerous read/write requests. Besides, I am aware of Tadeusz' patch to link algif_akcipher to the keyring and I planned to port it to the current implementation. But I thought I offer a small patch focusing on the externalization of the akcipher API first. I think the keyctl and AF_ALG are no opponents, but rather are orthogonal to each other. The statement I made for the KPP AF_ALG RFC applies here too: """ I am aware and in fact supported development of the DH support in the keys subsystem. The question will be raised whether the AF_ALG KPP interface is superfluous in light of the keys DH support. My answer is that AF_ALG KPP is orthogonal to the keys DH support. The keys DH support use case is that the keys are managed inside the kernel and thus has the focus on the key management. Contrary, AF_ALG KPP does not really focus on key management but simply externalizes the DH/ECDH support found in the kernel including hardware acceleration. User space is in full control of the key life cycle. This way, AF_ALG could be used to complement user-space network protocol implementations like TLS or IKE to offload the resource intense DH calculations to accelerators. """ Ciao Stephan
Re: [PATCH v8 4/4] crypto: algif_akcipher - enable compilation
Hi, Stephan, On 08/10/2017 09:40 AM, Stephan Müller wrote: Add the Makefile and Kconfig updates to allow algif_akcipher to be compiled. Signed-off-by: Stephan Mueller--- crypto/Kconfig | 9 + crypto/Makefile | 1 + 2 files changed, 10 insertions(+) Any reason why you keep this patch separately? I think you can squash this patch with patch 3/4. Cheers, ta
Re: [PATCH v8 4/4] crypto: algif_akcipher - enable compilation
Am Freitag, 11. August 2017, 14:56:18 CEST schrieb Tudor Ambarus: Hi Tudor, > Any reason why you keep this patch separately? > I think you can squash this patch with patch 3/4. There is no real reason. If you think it makes sense to add it to patch 3, I will do that. Thanks. Ciao Stephan
Re: [PATCH v5 2/5] lib: Add zstd modules
On 08/10/2017 03:25 PM, Hugo Mills wrote: On Thu, Aug 10, 2017 at 01:41:21PM -0400, Chris Mason wrote: On 08/10/2017 04:30 AM, Eric Biggers wrote: Theses benchmarks are misleading because they compress the whole file as a single stream without resetting the dictionary, which isn't how data will typically be compressed in kernel mode. With filesystem compression the data has to be divided into small chunks that can each be decompressed independently. That eliminates one of the primary advantages of Zstandard (support for large dictionary sizes). I did btrfs benchmarks of kernel trees and other normal data sets as well. The numbers were in line with what Nick is posting here. zstd is a big win over both lzo and zlib from a btrfs point of view. It's true Nick's patches only support a single compression level in btrfs, but that's because btrfs doesn't have a way to pass in the compression ratio. It could easily be a mount option, it was just outside the scope of Nick's initial work. Could we please not add more mount options? I get that they're easy to implement, but it's a very blunt instrument. What we tend to see (with both nodatacow and compress) is people using the mount options, then asking for exceptions, discovering that they can't do that, and then falling back to doing it with attributes or btrfs properties. Could we just start with btrfs properties this time round, and cut out the mount option part of this cycle. In the long run, it'd be great to see most of the btrfs-specific mount options get deprecated and ultimately removed entirely, in favour of attributes/properties, where feasible. It's a good point, and as was commented later down I'd just do mount -o compress=zstd:3 or something. But I do prefer properties in general for this. My big point was just that next step is outside of Nick's scope. -chris
Re: [PATCH v8 3/4] crypto: AF_ALG -- add asymmetric cipher
Hi, Stephan, On 08/10/2017 09:40 AM, Stephan Müller wrote: This patch adds the user space interface for asymmetric ciphers. The interface allows the use of sendmsg as well as vmsplice to provide data. The akcipher interface implementation uses the common AF_ALG interface code regarding TX and RX SGL handling. Signed-off-by: Stephan Mueller--- crypto/algif_akcipher.c | 466 include/crypto/if_alg.h | 2 + 2 files changed, 468 insertions(+) create mode 100644 crypto/algif_akcipher.c diff --git a/crypto/algif_akcipher.c b/crypto/algif_akcipher.c new file mode 100644 index ..1b36eb0b6e8f --- /dev/null +++ b/crypto/algif_akcipher.c @@ -0,0 +1,466 @@ +/* + * algif_akcipher: User-space interface for asymmetric cipher algorithms + * + * Copyright (C) 2017, Stephan Mueller + * + * This file provides the user-space API for asymmetric ciphers. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the Free + * Software Foundation; either version 2 of the License, or (at your option) + * any later version. + * + * The following concept of the memory management is used: + * + * The kernel maintains two SGLs, the TX SGL and the RX SGL. The TX SGL is + * filled by user space with the data submitted via sendpage/sendmsg. Filling + * up the TX SGL does not cause a crypto operation -- the data will only be + * tracked by the kernel. Upon receipt of one recvmsg call, the caller must + * provide a buffer which is tracked with the RX SGL. + * + * During the processing of the recvmsg operation, the cipher request is + * allocated and prepared. As part of the recvmsg operation, the processed + * TX buffers are extracted from the TX SGL into a separate SGL. + * + * After the completion of the crypto operation, the RX SGL and the cipher + * request is released. The extracted TX SGL parts are released together with + * the RX SGL release. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include I like that you ordered these alphabetically. Is there a reason why crypto/scatterwalk.h is not after crypto/if_alg.h? + +struct akcipher_tfm { + struct crypto_akcipher *akcipher; + bool has_key; +}; + +static int akcipher_sendmsg(struct socket *sock, struct msghdr *msg, + size_t size) +{ + return af_alg_sendmsg(sock, msg, size, 0); +} + +static int _akcipher_recvmsg(struct socket *sock, struct msghdr *msg, +size_t ignored, int flags) +{ + struct sock *sk = sock->sk; + struct alg_sock *ask = alg_sk(sk); + struct sock *psk = ask->parent; + struct alg_sock *pask = alg_sk(psk); + struct af_alg_ctx *ctx = ask->private; + struct akcipher_tfm *akc = pask->private; + struct crypto_akcipher *tfm = akc->akcipher; + struct af_alg_async_req *areq; + int err = 0; initialization not needed. + int maxsize; + size_t len = 0; initialization not needed. len will be initialized in af_alg_get_rsgl. Also, size_t could be 32 or 64 bit wide. Could you declare the size_t variables before the int ones? This will avoid stack padding on 64bit systems if one adds a new int variable in the same place where the ints are now. + size_t used = 0; initialization to zero not needed. You can directly initialize to ctx->used or don't initialize at all. + + maxsize = crypto_akcipher_maxsize(tfm); + if (maxsize < 0) + return maxsize; + + /* Allocate cipher request for current operation. */ + areq = af_alg_alloc_areq(sk, sizeof(struct af_alg_async_req) + +crypto_akcipher_reqsize(tfm)); + if (IS_ERR(areq)) + return PTR_ERR(areq); + + /* convert iovecs of output buffers into RX SGL */ + err = af_alg_get_rsgl(sk, msg, flags, areq, maxsize, ); + if (err) + goto free; + + /* ensure output buffer is sufficiently large */ + if (len < maxsize) { + err = -EMSGSIZE; + goto free; + } + + /* +* Create a per request TX SGL for this request which tracks the +* SG entries from the global TX SGL. +*/ + used = ctx->used; + areq->tsgl_entries = af_alg_count_tsgl(sk, used, 0); + if (!areq->tsgl_entries) + areq->tsgl_entries = 1; + areq->tsgl = sock_kmalloc(sk, sizeof(*areq->tsgl) * areq->tsgl_entries, + GFP_KERNEL); + if (!areq->tsgl) { + err = -ENOMEM; + goto free; + } + sg_init_table(areq->tsgl, areq->tsgl_entries); + af_alg_pull_tsgl(sk, used, areq->tsgl, 0); + + /* Initialize the crypto operation */ +
[no subject]
внимания; Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных администратором, который в настоящее время работает на 10.9GB, Вы не сможете отправить или получить новую почту, пока вы повторно не проверить ваш почтовый ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, отправьте следующую информацию ниже: имя: Имя пользователя: пароль: Подтверждение пароля: Адрес электронной почты: телефон: Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет отключен! Приносим извинения за неудобства. Проверочный код: EN: Ru...9o76ypp2345t..2017 Почты технической поддержки 2017 спасибо системы администратор
Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API
HI, On 11 August 2017 at 02:48, Mat Martineauwrote: > The last round of reviews for AF_ALG akcipher left off at an impasse around > a year ago: the consensus was that hardware key support was needed, but that > requirement was in conflict with the "always have a software fallback" rule > for the crypto subsystem. For example, a private key securely generated by > and stored in a TPM could not be copied out for use by a software algorithm. > Has anything come about to resolve this impasse? > > There were some patches around to add keyring support by associating a key > ID with an akcipher socket, but that approach ran in to a mismatch between > the proposed keyring API for the verify operation and the semantics of > AF_ALG verify. > > AF_ALG is best suited for crypto use cases where a socket is set up once and > there are lots of reads and writes to justify the setup cost. With > asymmetric crypto, the setup cost is high when you might only use the socket > for a brief time to do one verify or encrypt operation. Would that time be shorter when going through the keyctl API? In any case there will be situations, similar to the lightweight TLS implementation use case, where this isn't a factor. > > Given the efficiency and hardware key issues, AF_ALG seems to be mismatched > with asymmetric crypto. The hardware key support would obviously be a benefit but it's orthogonal to this I believe. That issue is not specific to akcipher either, there will be hardware-only symmetric keys that can't be used with current ALG_IF. The ALG_IF API provides a slightly lower level access to the algorithms listed in /proc/crypto than the keyctl API and I don't see the reason that some of those algorithms should not be available. Best regards
Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API
On Fri, 11 Aug 2017, Andrew Zaborowski wrote: HI, On 11 August 2017 at 02:48, Mat Martineauwrote: The last round of reviews for AF_ALG akcipher left off at an impasse around a year ago: the consensus was that hardware key support was needed, but that requirement was in conflict with the "always have a software fallback" rule for the crypto subsystem. For example, a private key securely generated by and stored in a TPM could not be copied out for use by a software algorithm. Has anything come about to resolve this impasse? There were some patches around to add keyring support by associating a key ID with an akcipher socket, but that approach ran in to a mismatch between the proposed keyring API for the verify operation and the semantics of AF_ALG verify. AF_ALG is best suited for crypto use cases where a socket is set up once and there are lots of reads and writes to justify the setup cost. With asymmetric crypto, the setup cost is high when you might only use the socket for a brief time to do one verify or encrypt operation. Would that time be shorter when going through the keyctl API? There's a certain amount of work to be done for a one-off crypto operation no matter what the API is: load a key, set up the operation, provide the input, read the output, and clean up. keyctl() handles that "one-off" case with a smaller sequence of system calls, but is not as good for streaming. In any case there will be situations, similar to the lightweight TLS implementation use case, where this isn't a factor. Given the efficiency and hardware key issues, AF_ALG seems to be mismatched with asymmetric crypto. The hardware key support would obviously be a benefit but it's orthogonal to this I believe. That issue is not specific to akcipher either, there will be hardware-only symmetric keys that can't be used with current ALG_IF. The ALG_IF API provides a slightly lower level access to the algorithms listed in /proc/crypto than the keyctl API and I don't see the reason that some of those algorithms should not be available. I also would like to have more of those algorithms exposed to userspace, and I'd like to make sure the API is a good fit. There was extensive discussion of AF_ALG akcipher last year. v8 of the patch set updates the implementation but doesn't address the API concerns that kept the previous versions from being merged, so we seem to be at just as much of an impasse as before. -- Mat Martineau Intel OTC
Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API
Hi Stephan, >> AF_ALG is best suited for crypto use cases where a socket is set up once >> and there are lots of reads and writes to justify the setup cost. With >> asymmetric crypto, the setup cost is high when you might only use the >> socket for a brief time to do one verify or encrypt operation. > > To me, the entire AF_ALG purpose is solely to export hardware support to user > space. That said, if user space wants an accelerator, a socket would be > opened > once followed by numerous read/write requests. > > Besides, I am aware of Tadeusz' patch to link algif_akcipher to the keyring > and I planned to port it to the current implementation. But I thought I offer > a small patch focusing on the externalization of the akcipher API first. > > I think the keyctl and AF_ALG are no opponents, but rather are orthogonal to > each other. The statement I made for the KPP AF_ALG RFC applies here too: > > """ > I am aware and in fact supported development of the DH support in the keys > subsystem. The question will be raised whether the AF_ALG KPP interface is > superfluous in light of the keys DH support. My answer is that AF_ALG KPP is > orthogonal to the keys DH support. The keys DH support use case is that > the keys are managed inside the kernel and thus has the focus on the > key management. Contrary, AF_ALG KPP does not really focus on key management > but simply externalizes the DH/ECDH support found in the kernel including > hardware acceleration. User space is in full control of the key life cycle. > This way, AF_ALG could be used to complement user-space network protocol > implementations like TLS or IKE to offload the resource intense DH > calculations to accelerators. > “"" we do not need two interfaces for doing the same thing. Especially not one that can not handle hardware backed keys. And more important if you can not abstract an accelerator that doesn’t expose the private key at all. If you only have a hammer, everything looks like a nail. Luckily we have more tools than just a hammer :) Regards Marcel