Re: [PATCH RFC v4 2/4] crypto: add PKE API
On 06/11/2015 07:42 PM, Herbert Xu wrote: >> The testmgr code can mark an entire cipher implementation as fips_allowed=1 >> as >> > already done for RSA. However, unlike with the other ciphers, that flag >> > must >> > go in conjunction with the used key sizes. >> > >> > For FIPS mode, the following restrictions apply: >> > >> > - RSA: 2048/3072 >> > >> > - DSA: L 2048 / N 224; L 2048 / N 256; L 3072 / N 256 >> > >> > - ECDSA: only the NIST curves >> > >> > Any other key sizes for the given ciphers is not allowed in FIPS mode. >> > >> > Should that constraint be considered here? > Yes. However it should be placed into a helper that everybody > can call so that future hardware implementations can also make > the same checks. I will make the algorithm marked as fips allowed always and then fail in setkey if fips is enabled and the given key doesn't meet the fips requirement. Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC v4 2/4] crypto: add PKE API
On Thu, Jun 11, 2015 at 11:50:06PM -0700, Tadeusz Struk wrote: > > Should I make it MPI[] rather than void * It should be in encoded format since only the algorithms should be decoding it. Otherwise you have craziness where RSA-specific knowledge is placed into x509_cert_parser.c to parse RSA keys. It's probably easiest to go with the BER encoding that the only current user is using. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC v4 2/4] crypto: add PKE API
On 06/11/2015 07:59 PM, Herbert Xu wrote:
>> +int crypto_akcipher_setkey(struct crypto_akcipher *tfm,
>> > + const struct public_key *pkey)
>> > +{
>> > + if (tfm->pkey)
>> > + akcipher_free_key(tfm->pkey);
>> > +
>> > + return akcipher_clone_key(tfm, pkey);
>> > +}
> No please do not expose the struct public_key crap to the new
> API. The key should be completely opaque to entities outside
> of the algorithm. So make it raw and read out the MPIs from
> it.
>
> The contents of the function must go into the algorithm setkey
> function, not the crypto API. So RSA would read out however
> many MPIs it needs and verify it, and so on.
Should I make it MPI[] rather than void *
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC v4 2/4] crypto: add PKE API
On Thu, Jun 11, 2015 at 12:05:44PM -0700, Tadeusz Struk wrote:
>
> +int crypto_akcipher_setkey(struct crypto_akcipher *tfm,
> +const struct public_key *pkey)
> +{
> + if (tfm->pkey)
> + akcipher_free_key(tfm->pkey);
> +
> + return akcipher_clone_key(tfm, pkey);
> +}
No please do not expose the struct public_key crap to the new
API. The key should be completely opaque to entities outside
of the algorithm. So make it raw and read out the MPIs from
it.
The contents of the function must go into the algorithm setkey
function, not the crypto API. So RSA would read out however
many MPIs it needs and verify it, and so on.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC v4 2/4] crypto: add PKE API
On Fri, Jun 12, 2015 at 10:42:46AM +0800, Herbert Xu wrote: > On Fri, Jun 12, 2015 at 03:00:42AM +0200, Stephan Mueller wrote: > > > > The testmgr code can mark an entire cipher implementation as fips_allowed=1 > > as > > already done for RSA. However, unlike with the other ciphers, that flag > > must > > go in conjunction with the used key sizes. > > > > For FIPS mode, the following restrictions apply: > > > > - RSA: 2048/3072 > > > > - DSA: L 2048 / N 224; L 2048 / N 256; L 3072 / N 256 > > > > - ECDSA: only the NIST curves > > > > Any other key sizes for the given ciphers is not allowed in FIPS mode. > > > > Should that constraint be considered here? > > Yes. However it should be placed into a helper that everybody > can call so that future hardware implementations can also make > the same checks. Ugh I didn't notice this was the generic API setkey function. No it should go into the algorithm-specific setkey function and then be in the form of a helper so that all implementations of that algorithm can call it. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC v4 2/4] crypto: add PKE API
On Fri, Jun 12, 2015 at 03:00:42AM +0200, Stephan Mueller wrote: > > The testmgr code can mark an entire cipher implementation as fips_allowed=1 > as > already done for RSA. However, unlike with the other ciphers, that flag must > go in conjunction with the used key sizes. > > For FIPS mode, the following restrictions apply: > > - RSA: 2048/3072 > > - DSA: L 2048 / N 224; L 2048 / N 256; L 3072 / N 256 > > - ECDSA: only the NIST curves > > Any other key sizes for the given ciphers is not allowed in FIPS mode. > > Should that constraint be considered here? Yes. However it should be placed into a helper that everybody can call so that future hardware implementations can also make the same checks. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC v4 2/4] crypto: add PKE API
Am Thursday 11 June 2015, 12:05:44 schrieb Tadeusz Struk:
Hi Tadeusz,
>+
>+static int akcipher_clone_key(struct crypto_akcipher *tfm,
>+const struct public_key *pkey)
>+{
>+ int i, ret = 0;
>+
>+ tfm->pkey = kzalloc(sizeof(*tfm->pkey), GFP_KERNEL);
>+
>+ if (!tfm->pkey)
>+ return -ENOMEM;
>+
>+ for (i = 0; i < ARRAY_SIZE(tfm->pkey->mpi); i++) {
>+ if (!pkey->mpi[i])
>+ continue;
>+
>+ if (mpi_copy(&tfm->pkey->mpi[i], pkey->mpi[i])) {
>+ akcipher_free_key(tfm->pkey);
>+ tfm->pkey = NULL;
>+ ret = -ENOMEM;
>+ break;
>+ }
>+ }
>+ return ret;
>+}
The testmgr code can mark an entire cipher implementation as fips_allowed=1 as
already done for RSA. However, unlike with the other ciphers, that flag must
go in conjunction with the used key sizes.
For FIPS mode, the following restrictions apply:
- RSA: 2048/3072
- DSA: L 2048 / N 224; L 2048 / N 256; L 3072 / N 256
- ECDSA: only the NIST curves
Any other key sizes for the given ciphers is not allowed in FIPS mode.
Should that constraint be considered here?
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC v4 2/4] crypto: add PKE API
Add Public Key Encryption API.
Signed-off-by: Tadeusz Struk
---
crypto/Kconfig |6 +
crypto/Makefile|1
crypto/akcipher.c | 154 +
crypto/crypto_user.c | 23 ++
include/crypto/akcipher.h | 408
include/linux/crypto.h |1
include/linux/cryptouser.h |6 +
7 files changed, 599 insertions(+)
create mode 100644 crypto/akcipher.c
create mode 100644 include/crypto/akcipher.h
diff --git a/crypto/Kconfig b/crypto/Kconfig
index cb7806f..d119b38 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -91,6 +91,12 @@ config CRYPTO_PCOMP2
tristate
select CRYPTO_ALGAPI2
+config CRYPTO_AKCIPHER
+ tristate "Public Key Algorithms API"
+ select CRYPTO_ALGAPI
+ help
+ Crypto API interface for public key algorithms.
+
config CRYPTO_MANAGER
tristate "Cryptographic algorithm manager"
select CRYPTO_MANAGER2
diff --git a/crypto/Makefile b/crypto/Makefile
index c842035..6f2940a 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -28,6 +28,7 @@ crypto_hash-y += shash.o
obj-$(CONFIG_CRYPTO_HASH2) += crypto_hash.o
obj-$(CONFIG_CRYPTO_PCOMP2) += pcompress.o
+obj-$(CONFIG_CRYPTO_AKCIPHER) += akcipher.o
cryptomgr-y := algboss.o testmgr.o
diff --git a/crypto/akcipher.c b/crypto/akcipher.c
new file mode 100644
index 000..286f31f
--- /dev/null
+++ b/crypto/akcipher.c
@@ -0,0 +1,154 @@
+/*
+ * Public Key Encryption
+ *
+ * Copyright (c) 2015, Intel Corporation
+ * Authors: Tadeusz Struk
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "internal.h"
+
+#ifdef CONFIG_NET
+static int crypto_akcipher_report(struct sk_buff *skb, struct crypto_alg *alg)
+{
+ struct crypto_report_akcipher rakcipher;
+
+ strncpy(rakcipher.type, "akcipher", sizeof(rakcipher.type));
+ strncpy(rakcipher.subtype, alg->cra_name, sizeof(rakcipher.subtype));
+
+ if (nla_put(skb, CRYPTOCFGA_REPORT_AKCIPHER,
+ sizeof(struct crypto_report_akcipher), &rakcipher))
+ goto nla_put_failure;
+ return 0;
+
+nla_put_failure:
+ return -EMSGSIZE;
+}
+#else
+static int crypto_akcipher_report(struct sk_buff *skb, struct crypto_alg *alg)
+{
+ return -ENOSYS;
+}
+#endif
+
+static void crypto_akcipher_show(struct seq_file *m, struct crypto_alg *alg)
+ __attribute__ ((unused));
+
+static void crypto_akcipher_show(struct seq_file *m, struct crypto_alg *alg)
+{
+ seq_puts(m, "type : akcipher\n");
+ seq_printf(m, "subtype : %s\n", alg->cra_name);
+}
+
+static void akcipher_free_key(struct public_key *key)
+{
+ public_key_destroy(key);
+}
+
+static void crypto_akcipher_exit_tfm(struct crypto_tfm *tfm)
+{
+ struct crypto_akcipher *akcipher = __crypto_akcipher_tfm(tfm);
+
+ if (akcipher->pkey)
+ akcipher_free_key(akcipher->pkey);
+
+ akcipher->pkey = NULL;
+}
+
+static int crypto_akcipher_init_tfm(struct crypto_tfm *tfm)
+{
+ struct crypto_akcipher *akcipher = __crypto_akcipher_tfm(tfm);
+
+ akcipher->base.exit = crypto_akcipher_exit_tfm;
+ return 0;
+}
+
+static const struct crypto_type crypto_akcipher_type = {
+ .extsize = crypto_alg_extsize,
+ .init_tfm = crypto_akcipher_init_tfm,
+#ifdef CONFIG_PROC_FS
+ .show = crypto_akcipher_show,
+#endif
+ .report = crypto_akcipher_report,
+ .maskclear = ~CRYPTO_ALG_TYPE_MASK,
+ .maskset = CRYPTO_ALG_TYPE_MASK,
+ .type = CRYPTO_ALG_TYPE_AKCIPHER,
+ .tfmsize = offsetof(struct crypto_akcipher, base),
+};
+
+struct crypto_akcipher *crypto_alloc_akcipher(const char *alg_name, u32 type,
+ u32 mask)
+{
+ return crypto_alloc_tfm(alg_name, &crypto_akcipher_type, type, mask);
+}
+EXPORT_SYMBOL_GPL(crypto_alloc_akcipher);
+
+static int akcipher_clone_key(struct crypto_akcipher *tfm,
+ const struct public_key *pkey)
+{
+ int i, ret = 0;
+
+ tfm->pkey = kzalloc(sizeof(*tfm->pkey), GFP_KERNEL);
+
+ if (!tfm->pkey)
+ return -ENOMEM;
+
+ for (i = 0; i < ARRAY_SIZE(tfm->pkey->mpi); i++) {
+ if (!pkey->mpi[i])
+ continue;
+
+ if (mpi_copy(&tfm->pkey->mpi[i], pkey->mpi[i])) {
+ akcipher_free_key(tfm->pkey);
+ tfm->pkey = NULL;
+ ret = -ENOMEM;
+ break;
+ }
+ }
+ return ret;
+}
+
+int crypto_akcipher_setkey(struct crypto_akcipher *tfm,
+
