Daiki Ueno <[email protected]> writes:
> Makefile.in | 4 +-
> nettle-internal.h | 2 +-
> nettle-meta-hashes.c | 2 +
> nettle-meta.h | 2 +
> nettle.texinfo | 68 +
> sha3.c | 13 +
> sha3.h | 56 +
> shake128-meta.c | 42 +
> shake128.c | 84 +
> shake256-meta.c | 42 +
> shake256.c | 84 +
> testsuite/.test-rules.make | 6 +
> testsuite/Makefile.in | 1 +
> testsuite/meta-hash-test.c | 2 +
> testsuite/shake.awk | 14 +
> testsuite/shake128-test.c | 6183
> ++++++++++++++++++++++++++++++++++++++++++++
> testsuite/shake256-test.c | 6183
> ++++++++++++++++++++++++++++++++++++++++++++
> testsuite/testutils.c | 43 +-
> 18 files changed, 12812 insertions(+), 19 deletions(-)
> create mode 100644 shake128-meta.c
> create mode 100644 shake128.c
> create mode 100644 shake256-meta.c
> create mode 100644 shake256.c
> create mode 100755 testsuite/shake.awk
> create mode 100644 testsuite/shake128-test.c
> create mode 100644 testsuite/shake256-test.c
This is a contribution that is mostly independent of the rest of the
curve448 patches.
> diff --git a/nettle-meta-hashes.c b/nettle-meta-hashes.c
> index 2220968c..1cd7f677 100644
> --- a/nettle-meta-hashes.c
> +++ b/nettle-meta-hashes.c
> @@ -50,5 +50,7 @@ const struct nettle_hash * const nettle_hashes[] = {
> &nettle_sha3_256,
> &nettle_sha3_384,
> &nettle_sha3_512,
> + &nettle_shake128,
> + &nettle_shake256,
> NULL
> };
Does it make sense to group shake (wich is a "xof") to the hash
functions? I think we could skip the -meta things for now, and design an
interface for xof-like functions later.
> +@subsubsection @acronym{SHAKE128}
> +
> +In addition to those SHA-3 hash functions, Nettle also provides two
> +SHA-3 extendable-output functions (XOFs). Unlike SHA-3 hash functions,
> +the output of SHA-3 XOFs can be extended to any desired length.
Maybe some reference to the section on key derivation functions would be
helpful, since they serve a similar purpose.
> +Nettle defines SHAKE128 in @file{<nettle/sha3.h>}.
> +
> +@deftp {Context struct} {struct shake128_ctx}
> +@end deftp
> +
> +@defvr Constant SHAKE128_DIGEST_SIZE
> +The size of a SHAKE128 digest, i.e. 64.
> +@end defvr
Does it make sense at all to define a digest size?
> +@deftypefun void shake128_digest (struct shake128_ctx *@var{ctx}, size_t
> @var{length}, uint8_t *@var{digest})
> +Performs final processing and extracts the message digest, writing it
> +to @var{digest}. @var{length} may be smaller than
> +@code{SHAKE128_DIGEST_SIZE}, in which case only the first @var{length}
> +octets of the digest are written.
Isn't the point to allow arbitrary "digest size", which is perhaps
better called "output size"?
In case it makes sense to use a very long digest size, e.g., using shake
as a stream cipher, should we provide some method to get the output
incrementally, one or more blocks at a time?
> +void
> +_sha3_shake_pad (struct sha3_state *state,
> + unsigned block_size, uint8_t *block, unsigned pos)
> +{
> + assert (pos < block_size);
> + block[pos++] = 0x1F;
> +
> + memset (block + pos, 0, block_size - pos);
> + block[block_size - 1] |= 0x80;
> +
> + sha3_absorb (state, block_size, block);
> +}
Difference to _sha3_pad is the magic constant 0x1f, instead of 6? Maybe
add the padding value as an argument to _sha3_pad, rather than
introducing a new function? The function is not part of the supported
api, and from a search at
https://codesearch.debian.net/search?q=_sha3_pad, it's seems it's also
not used outside of nettle.
> +#define SHAKE128_DIGEST_SIZE 0 /* not used */
I think it's better to not define _DIGEST_SIZE at all.
> +#define SHAKE128_BLOCK_SIZE 168
How is the block size motivated? It gives roughly same security as what
sha3-128 would give, i.e., "64 bit security" against collisions, and
"128 bit security" against second preimage? It seems to affect both
processing of input and output.
> +struct shake256_ctx
> +{
> + struct sha3_state state;
> + unsigned index;
> + uint8_t block[SHAKE256_BLOCK_SIZE];
> +};
This is identical to sha3_256_ctx, right? Would it make sense to use the
same context, but with a separate function to be used instead of
sha3_256_digest? Both _init and _update are also identical, if I'm not
missing something. Could be called sha3_256_shake or sha3_256_xof or
something like that? Maybe one function to produce all output and reset
the context, and a separate function or functions to produce output
incrementally?
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
