Am Dienstag, 26. Januar 2016, 18:28:14 schrieb Herbert Xu:
Hi Herbert,
>On Tue, Jan 26, 2016 at 07:20:59AM +0100, Stephan Mueller wrote:
>> +/*
>> + * Implementation of the KDF in counter mode according to SP800-108
>> section 5.1. + *
>> + * 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_ctr_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 = &ctx->shash;
>> + unsigned int h = crypto_shash_digestsize(desc->tfm);
>> + int err = 0;
>> + u8 *dst_orig = dst;
>> + u32 i = 1;
>> + u8 iteration[sizeof(u32)];
>> +
>> + /* enforce the note from above */
>> + if (dlen != h && src == dst)
>> + return -EINVAL;
>
>Why is this an RNG? It always produces exactly h bytes so it looks
>like a hash function to me, no?
It generates an arbitrary number of bytes like an RNG -- see dlen. The check
you quote here is only for the special case where the caller wants exactly h
bytes where he can have an in-place cipher operation.
When he wants to generate more data, then we cannot have dst and src pointing
to the same location. We have multiple loops we always require the use of the
original src data. Thus, when we have multiple loops, src would be overwritten
in the first loop iteration which means that with the second loop iteration,
we would not be compliant to the spec any more.
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
