Re: [PATCH v5 3/4] crypto: kdf - SP800-108 Key Derivation Function

2016-08-16 Thread Herbert Xu 
On Tue, Aug 16, 2016 at 11:25:33AM +0200, Stephan Mueller wrote:
>> I was thinking of the DRBG implementation: decouple it from the underlying 
> ciphers. Though, I am not fully sure that will work as there are several 
> specific settings that depend on the underlying ciphers (e.g. the state of a 
> Hash DRBG with SHA-256 is 444 bits whereas a Hash DRBG with SHA-512 has 888 
> bits).

The only reason DRBG is in crypto is because it implements stdrng.

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-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 3/4] crypto: kdf - SP800-108 Key Derivation Function

2016-08-16 Thread Stephan Mueller 
Am Dienstag, 16. August 2016, 17:13:47 CEST schrieb Herbert Xu:

Hi Herbert,

> On Tue, Aug 16, 2016 at 11:11:47AM +0200, Stephan Mueller wrote:
> > Conceptually, a KDF is a random number generator by generating arbitrarily
> > sized strings from a fixed "seed". This lead me to add the RNG template
> > handling. Even the existing DRBG is more or less a "block chaining mode"
> > that is very similar to a KDF. Hence, the current plethora of 22
> > registered DRBGs could be elegantly eliminated if the DRBG is turned into
> > template using the proposed RNG framework.
> 
> The point is that there is no alternative implementation for kdf,
> nor is there likely to be one.

I was thinking of the DRBG implementation: decouple it from the underlying 
ciphers. Though, I am not fully sure that will work as there are several 
specific settings that depend on the underlying ciphers (e.g. the state of a 
Hash DRBG with SHA-256 is 444 bits whereas a Hash DRBG with SHA-512 has 888 
bits).
> 
> > If you think that a KDF should not be a generic mechanism, then the KDF
> > logic would need to move directly into the keys subsystem. But since TLS
> > is something folks speak about, a TLS KDF would need to be considered
> > eventually too which is yet again some form of RNG.
> 
> If a TLS KDF comes with a hardware implementation then we could
> include it.  Otherwise the answer would be the same.

It is certainly not an issue to move the KDF logic into the keys subsystem. 
However, as it (may) resemble SP800-56A which is in line with FIPS 140-2, 
folks may ask for a FIPS stamp on it. If a FIPS stamp is asked for, the KDF 
itself must be subject to a self test (like what we have in testmgr.c). If we 
move the KDF to the keys subsystem, the self test would then need to be 
implemented there.

Ciao
Stephan
--
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 3/4] crypto: kdf - SP800-108 Key Derivation Function

2016-08-16 Thread Herbert Xu 
On Tue, Aug 16, 2016 at 11:11:47AM +0200, Stephan Mueller wrote:
>
> Conceptually, a KDF is a random number generator by generating arbitrarily 
> sized strings from a fixed "seed". This lead me to add the RNG template 
> handling. Even the existing DRBG is more or less a "block chaining mode" that 
> is very similar to a KDF. Hence, the current plethora of 22 registered DRBGs 
> could be elegantly eliminated if the DRBG is turned into template using the 
> proposed RNG framework.

The point is that there is no alternative implementation for kdf,
nor is there likely to be one.

> If you think that a KDF should not be a generic mechanism, then the KDF logic 
> would need to move directly into the keys subsystem. But since TLS is 
> something folks speak about, a TLS KDF would need to be considered eventually 
> too which is yet again some form of RNG.

If a TLS KDF comes with a hardware implementation then we could
include it.  Otherwise the answer would be the same.

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-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 3/4] crypto: kdf - SP800-108 Key Derivation Function

2016-08-16 Thread Stephan Mueller 
Am Dienstag, 16. August 2016, 16:57:45 CEST schrieb Herbert Xu:

Hi Herbert,

> On Tue, Aug 09, 2016 at 02:28:37PM +0200, Stephan Mueller wrote:
> > The SP800-108 compliant Key Derivation Function is implemented as a
> > random number generator considering that it behaves like a deterministic
> > RNG.
> > 
> > All three KDF types specified in SP800-108 are implemented.
> > 
> > The code comments provide details about how to invoke the different KDF
> > types.
> > 
> > Signed-off-by: Stephan Mueller 
> 
> So I have no problems with this functionality existing in the kernel,
> assuming that the keys patch using it is accepted.
> 
> However, I'm still at a loss as to why this has to be done as
> an RNG.  IOW what benefit does implementing this as an RNG give
> us compared to just using the underlying hash directly from the
> keys subsystem?
> 
> In general the crypto API caters to algorithms that carry more
> than one implementation, especially if one of them is hardware-
> dependent.  I really can't see how KDF would fit this criterion.

The KDF is logically equivalent to a block chaining mode. As the KDF can be 
applied to arbitrary hash types (keyed and non-keyed), I thought of how to 
integrate it with the existing framework. None of the template mechanisms seem 
to fit what the KDF does.

Conceptually, a KDF is a random number generator by generating arbitrarily 
sized strings from a fixed "seed". This lead me to add the RNG template 
handling. Even the existing DRBG is more or less a "block chaining mode" that 
is very similar to a KDF. Hence, the current plethora of 22 registered DRBGs 
could be elegantly eliminated if the DRBG is turned into template using the 
proposed RNG framework.

If you think that a KDF should not be a generic mechanism, then the KDF logic 
would need to move directly into the keys subsystem. But since TLS is 
something folks speak about, a TLS KDF would need to be considered eventually 
too which is yet again some form of RNG.

Ciao
Stephan
--
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 3/4] crypto: kdf - SP800-108 Key Derivation Function

2016-08-16 Thread Herbert Xu 
On Tue, Aug 09, 2016 at 02:28:37PM +0200, Stephan Mueller wrote:
> The SP800-108 compliant Key Derivation Function is implemented as a
> random number generator considering that it behaves like a deterministic
> RNG.
> 
> All three KDF types specified in SP800-108 are implemented.
> 
> The code comments provide details about how to invoke the different KDF
> types.
> 
> Signed-off-by: Stephan Mueller 

So I have no problems with this functionality existing in the kernel,
assuming that the keys patch using it is accepted.

However, I'm still at a loss as to why this has to be done as
an RNG.  IOW what benefit does implementing this as an RNG give
us compared to just using the underlying hash directly from the
keys subsystem?

In general the crypto API caters to algorithms that carry more
than one implementation, especially if one of them is hardware-
dependent.  I really can't see how KDF would fit this criterion.

Thanks,
-- 
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-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 3/4] crypto: kdf - SP800-108 Key Derivation Function

2016-08-09 Thread Stephan Mueller 
The SP800-108 compliant Key Derivation Function is implemented as a
random number generator considering that it behaves like a deterministic
RNG.

All three KDF types specified in SP800-108 are implemented.

The code comments provide details about how to invoke the different KDF
types.

Signed-off-by: Stephan Mueller 
---
 crypto/kdf.c | 508 +++
 1 file changed, 508 insertions(+)
 create mode 100644 crypto/kdf.c

diff --git a/crypto/kdf.c b/crypto/kdf.c
new file mode 100644
index 000..6f9f082
--- /dev/null
+++ b/crypto/kdf.c
@@ -0,0 +1,508 @@
+/*
+ * Copyright (C) 2016, Stephan Mueller 
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, and the entire permission notice in its entirety,
+ *including the disclaimer of warranties.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. The name of the author may not be used to endorse or promote
+ *products derived from this software without specific prior
+ *written permission.
+ *
+ * ALTERNATIVELY, this product may be distributed under the terms of
+ * the GNU General Public License, in which case the provisions of the GPL2
+ * are required INSTEAD OF the above restrictions.  (This clause is
+ * necessary due to a potential bad interaction between the GPL and
+ * the restrictions contained in a BSD-style copyright.)
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, ALL OF
+ * WHICH ARE HEREBY DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
+ * OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
+ * BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
+ * USE OF THIS SOFTWARE, EVEN IF NOT ADVISED OF THE POSSIBILITY OF SUCH
+ * DAMAGE.
+ */
+
+/*
+ * For performing a KDF operation, the following input is required
+ * from the caller:
+ *
+ * * Keying material to be used to derive the new keys from
+ *   (denoted as Ko in SP800-108)
+ * * Label -- a free form binary string
+ * * Context -- a free form binary string
+ *
+ * The KDF is implemented as a random number generator.
+ *
+ * The Ko keying material is to be provided with the initialization of the KDF
+ * "random number generator", i.e. with the crypto_rng_reset function.
+ *
+ * The Label and Context concatenated string is provided when obtaining random
+ * numbers, i.e. with the crypto_rng_generate function. The caller must format
+ * the free-form Label || Context input as deemed necessary for the given
+ * purpose. Note, SP800-108 mandates that the Label and Context are separated
+ * by a 0x00 byte, i.e. the caller shall provide the input as
+ * Label || 0x00 || Context when trying to be compliant to SP800-108. For
+ * the feedback KDF, an IV is required as documented below.
+ *
+ * Example without proper error handling:
+ * char *keying_material = "\x00\x11\x22\x33\x44\x55\x66\x77";
+ * char *label_context = "\xde\xad\xbe\xef\x00\xde\xad\xbe\xef";
+ * kdf = crypto_alloc_rng(name, 0, 0);
+ * crypto_rng_reset(kdf, keying_material, 8);
+ * crypto_rng_generate(kdf, label_context, 9, outbuf, outbuflen);
+ *
+ * NOTE: In-place cipher operations are not supported.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct crypto_kdf_ctx {
+   struct shash_desc shash;
+   char ctx[];
+};
+
+/* convert 32 bit integer into its string representation */
+static inline void crypto_kw_cpu_to_be32(u32 val, u8 *buf)
+{
+   __be32 *a = (__be32 *)buf;
+
+   *a = cpu_to_be32(val);
+}
+
+/*
+ * Implementation of the KDF in double pipeline iteration mode according with
+ * counter to SP800-108 section 5.3.
+ *
+ * The caller must provide Label || 0x00 || Context in src. This src pointer
+ * may also be NULL if the caller wishes not to provide anything.
+ */
+static int crypto_kdf_dpi_random(struct crypto_rng *rng,
+const u8 *src, unsigned int slen,
+u8 *dst, unsigned int dlen)
+{
+   struct crypto_kdf_ctx *ctx = crypto_tfm_ctx(crypto_rng_tfm(rng));
+   struct shash_desc *desc = >shash;
+   unsigned int h = crypto_shash_digestsize(desc->tfm);
+   unsigned int alignmask