Nikos Mavrogiannopoulos <[email protected]> writes: > Here are the patches for HKDF only updated with the above approach (and > a sanity check for length).
Thanks, we're getting closer! > That patch set also includes a tweak to .gitlab-ci.yml for CI to work > without attempting to regenerate the testsuite make rules. Ouch, I think that indicates a real problem with the change I made, a ./configure && make && make check build will now always remake the .test-rules.make file, because it depends on Makefile, which obviously is modified by configure. That's pretty bad. I think I saw a problem with having it depend only on Makefile.in, I have to investigate and probably change back. > --- /dev/null > +++ b/hkdf.c > @@ -0,0 +1,85 @@ > +/* > + * Copyright (C) 2017 Red Hat, Inc. > + * > + * Author: Nikos Mavrogiannopoulos > + * > + * This file is part of GnuTLS. > + * > + * The GnuTLS is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public License > + * as published by the Free Software Foundation; either version 2.1 of > + * the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, but > + * WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public License > + * along with this program. If not, see <http://www.gnu.org/licenses/> > + * > + */ This file carries a GnuTLS copyright notice rather than the Nettle copyright notice used in most other files. I guess that's unintentional? Indentation in the rest of this file is also using a very different style than the rest of Nettle. > --- a/nettle.texinfo > +++ b/nettle.texinfo ... > +The key derivation function used in TLS 1.3 is HKDF, described > +in @cite{RFC 5869}, and is a derivation function based on HMAC. > + > +Nettle's @acronym{HKDF} functions are defined in > +@file{<nettle/hkdf.h>}. There are two abstract functions for extract > +and expand operations that operate on any HMAC implemented via the > @code{nettle_hash_update_func}, > +@code{nettle_hash_digest_func} interfaces. It's intended for HMAC, but it should work with any keyed hash function, aka MAC, right? > +@deftypefun void hkdf_extract (void *mac_ctx, nettle_hash_update_func > *update, nettle_hash_digest_func *digest, size_t digest_size,size_t > secret_size, const uint8_t *secret, uint8_t *dst) The Nettle convention for arguments is length, pointer, so I think it should be hkdf_extract(void *mac_ctx, nettle_hash_update_func *update, nettle_hash_digest_func *digest, size_t secret_size, const uint8_t *secret, size_t digest_size, uint8_t *digest) > +Extract a Pseudorandom Key (PRK) from a secret and a salt according > +to HKDF. The HMAC must have been initialized, with its key being the > +salt for the Extract operation. I find the terminology a bit confusing. There's "salt", "key", and "secret". If I get this right, what hkdf calls "salt" is used as the key for the underlying MAC? I think it would be good with an introductory paragraph explaining how these fit together and defining the terminology, and then the documentation for the actual functions wouldn't need to explain it. > This function will call the > +@var{update} and @var{digest} functions passing the @var{mac_ctx} > +context parameter as an argument in order to compute digest of size > +@var{digest_size}. Inputs are the secret @var{secret} of length > +@var{secret_length}. The output length is fixed to @var{digest_size} octets, > +thus the output buffer @var{dst} must have room for at least > @var{digest_size} octets. > +@end deftypefun I think it's confusing to say that the output length is "fixed". Do you mean that digest_size must be the same as the digest size of the underlying MAC algorithm? Or may it be smaller, like for most other *_digest methods in Nettle? To me, it seems reasonable to support smaller values, but write that to conform with the spec, output length must equal the underlying digest size (if that's what the spec says). (And I still find the utility of this function a bit questionable). > +@deftypefun void hkdf_expand (void *mac_ctx, nettle_hash_update_func > *update, nettle_hash_digest_func *digest, size_t digest_size, size_t > info_size, const uint8_t *info, size_t length, uint8_t *dst) > +Expand a Pseudorandom Key (PRK) to an arbitrary size according to HKDF. > +The HMAC must have been initialized, with its key being the > +PRK from the Extract operation. Is it required that hkdf_extract is used in some way to produce the key for hkdf_expand? Then I think the relation between _extract and _expand needs to be clarified. Would you always have the same number of calls to _extract and _expand, or could do _extract once and _expand multiple times (with different info string)? > This function will call the > +@var{update} and @var{digest} functions passing the @var{mac_ctx} > +context parameter as an argument in order to compute digest of size > +@var{digest_size}. Inputs are the info @var{info} of length > +@var{info_length}, and the desired derived output length @var{length}. > +The output buffer is @var{dst} which must have room for at least > @var{length} octets. > +@end deftypefun Do you intend to add specific functions like hkdf_hmac_sha256_expand(...) too? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
