Re: getrandom waits for a long time when /dev/random is insufficiently read from
On Fri, Jul 29, 2016 at 7:40 AM, Stephan Mueller wrote:
> And finally, you have a coding error that is very very common but fatal when
> reading from /dev/random: you do not account for short reads which implies
> that your loop continues even in the case of short reads.
>
> Fix your code with something like the following:
> int read_random(char *buf, size_t buflen)
> {
> int fd = 0;
> ssize_t ret = 0;
> size_t len = 0;
>
> fd = open("/dev/random", O_RDONLY|O_CLOEXEC);
> if(0 > fd)
> return fd;
> do {
> ret = read(fd, (buf + len), (buflen - len));
> if (0 < ret)
> len += ret;
> } while ((0 < ret || EINTR == errno || ERESTART == errno)
> && buflen > len);
Unless there is a documentation error, the same is required when using
getrandom(). It can also return short as well as to be interrupted.
regards,
Nikos
--
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 v5 0/7] /dev/random - a new approach
On Mon, Jun 20, 2016 at 5:43 PM, Stephan Mueller wrote: >> Personally, I don't really use /dev/random, nor would I recommend it >> for most application programmers. At this point, getrandom(2) really >> is the preferred interface unless you have some very specialized >> needs. > I fully agree. But there are use cases for /dev/random, notably as a seed > source for other DRNG. Is that really the case? I believe all DRNG's use /dev/urandom anyway for seeding since they cannot afford indeterminate blocking. It would be a gain for everyone if /dev/random was the same as /dev/urandom in Linux. regards, Nikos -- 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: [RFC][PATCH 0/6] /dev/random - a new approach
On Tue, May 3, 2016 at 4:48 PM, wrote: > On Tue, May 03, 2016 at 03:57:15PM +0200, Nikos Mavrogiannopoulos wrote: >> I believe their main concern is that they want to protect applications >> which do not check error codes of system calls, when running on a >> kernel which does not provide getrandom(). That way, they have an >> almost impossible task to simulate getrandom() on kernel which do not >> support it. > > The whole *point* of creating the getrandom(2) system call is that it > can't be simulated/emulated in userspace. If it can be, then there's > no reason why the system call should exist. This is one of the > reasons why haven't implemented mysql or TLS inside the kernel. :-) > So if their standard is "we need to simulate getrandom(2) on a kernel > which does not have it", we'll **never** see glibc support for it. By > definition, this is *impossible*. I know, and I share this opinion. To their defense they will have to provide a call which doesn't make applications fail in the following scenario: 1. crypto/ssl libraries are compiled to use getrandom() because it is available in libc and and in kernel 2. everything works fine 3. the administrator downgrades the kernel to a version without getrandom() because his network card works better with that version 4. Mayhem as applications fail However I don't see a way to avoid issues - though limited to corner cases - with any imperfect emulation. It would be much clear for glibc to just require a kernel with getrandom(). regards, Nikos -- 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: [RFC][PATCH 0/6] /dev/random - a new approach
On Tue, Apr 26, 2016 at 3:11 AM, Theodore Ts'o wrote: > On Mon, Apr 25, 2016 at 10:23:51AM +0200, Nikos Mavrogiannopoulos wrote: >> That's far from a solution and I wouldn't recommend to anyone doing >> that. We cannot expect each and every program to do glibc's job. The >> purpose of a system call like getrandom is to simplify the complex use >> of /dev/urandom and eliminate it, not to make code handling randomness >> in applications even worse. > Yes, but if glibc is falling down on the job and refusing to export > the system call (I think for political reasons; it's a Linux-only > interface, so Hurd wouldn't have it), I believe their main concern is that they want to protect applications which do not check error codes of system calls, when running on a kernel which does not provide getrandom(). That way, they have an almost impossible task to simulate getrandom() on kernel which do not support it. One may agree with their concerns, but the end result is that we have not available that system call at all, several years after it is there. Anyway it seems that there is some activity now, so hopefully we may have it sometime soon: https://sourceware.org/ml/libc-help/2016-04/msg8.html regards, Nikos -- 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: [RFC][PATCH 0/6] /dev/random - a new approach
On Mon, Apr 25, 2016 at 10:02 AM, Stephan Mueller wrote: >> > One more item to consider: If you do not want to change to use >> > getrandom(2), the LRNG provides you with another means. >> The main problem is not about willing to switch to getrandom() or not, >> but finding any system where getrandom() exists. Today due to libc not >> having the call, we can only use /dev/urandom and applications would >> most likely continue to do so long time after getrandom() is >> introduced to libc. > Implement the syscall yourself with syscall(). If you get ENOSYS back, revert > to your old logic of seeding from /dev/urandom. That's far from a solution and I wouldn't recommend to anyone doing that. We cannot expect each and every program to do glibc's job. The purpose of a system call like getrandom is to simplify the complex use of /dev/urandom and eliminate it, not to make code handling randomness in applications even worse. regards, Nikos -- 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: [RFC][PATCH 0/6] /dev/random - a new approach
On Thu, Apr 21, 2016 at 5:16 PM, Stephan Mueller wrote: >> > ... DRBG is “minimally” seeded with 112^6 bits of entropy. >> > This is commonly achieved even before user space is initiated. >> >> Unfortunately one of the issues of the /dev/urandom interface is the >> fact that it may start providing random numbers even before the >> seeding is complete. From the above quote, I understand that this >> issue is not addressed by the new interface. That's a serious >> limitation (of the current and inherited by the new implementation), >> since most/all newly deployed systems from "cloud" images generate >> keys using /dev/urandom (for sshd for example) on boot, and it is >> unknown to these applications whether they operate with uninitialized >> seed. > One more item to consider: If you do not want to change to use getrandom(2), > the LRNG provides you with another means. The main problem is not about willing to switch to getrandom() or not, but finding any system where getrandom() exists. Today due to libc not having the call, we can only use /dev/urandom and applications would most likely continue to do so long time after getrandom() is introduced to libc. regards, Nikos -- 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: [RFC][PATCH 0/6] /dev/random - a new approach
On Thu, Apr 21, 2016 at 11:11 AM, Stephan Mueller wrote: > Hi Herbert, Ted, > > The venerable Linux /dev/random served users of cryptographic mechanisms well > for a long time. Its behavior is well understood to deliver entropic data. In > the last years, however, the Linux /dev/random showed signs of age where it > has > challenges to cope with modern computing environments ranging from tiny > embedded > systems, over new hardware resources such as SSDs, up to massive parallel > systems as well as virtualized environments. > > With the experience gained during numerous studies of /dev/random, entropy > assessments of different noise source designs and assessing entropy behavior > in > virtual machines and other special environments, I felt to do something about > it. > I developed a different approach, which I call Linux Random Number Generator > (LRNG) to collect entropy within the Linux kernel. The main improvements > compared to the legacy /dev/random is to provide sufficient entropy during > boot > time as well as in virtual environments and when using SSDs. A secondary > design > goal is to limit the impact of the entropy collection on massive parallel > systems and also allow the use accelerated cryptographic primitives. Also, all > steps of the entropic data processing are testable. Finally massive > performance > improvements are visible at /dev/urandom / get_random_bytes. [quote from pdf] > ... DRBG is “minimally” seeded with 112^6 bits of entropy. > This is commonly achieved even before user space is initiated. Unfortunately one of the issues of the /dev/urandom interface is the fact that it may start providing random numbers even before the seeding is complete. From the above quote, I understand that this issue is not addressed by the new interface. That's a serious limitation (of the current and inherited by the new implementation), since most/all newly deployed systems from "cloud" images generate keys using /dev/urandom (for sshd for example) on boot, and it is unknown to these applications whether they operate with uninitialized seed. While one could argue for using /dev/random, the unpredictability of the delay it incurs is prohibitive for any practical use. Thus I'd expect any new interface to provide a better /dev/urandom, by ensuring that the kernel seed buffer is fully seeded prior to switching to userspace. About the rest of the design, I think it is quite clean. I think the DRBG choice is quite natural given the NIST recommendations, but have you considered using a stream cipher instead like chacha20 which in most of cases it would outperform the DRBG based on AES? regards, Nikos -- 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 0/3] crypto: af_alg - add TLS type encryption
On Thu, Apr 14, 2016 at 12:46 AM, Tadeusz Struk wrote: > Hi Fridolin, > On 04/12/2016 04:13 AM, Fridolin Pokorny wrote: >> we were experimenting with this. We have a prove of concept of a kernel >> TLS type socket, so called AF_KTLS, which is based on Dave Watson's >> RFC5288 patch. It handles both TLS and DTLS, unfortunately it is not >> ready now to be proposed here. There are still issues which should be >> solved (but mostly user space API design) [1]. If you are interested, we >> could combine efforts. >> >> Regards, >> Fridolin Pokorny >> >> [1] https://github.com/fridex/af_ktls > I had a quick look and it looks like is limited only to gcm(aes). > I would be more interested to have a generic interface that could do generic > algorithm > suits like aes-cbc-hmac-sha1 also. This is not a real limitation but an advantage. The cbc-hmac-sha1 needs a lot of hacks to be implemented correct (just take a look at one of the existing implementations). There is no point to bring such hacks into kernel especially since these ciphersuites are banned from HTTP/2.0 (see RFC7540), and have been dropped from TLS 1.3. > This also seems to work in a synchronous (send one and wait) mode, which is a > not good > solution for HW accelerators, which I'm trying to enable. Is that something that cannot be addressed? regards, Nikos -- 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: communicating from the user space
On Mon, Feb 23, 2015 at 9:18 AM, Stephan Mueller wrote: >> one more thing while compiling openssl with above mentioned changes I >> faced compilation issues in linux ,Please can you also let me know >> whether there are per-requisites like any dependent libraries or >> installing cryptodev-linux on host/target machine before compiling >> openssl etc? > Per default, you lack the kernel side support (there is no /dev/crypto) unless > you patch your kernel. Thus, that cryptodev support in OpenSSL is not used on > default kernels. It depends. If you are working in an embedded system /dev/crypto is most probably there. AF_ALG could be supported too, but there is little reason to use it, unless working slow is your goal. regards, Nikos -- 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: communicating from the user space
On Mon, Feb 23, 2015 at 5:06 AM, sri sowj wrote: > Hi Nikos, > > Please can you let me know my understanding regarding openssl and > crypto are correct? > I have mentioned my understanding in my earlier posts,but let me > mention it here again. > I want to interact with Crypto Hardware from user space using openssl > like libraries based applications through cryptodev-linux interface. > it looks like openssl comes with cryptodev-linux support(through > eng_cryptodev.c) . > When I downloaded openssl,eng_cryptodev.c file is available by default. > below link refers about eng_cryptodev.c for openssl support : > http://repo.or.cz/w/cryptodev-linux.git/commitdiff/56cc4e3b8b761cb34f928f4eee59755d1f0afc53 That's a very old link. Note that openssl's cryptodev support works well for ciphers, but not for digests (hashes). So the best is to compile without digest support, or use the patches in https://github.com/openssl/openssl/pull/191 The most current instructions are: https://github.com/cryptodev-linux/cryptodev-linux/blob/master/INSTALL and in https://github.com/cryptodev-linux/cryptodev-linux regards, Nikos -- 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: communicating from the user space
On Sun, 2015-02-22 at 16:04 +0100, Stephan Mueller wrote: > Am Sonntag, 22. Februar 2015, 18:32:34 schrieb sri sowj: > > Hi sri, > > > Hi Stephen, > > > > It was a great information with respective PF_ALG , I have explored a > > bit on openssl and algorithms prospect , Please let me know if > > anything to add to it. > > > > openssl crypto engine: > > > > below are the steps to enable openssl to communicate using pf/af_alg. > > > > #1:git clone http://src.carnivore.it/users/common/af_alg/ > Yes, that is it. But it is not fully efficient as it does not use vmsplice > where appropriate. So, libkcapi should be faster in several use cases. When would vmsplice be appropriate? As far as I understand vmsplice adds a cost on operations for small data, which is the majority of use cases in crypto. In the measurements I did for cryptodev-linux [0] vmsplice did improve performance only for more than 64k packets which is never the case with real world crypto (TLS has a maximum of 14k for example). regards, Nikos [0]. http://cryptodev-linux.org/comparison.html -- 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: RFC possible changes for Linux random device
On Mon, 2014-09-15 at 20:40 -0400, Sandy Harris wrote: > I have some experimental code to replace parts of random.c It is not > finished but far enough along to seek comment. It does compile with > either gcc or clang, run and produce reasonable-looking results but is > not well-tested. splint(1) complains about parts of it, but do not > think it is indicating any real problems. > > I change nothing on the input side; the entropy collection and > estimation parts of existing code are untouched. The hashing and > output routines, though, are completely replaced, and much of the > initialisation code is modified. > It uses the 128-bit hash from AES-GCM instead of 160-bit SHA-1. > Changing the hash allows other changes. One design goal was improved > decoupling so that heavy use of /dev/urandom does not deplete the > entropy pool for /dev/random. Another was simpler mixing in of > additional data in various places. Hello, What are the advantages of this change? It was not clear from the original thread. regards, Nikos -- 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: Asymmetric cryptography HW offloading
On 09/27/2013 12:58 PM, Horia Geantă wrote: > Thanks for the tip. > I took a look at BSD - AFAICT there is no SW implementation and crypto > engine drivers handle only the first two operations (MOD_EXP). > > My main concern now is the asymmetric ciphers API, that would eventually > allow implementing the operations in SW/HW. > I was wondering whether the same logic as for symmetric ciphers > could/should be used (the API layering mentioned in > Documentation/crypto/api-intro.txt). > For example, crypto/asymmetric_keys/rsa.c could be registered and then > used via Crypto API: > rsa.c: crypto_alg->cra_name = "rsa"; As RSA fits into the encryption API it may be just ok. I'd say do it and then we see whether that API causes some bottleneck for asymmetric encryption. But how would you fit modexp in that case? Having the expensive big number operations could be useful to non-crypto number crunching projects as well (e.g. gmp and its users). regards, Nikos -- 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: Asymmetric cryptography HW offloading
On 09/23/2013 02:31 PM, Horia Geantă wrote: > Hi, > > CAAM crypto engine (drivers/crypto/caam/*) is capable of asymmetric > operations, like: modular exponentiation, RSA > sign/verify/encrypt/decrypt, (EC)DSA sign etc. > I would appreciate some design guidelines on how to harness these > capabilities, for crypto engines in general. > > 1. In-kernel interface for asymmetric crypto > Should crypto/asymmetric_keys/* be used, i.e. appended with modular > exponentiation, other asymmetric operations? The BSD's cryptodev supports the following operations which may help in that aspect (no elliptic curve operations present). I don't know if all of them worth the context switch. #define CRK_MOD_EXP 0 #define CRK_MOD_EXP_CRT 1 #define CRK_DSA_SIGN2 #define CRK_DSA_VERIFY 3 #define CRK_DH_COMPUTE_KEY 4 #define CRK_MOD_ADD 5 #define CRK_MOD_ADDINV 6 #define CRK_MOD_SUB 7 #define CRK_MOD_MULT8 #define CRK_MOD_MULTINV 9 #define CRK_MOD 10 > 2. User space interface > Should AF_ALG be expanded to provide access to this new asymmetric cypto > API? The API would allow user space applications to offload PKC operations in > HW. I'd be interested into adding this support into cryptodev-linux once present in kernel. regards, Nikos -- 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: mv_cesa hash functions
On 02/22/2012 02:03 PM, Frank wrote: > Hi, > > After doing some trials with hardware crypto offloading through usermode > interfaces (af_alg and cryptodev) to Marvell CESA accelerated ciphers and > hash functions with the 3.2.4 kernel's mv_cesa in Debian Wheezy on a Marvell > Kirkwood system, I've noticed the following kernel output when I load the > mv_cesa kernel module: > > [490889.448060] alg: hash: Test 1 failed for mv-sha1 > [490889.452786] : c1 94 3f 2e a2 41 ce 88 d5 47 07 43 c4 a8 17 5d > [490889.459368] 0010: 77 e8 47 ca > [490889.464321] alg: hash: Test 1 failed for mv-hmac-sha1 > [490889.469493] : 06 71 4d 7c cc cc b5 cf 1b d6 c7 ab d0 25 c4 21 > [490889.476068] 0010: 66 0b 8e 70 > Using SHA1 in a ssl/tls handshake fails in tests with mv_cesa loaded, which > might be related to this. It might be related. I noticed the same issue in userspace with /dev/crypto. It can be solved by adding a 50 ms delay after the encryption, decryption and hashing operations. (a delay less than that didn't work). regards, Nikos -- 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 1/1] Added CRYPTO_ALG_KERN_DRIVER_ONLY flag (4rd attempt)
This patch is the same as the previous but without the inline function.
regards,
Nikos
>From 1562727aab0e2fcce87e22a73abe6ea1c7c8975f Mon Sep 17 00:00:00 2001
From: Nikos Mavrogiannopoulos
Date: Tue, 1 Nov 2011 13:39:56 +0100
Subject: [PATCH] Added CRYPTO_ALG_KERN_DRIVER_ONLY flag.
The added CRYPTO_ALG_KERN_DRIVER_ONLY indicates whether a cipher
is only available via a kernel driver. If the cipher implementation
might be available by using an instruction set or by porting the
kernel code, then it must not be set.
Signed-off-by: Nikos Mavrogiannopoulos
---
drivers/crypto/caam/caamalg.c |3 +-
drivers/crypto/geode-aes.c|6 +++-
drivers/crypto/hifn_795x.c|3 +-
drivers/crypto/ixp4xx_crypto.c|2 +
drivers/crypto/mv_cesa.c | 12 ++---
drivers/crypto/n2_core.c |7 -
drivers/crypto/omap-aes.c |8 +-
drivers/crypto/omap-sham.c|4 +++
drivers/crypto/picoxcell_crypto.c | 46 -
drivers/crypto/s5p-sss.c |6 +++-
drivers/crypto/talitos.c |1 +
include/linux/crypto.h|5
12 files changed, 78 insertions(+), 25 deletions(-)
diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
index e73cf2e..e9acadb 100644
--- a/drivers/crypto/caam/caamalg.c
+++ b/drivers/crypto/caam/caamalg.c
@@ -2205,7 +2205,8 @@ static struct caam_crypto_alg *caam_alg_alloc(struct device *ctrldev,
alg->cra_blocksize = template->blocksize;
alg->cra_alignmask = 0;
alg->cra_ctxsize = sizeof(struct caam_ctx);
- alg->cra_flags = CRYPTO_ALG_ASYNC | template->type;
+ alg->cra_flags = CRYPTO_ALG_ASYNC | CRYPTO_ALG_KERN_DRIVER_ONLY |
+ template->type;
switch (template->type) {
case CRYPTO_ALG_TYPE_ABLKCIPHER:
alg->cra_type = &crypto_ablkcipher_type;
diff --git a/drivers/crypto/geode-aes.c b/drivers/crypto/geode-aes.c
index 219d09c..f3e36c8 100644
--- a/drivers/crypto/geode-aes.c
+++ b/drivers/crypto/geode-aes.c
@@ -393,7 +393,8 @@ static struct crypto_alg geode_cbc_alg = {
.cra_driver_name = "cbc-aes-geode",
.cra_priority = 400,
.cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
- CRYPTO_ALG_NEED_FALLBACK,
+ CRYPTO_ALG_KERN_DRIVER_ONLY |
+ CRYPTO_ALG_NEED_FALLBACK,
.cra_init = fallback_init_blk,
.cra_exit = fallback_exit_blk,
.cra_blocksize = AES_MIN_BLOCK_SIZE,
@@ -479,7 +480,8 @@ static struct crypto_alg geode_ecb_alg = {
.cra_driver_name = "ecb-aes-geode",
.cra_priority = 400,
.cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
- CRYPTO_ALG_NEED_FALLBACK,
+ CRYPTO_ALG_KERN_DRIVER_ONLY |
+ CRYPTO_ALG_NEED_FALLBACK,
.cra_init = fallback_init_blk,
.cra_exit = fallback_exit_blk,
.cra_blocksize = AES_MIN_BLOCK_SIZE,
diff --git a/drivers/crypto/hifn_795x.c b/drivers/crypto/hifn_795x.c
index fe765f4..6bd9d17 100644
--- a/drivers/crypto/hifn_795x.c
+++ b/drivers/crypto/hifn_795x.c
@@ -2494,7 +2494,8 @@ static int hifn_alg_alloc(struct hifn_device *dev, struct hifn_alg_template *t)
t->drv_name, dev->name);
alg->alg.cra_priority = 300;
- alg->alg.cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC;
+ alg->alg.cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
+CRYPTO_ALG_KERN_DRIVER_ONLY | CRYPTO_ALG_ASYNC;
alg->alg.cra_blocksize = t->bsize;
alg->alg.cra_ctxsize = sizeof(struct hifn_context);
alg->alg.cra_alignmask = 0;
diff --git a/drivers/crypto/ixp4xx_crypto.c b/drivers/crypto/ixp4xx_crypto.c
index 4c20c5b..a82c11a 100644
--- a/drivers/crypto/ixp4xx_crypto.c
+++ b/drivers/crypto/ixp4xx_crypto.c
@@ -1449,6 +1449,7 @@ static int __init ixp_module_init(void)
/* block ciphers */
cra->cra_type = &crypto_ablkcipher_type;
cra->cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
+ CRYPTO_ALG_KERN_DRIVER_ONLY |
CRYPTO_ALG_ASYNC;
if (!cra->cra_ablkcipher.setkey)
cra->cra_ablkcipher.setkey = ablk_setkey;
@@ -1461,6 +1462,7 @@ static int __init ixp_module_init(void)
/* authenc */
cra->cra_type = &crypto_aead_type;
cra->cra_flags = CRYPTO_ALG_TYPE_AEAD |
+ CRYPTO_ALG_KERN_DRIVER_ONLY |
CRYPTO_ALG_ASYNC;
cra->cra_aead.setkey = aead_setkey;
cra->cra_aead.setauthsize = aead_setauthsize;
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index 015c0fc..9d41ec6 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
@@ -896,7 +896,8 @@ struct crypto_alg mv_aes_alg_ecb = {
.cra_name = "ecb(aes)",
.cra_driver_name = "mv-ecb-aes",
.cra_priority = 300,
- .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC,
+ .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
+ CRYPTO_ALG_KERN_DRIVER_ONLY | CRYPTO_ALG_ASYNC,
.cra_blocksize = 16,
.cra_ctxsize = sizeof(struct mv_ctx),
.cra_alignmask = 0,
@@ -918,7 +919,8 @@ struct crypto_alg mv_aes_alg_cbc = {
.cra_name = "cb
Re: [PATCH 1/1] Added CRYPTO_ALG_KERN_DRIVER_ONLY flag (3rd attempt)
On Fri, Jan 6, 2012 at 10:12 AM, Herbert Xu wrote: >> How the flag is exported by cryptodev-linux: >> http://repo.or.cz/w/cryptodev-linux.git/blob/aead:/ioctl.c#l716 > Actually I was looking for code that uses crypto_tfm_alg_flags > function. The code above will use it once it is accepted. Now it accesses directly the flags. regards, Nikos -- 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 1/1] Added CRYPTO_ALG_KERN_DRIVER_ONLY flag (3rd attempt)
On Fri, Jan 6, 2012 at 9:28 AM, Herbert Xu wrote: >> I needed this function in order to access the new flag without >> relying on the structure format. The available crypto_tfm_alg_type() >> would apply a mask and remove it, thus I added this function. > Can you show me some example code so I can see how you intend > to use it in userspace? I intend to export the flag to use space as shown below. The idea is to allow userspace libraries decide whether to use the acceleration (i.e. if the CRYPTO_ALG_KERN_DRIVER_ONLY is not given they shouldn't attempt to use the kernel algorithm). How the flag is exported by cryptodev-linux: http://repo.or.cz/w/cryptodev-linux.git/blob/aead:/ioctl.c#l716 An example of using it in userspace: http://repo.or.cz/w/cryptodev-linux.git/blob/aead:/examples/aes.c#l43 regards, Nikos -- 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 1/1] Added CRYPTO_ALG_KERN_DRIVER_ONLY flag (3rd attempt)
On 01/06/2012 02:37 AM, Herbert Xu wrote:
> Nikos Mavrogiannopoulos wrote:
>> The added CRYPTO_ALG_KERN_DRIVER_ONLY indicates whether a cipher
>> is only available via a kernel driver. If the cipher implementation
>> might be available by using an instruction set or by porting the
>> kernel code, then it must not be set.
[...]
>> +static inline u32 crypto_tfm_alg_flags(struct crypto_tfm *tfm)
>> +{
>> + return tfm->__crt_alg->cra_flags;
>> +}
>> +
> Who is going to use this? For one it's not type-safe as we try
> to avoid directly using crypto_tfm in kernel code.
I needed this function in order to access the new flag without
relying on the structure format. The available crypto_tfm_alg_type()
would apply a mask and remove it, thus I added this function.
regards,
Nikos
--
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 1/1] Added CRYPTO_ALG_KERN_DRIVER_ONLY flag (3rd attempt)
The added CRYPTO_ALG_KERN_DRIVER_ONLY indicates whether a cipher
is only available via a kernel driver. If the cipher implementation
might be available by using an instruction set or by porting the
kernel code, then it must not be set.
In addition it provides crypto_tfm_alg_flags() to obtain
this and other possible flags.
Signed-off-by: Nikos Mavrogiannopoulos
---
drivers/crypto/caam/caamalg.c |3 +-
drivers/crypto/geode-aes.c|6 +++-
drivers/crypto/hifn_795x.c|3 +-
drivers/crypto/ixp4xx_crypto.c|2 +
drivers/crypto/mv_cesa.c | 12 ++---
drivers/crypto/n2_core.c |7 -
drivers/crypto/omap-aes.c |8 +-
drivers/crypto/omap-sham.c|4 +++
drivers/crypto/picoxcell_crypto.c | 46 -
drivers/crypto/s5p-sss.c |6 +++-
drivers/crypto/talitos.c |1 +
include/linux/crypto.h| 10
12 files changed, 83 insertions(+), 25 deletions(-)
diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
index a5bc706..4117836 100644
--- a/drivers/crypto/caam/caamalg.c
+++ b/drivers/crypto/caam/caamalg.c
@@ -2205,7 +2205,8 @@ static struct caam_crypto_alg *caam_alg_alloc(struct
device *ctrldev,
alg->cra_blocksize = template->blocksize;
alg->cra_alignmask = 0;
alg->cra_ctxsize = sizeof(struct caam_ctx);
- alg->cra_flags = CRYPTO_ALG_ASYNC | template->type;
+ alg->cra_flags = CRYPTO_ALG_ASYNC | CRYPTO_ALG_KERN_DRIVER_ONLY |
+template->type;
switch (template->type) {
case CRYPTO_ALG_TYPE_ABLKCIPHER:
alg->cra_type = &crypto_ablkcipher_type;
diff --git a/drivers/crypto/geode-aes.c b/drivers/crypto/geode-aes.c
index 219d09c..f3e36c8 100644
--- a/drivers/crypto/geode-aes.c
+++ b/drivers/crypto/geode-aes.c
@@ -393,7 +393,8 @@ static struct crypto_alg geode_cbc_alg = {
.cra_driver_name= "cbc-aes-geode",
.cra_priority = 400,
.cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
-
CRYPTO_ALG_NEED_FALLBACK,
+ CRYPTO_ALG_KERN_DRIVER_ONLY |
+ CRYPTO_ALG_NEED_FALLBACK,
.cra_init = fallback_init_blk,
.cra_exit = fallback_exit_blk,
.cra_blocksize = AES_MIN_BLOCK_SIZE,
@@ -479,7 +480,8 @@ static struct crypto_alg geode_ecb_alg = {
.cra_driver_name= "ecb-aes-geode",
.cra_priority = 400,
.cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
-
CRYPTO_ALG_NEED_FALLBACK,
+ CRYPTO_ALG_KERN_DRIVER_ONLY |
+ CRYPTO_ALG_NEED_FALLBACK,
.cra_init = fallback_init_blk,
.cra_exit = fallback_exit_blk,
.cra_blocksize = AES_MIN_BLOCK_SIZE,
diff --git a/drivers/crypto/hifn_795x.c b/drivers/crypto/hifn_795x.c
index fe765f4..6bd9d17 100644
--- a/drivers/crypto/hifn_795x.c
+++ b/drivers/crypto/hifn_795x.c
@@ -2494,7 +2494,8 @@ static int hifn_alg_alloc(struct hifn_device *dev, struct
hifn_alg_template *t)
t->drv_name, dev->name);
alg->alg.cra_priority = 300;
- alg->alg.cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC;
+ alg->alg.cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
+ CRYPTO_ALG_KERN_DRIVER_ONLY | CRYPTO_ALG_ASYNC;
alg->alg.cra_blocksize = t->bsize;
alg->alg.cra_ctxsize = sizeof(struct hifn_context);
alg->alg.cra_alignmask = 0;
diff --git a/drivers/crypto/ixp4xx_crypto.c b/drivers/crypto/ixp4xx_crypto.c
index 4c20c5b..a82c11a 100644
--- a/drivers/crypto/ixp4xx_crypto.c
+++ b/drivers/crypto/ixp4xx_crypto.c
@@ -1449,6 +1449,7 @@ static int __init ixp_module_init(void)
/* block ciphers */
cra->cra_type = &crypto_ablkcipher_type;
cra->cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
+CRYPTO_ALG_KERN_DRIVER_ONLY |
CRYPTO_ALG_ASYNC;
if (!cra->cra_ablkcipher.setkey)
cra->cra_ablkcipher.setkey = ablk_setkey;
@@ -1461,6 +1462,7 @@ static int __init ixp_module_init(void)
/* authenc */
cra->cra_type = &crypto_aead_type;
cra->cra_flags = CRYPTO_ALG_TYPE_AEAD |
+
Re: [PATCH 1/1] Added CRYPTO_ALG_KERN_DRIVER_ONLY flag.
On 12/12/2011 09:43 PM, Kim Phillips wrote: > This appears to be based on an older version of the current master > of Herbert's cryptodev tree on github [1] - it's missing the hmac > algorithms introduced in commit 79b3a41 "crypto: talitos - add hmac > algorithms", and a caam entry is missing (it's an offload engine, > just like talitos). Something like: Thanks, I've resubmitted with your patch included. regards, Nikos -- 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 1/1] Added CRYPTO_ALG_KERN_DRIVER_ONLY flag (2nd attempt)
The added CRYPTO_ALG_KERN_DRIVER_ONLY indicates whether a cipher
is only available via a kernel driver. If the cipher implementation
might be available by using an instruction set or by porting the
kernel code, then it must not be set.
In addition it provides crypto_tfm_alg_flags() to obtain
this and other possible flags.
Signed-off-by: Nikos Mavrogiannopoulos
---
drivers/crypto/caam/caamalg.c |3 +-
drivers/crypto/geode-aes.c|6 +++-
drivers/crypto/hifn_795x.c|3 +-
drivers/crypto/ixp4xx_crypto.c|2 +
drivers/crypto/mv_cesa.c | 12 ++---
drivers/crypto/n2_core.c |7 -
drivers/crypto/omap-aes.c |8 -
drivers/crypto/omap-sham.c|4 +++
drivers/crypto/picoxcell_crypto.c | 46 ++
drivers/crypto/s5p-sss.c |6 +++-
drivers/crypto/talitos.c | 49 ++--
include/linux/crypto.h| 10 +++
12 files changed, 117 insertions(+), 39 deletions(-)
diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
index a5bc706..4117836 100644
--- a/drivers/crypto/caam/caamalg.c
+++ b/drivers/crypto/caam/caamalg.c
@@ -2205,7 +2205,8 @@ static struct caam_crypto_alg *caam_alg_alloc(struct
device *ctrldev,
alg->cra_blocksize = template->blocksize;
alg->cra_alignmask = 0;
alg->cra_ctxsize = sizeof(struct caam_ctx);
- alg->cra_flags = CRYPTO_ALG_ASYNC | template->type;
+ alg->cra_flags = CRYPTO_ALG_ASYNC | CRYPTO_ALG_KERN_DRIVER_ONLY |
+template->type;
switch (template->type) {
case CRYPTO_ALG_TYPE_ABLKCIPHER:
alg->cra_type = &crypto_ablkcipher_type;
diff --git a/drivers/crypto/geode-aes.c b/drivers/crypto/geode-aes.c
index 219d09c..f3e36c8 100644
--- a/drivers/crypto/geode-aes.c
+++ b/drivers/crypto/geode-aes.c
@@ -393,7 +393,8 @@ static struct crypto_alg geode_cbc_alg = {
.cra_driver_name= "cbc-aes-geode",
.cra_priority = 400,
.cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
-
CRYPTO_ALG_NEED_FALLBACK,
+ CRYPTO_ALG_KERN_DRIVER_ONLY |
+ CRYPTO_ALG_NEED_FALLBACK,
.cra_init = fallback_init_blk,
.cra_exit = fallback_exit_blk,
.cra_blocksize = AES_MIN_BLOCK_SIZE,
@@ -479,7 +480,8 @@ static struct crypto_alg geode_ecb_alg = {
.cra_driver_name= "ecb-aes-geode",
.cra_priority = 400,
.cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
-
CRYPTO_ALG_NEED_FALLBACK,
+ CRYPTO_ALG_KERN_DRIVER_ONLY |
+ CRYPTO_ALG_NEED_FALLBACK,
.cra_init = fallback_init_blk,
.cra_exit = fallback_exit_blk,
.cra_blocksize = AES_MIN_BLOCK_SIZE,
diff --git a/drivers/crypto/hifn_795x.c b/drivers/crypto/hifn_795x.c
index fe765f4..6bd9d17 100644
--- a/drivers/crypto/hifn_795x.c
+++ b/drivers/crypto/hifn_795x.c
@@ -2494,7 +2494,8 @@ static int hifn_alg_alloc(struct hifn_device *dev, struct
hifn_alg_template *t)
t->drv_name, dev->name);
alg->alg.cra_priority = 300;
- alg->alg.cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC;
+ alg->alg.cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
+ CRYPTO_ALG_KERN_DRIVER_ONLY | CRYPTO_ALG_ASYNC;
alg->alg.cra_blocksize = t->bsize;
alg->alg.cra_ctxsize = sizeof(struct hifn_context);
alg->alg.cra_alignmask = 0;
diff --git a/drivers/crypto/ixp4xx_crypto.c b/drivers/crypto/ixp4xx_crypto.c
index 4c20c5b..a82c11a 100644
--- a/drivers/crypto/ixp4xx_crypto.c
+++ b/drivers/crypto/ixp4xx_crypto.c
@@ -1449,6 +1449,7 @@ static int __init ixp_module_init(void)
/* block ciphers */
cra->cra_type = &crypto_ablkcipher_type;
cra->cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
+CRYPTO_ALG_KERN_DRIVER_ONLY |
CRYPTO_ALG_ASYNC;
if (!cra->cra_ablkcipher.setkey)
cra->cra_ablkcipher.setkey = ablk_setkey;
@@ -1461,6 +1462,7 @@ static int __init ixp_module_init(void)
/* authenc */
cra->cra_type = &crypto_aead_type;
cra-
[PATCH 1/1] Added CRYPTO_ALG_KERN_DRIVER_ONLY flag.
The added CRYPTO_ALG_KERN_DRIVER_ONLY flag indicates whether a cipher
is only available via a kernel driver. If the cipher implementation
might be available by using an instruction set or by porting the
kernel code, then it must not be set.
Signed-off-by: Nikos Mavrogiannopoulos
---
drivers/crypto/geode-aes.c|8 --
drivers/crypto/hifn_795x.c|3 +-
drivers/crypto/ixp4xx_crypto.c|2 +
drivers/crypto/mv_cesa.c | 12 ++---
drivers/crypto/n2_core.c |7 -
drivers/crypto/omap-aes.c |8 -
drivers/crypto/omap-sham.c|4 +++
drivers/crypto/picoxcell_crypto.c | 46 +++
drivers/crypto/s5p-sss.c |6 +++-
drivers/crypto/talitos.c | 48 ++--
include/linux/crypto.h|5
11 files changed, 110 insertions(+), 39 deletions(-)
diff --git a/drivers/crypto/geode-aes.c b/drivers/crypto/geode-aes.c
index 219d09c..8b0ef70 100644
--- a/drivers/crypto/geode-aes.c
+++ b/drivers/crypto/geode-aes.c
@@ -392,8 +392,9 @@ static struct crypto_alg geode_cbc_alg = {
.cra_name = "cbc(aes)",
.cra_driver_name= "cbc-aes-geode",
.cra_priority = 400,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
-
CRYPTO_ALG_NEED_FALLBACK,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_KERN_DRIVER_ONLY |
+ CRYPTO_ALG_NEED_FALLBACK,
.cra_init = fallback_init_blk,
.cra_exit = fallback_exit_blk,
.cra_blocksize = AES_MIN_BLOCK_SIZE,
@@ -479,7 +480,8 @@ static struct crypto_alg geode_ecb_alg = {
.cra_driver_name= "ecb-aes-geode",
.cra_priority = 400,
.cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
-
CRYPTO_ALG_NEED_FALLBACK,
+ CRYPTO_ALG_KERN_DRIVER_ONLY |
+ CRYPTO_ALG_NEED_FALLBACK,
.cra_init = fallback_init_blk,
.cra_exit = fallback_exit_blk,
.cra_blocksize = AES_MIN_BLOCK_SIZE,
diff --git a/drivers/crypto/hifn_795x.c b/drivers/crypto/hifn_795x.c
index fe765f4..14780c8 100644
--- a/drivers/crypto/hifn_795x.c
+++ b/drivers/crypto/hifn_795x.c
@@ -2494,7 +2494,8 @@ static int hifn_alg_alloc(struct hifn_device *dev, struct
hifn_alg_template *t)
t->drv_name, dev->name);
alg->alg.cra_priority = 300;
- alg->alg.cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC;
+ alg->alg.cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
+ CRYPTO_ALG_KERN_DRIVER_ONLY | CRYPTO_ALG_ASYNC;
alg->alg.cra_blocksize = t->bsize;
alg->alg.cra_ctxsize = sizeof(struct hifn_context);
alg->alg.cra_alignmask = 0;
diff --git a/drivers/crypto/ixp4xx_crypto.c b/drivers/crypto/ixp4xx_crypto.c
index 4c20c5b..a82c11a 100644
--- a/drivers/crypto/ixp4xx_crypto.c
+++ b/drivers/crypto/ixp4xx_crypto.c
@@ -1449,6 +1449,7 @@ static int __init ixp_module_init(void)
/* block ciphers */
cra->cra_type = &crypto_ablkcipher_type;
cra->cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
+CRYPTO_ALG_KERN_DRIVER_ONLY |
CRYPTO_ALG_ASYNC;
if (!cra->cra_ablkcipher.setkey)
cra->cra_ablkcipher.setkey = ablk_setkey;
@@ -1461,6 +1462,7 @@ static int __init ixp_module_init(void)
/* authenc */
cra->cra_type = &crypto_aead_type;
cra->cra_flags = CRYPTO_ALG_TYPE_AEAD |
+CRYPTO_ALG_KERN_DRIVER_ONLY |
CRYPTO_ALG_ASYNC;
cra->cra_aead.setkey = aead_setkey;
cra->cra_aead.setauthsize = aead_setauthsize;
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index 38a3297..04f47e5 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
@@ -897,7 +897,8 @@ struct crypto_alg mv_aes_alg_ecb = {
.cra_name = "ecb(aes)",
.cra_driver_name= "mv-ecb-aes",
.cra_priority = 300,
- .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC,
+ .cra_flags = CRYPTO_ALG_TYPE_ABLKCI
Re: Hardware acceleration indication in af_alg
On 11/01/2011 01:59 PM, Jamie Iles wrote: > Hi Nikos, > > On Tue, Nov 01, 2011 at 01:43:26PM +0100, Nikos Mavrogiannopoulos wrote: [...] >> I suppose that no answer means there is no way. In that case would you >> consider this or a similar patch to indicate whether a driver provides >> an algorithm not available to userspace via other means (e.g. >> instruction set)? This would allow users of the kernel interfaces to >> avoid using software implementations or implementations that are >> available to userspace anyway. > [...] >> diff --git a/include/linux/crypto.h b/include/linux/crypto.h >> index de9adec..3e14cee 100644 >> --- a/include/linux/crypto.h >> +++ b/include/linux/crypto.h >> @@ -51,6 +51,11 @@ >> #define CRYPTO_ALG_DYING0x0040 >> #define CRYPTO_ALG_ASYNC0x0080 >> >> +/* Set this bit if the algorithm provided is hardware accelerated but >> + * not available to userspace via instruction set or so. >> + */ >> +#define CRYPTO_ALG_KERN_ONLY0x0100 > Would it be a bit clearer if this was CRYPTO_ALG_IS_UNPRIVILIGED and was > set the other way round (so instruction set based ones that users can > use)? I had to do a double take with KERN_ONLY. Could also be, although I think both names are not so intuitive :) Note btw that the flag value in the patch is not correct (it overlaps with another one). regards, Nikos -- 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: Hardware acceleration indication in af_alg
On 10/28/2011 06:24 PM, Nikos Mavrogiannopoulos wrote:
>>> I can imagine, an alternative approach and perhaps better
>>> approach would be to measure the speed of the kernel provided
>>> algorithm against a software implementation, but there are many
>>> other factors that could influence the results. Therefore, it is
>>> perhaps better to just make the assumption that hardware
>>> acceleration is faster which is made in the kernel anyhow.
>> You have to be careful to distinguish between hardware
>> acceleration that is directly available to user-space (such as
>> AESNI) and those that aren't.
> How can this be done? The only driver field that could be used for
> that is cra_priority and it seems it typically set to 300
> irrespective of instruction based crypto or external device.
I suppose that no answer means there is no way. In that case would you
consider this or a similar patch to indicate whether a driver provides
an algorithm not available to userspace via other means (e.g.
instruction set)? This would allow users of the kernel interfaces to
avoid using software implementations or implementations that are
available to userspace anyway.
regards,
Nikos
>From ee66a849c15c6b83cb0fd85d61eedef707288aea Mon Sep 17 00:00:00 2001
From: Nikos Mavrogiannopoulos
Date: Tue, 1 Nov 2011 13:39:56 +0100
Subject: [PATCH] Added CRYPTO_ALG_KERN_ONLY flag to indicate whether a cipher
maybe available to userspace via instruction set or not.
---
drivers/crypto/geode-aes.c|4 +++-
drivers/crypto/hifn_795x.c|2 +-
drivers/crypto/ixp4xx_crypto.c|2 ++
drivers/crypto/mv_cesa.c |8
drivers/crypto/n2_core.c |4 ++--
drivers/crypto/omap-aes.c |4 ++--
drivers/crypto/omap-sham.c|4
drivers/crypto/picoxcell_crypto.c | 35 ---
drivers/crypto/s5p-sss.c |4 ++--
drivers/crypto/talitos.c | 28 ++--
include/linux/crypto.h|5 +
11 files changed, 63 insertions(+), 37 deletions(-)
diff --git a/drivers/crypto/geode-aes.c b/drivers/crypto/geode-aes.c
index 219d09c..3a8a3ef1 100644
--- a/drivers/crypto/geode-aes.c
+++ b/drivers/crypto/geode-aes.c
@@ -392,7 +392,8 @@ static struct crypto_alg geode_cbc_alg = {
.cra_name = "cbc(aes)",
.cra_driver_name = "cbc-aes-geode",
.cra_priority = 400,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_KERN_ONLY |
CRYPTO_ALG_NEED_FALLBACK,
.cra_init = fallback_init_blk,
.cra_exit = fallback_exit_blk,
@@ -479,6 +480,7 @@ static struct crypto_alg geode_ecb_alg = {
.cra_driver_name = "ecb-aes-geode",
.cra_priority = 400,
.cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_KERN_ONLY |
CRYPTO_ALG_NEED_FALLBACK,
.cra_init = fallback_init_blk,
.cra_exit = fallback_exit_blk,
diff --git a/drivers/crypto/hifn_795x.c b/drivers/crypto/hifn_795x.c
index fe765f4..7556a045 100644
--- a/drivers/crypto/hifn_795x.c
+++ b/drivers/crypto/hifn_795x.c
@@ -2494,7 +2494,7 @@ static int hifn_alg_alloc(struct hifn_device *dev, struct hifn_alg_template *t)
t->drv_name, dev->name);
alg->alg.cra_priority = 300;
- alg->alg.cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC;
+ alg->alg.cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_KERN_ONLY | CRYPTO_ALG_ASYNC;
alg->alg.cra_blocksize = t->bsize;
alg->alg.cra_ctxsize = sizeof(struct hifn_context);
alg->alg.cra_alignmask = 0;
diff --git a/drivers/crypto/ixp4xx_crypto.c b/drivers/crypto/ixp4xx_crypto.c
index 4c20c5b..52e6525 100644
--- a/drivers/crypto/ixp4xx_crypto.c
+++ b/drivers/crypto/ixp4xx_crypto.c
@@ -1449,6 +1449,7 @@ static int __init ixp_module_init(void)
/* block ciphers */
cra->cra_type = &crypto_ablkcipher_type;
cra->cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
+ CRYPTO_ALG_KERN_ONLY |
CRYPTO_ALG_ASYNC;
if (!cra->cra_ablkcipher.setkey)
cra->cra_ablkcipher.setkey = ablk_setkey;
@@ -1461,6 +1462,7 @@ static int __init ixp_module_init(void)
/* authenc */
cra->cra_type = &crypto_aead_type;
cra->cra_flags = CRYPTO_ALG_TYPE_AEAD |
+ CRYPTO_ALG_KERN_ONLY |
CRYPTO_ALG_ASYNC;
cra->cra_aead.setkey = aead_setkey;
cra->cra_aead.setauthsize = aead_setauthsize;
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index 3cf303e..8d157ed 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
@@ -895,7 +895,7 @@ struct crypto_alg mv_aes_alg_ecb = {
.cra_name = "ecb(aes)",
.cra_driver_name = "mv-ecb-aes",
.cra_priority = 300,
- .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC
Re: Hardware acceleration indication in af_alg
On 10/21/2011 03:23 PM, Herbert Xu wrote: > Matthias-Christian Ott wrote: >> I did some experiments with af_alg and noticed that to be really >> useful, it should indicate whether a certain algorithm is hardware >> accelerated. I guess this has to be inferred by the priority of the >> algorithm could be made available via a read-only socket option. Any >> thoughts on this? >> >> I can imagine, an alternative approach and perhaps better approach >> would be to measure the speed of the kernel provided algorithm against >> a software implementation, but there are many other factors that could >> influence the results. Therefore, it is perhaps better to just make >> the assumption that hardware acceleration is faster which is made in >> the kernel anyhow. > You have to be careful to distinguish between hardware acceleration > that is directly available to user-space (such as AESNI) and those > that aren't. How can this be done? The only driver field that could be used for that is cra_priority and it seems it typically set to 300 irrespective of instruction based crypto or external device. regards, Nikos -- 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] random: add blocking facility to urandom
On 09/07/2011 10:02 PM, Steve Grubb wrote: When a system is underattack, do you really want to be using a PRNG for anything like seeding openssl? Because a PRNG is what urandom degrades into when its attacked. Using a PRNG is not a problem. Making sure it is well seeded and no input from the attacker can compromise its state are the difficult parts. Making predictable estimates and blocking when your estimates are off, makes it a good target for DoS. When your system is under attack, you want to use your services. If they block then the attack might have just been successful. regards, Nikos -- 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: comparison of the AF_ALG interface with the /dev/crypto
On 09/01/2011 05:32 PM, David Miller wrote: From: Nikos Mavrogiannopoulos Date: Thu, 1 Sep 2011 17:06:06 +0200 It would be interesting to have a partial kernel-space TLS implementation but I don't know whether such a thing could ever make it to kernel. Herbert and I have discussed this several times and we plan on implementing this at some point. The problem is that TLS is not a universal thing. There is still SSH, kerberos, openvpn (as far as I remember it is a custom protocol), etc. It makes sense to have something to apply broadly, especially when it is in the Linux kernel. Currently have a device such as /dev/crypto looks like a good compromise. regards, Nikos -- 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: comparison of the AF_ALG interface with the /dev/crypto
On Thu, Sep 1, 2011 at 4:59 PM, Herbert Xu wrote: >> latency, maybe(?) high throughput or so). Thus, I designed this >> benchmark with a use-case in mind, i.e., a TLS or DTLS tunnel >> executing in a system with such an accelerator. There might be other >> benchmarks with other use cases in mind, but I haven't seen any. > Putting TLS data-path in user-space is always going to be less > than optimal, especially with hardware crypto offload, since you'll > be crossing the user-space/kernel boundary multiple times. Indeed but today that's what we have in some systems. User-space TLS implementations (GnuTLS and OpenSSL) and kernel-space crypto offloading. The purpose of the /dev/crypto and AF_ALG interfaces is to connect those together. It would be interesting to have a partial kernel-space TLS implementation but I don't know whether such a thing could ever make it to kernel. regards, Nikos -- 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: comparison of the AF_ALG interface with the /dev/crypto
On Thu, Sep 1, 2011 at 4:14 PM, Herbert Xu wrote: > Are you maxing out your submission CPU? If not then you're testing > the latency of the interface, as opposed to the throughput. I think it is obvious that a benchmark of throughput measures throughput. If however, you think that AF_ALG is in disadvantage in this benchmark, because it is a high latency interface, you're free to propose and perform another one. I haven't seen anywhere how is this interface was supposed to be used, nor about its qualities (high latency, maybe(?) high throughput or so). Thus, I designed this benchmark with a use-case in mind, i.e., a TLS or DTLS tunnel executing in a system with such an accelerator. There might be other benchmarks with other use cases in mind, but I haven't seen any. regards, Nikos -- 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: comparison of the AF_ALG interface with the /dev/crypto
On 09/01/2011 08:43 AM, Herbert Xu wrote: On Thu, Sep 01, 2011 at 08:26:07AM +0200, Nikos Mavrogiannopoulos wrote: Actually this is the reason of the ecb(cipher-null) comparison. To emulate the case of a hardware offload device. I tried to make that clear in the text, but may not be. If you see AF_ALG performs really bad on that case. It performs better when a software or a padlock implementation of AES is involved (which as you say it is a useless use-case). It's meaningless because such devices operate at a rate much lower than the figures you give. Have you actually measured that? -- 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: comparison of the AF_ALG interface with the /dev/crypto
On 09/01/2011 04:15 AM, Herbert Xu wrote: Nikos Mavrogiannopoulos wrote: Given my benchmarks have no issues, it is not apparent to me why one should use AF_ALG instead of cryptodev. I do not know though why AF_ALG performs so poor. I'd speculate by blaming it on the usage of the socket API and the number of system calls required. The target usage of AF_ALG is hardware offload devices that cannot be directly used in user-space, not software crypto on implementations such as AESNI/Padlock. Going through the kernel to use something like AESNI/Padlock or software crypto is insane. Given the intended target case, your numbers are pretty much meaningless as cryptodev's performance can be easily beaten by a pure user-space implementation. Actually this is the reason of the ecb(cipher-null) comparison. To emulate the case of a hardware offload device. I tried to make that clear in the text, but may not be. If you see AF_ALG performs really bad on that case. It performs better when a software or a padlock implementation of AES is involved (which as you say it is a useless use-case). Of course, I don't own such an offloading device and cannot test it directly. If you have different values from a benchmark with an actual hardware accelerator, I'll be happy to include them. regards, Nikos -- 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: comparison of the AF_ALG interface with the /dev/crypto
On 08/28/2011 10:35 PM, David Miller wrote: The benchmark idea was to test the speed of initialization, encryption and deinitiation, as well as the encryption speed alone. These are the most common use cases of the frameworks (i.e. how they would be used by a cryptographic library). Be sure to use splice() with AF_ALG for maximum performance. For example, see the test program below. You'll need to replace "8192" with whatever the page size is on your cpu. As I understand with splice you can encrypt only page aligned data that span a multiple of pages. This is a very uncommon case. My benchmark targets the generic case, i.e., the way this interface will be used in crypto libraries like gnutls. However, I'll update the comparison page to include the splice version as well. regards, Nikos -- 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
comparison of the AF_ALG interface with the /dev/crypto
Hello, I've compared the cryptodev [0] and AF_ALG interfaces in terms of performance [1]. I've put the results, as well as the benchmarks used in: http://home.gna.org/cryptodev-linux/comparison.html The benchmark idea was to test the speed of initialization, encryption and deinitiation, as well as the encryption speed alone. These are the most common use cases of the frameworks (i.e. how they would be used by a cryptographic library). The AF_ALG appears to have poor performance comparing to cryptodev. Note that the test with software AES is not really indicative because the cost of software encryption masks the overhead of the framework. The difference is clearly seen in the NULL cipher that has no cost (as one would expect from a hardware cipher accelerator). Given my benchmarks have no issues, it is not apparent to me why one should use AF_ALG instead of cryptodev. I do not know though why AF_ALG performs so poor. I'd speculate by blaming it on the usage of the socket API and the number of system calls required. regards, Nikos [0]. http://home.gna.org/cryptodev-linux/ [1]. Both intend to provide user-space with high-bandwidth hardware accelerated ciphers, thus performance seems a rational to compare. -- 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: [RFC v1.1 1/5] crypto: GnuPG based MPI lib
On Wed, Aug 17, 2011 at 2:23 PM, Dmitry Kasatkin wrote: >> Was there a particular reason to select the GnuPG mpi lib? Why not >> include gmp (the gnupg mpi lib is a very old fork of gmp), or some other >> big number library? > GNUPG MPI kernel port was available and has shown the best performance > comparing to other kernel implementations > such as LibTomMath and once other rsa implementation.. > In fact I took libtommath from your cryptodev-linux#newapi project. > I have patches and RSA implementation in my git trees. > IIRC performance was about twice worse than in Gnupg MPI lib... Quite impressive [0]. In GnuTLS we had the same (2x) performance optimization by switching to gmp from the gnupg mpi. I remember some projects ported gmp to linux kernel, but I don't know how wise that would be. Gmp (and the original gnupg mpi - don't know about the port) have no easy way to indicate memory allocation failure. That was my reason to select libtommath instead of them. regards, Nikos [0]. There is a limitation in libtommath as I ported it in the linux kernel. It uses 32-bit numbers even in x86-64. Libtommath required an 128-bit type to support 64-bit numbers that was available to user-space via gcc but not in linux-kernel. Performance of mpi was not my goal then, so I didn't investigate it more. -- 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: [RFC v1.1 1/5] crypto: GnuPG based MPI lib
On Mon, Aug 15, 2011 at 6:12 PM, Dmitry Kasatkin wrote: > On 11/08/11 20:20, Dmitry Kasatkin wrote: >> From: Dmitry Kasatkin >> >> Adds the multi-precision-integer maths library which was originally taken >> from GnuPG and ported to the kernel by (among others) David Howells. >> This version is taken from Fedora kernel 2.6.32-71.14.1.el6. >> This library is used to implemenet RSA digital signature verification >> used in IMA/EVM integrity protection subsystem. Was there a particular reason to select the GnuPG mpi lib? Why not include gmp (the gnupg mpi lib is a very old fork of gmp), or some other big number library? regards, Nikos -- 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: RSA verification in the kernel
On Thu, Jan 13, 2011 at 8:19 AM, Dmitry Kasatkin wrote: > Hi, > Does anybody know if there is a GPL implementation of RSA verification > for the Linux kernel? > I know DigSig, but is anything recent available? In NCR [http://home.gna.org/cryptodev-linux/ncr.html] I've added RSA and DSA using the public domain libtommath/libtomcrypt. You could use them. The internal API for RSA is the libtomcrypt one. regards, Nikos -- 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 Update for 2.6.38
On Fri, Jan 7, 2011 at 2:04 PM, Neil Horman 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-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: Crypto API User-interface
On Tue, Oct 19, 2010 at 3:44 PM, Herbert Xu wrote: > OK I've gone ahead and implemented the user-space API for hashes > and ciphers. > To recap this interface is designed to allow user-space programs > to access hardware cryptographic accelerators that we have added > to the kernel. > The intended usage scenario is where a large amount of data needs > to be processed where the benefits offered by hardware acceleration > that is normally unavailable in user-space (as opposed to ones > such as the Intel AES instruction which may be used directly from > user-space) outweigh the overhead of going through the kernel. What is the overall advantage of this API comparing to other existing ones that achieve similar goals[0][1]? Some observations: 1. To perform an encryption of data 6 system calls are made (I don't count the 2 used for socket initialization since I suppose can be global for all operations) and a file descriptor is assigned. The number of system calls made has great impact to the actual speed seen by userspace (as you said this API is for user-space to access the high-speed peripherals that do encryption). 2. Due to the usage of read() and write() no zero-copy can happen for user-space buffers[3]. regards, Nikos [0]. http://home.gna.org/cryptodev-linux/ [1]. http://home.gna.org/cryptodev-linux/ncr.html [2]. The openbsd[0] api can do it with 3 system calls and NCR[1] with one, and both require no file descriptor for each operation. [3]. The openbsd[0] api and NCR[1] do zero-copy for user-space buffers. -- 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: RFC: Crypto API User-interface
On Tue, Sep 7, 2010 at 4:06 PM, Christoph Hellwig wrote: >> This is what I am proposing for the Crypto API user-interface. > > Can you explain why we would ever want a userspace interface to it? > > doing crypto in kernel for userspace consumers sis simply insane. > It's computational intensive code which has no business in kernel space > unless absolutely required (e.g. for kernel consumers). In addition > to that adding the context switch overhead and address space transitions > is god awfull too. > This all very much sounds like someone had far too much crack. Or that someone is not really aware of some cryptographic uses. Embedded systems have crypto accelerators in hardware available through kernel device drivers. In the systems I worked the accelerators via a crypto device interface gave a 50x to 100x boost in crypto operations and relieved the CPU from doing them. regards, Nikos -- 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: RFC: Crypto API User-interface
On Tue, Sep 7, 2010 at 4:11 PM, Herbert Xu wrote: >> > This is what I am proposing for the Crypto API user-interface. >> >> Can you explain why we would ever want a userspace interface to it? >> >> doing crypto in kernel for userspace consumers sis simply insane. >> It's computational intensive code which has no business in kernel space >> unless absolutely required (e.g. for kernel consumers). In addition >> to that adding the context switch overhead and address space transitions >> is god awfull too. >> >> This all very much sounds like someone had far too much crack. > > FWIW I don't care about user-space using kernel software crypto at > all. It's the security people that do. Then I'd suggest to not enforce your design over to people who have thought and have interests on that. The NCR api which you rejected (for not supporting kernel keyring - which your design also doesn't!), has specific security goals and protects against specific threats. This design here has been proposed by you quite many times in the past and neither you, nor anyone else bothered implementing it. Now we have two working implementations that offer user-space access to crypto operations, (the openbsd cryptodev port), and NCR, but you discard them and insist on a different design. Maybe yours is better (you have to argue about that)... Probably I'd use it if it was there, but it isn't. regards, Nikos -- 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 09/06/2010 10:42 PM, Kyle Moffett wrote: >>> 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. 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? > 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? In short: cryptographic operations. > 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? An unprivileged process will load a key from disk to kernel and use it. The keys leave the NCR framework only encrypted and authenticated. > Is it just a canonical interface for userspace to encrypt or decrypt > data using the kernel's CryptoAPI? I don't understand what do you mean by canonical, but this API can be used to perform crypto operations. It uses the internal linux API where possible. regards, Nikos -- 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 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. > 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 what would this suggest? > 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). Each key of NCR contains a key ID, that is the same in public and private keys (if generated by NCR), and that could be used to index it. Secret keys have a key id specified by the user. It does not require you to use it though. > 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. If you are sharing a cache, the protection given by NCR is actually not used. Unless of course you start wrapping keys to ensure that noone unauthorized except from the legitimate systems access them. Doing the crypto in user-space would be more efficient in that case. > 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. I cannot get the big picture of you suggestions. How does this fit to NCR given the explanation on how keys are (not) stored by NCR. Is your suggestion about convenience calls to retrieve and store keys from and to keyring? Or you are suggesting NCR to be using the keyring for its internal reference of keys? If it is the latter, what would be the advantage of doing that? regards. Nikos -- 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 09/06/2010 02:17 PM, Herbert Xu 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. > > 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. I think this is a misunderstanding. The NCR does not have a keyring. The only common thing it has with a keyring is the word "key". The fact that it holds a reference to the key being used for encryption doesn't really make it a keyring. The kernel Keyring can be used with NCR to store keys as well as any other keyring. regards, Nikos -- 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 09/03/2010 11:18 AM, Herbert Xu wrote: > I will be looking at this myself so please stay tuned and be ready > to yell if you see that your requirements are not met. On 08/20/2010 03:56 PM, Ted Ts'o wrote: > So I'm bit at a list what's the whole point of this patch series. > Could you explain that in the documentation, please? Especially for > crypto, explaining when something should be used, what the threat > model is, etc., is often very important. Hello, The document discussing the model, threats and design goals of this framework can be found at: https://www.cosic.esat.kuleuven.be/publications/article-1490.pdf Comments and suggestions are welcome. regards, Nikos PS. The existing (proposed) implementation covers about 90% of the design goals, the rest are work in progress. -- 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
2010/9/3 Herbert Xu : >> * ioctl(NCRIO_SESSION_INIT) to allocate a crypto session (to encrypt, >> decrypt, hash, sign, or verify signature), then >> ioctl(NCRIO_SESSION_UPDATE) to act on chunks of data. Deallocate the >> session, and optionally retrieve session results (e.g. hash or >> signature), using ioctl(NCRIO_SESSION_FINAL). >> There is also NCRIO_SESSION_ONCE for an one-shot crypto operation >> using a single user->kernel context switch. >> Full documentation of the interface is in >> Documentation/crypto/userspace.txt . > > Thanks for the updated patch-set. It does indeed fulfil some > of the requirements raised earlier. > > However, as far as I can see this still does not address the > extensibility. For example, say we want add an interface to > allow the xoring of two arbitrary data streams using DMA offload, > this interface would make that quite awkward. Although I think the current API could handle something like this, I also think it is undesirable to do so. The API was designed with cryptographic operations in mind, and its extensibility might better be judged on how it can incorporate future cryptographic protocols (sigma-proofs and other zero-knowledge protocols and other protocols that I might not know of). An XOR operation, doesn't really fit into a cryptographic API. It could however be included in the current design with some utility ioctls() that address such helper operations. Even better, I think a XOR operation deserves a system call, since it is quite useful in a variety of applications, not only cryptographic ones. > In fact the whole interface is really tailored to the traditional > encryption/hash operations that BSD provided so I think this is not > a good foundation for our user-space API. It supports much more than the openbsd API, but indeed it is designed with cryptographic operations in mind and this limitation can allow a semi-formal verification of its properties. I'll try to post a link to the design document as soon. regards, Nikos -- 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
crypto_xor
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...
Something like:
void crypto_xor(u8 *dst, const u8 *src, unsigned int size)
{
unsigned long *a = (unsigned long *)dst;
unsigned long *b = (unsigned long *)src;
for (; size >= sizeof(unsigned long); size -= sizeof(unsigned long))
*a++ ^= *b++;
crypto_xor_byte((u8 *)a, (u8 *)b, size);
}
regards,
Nikos
--
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 00/19] RFC, v2: "New" /dev/crypto user-space interface
On Mon, Aug 23, 2010 at 10:09 AM, Arnd Bergmann wrote: >> This is an alternative design. There quite some reasons against that, >> such as the auditing features. For me the main reason was that there >> was no way to make it as fast (zero-copy) as this design, for the >> requirements we had (interface with existing crypto libraries through >> pkcs11). Zero-copy is important since crypto operations might involve >> large chunks of data. > You mean using a shared memory segment would not be possible without changing > the libpkcs11 interface? Indeed. The pkcs11 backend would have to copy the data to the shared segment, thus high-performance applications requiring zero-copy, would avoid to use this interface. Moreover if more than one applications are using the interface, the shared segment it is going to be a bottleneck. Having multiple shared segments might help, but I don't know how practical is something like that with the posix ipc. regards, Nikos -- 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 00/19] RFC, v2: "New" /dev/crypto user-space interface
On 08/21/2010 07:08 PM, Arnd Bergmann wrote: > On Friday 20 August 2010 10:45:43 Miloslav Trmač wrote: >> >> Major changes since the previous post: >> * "struct nlattr"-based extensible attributes used for extensibility >> of most operations, both for input and output attributes > The API here looks overly complex resulting from the use of a combination > of ioctl and netlink. If your interface cannot be easily expressed using > simple (no indirect pointers or variable-length fields please) ioctl > and read/write operations, why not go all the way and turn the interface > into a netlink facility? I believe that this is the result of the discussion in the version 1 of the proposal. The original API was specified with ioctls only. >> * Full compat_ioctl implementation > New drivers should be written to *avoid* compat_ioctl calls, using only > very simple fixed-length data structures as ioctl commands. There are cases where this cannot be easily done, when say pointers are involved. IMHO forcing pointers to be u64 or u32 is dirtier than using the compat interface. >> * Version number added to the data format used when wrapping keys for storage > Again, wrong direction. If you think you need a version number, the interface > is probably not ready for inclusion yet. Make sure it is simple enough that > you don't run into the case where you have to make incompatible changes > that require API versioning. Note that the version number is not to the interface but to data that are intended for storage. It is desirable to have such a version there. >> The libtom* patches will probably still be too large for the mailing list; >> the whole patch set is also available at >> http://people.redhat.com/mitr/cryptodev-ncr/v2/ . > They actually seem to have made it to the list. However, the more signficant > problem is the amount of code added to a security module. 2 lines of > code that is essentially a user-level library moved into kernel space > can open up so many possible holes that you end up with a less secure > (and slower) setup in the end than just doing everything in user space. The same argument could apply to an other algorithm in the kernel such as deflate, lzma, AES etc. There are cases that the benefits outweigh the risks of adding them. I believe this is such a case. >> These are the major differences compared to the BSD-like interface: >> * The API supports key storage and management inside the kernel. >> An application can thus ask the kernel to generate a key; the key is >> then referenced via an integer identifier, and the application can be >> prevented from accessing the raw key data. Such a key can, if so >> configured, >> still be wrapped for key transport to the recipient of the message, and >> unwrapped by the recipient. > As Kyle mentioned, we already have a key management API in the kernel. > I think you should make a better effort of interfacing with that and > adding features you need to it, like a way to prevent the kernel from > handing out keys as you mentioned in your reply. Note that the NCR does not do key management. Integrating with the key management API could be nice, but it is not something critical and is not duplicating code or efforts in any way. >> An user-space library is not separated, options are a) root >> running daemon that does crypto, but this would be slow due to context >> switches, scheduler mismatching and all the IPC overhead and b) use crypto >> that is in the kernel. > I think you will have to back that statement by measurements. There are > reasonably fast ways to do IPC and the interface you suggest to put in the > kernel does not exactly look tuned for performance. This is an alternative design. There quite some reasons against that, such as the auditing features. For me the main reason was that there was no way to make it as fast (zero-copy) as this design, for the requirements we had (interface with existing crypto libraries through pkcs11). Zero-copy is important since crypto operations might involve large chunks of data. >> * FIPS-140-3 calls out for cryptographic functions to be non-debuggable >> (ptrace) >> meaning that you cannot get to the key material. The solution is the same >> as >> above. > > We have kgdb, kdb, qemu gdbserver, tracing and more things that would very > much make your code debuggable. > OTOH, disabling ptrace with a root-only prctl should be an easy thing to > implement if there is a use case for it. You are right. Debugging by the administrator was not an issue. Only users should be prevented from that. It should have been mentioned. regards, Nikos -- 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 08/21/2010 03:09 PM, Kyle Moffett wrote:
>> This patch introduces the new user-space API, .
>>
>> Quick overview:
>>
>> * open("/dev/crypto") to get a FD, which acts as a namespace for key and
>> session identifiers.
>>
>> * ioctl(NCRIO_KEY_INIT) to allocate a key object; then generate the key
>> material inside the kernel, load a plaintext key, unwrap a key, or
>> derive a key. Similarly the key material can be copied out of the
>> kernel or wrapped.
>>
>> [...snip...]
>
> Ugh... We already have one very nice key/keyring API in the kernel
> (see Documentation/keys.txt) that's being used for crypto keys for
> NFSv4, AFS, etc. Can't you just add a bunch of cryptoapi key types to
> that API instead?
It is not that simple. My understanding of the keyring API is that it
allows exporting of the keys to user-space and this crypto API
explicitly prevents that, so enhancing the API that way will remove the
benefits of using it. It would be ideal to combine somehow those
solutions but this is more elaborate work than adding a bunch of new key
types. If anyone is interested in attempting that I'd be glad to help.
regards,
Nikos
--
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
2010/8/20 Stefan Richter :
>> +struct ncr_session_input_data {
>> + const void __user *data;
>> + __kernel_size_t data_size;
>> +};
>> +
>> +};
> Why not using fixed-size fit-all members?
> struct ncr_session_input_data {
> __u64 data; /* user pointer, cast to/from u64 */
> __u32 data_size; /* or __u64? */
> };
A reason is that using (void*) is cleaner as an API. It avoids the
pointer to int casting and the warnings that such a cast will have.
regards,
Nikos
--
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 00/19] RFC, v2: "New" /dev/crypto user-space interface
On 08/20/2010 03:56 PM, Ted Ts'o wrote: > On Fri, Aug 20, 2010 at 10:45:43AM +0200, Miloslav Trmač wrote: >> Hello, following is a patchset providing an user-space interface to >> the kernel crypto API. It is based on the older, BSD-compatible, >> implementation, but the user-space interface is different. > > What's the goal of exporting the kernel crypto routines to userspace, > as opposed to just simply doing the crypto in userspace? This was the goal of the original cryptodev OpenBSD API and the subsequent linux port in http://home.gna.org/cryptodev-linux/. In typical PCs it might even be slower to use such an accelerator in kernel space, but in embedded systems where the hardware version of AES might be 100 times faster than the software it might make sense. However the design goal of this API is to separate cryptographic operations from the applications. That is applications in userspace can use keys, but the keys cannot be extracted from them, so for example code injection in the web server will not be able to extract the private key of the web service. (this approach is also required for certification of linux on certain fields as Miloslav described in the first post). The interface is designed in a way that it can be wrapped by a PKCS #11 module and used transparently by other crypto libraries (openssl/nss/gnutls). TPM is quite limited in this respect and cannot fulfill this goal. > So I'm bit at a list what's the whole point of this patch series. > Could you explain that in the documentation, please? Especially for > crypto, explaining when something should be used, what the threat > model is, etc., is often very important. A detailed document describing this framework, threats and model is on its way. best regards, Nikos -- 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 0/4] RFC: "New" /dev/crypto user-space interface
2010/8/11 Linus Walleij : Hello, > Hi Miloslav, > c.f how the ALSA mixer presents a lot of things to userspace without > using any enums at all in /dev/snd/controlC0 for card 0. For example > in include/linux/soundcard.h you find the different control knobs > enumerated with strings so as to avoid explicit enums. This is a double edged sword. Although it provides freedom at the userspace, it would also allow crypto algorithms that were not considered by the original design to be used with unpredictable results. Moreover typos are found at run-time rather than compile-time. For this and similar reasons interfaces of crypto libraries and PKCS #11 define explicitly the allowed algorithms. This design followed this principle. > 2. To avoid security hazards the API would benefit from being programmed > with at least some secure programming concepts in mid. Input argument > checking separate from algorithm separate from output argument checking, > and erasing of information from stacks and buffers. More or less What do you consider as a threat here? Is it for the kernel returing unerased buffers and stack to userspace? > 3. A general interface for stream ciphers would be nice. The only differences > are that they do not operate on blocks, but bits, and that they > always require > an IV. Arguably this can be added later if the aspect if just considered > when > devising the interface. The recent discussion in this thread > regarding netlink > points in a direction where streams are a natural part of the concept I > believe. This interface works (or should) with any kind of cipher. It is designed to be wrappable to a pkcs #11 module, to be used easily as backend by existing crypto applications and libraries. regards, Nikos -- 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 API from user space
Dmitry Kasatkin wrote: > Hi, > > Can I use kernel Crypto API from user space? > I remember 2 or 3 projects about it. > > But what is the one and only one I need? :) I don't know which is the one you need, but I know the one I use. Check http://home.gna.org/cryptodev-linux/ regards, Nikos -- 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: RFC: kcrypto - (yet another) user space interface
Sebastian Andrzej Siewior wrote: > * Phil Sutter | 2010-06-10 20:22:29 [+0200]: > >> Hello everyone, > Hi Phil, > > please take look at [0] and [1]. From README I can tell that those two > posts are different from you have so far. > You might want to take a look at AF_PACKET interface. It does zero copy > via a ring buffer interface of pre-mmaped user memory. So no > get_user_pages() then :) > > I think that is the way to go. The problem with right or wrong is that they are only known afterwards. For me the right way to go is _to go_. I can see discussions in this least, years ago on talks about the "perfect" userspace crypto api and rejections implementations because they are not perfect enough. I don't believe there is such thing as a perfect crypto api. Other operating systems have a userspace crypto API (maybe not perfect) but linux hasn't. I don't think this is the way to go. regards, Nikos -- 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: cryptodev support
Emanuele Cesena wrote: > On Wed, 2010-03-17 at 14:43 +0100, Nikos Mavrogiannopoulos wrote: >> It is one way that >> few other OS's support as well. For this reason it is the best from the >> user-space developer point of view to have a single API across many OS'. > This is really good, in my opinion. > What the others think? Hello, For anyone interested in the /dev/crypto for linux I've setup a website and made a beta release of the cryptodev module. It can be found at: http://home.gna.org/cryptodev-linux/ regards, Nikos -- 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: cryptodev support
Emanuele Cesena wrote: > On Wed, 2010-03-17 at 13:50 +0100, Nikos Mavrogiannopoulos wrote: >> Hello, >> I needed to access crypto hardware modules from userspace and I made >> that by adding cryptodev support on top of linux-crypto. It is a >> separate module available at: >> http://repo.or.cz/w/cryptodev-linux.git >> > I'm also interested in the userspace module (we are working on a patch > for opencryptoki), but this version looks quite different from the ideas > "recently" discussed in this mailing list and, probably even more > important, from the idea for future development (i.e. moving to a > socket-like interface). I'm not aware of the discussion in the ml. I don't argue that this is the only way to expose the internal API to userspace. It is one way that few other OS's support as well. For this reason it is the best from the user-space developer point of view to have a single API across many OS'. regards, Nikos -- 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
cryptodev support
Hello, I needed to access crypto hardware modules from userspace and I made that by adding cryptodev support on top of linux-crypto. It is a separate module available at: http://repo.or.cz/w/cryptodev-linux.git It was originally based on the old cryptodev module found at http://www.logix.cz/michal/devel/cryptodev/ In the extras directory there is a patch for openssl that will make use of the /dev/crypto. Gnutls (2.9.x) will use /dev/crypto if it compiled with --enable-cryptodev. regards, Nikos -- 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
