On Mon, 2017-05-22 at 19:09 +0200, Niels Möller wrote: > > 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.
Do you see the gitlab notifications about broken builds? An approach to avoid broken builds in master, may be to wait for a successful build prior to committing to master. For example committing to a branch first and waiting for the gitlab.com mirror sync and the CI results. The above process would be easier to handle that if you use switch to using merge requests for contribution. That of course would require moving to gitlab.com or enabling CI pipelines in git.lysator.liu.se (assuming it provides some CI runners). I've put my updates at a merge request on my mirror repo, to see how that it would look: https://gitlab.com/nmav/nettle/merge_requests/1 (notice that the previous failure in CI compilation is now apparent, and in the 'Changes' tab it is possible to comment inline in changes) > > +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? It may but HKDF is only defined with HMAC. > > +@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) I follow the convention in the pbkdf2() function. There the digest_size is part of the hash parameters passed. One could add an additional parameter for digest_size to allow getting a smaller prk. I didn't see the reason for it as the PRK is used as is in the expand operation. I could add it if needed, but as you said if one wants a smaller value he can use the hmac operation directly. That is a helper function for directly mapping the functionality needed for HKDF. > > 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). [...] > > +@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)? I'm not sure what you mean. The relation is defined in HKDF document, though upper protocols like tls 1.3 may utilize these in arbitrary ways. Nettle provides the implementation of the primitives. > > 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? I have no immediate plans for that. regards, Nikos _______________________________________________ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
