Re: nettle: PACBTI for arm64 assembly
Bill Roberts writes: > Do you have this on a remote I can pull from? I've filed an MR at: https://git.lysator.liu.se/nettle/nettle/-/merge_requests/65 Regards, -- Daiki Ueno ___ nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se To unsubscribe send an email to nettle-bugs-le...@lists.lysator.liu.se
nettle: PACBTI for arm64 assembly
Hello,
The attached is my attempt to enable PAC/BTI[1] support for AArch64. As
the Nettle assembly files only define leaf functions (i.e., no
subroutine calls with LR/SP save/restore), PAC is not applicable and
thus only BTI is enabled for now.
To test, I used the mock[2] environment with the fedora-40-aarch64
configuration:
$ mock -r fedora-40-aarch64 --init
sh-5.2# ./.bootstrap
sh-5.2# ./configure --disable-documentation
CFLAGS="-mbranch-protection=standard"
sh-5.2# make -j$(nproc)
sh-5.2# readelf -n libnettle.so
Displaying notes found in: .note.gnu.property
OwnerData size Description
GNU 0x0010 NT_GNU_PROPERTY_TYPE_0
Properties: AArch64 feature: BTI, PAC
...
Regards,
Footnotes:
[1] https://wiki.debian.org/ToolChain/PACBTI
[2] https://fedoraproject.org/wiki/Using_Mock_to_test_package_builds
--
Daiki Ueno
>From bad675b345897fc248e0dc7261c3dd9f51b5c0d2 Mon Sep 17 00:00:00 2001
From: Daiki Ueno
Date: Mon, 15 Jul 2024 11:22:09 +0900
Subject: [PATCH] build: Support PACBTI in AArch64 assembly
This adds support for the branch protection mechanism provided in
64-bit Arm architecture, namely:
- Armv8.3-A Pointer Authentication (PAC)
- Armv8.5-A Branch Target Identification (BTI)
Note that PAC is currently unused in the assembly files as they only
define leaf functions wrapped by the corresponding C functions, which
will be instrumented by the compiler.
Signed-off-by: Daiki Ueno
---
asm.m4 | 2 +-
config.m4.in | 7 +++
configure.ac | 121 ++-
3 files changed, 117 insertions(+), 13 deletions(-)
diff --git a/asm.m4 b/asm.m4
index 2bb1068c..f9751608 100644
--- a/asm.m4
+++ b/asm.m4
@@ -30,7 +30,7 @@ define(`GMP_NUMB_BITS',`')dnl
define(`PROLOGUE',
`.globl C_NAME($1)
DECLARE_FUNC(C_NAME($1))
-C_NAME($1): ASM_X86_ENDBR')
+C_NAME($1): ASM_X86_ENDBR`'ASM_ARM64_BTI_C')
define(`EPILOGUE',
`ifelse(ELF_STYLE,yes,
diff --git a/config.m4.in b/config.m4.in
index b98a5817..e96fa6cb 100644
--- a/config.m4.in
+++ b/config.m4.in
@@ -12,7 +12,14 @@ define(`WORDS_BIGENDIAN', `@ASM_WORDS_BIGENDIAN@')dnl
define(`ASM_X86_ENDBR',`@ASM_X86_ENDBR@')dnl
define(`ASM_X86_MARK_CET_ALIGN',`@ASM_X86_MARK_CET_ALIGN@')dnl
define(`ASM_PPC_WANT_R_REGISTERS',`@ASM_PPC_WANT_R_REGISTERS@')dnl
+define(`ASM_ARM64_BTI_C',`@ASM_ARM64_BTI_C@')dnl
+define(`ASM_ARM64_SIGN_LR',`@ASM_ARM64_SIGN_LR@')dnl
+define(`ASM_ARM64_AUTH_LR',`@ASM_ARM64_AUTH_LR@')dnl
+define(`ASM_ARM64_PROPERTY_BTI',`@ASM_ARM64_PROPERTY_BTI@')dnl
+define(`ASM_ARM64_PROPERTY_PAC',`@ASM_ARM64_PROPERTY_PAC@')dnl
+define(`ASM_ARM64_MARK_PACBTI',`@ASM_ARM64_MARK_PACBTI@')dnl
divert(1)
@ASM_X86_MARK_CET@
+@ASM_ARM64_MARK_PACBTI@
@ASM_MARK_NOEXEC_STACK@
divert
diff --git a/configure.ac b/configure.ac
index 7ae99f25..99c26085 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1012,6 +1012,16 @@ EOF
ASM_ALIGN_LOG="$nettle_cv_asm_align_log"
fi
+AC_CACHE_CHECK([if .note.gnu.property section is needed],
+ [nettle_cv_asm_gnu_property],
+ [AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
+#if !defined __ELF__
+#error GNU property is not needed
+#endif
+]], [[]])],
+ [nettle_cv_asm_gnu_property=yes],
+ [nettle_cv_asm_gnu_property=no])])
+
dnl Define
dnl 1. ASM_X86_ENDBR for endbr32/endbr64.
dnl 2. ASM_X86_MARK_CET to add a .note.gnu.property section to mark
@@ -1041,19 +1051,8 @@ if test "$nettle_cv_asm_x86_intel_cet" = yes; then
ASM_X86_MARK_CET_ALIGN=2
;;
esac
- AC_CACHE_CHECK([if .note.gnu.property section is needed],
-[nettle_cv_asm_x86_gnu_property],
-[AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
-#if !defined __ELF__ || !defined __CET__
-#error GNU property is not needed
-#endif
-]], [[]])],
- [nettle_cv_asm_x86_gnu_property=yes],
- [nettle_cv_asm_x86_gnu_property=no])])
-else
- nettle_cv_asm_x86_gnu_property=no
fi
-if test "$nettle_cv_asm_x86_gnu_property" = yes; then
+if test "$nettle_cv_asm_gnu_property" = yes && test "$nettle_cv_asm_x86_intel_cet" = yes; then
ASM_X86_MARK_CET='
.pushsection ".note.gnu.property", "a"
.p2align ASM_X86_MARK_CET_ALIGN
@@ -1074,6 +1073,98 @@ if test "$nettle_cv_asm_x86_gnu_property" = yes; then
.popsection'
fi
+dnl Define
+dnl 1. ASM_ARM64_BTI_C for BTI.
+dnl 2. ASM_ARM64_{SIGN,AUTH}_LR for PAC, currently unused.
+dnl 3. ASM_ARM64_MARK_PACBTI to add a .note.gnu.property section to mark
+dnl support for:
+dnl- Armv8.3-A Pointer Authentication and
+dnl- Armv8.5-A Branch Target Identification
+dnl if needed.
+AC_CACHE_CHECK([if Armv8.5-A BTI is enabled],
+ [nettle_cv_asm_arm64_bti],
+ [AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
+#if !(defined __ARM_FEATURE_BTI_DEFAULT && __ARM_FEATURE_B
Re: Nettle release plans
Hello Niels, Niels Möller writes: > I'm thinking about Nettle releases. I think it would be nice to get out > a maintenance 3.10 release before summer vacations. (current NEWS file > at https://git.lysator.liu.se/nettle/nettle/-/blob/master/NEWS is fairly > accurate). That would be awesome. > After that, there are two different directions: > > * Try to clean up some of the API issues. This will break the API > (and like for previous changes, it could make sense to add > foo-compat.h include files that supports old API, to make it easy to > upgrade an application to work with the new nettle version, while > incrementally adjusting to the new api). It may also break > ABI and imply an soname change, or we could keep old symbols > working for the case of old applications linking to new libnettle.so > (but not the other way round, as documented at > https://www.lysator.liu.se/~nisse/nettle/nettle.html#Compatibility). > If we go this way, that would be a Nettle-4.0, and it would make sense > to me to try to get that done without much new features, and without > making it a huge long-term project. I have a bit of concern, if an application links to nettle, but also bundles some parts of it to support lower nettle versions, that would make it difficult to import the code[1] as it would require pulling in dependent files. That said, none of the issues marked as "API change" on the issue tracker looks too disruptive to me (maybe #2 and #5 are): https://git.lysator.liu.se/nettle/nettle/-/issues/?label_name%5B%5D=API%20change Do you have anything else in your mind? > * Focus on getting post-quantum algorithms into Nettle. From GnuTLS perspective, it would be helpful if there is support for at least one post-quantum KEM algorithm so it could make TLS handshake provide quantum safety and forward secrecy (with PSK). Signature algorithms could be done later. Regards, Footnotes: [1] https://gitlab.com/gnutls/gnutls/-/blob/master/devel/import-from-nettle.sh -- Daiki Ueno ___ nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se To unsubscribe send an email to nettle-bugs-le...@lists.lysator.liu.se
Re: Deterministic (EC)DSA
Niels Möller writes: > Daiki Ueno writes: > >> I agree, that's a valid use-case. Perhaps this might suffice: >> >> /* Sign DIGEST with KEY using deterministic nonce generation. >>* >>* DIGEST must be of the same length of SHA-256 output, that is 32 >>* octets long. */ >> void >> ecdsa_sha256_sign_deterministic (const struct ecc_scalar *key, >>const uint8_t *digest, >>struct dsa_signature *signature); > > Looks good to me. Underlying more general helper functions > (however they are organized) can be internal only. I've updated the MR along these lines. Regards, -- Daiki Ueno ___ nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se To unsubscribe send an email to nettle-bugs-le...@lists.lysator.liu.se
Re: Deterministic (EC)DSA
Niels Möller writes: > Daiki Ueno writes: > >> I have a slight feeling that the current API is not easy to use, as the >> caller needs to instantiate both hash and HMAC contexts, as there are no >> correlations between the two: > > On a more abstract level, are there any reasonable usecases for having > one hash function for processing the message, and a different underlying > hash function for the hmac used to produce the deterministic nonce? Not that I know of. The RFC mandates the same hash function to be used in both for processing the message and generating a nonce. >> What would you say to introducing a specialized API, something like the >> following? >> >> void >> ecdsa_sha256_sign_deterministic (const struct ecc_scalar *key, >>size_t length, >>const uint8_t *message, >>struct dsa_signature *signature); > > I think that could sense, but we also need an advertised api function > that takes the digest as input, for applications that want to process > the message using multiple _update calls. I agree, that's a valid use-case. Perhaps this might suffice: /* Sign DIGEST with KEY using deterministic nonce generation. * * DIGEST must be of the same length of SHA-256 output, that is 32 * octets long. */ void ecdsa_sha256_sign_deterministic (const struct ecc_scalar *key, const uint8_t *digest, struct dsa_signature *signature); Regards, -- Daiki Ueno ___ nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se To unsubscribe send an email to nettle-bugs-le...@lists.lysator.liu.se
Re: Deterministic (EC)DSA
Niels Möller writes: > Daiki Ueno writes: > >> The attached patch adds support for the deterministic DSA and ECDSA, as >> defined in RFC 6979, which enables us to use the signing function >> without randomness. > > Thanks, I've had a first read, and added some comments on your MR > (https://git.lysator.liu.se/nettle/nettle/-/merge_requests/64). Thank you; I updated the MR to address those comments. I have a slight feeling that the current API is not easy to use, as the caller needs to instantiate both hash and HMAC contexts, as there are no correlations between the two: struct sha256_ctx sha256; sha256_init (&sha256); sha256_update (&sha256, length, message); sha256_digest (&sha256, SHA256_DIGEST_SIZE, digest); struct hmac_sha256_ctx hmac_sha256; ecdsa_sign_deterministic (&key, &hmac_sha256, &nettle_hmac_sha256, digest, &sig); What would you say to introducing a specialized API, something like the following? void ecdsa_sha256_sign_deterministic (const struct ecc_scalar *key, size_t length, const uint8_t *message, struct dsa_signature *signature); Regards, -- Daiki Ueno ___ nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se To unsubscribe send an email to nettle-bugs-le...@lists.lysator.liu.se
Deterministic (EC)DSA
Hello, The attached patch adds support for the deterministic DSA and ECDSA, as defined in RFC 6979, which enables us to use the signing function without randomness. The original code has been hosted in GnuTLS for a while, implemented as a custom random function which can be used in combination with dsa_sign and ecdsa_sign. While this approach works in general, it requires pre/post processing: e.g., access to ECC q[1] and cancelling out the Nettle's tweak in dsa_sign adding 1[2] to the random value. Therefore, I would rather like this to be included in Nettle itself. Note also that this implementation should be identical to the latest code in GnuTLS, which addresses the Minerva attack[3]. The same patch is also available at GitLab: https://git.lysator.liu.se/nettle/nettle/-/merge_requests/64 Footnotes: [1] https://gitlab.com/gnutls/gnutls/-/blob/c1428c07d406f18cca94f94e2b7ca1f866df42d9/lib/nettle/int/ecdsa-compute-k.c#L32 [2] https://gitlab.com/gnutls/gnutls/-/blob/c1428c07d406f18cca94f94e2b7ca1f866df42d9/lib/nettle/int/dsa-compute-k.c#L212 [3] https://nvd.nist.gov/vuln/detail/CVE-2024-28834 Regards, -- Daiki Ueno >From 0b9860dfa63becdc2e2d8468889c35a2991c0329 Mon Sep 17 00:00:00 2001 From: Daiki Ueno Date: Sun, 14 Apr 2024 09:05:19 +0900 Subject: [PATCH] Add support for deterministic DSA and ECDSA This implements deterministic nonce construction for DSA and ECDSA, as defined in RFC 6979. Signed-off-by: Daiki Ueno --- Makefile.in | 5 +- dsa-compute-k.c | 173 +++ dsa-compute-k.h | 49 dsa-sign.c | 65 ++ dsa.h| 9 ++ ecdsa-sign.c | 26 ecdsa.h | 10 ++ gmp-glue.h | 5 +- nettle-internal.h| 1 + testsuite/.gitignore | 2 + testsuite/Makefile.in| 3 +- testsuite/deterministic-dsa-test.c | 96 +++ testsuite/deterministic-ecdsa-test.c | 82 + 13 files changed, 522 insertions(+), 4 deletions(-) create mode 100644 dsa-compute-k.c create mode 100644 dsa-compute-k.h create mode 100644 testsuite/deterministic-dsa-test.c create mode 100644 testsuite/deterministic-ecdsa-test.c diff --git a/Makefile.in b/Makefile.in index 29ad54d7..227c459a 100644 --- a/Makefile.in +++ b/Makefile.in @@ -225,7 +225,8 @@ hogweed_SOURCES = sexp.c sexp-format.c \ ed25519-sha512.c ed25519-sha512-pubkey.c \ ed25519-sha512-sign.c ed25519-sha512-verify.c \ ed448-shake256.c ed448-shake256-pubkey.c \ - ed448-shake256-sign.c ed448-shake256-verify.c + ed448-shake256-sign.c ed448-shake256-verify.c \ + dsa-compute-k.c OPT_SOURCES = fat-arm.c fat-arm64.c fat-ppc.c fat-s390x.c fat-x86_64.c mini-gmp.c @@ -278,7 +279,7 @@ DISTFILES = $(SOURCES) $(HEADERS) getopt.h getopt_int.h \ ctr-internal.h chacha-internal.h sha3-internal.h \ salsa20-internal.h umac-internal.h hogweed-internal.h \ rsa-internal.h pkcs1-internal.h dsa-internal.h eddsa-internal.h \ - gmp-glue.h ecc-internal.h fat-setup.h oaep.h \ + gmp-glue.h ecc-internal.h fat-setup.h oaep.h dsa-compute-k.h \ mini-gmp.h asm.m4 m4-utils.m4 \ nettle.texinfo nettle.info nettle.html nettle.pdf sha-example.c diff --git a/dsa-compute-k.c b/dsa-compute-k.c new file mode 100644 index ..28b4f6d5 --- /dev/null +++ b/dsa-compute-k.c @@ -0,0 +1,173 @@ +/* dsa-compute-k.c + + The DSA publickey algorithm, deterministic nonce construction (RFC 6979). + + Copyright (C) 2019-2024 Red Hat, Inc. + + This file is part of GNU Nettle. + + GNU Nettle is free software: you can redistribute it and/or + modify it under the terms of either: + + * the GNU Lesser General Public License as published by the Free + Software Foundation; either version 3 of the License, or (at your + option) any later version. + + or + + * the GNU General Public License as published by the Free + Software Foundation; either version 2 of the License, or (at your + option) any later version. + + or both in parallel, as here. + + GNU Nettle 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 + General Public License for more details. + + You should have received copies of the GNU General Public License and + the GNU Lesser General Public License along with this program. If + not, see http://www.gnu.org/licenses/. +*/ + +#if HAVE_CONFIG_H +# include "config.h" +#endif + +#include "dsa-compute-k.h" + +#include "gmp-glue.h" +#include "nettle-internal.h" +#include + +#define MIN(a,b) (((a) < (b)) ? (a) : (b)) + +void +_dsa_compute_k (mp_limb_t *k, const mp_limb_t *q, const mp_limb_t *x, + mp_bitcnt_t
Re: additional API for SHAKE streaming read
Hello Niels,
Thank you for the feedback.
Niels Möller writes:
>> -@subsubsection @acronym{SHAKE-256}
>> +@subsubsection @acronym{SHAKE-128}
>> @cindex SHAKE
>
> I think heading should be just "shake".
Done.
>> -In addition to those SHA-3 hash functions, Nettle also provides a SHA-3
>> -extendable-output function (XOF), SHAKE-256. Unlike SHA-3 hash functions,
>> -SHAKE can produce an output digest of any desired length.
>> +In addition to those SHA-3 hash functions, Nettle also provides a
>> +SHA-3 extendable-output function (XOF) called SHAKE. Unlike hash
>> +functions, SHAKE can produce an output digest of any desired
>> +length. There are two variants, SHAKE-128 and SHAKE-256, with
>> +different security strengths in terms of collision or preimage
>> +resistance.
>> +
>> +SHAKE-128 internally uses a SHA-3 hash function with 128-bit security
>> +strength against second preimage attacks. The hash function is not
>> +usable alone with Nettle, only for the use with SHAKE-128.
>
> I think it would be good to write in the intro that shake-256
> corresponds to sha3-256, while shake-128 uses sha3 with parameters
> corresponding to 128-bit security, for which there's no corresponding
> plain hash function defined.
>
> It might also make sense to explain the difference between _shake and
> _shake_output functions here, and make the description under each
> function a bit shorter.
Yes, I've consolidated the description and put it at the introduction.
Regards,
--
Daiki Ueno
>From 36da108f985c23d82358b7433f320665896ba5dc Mon Sep 17 00:00:00 2001
From: Daiki Ueno
Date: Thu, 11 Apr 2024 17:51:39 +0900
Subject: [PATCH v2] Update documentation for SHAKE
Signed-off-by: Daiki Ueno
---
nettle.texinfo | 69 --
1 file changed, 56 insertions(+), 13 deletions(-)
diff --git a/nettle.texinfo b/nettle.texinfo
index 95e89971..484480ca 100644
--- a/nettle.texinfo
+++ b/nettle.texinfo
@@ -755,28 +755,71 @@ octets of the digest are written.
This function also resets the context.
@end deftypefun
-@subsubsection @acronym{SHAKE-256}
+@subsubsection @acronym{SHAKE}
@cindex SHAKE
-In addition to those SHA-3 hash functions, Nettle also provides a SHA-3
-extendable-output function (XOF), SHAKE-256. Unlike SHA-3 hash functions,
-SHAKE can produce an output digest of any desired length.
+In addition to those SHA-3 hash functions, Nettle also supports a
+SHA-3 extendable-output function (XOF) called SHAKE. Unlike hash
+functions, SHAKE can produce an output digest of any desired
+length. There are two variants, SHAKE-128 and SHAKE-256, with
+different security strengths in terms of collision or preimage
+resistance: SHAKE-128 internally uses a SHA-3 hash function with
+128-bit security, while SHAKE-256 corresponds to SHA3-256 which
+provides 256-bit security.
+
+To use SHAKE, the context struct needs to be initialized with the
+@code{init} function and data is hashed using the @code{update}
+function. Afterwards, a digest can be generated using either the
+@code{shake} or @code{shake_ouput} function, where the former
+generates the digest at once and resets the context, while the latter
+can be called multiple times to generate the digest in an incremental
+manner.
+
+For SHAKE-128 they are defined as follows.
+
+@deftp {Context struct} {struct sha3_128_ctx}
+@end deftp
+
+@deftypefun void sha3_128_init (struct sha3_128_ctx *@var{ctx})
+Initialize the SHA3-256 state.
+@end deftypefun
+
+@deftypefun void sha3_128_update (struct sha3_128_ctx *@var{ctx}, size_t @var{length}, const uint8_t *@var{data})
+Hash some more data.
+@end deftypefun
+
+@deftypefun void sha3_128_shake (struct sha3_128_ctx *@var{ctx}, size_t @var{length}, uint8_t *@var{digest})
+Performs final processing and produces a SHAKE-128 digest, writing it
+to @var{digest}. @var{length} can be of arbitrary size.
+
+This function also resets the context.
+@end deftypefun
+
+@deftypefun void sha3_128_shake_output (struct sha3_128_ctx *@var{ctx}, size_t @var{length}, uint8_t *@var{digest})
+Performs final processing and produces a SHAKE-128 digest, writing it
+to @var{digest}. @var{length} can be of arbitrary size.
+
+This function does not reset the context.
+@end deftypefun
-To use SHAKE256, the context struct, init and update functions are the
-same as for SHA3-256. To get a SHAKE256 digest, the following function
-is used instead of @code{sha3_256_digest}. For an output size of
-@code{SHA3_256_DIGEST_SIZE}, security is equivalent to SHA3-256 (but the
-digest is different). Increasing output size further does not increase
-security in terms of collision or preimage resistance. It can be seen as
-a built in pseudorandomness generator.
+For SHAKE-256, the corresponding context struct and the @code{init}
+and @code{update} functions are the same as SHA3-256. To gen
Re: additional API for SHAKE streaming read
Sorry for the late response.
Niels Möller writes:
>>> 2. Implement shake128.
>>
>> I've extracted it from the ML-KEM merge request and put it here:
>> https://git.lysator.liu.se/nettle/nettle/-/merge_requests/63
>>
>> Not sending via email as it includes a huge test vector.
>
> Thanks, merged to the sha3-shake-updates branch. Sorry if you didn't
> intend me to do that right away (I noticed some minor problems after
> merge, which I've fixed). I'd like to merge to master after ci runs have
> completed.
Thank you for merging it (with the fixes); I wasn't actually aware of
the problems.
>>> 3. Update docs.
>>
>> I can do that once we settle the interface.
>
> Excellent. To me, interface in sha3.h now looks good.
I'm attaching a patch to update the documentation.
Regards,
--
Daiki Ueno
>From da9c6bea06043d37c895233ca35d5b9c7fb029b5 Mon Sep 17 00:00:00 2001
From: Daiki Ueno
Date: Thu, 11 Apr 2024 17:51:39 +0900
Subject: [PATCH] Update documentation for SHAKE
Signed-off-by: Daiki Ueno
---
nettle.texinfo | 67 --
1 file changed, 59 insertions(+), 8 deletions(-)
diff --git a/nettle.texinfo b/nettle.texinfo
index 95e89971..85a3a6b5 100644
--- a/nettle.texinfo
+++ b/nettle.texinfo
@@ -755,28 +755,79 @@ octets of the digest are written.
This function also resets the context.
@end deftypefun
-@subsubsection @acronym{SHAKE-256}
+@subsubsection @acronym{SHAKE-128}
@cindex SHAKE
-In addition to those SHA-3 hash functions, Nettle also provides a SHA-3
-extendable-output function (XOF), SHAKE-256. Unlike SHA-3 hash functions,
-SHAKE can produce an output digest of any desired length.
+In addition to those SHA-3 hash functions, Nettle also provides a
+SHA-3 extendable-output function (XOF) called SHAKE. Unlike hash
+functions, SHAKE can produce an output digest of any desired
+length. There are two variants, SHAKE-128 and SHAKE-256, with
+different security strengths in terms of collision or preimage
+resistance.
+
+SHAKE-128 internally uses a SHA-3 hash function with 128-bit security
+strength against second preimage attacks. The hash function is not
+usable alone with Nettle, only for the use with SHAKE-128.
+
+Nettle defines context struct, init and update functions in
+@file{}.
+
+@deftp {Context struct} {struct sha3_128_ctx}
+@end deftp
+
+@deftypefun void sha3_128_init (struct sha3_128_ctx *@var{ctx})
+Initialize the SHA3-256 state.
+@end deftypefun
+
+@deftypefun void sha3_128_update (struct sha3_128_ctx *@var{ctx}, size_t @var{length}, const uint8_t *@var{data})
+Hash some more data.
+@end deftypefun
+
+After all data is fed into the context, the following functions can be
+used to generate the output.
+
+@deftypefun void sha3_128_shake (struct sha3_128_ctx *@var{ctx}, size_t @var{length}, uint8_t *@var{digest})
+Performs final processing and produces a SHAKE-128 digest, writing it
+to @var{digest}. @var{length} can be of arbitrary size.
-To use SHAKE256, the context struct, init and update functions are the
-same as for SHA3-256. To get a SHAKE256 digest, the following function
+This function also resets the context.
+@end deftypefun
+
+@deftypefun void sha3_128_shake_output (struct sha3_128_ctx *@var{ctx}, size_t @var{length}, uint8_t *@var{digest})
+Performs final processing and produces a SHAKE-128 digest, writing it
+to @var{digest}. @var{length} can be of arbitrary size.
+
+Unlike @code{sha3_128_shake}, this function doesn't reset the context
+and thus can be called multiple times to retrieve output in an
+incremental manner.
+@end deftypefun
+
+@subsubsection @acronym{SHAKE-256}
+
+To use SHAKE-256, the context struct, init and update functions are the
+same as for SHA3-256. To get a SHAKE-256 digest, the following function
is used instead of @code{sha3_256_digest}. For an output size of
@code{SHA3_256_DIGEST_SIZE}, security is equivalent to SHA3-256 (but the
digest is different). Increasing output size further does not increase
security in terms of collision or preimage resistance. It can be seen as
a built in pseudorandomness generator.
-@deftypefun void sha3_256_shake (struct shake256_ctx *@var{ctx}, size_t @var{length}, uint8_t *@var{digest})
-Performs final processing and produces a SHAKE256 digest, writing it
+@deftypefun void sha3_256_shake (struct sha3_256_ctx *@var{ctx}, size_t @var{length}, uint8_t *@var{digest})
+Performs final processing and produces a SHAKE-256 digest, writing it
to @var{digest}. @var{length} can be of arbitrary size.
This function also resets the context.
@end deftypefun
+@deftypefun void sha3_256_shake_output (struct sha3_256_ctx *@var{ctx}, size_t @var{length}, uint8_t *@var{digest})
+Performs final processing and produces a SHAKE-256 digest, writing it
+to @var{digest}. @var{length} can be of arbitrary size.
+
+Unlike @code{sha3_256_shake}, this function doesn't rese
Re: additional API for SHAKE streaming read
Niels Möller writes:
> Niels Möller writes:
>
>> I'll try to clean up and post or commit some of my changes, I'm sorry
>> that will cause some conflicts.
>
> I've pushed my changes to a branch sha3-shake-updates, does that look
> reasonable to you? If so, I think the next steps are
Yes, that looks good to me, except _nettle_sha3_shake has a
copy-and-paste error where SHA3_256_BLOCK_SIZE is hard-coded.
> 1. Decide what should be renamed sha3_shake256_*
I guess we can live with the existing interface. For SHAKE128, we could
only provide sha3_128_init, sha3_128_update, and
sha3_128_shake{,_output}, without sha3_128_digest.
> 2. Implement shake128.
I've extracted it from the ML-KEM merge request and put it here:
https://git.lysator.liu.se/nettle/nettle/-/merge_requests/63
Not sending via email as it includes a huge test vector.
> 3. Update docs.
I can do that once we settle the interface.
Regards,
--
Daiki Ueno
___
nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se
To unsubscribe send an email to nettle-bugs-le...@lists.lysator.liu.se
Re: additional API for SHAKE streaming read
Hello Niels,
Niels Möller writes:
> Daiki Ueno writes:
>
>>> * One could perhaps use index == 0 instead of index == block_size for
>>> the case that there is no buffered data. But the current convention
>>> does make your "if (length <= left)" nice and simple.
>>
>> I agree that the current convention is a bit awkward, so in the attached
>> patch I changed to use index == 0 as the indicator where buffering is
>> needed. That actually makes the code simpler as we can defer buffering
>> until when the data is read. One drawback though is that it causes
>> additional memcpy in a corner case where the _shake_output is used to
>> retrieve data smaller than the block size.
>
> I wonder if that will still be simpler if one also moves the
> sha3_permute calls?
>
> I have merged your previous version to a branch
> add-sha3_256_shake_output, and ci looks green. So perhaps best to merge
> that to master, and iterate from there?
Sorry for the delay, and thank you for merging it to master. I've come
up with the attached 3 patches on top of it, which basically do:
- Apply my changes in the previous post to count index from zero, not
the end of the block
- Rename sha3_256_shake_output to sha3_shake256_output and add
sha3_shake256_init/update as well, as you suggested in the previous
conversation. That would help us implement SHAKE128 without exposing
SHA3-128 digest functions and I find it easier to read when used in
the ML-KEM implementation.
- Generalize _shake_output function independent of the underlying SHA-3
algorithm.
>>> * It looks a bit backwards to me that each iteration *first* copies data
>>> to the digest, and *then* calls sha3_permute. In case no more data is
>>> to be output, that sha3_permute call is wasted. It would be more
>>> natural to me to not call sha3_permute until we know the output is
>>> needed. But to fix that and still keep things nice for the first
>>> output block, I think one would need to reorganize _nettle_sha3_pad to
>>> not imply a call to sha3_permute (via sha3_absorb). So that's better
>>> done in a separate change.
>>
>> Right, I can do that after the current patch is settled.
>
> I've done a bit of hacking locally. What I did was to take out the
> xoring parts of sha3_absorb into it's own function sha3_xor_block, and
> let sha3_pad_shake use that, without any call to sha3_permute. And then
> call sha3_permute as output is needed.
Cool!
>>> * I'm still tempted to use ctx->index = ~index rather than ctx->index =
>>> index | INDEX_HIGH_BIT. But maybe that would just be too obfuscated.
>>
>> I'm actually not sure how this works. For example, if unsigned int is
>> 32-bit and index is 3, wouldn't ~index turn to 0xfffc, while index |
>> INDEX_HIGH_BIT is 0x8003?
>
> It would be a different representation, with the very minor advantage
> that the INDEX_HIGH_BIT value isn't needed (in source code, or handled
> at runtime). Like
>
> index = ctx->index;
>
> if (index < sizeof(ctx->block))
> { ... first call to shake_output, pad and initialize... }
> else
> index = ~index;
>
> assert (index <= sizeof(ctx->block));
>
> ... output processing ...
>
> ctx->index = ~index;
I see. I rewote it using this pattern.
>>> In next step, to also support shake128, we should generalize your code
>>> using an internal function _sha3_shake_output taking block and block
>>> size as arguments.
>>
>> Yes.
>
> I've tried that in my local hack, I think it's rather straight-forward.
> (I might be able to post corresponding patch later). What's unclear is
> how much to share between _shake and shake_output. One could define
> _shake as _shake_output + _init. The drawback I see is that (i) we would
> allow _shake_output followed by _shake, which isn't proper api usage,
> and (ii) _shake needs a lot less logic since it should always start by
> padding, and it doesn't need to buffer any data, so it seems a bit wrong
> to have it call shake_output that does this unneeded extra work.
In the attached patch, _shake is now re-implemented using _shake_output
+ _init, and also marked as deprecated in favor of the new incremental
interface.
Regards,
--
Daiki Ueno
>From aab41e6fe2dd4461c59af63a84b45e19ec0eb9e7 Mon Sep 17 00:00:00 2001
From: Daiki Ueno
Date: Sat, 23 Mar 2024 17:44:33 +0900
Subject: [PATCH 1/3] shake256: Simplify the implementation
Signed-off-by: Daiki Ueno
---
shake256.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/shake256.c
Re: additional API for SHAKE streaming read
Niels Möller writes:
> Daiki Ueno writes:
>
>> Yes, this makes the code a lot simpler. I'm attaching an updated patch.
>
> Thanks, looks good to me. Some details I'm thinking about that might be
> improvements:
>
> * One could perhaps use index == 0 instead of index == block_size for
> the case that there is no buffered data. But the current convention
> does make your "if (length <= left)" nice and simple.
I agree that the current convention is a bit awkward, so in the attached
patch I changed to use index == 0 as the indicator where buffering is
needed. That actually makes the code simpler as we can defer buffering
until when the data is read. One drawback though is that it causes
additional memcpy in a corner case where the _shake_output is used to
retrieve data smaller than the block size.
> * It looks a bit backwards to me that each iteration *first* copies data
> to the digest, and *then* calls sha3_permute. In case no more data is
> to be output, that sha3_permute call is wasted. It would be more
> natural to me to not call sha3_permute until we know the output is
> needed. But to fix that and still keep things nice for the first
> output block, I think one would need to reorganize _nettle_sha3_pad to
> not imply a call to sha3_permute (via sha3_absorb). So that's better
> done in a separate change.
Right, I can do that after the current patch is settled.
> * I'm still tempted to use ctx->index = ~index rather than ctx->index =
> index | INDEX_HIGH_BIT. But maybe that would just be too obfuscated.
I'm actually not sure how this works. For example, if unsigned int is
32-bit and index is 3, wouldn't ~index turn to 0xfffc, while index |
INDEX_HIGH_BIT is 0x8003?
> In next step, to also support shake128, we should generalize your code
> using an internal function _sha3_shake_output taking block and block
> size as arguments.
Yes.
> I'm also not sure about proper naming for shake128. If I read the
> Instances table at https://en.wikipedia.org/wiki/SHA-3 right, there's no
> standard regular hash function corresponding to shake128. We could still
> name it sha3_128_shake, but that might be confusing (there's no
> corresponding sha3_128_digest, would there be any use for that?). The
> alternative could be to use names sha3_shakeN_init, sha3_shakeN_update,
> sha3_shakeN_digest, sha3_shakeN_output (with some of the shake256
> functions, as well as the context struct, being aliases to corresponding
> sha3_256 names). But aliases also have a cost in potential confusion.
I agree; we probably shouldn't expose sha3_128_digest et. al., from the
API.
>> + if (length > 0)
>> +{
>> + /* Fill in the buffer for next call. */
>> + _nettle_write_le64 (sizeof (ctx->block), ctx->block, ctx->state.a);
>> + sha3_permute (&ctx->state);
>> + memcpy (digest, ctx->block, length);
>> + ctx->index = length | INDEX_HIGH_BIT;
>> +}
>> + else
>> +ctx->index = sizeof (ctx->block) | INDEX_HIGH_BIT;
>> +}
>
> If I read your code right, we actually always have length > 0 at this
> place. So either delete the if conditional, or change the condition of
> the loop above from (length > sizeof (ctx->block)) to (length >= sizeof
> (ctx->block)). The latter option would avoid a memcpy in the case that
> the requested digest ends with a full block.
Indeed, fixed.
Regards,
--
Daiki Ueno
>From 42c6b5686d361f5572fc6e2daf5d7e355d5b90c0 Mon Sep 17 00:00:00 2001
From: Daiki Ueno
Date: Sun, 10 Mar 2024 09:43:04 +0900
Subject: [PATCH] sha3: Extend SHAKE256 API with incremental output
This adds an alternative function sha3_256_shake_output in the
SHAKE256 support, which enables to read output multiple times in an
incremental manner.
Signed-off-by: Daiki Ueno
---
sha3.h| 8 +
shake256.c| 65 +++
testsuite/shake256-test.c | 65 +++
3 files changed, 138 insertions(+)
diff --git a/sha3.h b/sha3.h
index 9220829d..4b7e186c 100644
--- a/sha3.h
+++ b/sha3.h
@@ -49,6 +49,7 @@ extern "C" {
#define sha3_256_update nettle_sha3_256_update
#define sha3_256_digest nettle_sha3_256_digest
#define sha3_256_shake nettle_sha3_256_shake
+#define sha3_256_shake_output nettle_sha3_256_shake_output
#define sha3_384_init nettle_sha3_384_init
#define sha3_384_update nettle_sha3_384_update
#define sha3_384_digest nettle_sha3_384_digest
@@ -143,6 +144,13 @@ sha3_256_shake(struct sha3_256_ctx *ctx,
size_t length,
uint8_t *digest);
+/* Unlike sha3_256_shake, this function can be called multiple times
+ to retrieve output from shake256 in an in
Re: additional API for SHAKE streaming read
Hello Niels,
Thank you for the suggestions, all makes sense to me.
Niels Möller writes:
>> +void
>> +sha3_256_shake_output(struct sha3_256_ctx *ctx,
>> + size_t length,
>> + uint8_t *digest)
>> +{
>> + unsigned offset;
>> + unsigned mask = UINT_MAX >> 1;
>
> I think I'd name the local variable "index" rather than "offset", to
> match the state variable. And I think it would make sense with a define
> for the high bit, something like
>
> #define INDEX_HIGH_BIT (~((UINT_MAX) >> 1))
>
> (one could also use something like ~0U instead of UINT_MAX, but UINT_MAX
> may be more readable).
Renamed and introduced the macro.
>> + /* We use the leftmost bit as a flag to indicate SHAKE is initialized. */
>> + if (ctx->index & ~mask)
>> +offset = ctx->index & mask;
>
> The value of offset here is in the range 0 < offset <=
> SHA3_256_BLOCK_SIZE, right? One could use a representation where
>
> offset = ~ctx->index;
>
> instead of bitwise operations. One would still need the condition if
> (ctx->index & INDEX_HIGH_BIT), but that would typically be compiled to
> the same as if ((signed int) ctx->index < 0).
>
> I think it would also make sense with an
>
> assert (ctx->index < SHA3_256_BLOCK_SIZE);
>
> in the start of sha3_256_update, which will trigger if the update
> function is called after the output function, with no init in between.
>
>> + else
>> +{
>> + _sha3_pad_shake (&ctx->state, SHA3_256_BLOCK_SIZE, ctx->block,
>> ctx->index);
>> + /* Point at the end of block to trigger fill in of the buffer. */
>> + offset = sizeof (ctx->block);
>
> I think this block deserves a comment that this is the first call to
> sha3_256_shake_output. For the block size, I think it would be nice to
> consitently use one of SHA3_256_BLOCK_SIZE and sizeof (ctx->block).
I chose the latter to not embed algorithm specific constant, as the same
code also needs to support SHAKE128 (to be added).
>> +}
>> +
>> + for (;;)
>> +{
>> + /* Write remaining data from the buffer. */
>> + if (offset < sizeof (ctx->block))
>> +{
>> + unsigned remaining;
>> +
>> + remaining = MIN(length, sizeof (ctx->block) - offset);
>> + memcpy (digest, &ctx->block[offset], remaining);
>> + digest += remaining;
>> + offset += remaining;
>
> I think handling of the leftover can be moved before the loop, and
> simplified as
>
> unsigned left = sizeof(ctx->block) - offset;
> if (length <= left)
> {
> memcpy (digest, ctx->block + offset, length);
> ctx->index = (offset + length) | INDEX_HIGH_BIT;
> return;
> }
> memcpy (digest, ctx->block + offset, left);
> digest += left;
> length -= left;
>
> followed by a loop
>
> for (; length >= SHA3_256_BLOCK_SIZE;
> length -= SHA3_256_BLOCK_SIZE, digest += SHA3_256_BLOCK_SIZE)
> {
> ... output a full block ...
> }
>
> if (length > 0)
> {
> ... do final partial block ...
> ctx->index = length | INDEX_HIGH_BIT;
> }
> else
> ctx->index = SHA3_256_BLOCK_SIZE | INDEX_HIGH_BIT;
Yes, this makes the code a lot simpler. I'm attaching an updated patch.
Regards,
--
Daiki Ueno
>From 2634e69aa3172d0a7a1852159771a905c0cb9a9d Mon Sep 17 00:00:00 2001
From: Daiki Ueno
Date: Sun, 10 Mar 2024 09:43:04 +0900
Subject: [PATCH] sha3: Extend SHAKE256 API with incremental output
This adds an alternative function sha3_256_shake_output in the
SHAKE256 support, which enables to read output multiple times in an
incremental manner.
Signed-off-by: Daiki Ueno
---
sha3.h| 8 ++
shake256.c| 60 +++
testsuite/shake256-test.c | 58 +
3 files changed, 126 insertions(+)
diff --git a/sha3.h b/sha3.h
index 9220829d..4b7e186c 100644
--- a/sha3.h
+++ b/sha3.h
@@ -49,6 +49,7 @@ extern "C" {
#define sha3_256_update nettle_sha3_256_update
#define sha3_256_digest nettle_sha3_256_digest
#define sha3_256_shake nettle_sha3_256_shake
+#define sha3_256_shake_output nettle_sha3_256_shake_output
#define sha3_384_init nettle_sha3_384_init
#define sha3_384_update nettle_sha3_384_update
#define sha3_384_digest nettle_sha3_384_digest
@@ -143,6 +144,13 @@ sha3_256_shake(struct sha3_256_ctx *ctx,
size_t length,
uint8_t *digest);
+/* Unlike sha3_256_shake, this function can be called multiple times
+ to retrieve output from
Re: additional API for SHAKE streaming read
Hello Niels,
Niels Möller writes:
> Daiki Ueno writes:
>
>> When I'm trying to implement ML-KEM (Kyber), I realized that the current
>> API for SHAKE (sha3_256_shake) is a bit too limited: while ML-KEM uses
>> SHAKE128 as a source of pseudorandom samples[1], the the current API
>> requires the total number of bytes are determined prior to the call, and
>> after the call the hash context is reset.
>
> I vaguely recall discussing that when shake256 was added, and we
> concluded it was good enough as a start, and could be extended later.
>
> I think it would be nice if one could support the streaming case with
> the existing struct sha3_256_ctx, and little extra wrapping. Question is
> what the interface should be. I see a few variants:
>
> 1.
> void /* Essentially the same as _sha3_pad_shake */
> sha3_256_shake_start (struct sha3_256_ctx *ctx);
>
> void /* Unbuffered, length must be a multiple of SHA3_256_BLOCK_SIZE */
> sha3_256_shake_output (struct sha3_256_ctx *ctx
> size_t length, uint8_t *dst);
>
> void /* Last call, length can be arbitrary, context reinitialized */
> sha3_256_shake_end (struct sha3_256_ctx *ctx
> size_t length, uint8_t *dst);
>
> Requiring all calls but the last to be full blocks is consistent with
> nettle's funtions for block ciphers. But since we anyway have a buffer
> available (to support arbitrary sizes for streaming the input), we could
> perhaps just as well reuse that buffer.
>
> 2.
> void /* Essentially the same as _sha3_pad_shake */
> sha3_256_shake_start (struct sha3_256_ctx *ctx);
>
> void /* Arbitrary length, no need to signal end of data */
> sha3_256_shake_output (struct sha3_256_ctx *ctx
> size_t length, uint8_t *dst);
>
> void /* Explicit init call needed to start a new input message */
> sha3_256_init (struct sha3_256_ctx *ctx);
>
> In this case, sha3_256_shake_output would use ctx->index and ctx->buffer
> for partial blocks.
>
> With some hacking (say, using the unused high bit of ctx->index to
> signal that shake is in output mode), then we could have just
>
> 3.
> void /* Arbitrary length, no need to signal start or end of output */
> sha3_256_shake_output (struct sha3_256_ctx *ctx
> size_t length, uint8_t *dst);
>
> void /* Explicit init call needed to start a new input message */
> sha3_256_init (struct sha3_256_ctx *ctx);
>
> As always, naming is also a crucial question. Is _shake_output a good
> name? Or _shake_read, or _shake_generate? From the terminology in the
> spec (https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf), I think
> "_shake_output" is reasonable.
>
> When deciding on naming and conventions, we should strive to define
> somthing that can be reused for later hash functions with variable
> output size (called extendable-output functions, "XOF", in the spec).
>
> So what do you think makes most sense?
Thank you. The option (3) sounds like a great idea as it only need one
more function to be added for streaming. I tried to implement it as the
attached patch.
Regards,
--
Daiki Ueno
>From fa02672ce0ee7956a444381c88693c9b03c2bd15 Mon Sep 17 00:00:00 2001
From: Daiki Ueno
Date: Sun, 10 Mar 2024 09:43:04 +0900
Subject: [PATCH] sha3: Extend SHAKE256 API with incremental output
This adds an alternative function sha3_256_shake_output in the
SHAKE256 support, which enables to read output multiple times in an
incremental manner.
Signed-off-by: Daiki Ueno
---
sha3.h| 8 ++
shake256.c| 52 +++
testsuite/shake256-test.c | 58 +++
3 files changed, 118 insertions(+)
diff --git a/sha3.h b/sha3.h
index 9220829d..4b7e186c 100644
--- a/sha3.h
+++ b/sha3.h
@@ -49,6 +49,7 @@ extern "C" {
#define sha3_256_update nettle_sha3_256_update
#define sha3_256_digest nettle_sha3_256_digest
#define sha3_256_shake nettle_sha3_256_shake
+#define sha3_256_shake_output nettle_sha3_256_shake_output
#define sha3_384_init nettle_sha3_384_init
#define sha3_384_update nettle_sha3_384_update
#define sha3_384_digest nettle_sha3_384_digest
@@ -143,6 +144,13 @@ sha3_256_shake(struct sha3_256_ctx *ctx,
size_t length,
uint8_t *digest);
+/* Unlike sha3_256_shake, this function can be called multiple times
+ to retrieve output from shake256 in an incremental manner */
+void
+sha3_256_shake_output(struct sha3_256_ctx *ctx,
+ size_t length,
+ uint8_t *digest);
+
struct sha3_384_ctx
{
struct sha3_state state;
diff --git a/shake256.c b/shake256.c
index f5c77a43..1356218b 100644
--- a/shake256.c
+++ b/shake256.c
@@ -36,6 +36
Support for ML-KEM (Kyber)
Hello, I created a draft patch to support ML-KEM (a post-quantum key encapsulation mechanism, formerly known as Kyber)[1], based on the explanation in the corresponding IETF draft[2]. There are probably a lot of rooms for improvements (performance, side-channel safety), but I'm sharing the code at: https://git.lysator.liu.se/nettle/nettle/-/merge_requests/62 Any comments or suggestions would be appreciated. Footnotes: [1] https://csrc.nist.gov/pubs/fips/203/ipd [2] https://datatracker.ietf.org/doc/draft-cfrg-schwabe-kyber/ Regards, -- Daiki Ueno ___ nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se To unsubscribe send an email to nettle-bugs-le...@lists.lysator.liu.se
additional API for SHAKE streaming read
Hello,
When I'm trying to implement ML-KEM (Kyber), I realized that the current
API for SHAKE (sha3_256_shake) is a bit too limited: while ML-KEM uses
SHAKE128 as a source of pseudorandom samples[1], the the current API
requires the total number of bytes are determined prior to the call, and
after the call the hash context is reset.
Here I propose adding a couple of helper functions to support such
streaming use-case: sha3_256_shake_pad to process the final block, and
sha3_256_shake_read to read the digest from the current state without
resetting the context. With those functions, one could write a
streaming read interface as attached.
What do you think? The actual code changes can be found at:
https://git.lysator.liu.se/nettle/nettle/-/merge_requests/61
I also have a SHAKE128 implementation with analogous API, which I will
post later.
Regards,
Footnotes:
[1]
https://bwesterb.github.io/draft-schwabe-cfrg-kyber/draft-cfrg-schwabe-kyber.html#name-uniformly
--
Daiki Ueno
#include "sha3.h"
#include
struct shake_reader
{
struct sha3_256_ctx ctx;
uint8_t buf[SHA3_256_BLOCK_SIZE];
size_t offset;
};
static void
shake_reader_init (struct shake_reader *reader)
{
sha3_256_init (&reader->ctx);
reader->offset = sizeof(reader->buf);
}
static void
shake_reader_read (struct shake_reader *reader,
size_t length,
uint8_t *digest)
{
while (length > 0)
{
while (reader->offset < sizeof(reader->buf))
{
*digest++ = reader->buf[reader->offset++];
length--;
if (!length)
return;
}
if (reader->offset == sizeof(reader->buf))
{
sha3_256_shake_read (&reader->ctx, sizeof(reader->buf), reader->buf);
sha3_permute (&reader->ctx.state);
reader->offset = 0;
}
}
}
int main (void)
{
struct shake_reader reader;
uint8_t buf[3];
size_t n = 0;
shake_reader_init (&reader);
sha3_256_update (&reader.ctx, 0, NULL);
sha3_256_shake_pad (&reader.ctx);
while (n < 256)
{
shake_reader_read (&reader, sizeof(buf), buf);
int d1 = buf[0] + 256 * (buf[1] % 16);
int d2 = (buf[1] >> 4) + 16 * buf[2];
if (d1 < 3329)
{
printf ("%d\n", d1);
n++;
}
if (n == 256)
break;
if (d2 < 3329)
{
printf ("%d\n", d2);
n++;
}
}
return 0;
}
___
nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se
To unsubscribe send an email to nettle-bugs-le...@lists.lysator.liu.se
Re: Add RSA-OAEP encryption/decryption to Nettle
Niels Möller writes:
> I noticed that there are two failures in the ci builds. See
> https://gitlab.com/gnutls/nettle/-/pipelines/1178451395.
>
> One failure is the new side-channel test failing with mini-gmp. Which is
> expected, the test should just be skipped in mini-gmp builds (similar to
> several other sc tests).
Yes, I'm attaching the patch for this.
> The other is a complaint from ubsan. I guess it's related to the label
> == NULL case. I don't know what's the proper place for a fix, maybe it's
> not in the new code. I think the Nettle APIs should generally allow size
> == 0, ptr == NULL more or less everywhere, even where libc functions we
> use formally require ptr != NULL.
This is similar to this issue:
https://gitlab.com/gnutls/gnutls/-/issues/1306
where we passed NULL to sha*_update in the GnuTLS code, though it turned
to be a non-issue.
In the RSA-OAEP case, I'm not exactly sure whether we should be able to
safely special case label == NULL as its hash is part of plaintext data
block. Therefore I'm adding label = "" at the API entry points.
Regards,
--
Daiki Ueno
>From 9ffbac0aa6807231a6842a1ee67f6999c9c2c97a Mon Sep 17 00:00:00 2001
From: Daiki Ueno
Date: Sat, 17 Feb 2024 08:58:47 +0900
Subject: [PATCH] Fix a couple of CI failures in rsa-oaep-encrypt-test
- Skip sc-rsa-oaep-encrypt-test when compiled with mini-gmp
- Pass in "" as label if it was NULL, to pacify __nonnull nature of
memcpy
Signed-off-by: Daiki Ueno
---
rsa-oaep-decrypt.c| 7 +++
rsa-oaep-encrypt.c| 7 +++
testsuite/rsa-oaep-encrypt-test.c | 4
3 files changed, 18 insertions(+)
diff --git a/rsa-oaep-decrypt.c b/rsa-oaep-decrypt.c
index 4006a021..2c00422c 100644
--- a/rsa-oaep-decrypt.c
+++ b/rsa-oaep-decrypt.c
@@ -55,6 +55,13 @@ _rsa_oaep_decrypt (const struct rsa_public_key *pub,
TMP_GMP_DECL (m, mp_limb_t);
TMP_GMP_DECL (em, uint8_t);
int res;
+ const uint8_t empty = 0;
+
+ if (label == NULL)
+{
+ assert (label_length == 0);
+ label = ∅
+}
TMP_GMP_ALLOC (m, mpz_size (pub->n));
TMP_GMP_ALLOC (em, key->size);
diff --git a/rsa-oaep-encrypt.c b/rsa-oaep-encrypt.c
index 488821f0..7e6bb1e5 100644
--- a/rsa-oaep-encrypt.c
+++ b/rsa-oaep-encrypt.c
@@ -51,9 +51,16 @@ _rsa_oaep_encrypt (const struct rsa_public_key *key,
uint8_t *ciphertext)
{
mpz_t gibberish;
+ const uint8_t empty = 0;
mpz_init (gibberish);
+ if (label == NULL)
+{
+ assert (label_length == 0);
+ label = ∅
+}
+
if (_oaep_encode_mgf1 (gibberish, key->size,
random_ctx, random,
hash_ctx, hash,
diff --git a/testsuite/rsa-oaep-encrypt-test.c b/testsuite/rsa-oaep-encrypt-test.c
index 3d9808a5..511c2744 100644
--- a/testsuite/rsa-oaep-encrypt-test.c
+++ b/testsuite/rsa-oaep-encrypt-test.c
@@ -530,6 +530,10 @@ test_encrypt (void)
void
test_main (void)
{
+#if NETTLE_USE_MINI_GMP || WITH_EXTRA_ASSERTS
+ if (test_side_channel)
+SKIP();
+#endif
test_encrypt_decrypt ();
test_encrypt ();
}
--
2.43.0
___
nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se
To unsubscribe send an email to nettle-bugs-le...@lists.lysator.liu.se
Re: Add RSA-OAEP encryption/decryption to Nettle
Hello Niels,
Thank you for merging it and the suggestions.
Niels Möller writes:
> Thanks to the doc update, I now noticed the possibility of failure from
> the encryption functions. Failure is propagated from _oaep_encode_mgf1,
> which does
>
> assert (key_size >= 2 * hash->digest_size - 2);
>
> if (message_length > key_size - 2 * hash->digest_size - 2)
> return 0;
>
> Why is the first an assert (it could be triggered by using an unusually
> small RSA key with a large hash function, say rsa_oaep_sha512_encrypt
> with an old 512-bit RSA key, which from the docs isn't an obviously
> invalid usage), and the other a return value to indicate failure?
I think I split these conditions that way, as the first condition is
more about the algorithm setup, i.e., the user should choose RSA key
size and hash digest size appropriately, before using any of the
rsa_oaep_*_encrypt functions; otherwise treat it as a programming error.
That said, I agree that it would be more user friendly to combine them
and treat it as a regular error, as we do in pss_encode_mgf1.
> One alternative could be to instead check
>
> if (message_length > key_size
> || message_length + 2 + 2*hash->digest_size > key_size)
> return 0;
>
> (with two tests, to not trigger overflow in case message_length is close
> to the maximum size_t value; maybe that is more defensive than necessary
> since message_length large enough to trigger overflow can't be the size of
> properly allocated memory area).
I made this change in the attached patch.
> The opposite alternative would to be to have a documented way for the
> application to get the maximum message size, and have an assertion
> failure for both cases. That would have the advantage that no return
> value is needed, simplifying the api (at least very locally).
It is tempting, though for now I just documented the size restriction.
> Another doc detail: The docs for the decrypt functions don't say
> explicitly that *length is both an input and output argument. The text
> for the older function rsa_decrypt could be reused (or possibly
> improved).
Updated the documentation.
Regards,
--
Daiki Ueno
>From 04a7eb300a555617fd6f0503fdd48e8cf389e790 Mon Sep 17 00:00:00 2001
From: Daiki Ueno
Date: Fri, 16 Feb 2024 14:47:18 +0900
Subject: [PATCH] Clarify message length limitation in RSA-OAEP
Signed-off-by: Daiki Ueno
---
nettle.texinfo | 13 ++---
oaep.c | 5 ++---
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/nettle.texinfo b/nettle.texinfo
index 25bce6fb..95e89971 100644
--- a/nettle.texinfo
+++ b/nettle.texinfo
@@ -5202,8 +5202,12 @@ is done with one of the following functions:
@deftypefunx int rsa_oaep_sha384_encrypt (const struct rsa_public_key *@var{key}, void *@var{random_ctx}, nettle_random_func *@var{random}, size_t @var{label_length}, const uint8_t *@var{label}, size_t @var{length}, const uint8_t *@var{message}, uint8_t *@var{ciphertext})
@deftypefunx int rsa_oaep_sha512_encrypt (const struct rsa_public_key *@var{key}, void *@var{random_ctx}, nettle_random_func *@var{random}, size_t @var{label_length}, const uint8_t *@var{label}, size_t @var{length}, const uint8_t *@var{message}, uint8_t *@var{ciphertext})
Returns 1 on success, 0 on failure. The label is optional and if
-omitted, @var{label_length} and @var{label} can be set to 0 and
-@code{NULL} respectively.
+omitted, @var{label_length} and @var{label} is set to 0 and
+@code{NULL} respectively. The maximum size of @var{message} can be
+calculated with @code{k - 2 * hLen - 2}, where @code{k} is the key
+size in octets obtained with @var{key}->size, and @code{hLen} is the
+output size of the underlying hash function (e.g.,
+@code{SHA256_DIGEST_SIZE} for @code{rsa_oaep_sha256_encrypt}).
@end deftypefun
Decrypting a cipher text message using RSA with the OAEP padding
@@ -5213,7 +5217,10 @@ scheme is done with one of the following functions:
@deftypefunx int rsa_oaep_sha384_decrypt (const struct rsa_public_key *@var{pub}, const struct rsa_private_key *@var{key}, void *@var{random_ctx}, nettle_random_func *@var{random}, size_t @var{label_length}, const uint8_t *@var{label}, size_t *@var{length}, uint8_t *@var{message}, const uint8_t *@var{ciphertext})
@deftypefunx int rsa_oaep_sha512_decrypt (const struct rsa_public_key *@var{pub}, const struct rsa_private_key *@var{key}, void *@var{random_ctx}, nettle_random_func *@var{random}, size_t @var{label_length}, const uint8_t *@var{label}, size_t *@var{length}, uint8_t *@var{message}, const uint8_t *@var{ciphertext})
Returns 1 on success, 0 on failure. These function utilize randomized
-RSA blinding similarly to @code{rsa_decrypt_tr}.
+RSA blinding similarly to @code{rsa_decrypt_tr}. The message buffer
+pointed to by @var{cleartext} must be of size *@var{length}. After
+decryption, *@var{length} will b
Re: Add RSA-OAEP encryption/decryption to Nettle
Niels Möller writes: > Daiki Ueno writes: > >> Sorry for the confusion and thank you for the explanation; now I get it. >> I pushed a change along the of option (2). Could you take a look again? > > Thanks, looks good! Two nits, and let me know at which point you'd like > to get it merged, and do further improvements as followup MRs. Thank you; I have addressed those issues. As for the merging, I think it is ready now. I have also created a draft MR in GnuTLS to use the algorithm in PKCS#8, etc., so we can test the implementation in a broader context: https://gitlab.com/gnutls/gnutls/-/merge_requests/1805 > Since the oaep.h header now only declares internal functions, it > shouldn't be installed (moved from HEADERS to DISTFILES in Makefile.in). > > And it would be nice if the manual could give some more detail about the > label: As I understnd it, the label is optional, so it's fine to pass 0, > NULL if not needed. And if used, the same label must be used for both > encrypt and decrypt. Regards, -- Daiki Ueno ___ nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se To unsubscribe send an email to nettle-bugs-le...@lists.lysator.liu.se
Re: Add RSA-OAEP encryption/decryption to Nettle
Niels Möller writes: > Daiki Ueno writes: > >> Added `mark_bytes_undefined (1, &ciphertext[key->size]);` to the test >> cases doing encryption. > > I'm afraid that isn't right. For one, mark_bytes_undefined is > conditioned so it only has any effect when running the sc tests. Second, > it will not produce any warnings for writes, which I think is what we'd > like to detect here. I think the options are: > > 1. Just don't allocate any extra byte, and valgrind's should arrange for >alerts on out-of-bounds writes without anything special. > > 2. Allocate an extra byte, write some random value before the call, and >check that the value is unchanged after the call (some other tests >do that sort of thing, it's simple, old fashioned, and doesn't depend >on valgrind). > > 3. Allocate an extra byte, and mark it using VALGRIND_MAKE_MEM_NOACCESS >(wrapped in some macro depending on the memcheck.h configure check). >I don't think that gives any real benefit over valgrind's default >behavior with (1), but might make sense if done in combination with >(2). Sorry for the confusion and thank you for the explanation; now I get it. I pushed a change along the of option (2). Could you take a look again? Regards, -- Daiki Ueno ___ nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se To unsubscribe send an email to nettle-bugs-le...@lists.lysator.liu.se
Re: Add RSA-OAEP encryption/decryption to Nettle
Niels Möller writes: > Daiki Ueno writes: > >> The zip file is no longer accessible, but I still keep a copy and it >> seems identical to the one at: >> https://github.com/pyca/cryptography/tree/main/vectors/cryptography_vectors/asymmetric/RSA/pkcs-1v2-1d2-vec >> >> Is it OK to use the vector assuming it is public domain? > > According to the closest LICENSE file, > https://github.com/pyca/cryptography/blob/main/vectors/LICENSE, it's dual > licensed apache/BSD (our choice), so I think that is fine. And if > we copy just the test vectors and not any surrounding code, it seems > questionable if that is even copyrightable. > > So I think copying from there, with proper attribution, is perfectly > fine. Formally, we'll be exercising the BSD option. OK, thanks for the confirmation. I've expanded the KAT tests further using the vector and also added a license notice. >> Yes, the length should match key->size; I've omitted the >> ciphertext_length argument. > > Thanks. Please remove everywhere, it looks like it's still present in > some form in the test code. (You may still want to allocate an extra > byte at the end and check that it isn't modified. Alternatively, rely on > valgrind for detecting overwrites instead). Added `mark_bytes_undefined (1, &ciphertext[key->size]);` to the test cases doing encryption. Regards, -- Daiki Ueno ___ nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se To unsubscribe send an email to nettle-bugs-le...@lists.lysator.liu.se
Re: Add RSA-OAEP encryption/decryption to Nettle
Hello, Niels Möller writes: > Daiki Ueno writes: > >>>> * For tests, would it make some with some test that check that >>>> encryption with a given message and randomness gives the expected >>>> output? Even better if there are any authoritative testcases for that? >> >> I would be happy to add if there are any, even if they are not so >> authoritative, though I wasn't even able to find ones with compatible >> license, in particular with SHA-2 being used as an underlying hash >> algorithm for MGF-1. >> >> - Project Wycheproof (Apache 2.0): >> >> https://github.com/google/wycheproof/blob/master/testvectors/rsa_oaep_2048_sha256_mgf1sha256_test.json >> >> - Python Cryptography (Apache 2.0 and BSD): >> https://cryptography.io/en/latest/development/custom-vectors/rsa-oaep-sha2/ >> >> In any case, I'll try to check against those vectors manually outside >> the Nettle repository to ensure the correctness. > > To me it looks like those sources provide reasonable test vectors for > RSA OAEP decryption. > > On licensing, it looks like Apache and GPLv2 might be incompatible. I've > been a bit sloppy when incorporating test code (e.g., for some time I > had some testcode copied from openssl/libcrypto, to test compatibility > glue). But in this case, I think a fully correct workaround would be to > license the related test file LGPLv3 (no GPLv2 option); odd licensing > for some of the test files shouldn't matter much for Nettle applications > since the testcode isn't part of the library applications link. Proper > attribution is of course important. > > But my original question was for testing of RSA *en*cryption, if there > are some determinstic testvectors with known output, with tests wiring > something non-random for the randomness input. I did a bit of a research and realized that, when we added OAEP in libgcrypt, we apparently picked the test vector from: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1d2-vec.zip https://lists.gnupg.org/pipermail/gcrypt-devel/2011-June/001802.html The zip file is no longer accessible, but I still keep a copy and it seems identical to the one at: https://github.com/pyca/cryptography/tree/main/vectors/cryptography_vectors/asymmetric/RSA/pkcs-1v2-1d2-vec Is it OK to use the vector assuming it is public domain? In any case I incorporated one test from the vector. > What does the OAEP spec say about the ciphertet length? It would make > the interface easier if we say that the ciphertext length *always* > equals key->size; then one could delete passing and checking of the > ciphertext_length argument. In the current MR, it looks like leading > zero bytes are trimmed (behavior of nettle_mpz_sizeinbase_256_u), so > that ciphertext may sometimes be shorter. Yes, the length should match key->size; I've omitted the ciphertext_length argument. I'm not sure about the leading zeros though; as far as I read, nettle_mpz_to_octets seems to keep them. Regards, -- Daiki Ueno ___ nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se To unsubscribe send an email to nettle-bugs-le...@lists.lysator.liu.se
Re: Add RSA-OAEP encryption/decryption to Nettle
Hello Niels, Simo, Thanks for the comments. I've updated MR addressing part of them (see inline for the details). Simo Sorce writes: > On Mon, 2024-01-15 at 21:43 +0100, Niels Möller wrote: >> Thanks, I've had a look, and it looks pretty good to me. Some comments >> and questions: >> >> * For tests, would it make some with some test that check that >> encryption with a given message and randomness gives the expected >> output? Even better if there are any authoritative testcases for that? I would be happy to add if there are any, even if they are not so authoritative, though I wasn't even able to find ones with compatible license, in particular with SHA-2 being used as an underlying hash algorithm for MGF-1. - Project Wycheproof (Apache 2.0): https://github.com/google/wycheproof/blob/master/testvectors/rsa_oaep_2048_sha256_mgf1sha256_test.json - Python Cryptography (Apache 2.0 and BSD): https://cryptography.io/en/latest/development/custom-vectors/rsa-oaep-sha2/ In any case, I'll try to check against those vectors manually outside the Nettle repository to ensure the correctness. >> * Is it useful to have oaep_decode_mgf1 and oaep_encode_mgf1 advertised >> as public functions, or would it be better to make them internal? Made them internal functions. >> * Do you see any reasonable (i.e., with a net gain in maintainability) >> way to share more code between _oaep_sec_decrypt_variable and >> _pkcs1_sec_decrypt_variable? > > I did review this part, and to me it seem like it is more maintainable > to keep them separate, they already are tricky as it is, adding more > variability sounds to me would just make them more complex and > difficult to reason about. I agree with that, considering potential optimization opportunities by the compiler. >> * For oaep_decode_mgf1, oaep_encode_mgf1, maybe one could let the caller >> allocate and pass in the appropriate hashing context? Would be easy to >> do, e.g., in rsa_oaep_sha512_decrypt. But it looks like that would be >> inconsistent with pss_mgf1, though (which looks like it needs a >> separate hashing context). Done. >> * I think it was a design mistake to represent RSA ciphertexts as mpz_t >> rather then octet strings in Nettle's original RSA interfaces. I >> wonder if it would make sense to let the new functions take >> octet strings instead? Done. Regards, -- Daiki Ueno ___ nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se To unsubscribe send an email to nettle-bugs-le...@lists.lysator.liu.se
Re: Add RSA-OAEP encryption/decryption to Nettle
Hello Nicolas, Niels, Now that another attack on RSA encryption with PKCS#1 v1.5 padding has been discovered (though Nettle is not vulnerable)[1], it is recommended to avoid using the v1.5 scheme in new applications[2][3], and thus supporting RSA-OAEP in Nettle is becoming more relevant. I made some modifications to the existing merge request[4], mainly to make it side-channel safe at decryption: https://git.lysator.liu.se/nettle/nettle/-/merge_requests/60 Could you take a look when you have time? Footnotes: [1] https://people.redhat.com/~hkario/marvin/ [2] https://datatracker.ietf.org/doc/draft-kario-rsa-guidance/ [3] https://github.com/checkpoint-restore/criu/pull/2297#discussion_r1420116692 [4] https://git.lysator.liu.se/nettle/nettle/-/merge_requests/20 Regards, -- Daiki Ueno ___ nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se To unsubscribe send an email to nettle-bugs-le...@lists.lysator.liu.se
Re: [PATCH] Implement AES-GCM-SIV
I've also filed an MR for easier reviews and updates: https://git.lysator.liu.se/nettle/nettle/-/merge_requests/52 u...@gnu.org writes: > From: Daiki Ueno > > This implements AES-GCM-SIV, described in RFC8452, on top of the > existing AES-GCM primitives. In particular, its hash algorithm > POLYVAL is implemented using the GHASH with additional byte order > conversion according to RFC8452 Appendix A. Regards, -- Daiki Ueno ___ nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se To unsubscribe send an email to nettle-bugs-le...@lists.lysator.liu.se
Re: Nettle AUTHORS list
ni...@lysator.liu.se (Niels Möller) writes: > ni...@lysator.liu.se (Niels Möller) writes: > >> I've also noticed that the copyright/authorship section of the manual >> is very out-of-date, so I'm trying to put together a more >> comprehensive AUTHORS file to replace that. > > See below. Based on the author info in the manual, ChangeLog, and git > history. Let me know if you spot any errors. I see a couple of typos: libgrypt → libgcrypt (two places), curve488 → curve448. Regards, -- Daiki Ueno ___ nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se To unsubscribe send an email to nettle-bugs-le...@lists.lysator.liu.se
Re: Status update
ni...@lysator.liu.se (Niels Möller) writes: > 4. RSA-OAEP merge request. I intend to attend to (3) first, and will not >pay much attention to this one at the moment. If anyone else would >like to help out with review, maybe have alook at this one? >https://git.lysator.liu.se/nettle/nettle/-/merge_requests/20 I had a brief look at this and it's already in a pretty good shape. I'll try to do a thorough review if that helps. Given the use of PKCS #1 v1.5 padding seems to be becoming problematic[1], I guess this is a much wanted feature. Regards, Footnotes: [1] https://github.com/openssl/openssl/issues/13421 -- Daiki Ueno ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: GnuTLS testsuite error on ppc64 after nettle upgrade
Hello, ni...@lysator.liu.se (Niels Möller) writes: > ni...@lysator.liu.se (Niels Möller) writes: > >> I would guess that means that we got 209 bytes, including the 16-byte >> poly1305 authentication tag. Message size is then 209 - 16 = 193 bytes. >> If the first byte is a TLS packet type, the "length: 192" in the next to >> last line makes sense if the packet type byte is excluded. Right? That's exactly the case (under TLS 1.3). As the protocol uses separate keys for handshake and application traffic (and the error happens in sending application data and no post-handshake messages are exchanged), I guess you can also assume that the same data (all bytes are 0x2) with different lengths is fed into chacha_crypt* in the failing test case (mini-record-2). > I've found one problem, although I don't see that it would cause > precisely the reported problem. It would result in incorrect > encrypt/decrypt of the data immediately after a call to chacha_crypt or > chacha_crypt32 with 129 <= (length % 256) <= 192. In code used only on > ppc64 with the new altivec chacha code enabled. > > Tentative patch below, but I need to extend the tests to get proper test > coverage of this case. Thank you so much! The patch fixes the issue (tested on gcc cfarm). In the gdb trace, I see nettle_chacha_poly1305_encrypt() is called with the following length pattern: 128, 63, 128, 64, 192, 1, 192, 2. I can try to create a test case if necessary. Also: thank you Andreas for looking into it. Regards, -- Daiki Ueno ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: checking ECC point at infinity
ni...@lysator.liu.se (Niels Möller) writes: > I think the point multiplication functions were written under the > assumption that the scalar should be less than the group order. > Docs could perhaps be improved on that. > > But I don't known now exactly how it fails. It's good you get the > valgrind failures, but line numbers don't quite match my version. I was using the Nettle version installed on the system, sorry. I'm attaching the complete log taken with the git master (d1e45e07f). > If ecc_mul_a can be made to support this, I take it the output will be a > point with z = 0 (mod p) in homogenenous coordinates. > > And then the special case z = 0 has to be detected in some way in the > conversion to affine coordinates. That's done by ecc_j_to_a, but that > assumes a finite input point, since it inverts z without checking for > zero. I think it would be nice if it hits an assertion failure. >> As it works with the curve order minus 1, I added the following check >> instead in my library, though I'm not sure if this satisfies the >> original requirement: >> >> P = (n - 1) * Q > > Checking that (n-1) * Q = -Q should be mathematically equivalent. > There's a similar test in testsuite/ecc-mul-a-test.c and > testsuite/ecc-mul-g-test.c (but testing with the generator rather than > with an arbitrary public key). Thanks for the pointer and the confirmation; I've tightened the check based on testsuite/ecc-mul-a-test.c. For the record, the patch is: https://gitlab.com/gnutls/gnutls/-/merge_requests/1299/diffs?commit_id=23756c8580dff99d0856adca49dd22a55352ad62 Regards, -- Daiki Ueno ==42307== Memcheck, a memory error detector ==42307== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==42307== Using Valgrind-3.16.0 and LibVEX; rerun with -h for copyright info ==42307== Command: ./ecc-test ==42307== Parent PID: 3156 ==42307== ==42307== Conditional jump or move depends on uninitialised value(s) ==42307==at 0x48670AA: _nettle_ecc_mul_a (ecc-mul-a.c:145) ==42307==by 0x4867D0F: nettle_ecc_point_mul (ecc-point-mul.c:56) ==42307==by 0x4012EB: main (ecc-test.c:36) ==42307== ==42307== Conditional jump or move depends on uninitialised value(s) ==42307==at 0x485E278: _nettle_sec_tabselect (sec-tabselect.c:54) ==42307==by 0x486711A: _nettle_ecc_mul_a (ecc-mul-a.c:147) ==42307==by 0x4867D0F: nettle_ecc_point_mul (ecc-point-mul.c:56) ==42307==by 0x4012EB: main (ecc-test.c:36) ==42307== ==42307== Conditional jump or move depends on uninitialised value(s) ==42307==at 0x485F77F: _nettle_ecc_mod_add (ecc-mod-arith.c:53) ==42307==by 0x4862069: _nettle_ecc_dup_jj (ecc-dup-jj.c:81) ==42307==by 0x48671E6: _nettle_ecc_mul_a (ecc-mul-a.c:171) ==42307==by 0x4867D0F: nettle_ecc_point_mul (ecc-point-mul.c:56) ==42307==by 0x4012EB: main (ecc-test.c:36) ==42307== ==42307== Conditional jump or move depends on uninitialised value(s) ==42307==at 0x485F83F: _nettle_ecc_mod_sub (ecc-mod-arith.c:64) ==42307==by 0x4862117: _nettle_ecc_dup_jj (ecc-dup-jj.c:83) ==42307==by 0x48671E6: _nettle_ecc_mul_a (ecc-mul-a.c:171) ==42307==by 0x4867D0F: nettle_ecc_point_mul (ecc-point-mul.c:56) ==42307==by 0x4012EB: main (ecc-test.c:36) ==42307== ==42307== Conditional jump or move depends on uninitialised value(s) ==42307==at 0x485F83F: _nettle_ecc_mod_sub (ecc-mod-arith.c:64) ==42307==by 0x486216B: _nettle_ecc_dup_jj (ecc-dup-jj.c:84) ==42307==by 0x48671E6: _nettle_ecc_mul_a (ecc-mul-a.c:171) ==42307==by 0x4867D0F: nettle_ecc_point_mul (ecc-point-mul.c:56) ==42307==by 0x4012EB: main (ecc-test.c:36) ==42307== ==42307== Conditional jump or move depends on uninitialised value(s) ==42307==at 0x485F77F: _nettle_ecc_mod_add (ecc-mod-arith.c:53) ==42307==by 0x486219F: _nettle_ecc_dup_jj (ecc-dup-jj.c:87) ==42307==by 0x48671E6: _nettle_ecc_mul_a (ecc-mul-a.c:171) ==42307==by 0x4867D0F: nettle_ecc_point_mul (ecc-point-mul.c:56) ==42307==by 0x4012EB: main (ecc-test.c:36) ==42307== ==42307== Conditional jump or move depends on uninitialised value(s) ==42307==at 0x485F83F: _nettle_ecc_mod_sub (ecc-mod-arith.c:64) ==42307==by 0x48621B7: _nettle_ecc_dup_jj (ecc-dup-jj.c:88) ==42307==by 0x48671E6: _nettle_ecc_mul_a (ecc-mul-a.c:171) ==42307==by 0x4867D0F: nettle_ecc_point_mul (ecc-point-mul.c:56) ==42307==by 0x4012EB: main (ecc-test.c:36) ==42307== ==42307== Conditional jump or move depends on uninitialised value(s) ==42307==at 0x485F8F4: _nettle_ecc_mod_mul_1 (ecc-mod-arith.c:76) ==42307==by 0x486223F: _nettle_ecc_dup_jj (ecc-dup-jj.c:90) ==42307==by 0x48671E6: _nettle_ecc_mul_a (ecc-mul-a.c:171) ==42307==by 0x4867D0F: nettle_ecc_point_mul (ecc-point-mul.c:56) ==42307==by 0x4012EB: main (ecc-test.c:36) ==42307== ==42307== Conditional jump or move depends on uninitial
checking ECC point at infinity
Hello,
SP800-56A (revision 3) section 5.6.2.3.3 now mandates a check that the
generated public key (Q) multiplied by the curve order (n) results in an
identity element (= an infinity point).
It seem that it is not possible to implement this check with the
Nettle's public API. The attached patch naively multiplies Q by n but
it causes the valgrind errors below.
As it works with the curve order minus 1, I added the following check
instead in my library, though I'm not sure if this satisfies the
original requirement:
P = (n - 1) * Q
where P's x-coordinate is the same as Q's, and P also lies on the same
curve so that indicates P + Q (= n * Q) is an infinity point, according
to the group law.
Is there a better (direct) way to implement the check? Suggestions
appreciated.
Conditional jump or move depends on uninitialised value(s)
at 0x4880DFB: _nettle_ecc_mul_a (ecc-mul-a.c:145)
by 0x48815F8: nettle_ecc_point_mul (ecc-point-mul.c:55)
by 0x4012EB: main (ecc-test.c:36)
Conditional jump or move depends on uninitialised value(s)
at 0x487D1D9: _nettle_sec_tabselect (sec-tabselect.c:54)
by 0x4880E1B: _nettle_ecc_mul_a (ecc-mul-a.c:147)
by 0x48815F8: nettle_ecc_point_mul (ecc-point-mul.c:55)
by 0x4012EB: main (ecc-test.c:36)
Conditional jump or move depends on uninitialised value(s)
at 0x487E0F3: _nettle_ecc_mod_add (ecc-mod-arith.c:53)
by 0x487F51B: _nettle_ecc_dup_jj (ecc-dup-jj.c:81)
by 0x4880E66: _nettle_ecc_mul_a (ecc-mul-a.c:171)
by 0x48815F8: nettle_ecc_point_mul (ecc-point-mul.c:55)
by 0x4012EB: main (ecc-test.c:36)
Regards,
--
Daiki Ueno
#include
#include
#include
#include
static void
myrandom (void *ctx, size_t length, uint8_t *dst)
{
memset (dst, 0, length);
*dst = 0xff;
}
int
main (void)
{
const struct ecc_curve *curve = nettle_get_secp_256r1 ();
struct ecc_point pub;
struct ecc_scalar key;
mpz_t nz, x, y;
struct ecc_scalar n;
struct ecc_point r;
ecc_point_init (&pub, curve);
ecc_scalar_init (&key, curve);
ecc_scalar_init (&n, curve);
ecc_point_init (&r, curve);
ecdsa_generate_keypair (&pub, &key, NULL, myrandom);
/* Calculate P = nQ and check if it is an infinity point. */
mpz_init_set_str (nz, ""
"bce6faada7179e84f3b9cac2fc632551", 16);
ecc_scalar_set (&n, nz);
mpz_clear (nz);
ecc_point_mul (&r, &n, &pub);
mpz_init (x);
mpz_init (y);
ecc_point_get (&r, x, y);
assert (mpz_cmp_ui (x, 0) == 0);
assert (mpz_cmp_ui (y, 0) == 0);
mpz_clear (x);
mpz_clear (y);
ecc_point_clear (&pub);
ecc_scalar_clear (&key);
ecc_scalar_clear (&n);
ecc_point_clear (&r);
return 0;
}
/**
* Local variables:
* compile-command: "gcc -o ecc-test ecc-test.c `pkg-config hogweed --cflags
--libs` -lgmp"
* End:
*/
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Nettle-3.6 soon
Hello Niels, ni...@lysator.liu.se (Niels Möller) writes: > ni...@lysator.liu.se (Niels Möller) writes: > >> I've updated the NEWS file, and I don't think there are any easy changes >> pending. Please let me know ASAP if there's anything missing in NEWS, or >> if there are additional changes you think ought to be included before >> release. > > I've created a tarball at > > http://www.lysator.liu.se/~nisse/archive/nettle-3.6rc1.tar.gz > http://www.lysator.liu.se/~nisse/archive/nettle-3.6rc1.tar.gz.sig > > Only recent change is the updated libhogweed soname, requested by > Dmitry. Both testing and review of the NEWS file highly appreciated. > Please report test results, both positive and negative, to the list. It builds fine on all arches running Fedora rawhide (with GCC 10): https://koji.fedoraproject.org/koji/taskinfo?taskID=43267967 I suggest a couple of minor improvements on the NEWS entry as attached. diff --git a/NEWS b/NEWS index 0d31dbc3..46f97fb1 100644 --- a/NEWS +++ b/NEWS @@ -23,13 +23,13 @@ NEWS for the Nettle 3.6 release enabled via CFLAGS (gcc --fcf-protection=full). Contributed by H.J. Lu and Simo Sorce. - * A few new functions to improve support the Chacha variant + * A few new functions to improve support for the Chacha variant with 96-bit nonce and 32-bit block counter (the existing functions use nonce and counter of 64-bit each), and functions to set the counter. Contributed by Daiki Ueno. * New interface, struct nettle_mac, for MAC (message - authentication) algorithms. This abstraction is only for + authentication code) algorithms. This abstraction is only for MACs that don't require a per-message nonce. For HMAC, the key size is fixed, and equal the digest size of the underlying hash function. @@ -42,7 +42,7 @@ NEWS for the Nettle 3.6 release * Fix configure check for __builtin_bswap64, the incorrect check would result in link errors on platforms missing this - function. Patch contributed by by George Koehler. + function. Patch contributed by George Koehler. * All use of old-fashioned suffix rules in the Makefiles have been replaced with %-pattern rules. Nettle's use of suffix @@ -73,7 +73,7 @@ NEWS for the Nettle 3.6 release The libhogweed.so library was also intended to be fully binary compatible with nettle-3.5. However, the major version and the soname are incremented anyway, to avoid upgrade problems with - recent Gnutls versions that depend on Nettle internals outside + recent GnuTLS versions that depend on Nettle internals outside of the advertised ABI. NEWS for the Nettle 3.5.1 release Regards, -- Daiki Ueno ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
[PATCH v2 1/3] chacha: add function to set initial block counter
From: Daiki Ueno
The ChaCha20 based header protection algorithm in QUIC requires a way
to set the initial value of counter:
https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#name-chacha20-based-header-prote
This will add a new function chacha_set_counter, which takes an
8-octet initial value of the block counter.
Signed-off-by: Daiki Ueno
---
chacha-set-nonce.c | 7 +++
chacha.h| 5 +
nettle.texinfo | 12
testsuite/chacha-test.c | 37 +++--
4 files changed, 59 insertions(+), 2 deletions(-)
diff --git a/chacha-set-nonce.c b/chacha-set-nonce.c
index 607f176b..2c34e498 100644
--- a/chacha-set-nonce.c
+++ b/chacha-set-nonce.c
@@ -68,3 +68,10 @@ chacha_set_nonce96(struct chacha_ctx *ctx, const uint8_t
*nonce)
ctx->state[14] = LE_READ_UINT32(nonce + 4);
ctx->state[15] = LE_READ_UINT32(nonce + 8);
}
+
+void
+chacha_set_counter(struct chacha_ctx *ctx, const uint8_t *counter)
+{
+ ctx->state[12] = LE_READ_UINT32(counter + 0);
+ ctx->state[13] = LE_READ_UINT32(counter + 4);
+}
diff --git a/chacha.h b/chacha.h
index 429a55b6..440fe968 100644
--- a/chacha.h
+++ b/chacha.h
@@ -46,6 +46,7 @@ extern "C" {
#define chacha_set_key nettle_chacha_set_key
#define chacha_set_nonce nettle_chacha_set_nonce
#define chacha_set_nonce96 nettle_chacha_set_nonce96
+#define chacha_set_counter nettle_chacha_set_counter
#define chacha_crypt nettle_chacha_crypt
/* Currently, only 256-bit keys are supported. */
@@ -53,6 +54,7 @@ extern "C" {
#define CHACHA_BLOCK_SIZE 64
#define CHACHA_NONCE_SIZE 8
#define CHACHA_NONCE96_SIZE 12
+#define CHACHA_COUNTER_SIZE 8
#define _CHACHA_STATE_LENGTH 16
@@ -81,6 +83,9 @@ chacha_set_nonce(struct chacha_ctx *ctx, const uint8_t
*nonce);
void
chacha_set_nonce96(struct chacha_ctx *ctx, const uint8_t *nonce);
+void
+chacha_set_counter(struct chacha_ctx *ctx, const uint8_t *counter);
+
void
chacha_crypt(struct chacha_ctx *ctx, size_t length,
uint8_t *dst, const uint8_t *src);
diff --git a/nettle.texinfo b/nettle.texinfo
index 19eb6d34..0b339f51 100644
--- a/nettle.texinfo
+++ b/nettle.texinfo
@@ -1669,6 +1669,10 @@ ChaCha block size, 64.
Size of the nonce, 8.
@end defvr
+@defvr Constant CHACHA_COUNTER_SIZE
+Size of the counter, 8.
+@end defvr
+
@deftypefun void chacha_set_key (struct chacha_ctx *@var{ctx}, const uint8_t
*@var{key})
Initialize the cipher. The same function is used for both encryption and
decryption. Before using the cipher,
@@ -1681,6 +1685,14 @@ octets. This function also initializes the block
counter, setting it to
zero.
@end deftypefun
+@deftypefun void chacha_set_counter (struct chacha_ctx *@var{ctx}, const
uint8_t *@var{counter})
+Sets the block counter. It is always of size @code{CHACHA_COUNTER_SIZE},
+8 octets. This is rarely needed since @code{chacha_set_nonce}
+initializes the block counter to zero. When it is still necessary, this
+function must be called after @code{chacha_set_nonce}.
+
+@end deftypefun
+
@deftypefun void chacha_crypt (struct chacha_ctx *@var{ctx}, size_t
@var{length}, uint8_t *@var{dst}, const uint8_t *@var{src})
Encrypts or decrypts the data of a message, using ChaCha. When a
message is encrypted using a sequence of calls to @code{chacha_crypt},
diff --git a/testsuite/chacha-test.c b/testsuite/chacha-test.c
index d6489e9c..6875d4bb 100644
--- a/testsuite/chacha-test.c
+++ b/testsuite/chacha-test.c
@@ -38,8 +38,9 @@
#include "chacha-internal.h"
static void
-test_chacha(const struct tstring *key, const struct tstring *nonce,
- const struct tstring *expected, unsigned rounds)
+_test_chacha(const struct tstring *key, const struct tstring *nonce,
+const struct tstring *expected, unsigned rounds,
+const struct tstring *counter)
{
struct chacha_ctx ctx;
@@ -69,6 +70,9 @@ test_chacha(const struct tstring *key, const struct tstring
*nonce,
else
die ("Bad nonce size %u.\n", (unsigned) nonce->length);
+ if (counter)
+ chacha_set_counter(&ctx, counter->data);
+
chacha_crypt (&ctx, length, data, data);
ASSERT (data[-1] == 17);
@@ -98,6 +102,8 @@ test_chacha(const struct tstring *key, const struct tstring
*nonce,
ASSERT (nonce->length == CHACHA_NONCE_SIZE);
chacha_set_nonce(&ctx, nonce->data);
+ if (counter)
+ chacha_set_counter(&ctx, counter->data);
_chacha_core (out, ctx.state, rounds);
if (!MEMEQ(CHACHA_BLOCK_SIZE, out, expected->data))
@@ -117,6 +123,21 @@ test_chacha(const struct tstring *key, const struct
tstring *nonce,
}
}
+static void
+test_chacha(const struct tstring *key, const struct tstring *nonce,
+ const struct tstring *expected, unsigned rounds)
+{
+ _test_chacha(key, nonce, expected, rounds, NULL);
+}
+
+static void
+test_chacha_with_counter(c
[PATCH v2 3/3] doc: match ChaCha-Poly1305 documentation to the implementation
From: Daiki Ueno
While the documentation said the nonce size is 8 octets, the
implementation actually assumed 12 octets following RFC 7539.
Signed-off-by: Daiki Ueno
---
nettle.texinfo | 19 +++
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/nettle.texinfo b/nettle.texinfo
index fe44f6af..418f46d8 100644
--- a/nettle.texinfo
+++ b/nettle.texinfo
@@ -3323,17 +3323,12 @@ except that @var{cipher} and @var{f} are replaced with
a context structure.
ChaCha-Poly1305 is a combination of the ChaCha stream cipher and the
poly1305 message authentication code (@pxref{Poly1305}). It originates
from the NaCl cryptographic library by D. J. Bernstein et al, which
-defines a similar construction but with Salsa20 instead of ChaCha.
-
-Nettle's implementation ChaCha-Poly1305 should be considered
-@strong{experimental}. At the time of this writing, there is no
-authoritative specification for ChaCha-Poly1305, and a couple of
-different incompatible variants. Nettle implements it using the original
-definition of ChaCha, with 64 bits (8 octets) each for the nonce and the
-block counter. Some protocols prefer to use nonces of 12 bytes, and it's
-a small change to ChaCha to use the upper 32 bits of the block counter
-as a nonce, instead limiting message size to @math{2^32} blocks or 256
-GBytes, but that variant is currently not supported.
+defines a similar construction but with Salsa20 instead of ChaCha.
+
+Nettle's implementation of ChaCha-Poly1305 follows @cite{RFC 8439},
+where the ChaCha cipher is initialized with a 12-byte nonce and a 4-byte
+block counter. This allows up to 256 gigabytes of data to be encrypted
+using the same key.
For ChaCha-Poly1305, the ChaCha cipher is initialized with a key, of 256
bits, and a per-message nonce. The first block of the key stream
@@ -3362,7 +3357,7 @@ ChaCha-Poly1305 key size, 32.
@end defvr
@defvr Constant CHACHA_POLY1305_NONCE_SIZE
-Same as the ChaCha nonce size, 16.
+ChaCha-Poly1305 nonce size, 12.
@end defvr
@defvr Constant CHACHA_POLY1305_DIGEST_SIZE
--
2.24.1
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
[PATCH v2 2/3] chacha: add variant that treats counter value as 32-bit
From: Daiki Ueno
The ChaCha-Poly1305 implementation previously used the chacha_crypt
function that assumes the block counter is 64-bit long, while RFC 8439
defines that the counter is 32-bit long. Although this should be fine
as long as up to 256 gigabytes of data is encrypted with the same key,
it would be nice to use a separate functions (chacha_set_counter32 and
chacha_crypt32) that assume the counter is 32-bit long.
Signed-off-by: Daiki Ueno
---
chacha-crypt.c | 32
chacha-poly1305.c | 4 ++--
chacha-set-nonce.c | 6 ++
chacha.h| 10 ++
nettle.texinfo | 31 +++
testsuite/chacha-test.c | 34 ++
6 files changed, 111 insertions(+), 6 deletions(-)
diff --git a/chacha-crypt.c b/chacha-crypt.c
index 63d799ce..0bb44ed9 100644
--- a/chacha-crypt.c
+++ b/chacha-crypt.c
@@ -85,3 +85,35 @@ chacha_crypt(struct chacha_ctx *ctx,
m += CHACHA_BLOCK_SIZE;
}
}
+
+void
+chacha_crypt32(struct chacha_ctx *ctx,
+ size_t length,
+ uint8_t *c,
+ const uint8_t *m)
+{
+ if (!length)
+return;
+
+ for (;;)
+{
+ uint32_t x[_CHACHA_STATE_LENGTH];
+
+ _chacha_core (x, ctx->state, CHACHA_ROUNDS);
+
+ ++ctx->state[12];
+
+ /* stopping at 2^70 length per nonce is user's responsibility */
+
+ if (length <= CHACHA_BLOCK_SIZE)
+ {
+ memxor3 (c, m, x, length);
+ return;
+ }
+ memxor3 (c, m, x, CHACHA_BLOCK_SIZE);
+
+ length -= CHACHA_BLOCK_SIZE;
+ c += CHACHA_BLOCK_SIZE;
+ m += CHACHA_BLOCK_SIZE;
+ }
+}
diff --git a/chacha-poly1305.c b/chacha-poly1305.c
index 974a5022..a15fef0c 100644
--- a/chacha-poly1305.c
+++ b/chacha-poly1305.c
@@ -130,7 +130,7 @@ chacha_poly1305_encrypt (struct chacha_poly1305_ctx *ctx,
assert (ctx->data_size % CHACHA_POLY1305_BLOCK_SIZE == 0);
poly1305_pad (ctx);
- chacha_crypt (&ctx->chacha, length, dst, src);
+ chacha_crypt32 (&ctx->chacha, length, dst, src);
poly1305_update (ctx, length, dst);
ctx->data_size += length;
}
@@ -146,7 +146,7 @@ chacha_poly1305_decrypt (struct chacha_poly1305_ctx *ctx,
poly1305_pad (ctx);
poly1305_update (ctx, length, src);
- chacha_crypt (&ctx->chacha, length, dst, src);
+ chacha_crypt32 (&ctx->chacha, length, dst, src);
ctx->data_size += length;
}
diff --git a/chacha-set-nonce.c b/chacha-set-nonce.c
index 2c34e498..1547aea1 100644
--- a/chacha-set-nonce.c
+++ b/chacha-set-nonce.c
@@ -75,3 +75,9 @@ chacha_set_counter(struct chacha_ctx *ctx, const uint8_t
*counter)
ctx->state[12] = LE_READ_UINT32(counter + 0);
ctx->state[13] = LE_READ_UINT32(counter + 4);
}
+
+void
+chacha_set_counter32(struct chacha_ctx *ctx, const uint8_t *counter)
+{
+ ctx->state[12] = LE_READ_UINT32(counter + 0);
+}
diff --git a/chacha.h b/chacha.h
index 440fe968..fe28b835 100644
--- a/chacha.h
+++ b/chacha.h
@@ -47,7 +47,9 @@ extern "C" {
#define chacha_set_nonce nettle_chacha_set_nonce
#define chacha_set_nonce96 nettle_chacha_set_nonce96
#define chacha_set_counter nettle_chacha_set_counter
+#define chacha_set_counter32 nettle_chacha_set_counter32
#define chacha_crypt nettle_chacha_crypt
+#define chacha_crypt32 nettle_chacha_crypt32
/* Currently, only 256-bit keys are supported. */
#define CHACHA_KEY_SIZE 32
@@ -55,6 +57,7 @@ extern "C" {
#define CHACHA_NONCE_SIZE 8
#define CHACHA_NONCE96_SIZE 12
#define CHACHA_COUNTER_SIZE 8
+#define CHACHA_COUNTER32_SIZE 4
#define _CHACHA_STATE_LENGTH 16
@@ -86,10 +89,17 @@ chacha_set_nonce96(struct chacha_ctx *ctx, const uint8_t
*nonce);
void
chacha_set_counter(struct chacha_ctx *ctx, const uint8_t *counter);
+void
+chacha_set_counter32(struct chacha_ctx *ctx, const uint8_t *counter);
+
void
chacha_crypt(struct chacha_ctx *ctx, size_t length,
uint8_t *dst, const uint8_t *src);
+void
+chacha_crypt32(struct chacha_ctx *ctx, size_t length,
+ uint8_t *dst, const uint8_t *src);
+
#ifdef __cplusplus
}
#endif
diff --git a/nettle.texinfo b/nettle.texinfo
index 0b339f51..fe44f6af 100644
--- a/nettle.texinfo
+++ b/nettle.texinfo
@@ -1700,6 +1700,37 @@ all but the last call @emph{must} use a length that is a
multiple of
@code{CHACHA_BLOCK_SIZE}.
@end deftypefun
+@subsubsection 32-bit counter variant
+
+While the original paper uses 64-bit counter value, the variant defined
+in @cite{RFC 8439} uses 32-bit counter value. This variant is
+particularly useful for @pxref{ChaCha-Poly1305} AEAD construction, which
+supports 12-octet nonces.
+
+@defvr Constant CHACHA_NONCE96_SIZE
+Size of the nonce, 12.
+@end defvr
+
+@defvr Constant CHACHA_COUNTER32_SIZE
+Size of the counter, 4.
+@end defvr
+
+@deftypefun void chacha_set_nonce96 (struct chacha_ctx *@var{ctx}, const
uint8_t *@var{nonce})
+Sets the nonce
[PATCH 1/2] chacha: add function to set initial block counter
From: Daiki Ueno
The ChaCha20 based header protection algorithm in QUIC requires a way
to set the initial value of counter:
https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#name-chacha20-based-header-prote
This will add a new function chacha_set_counter, which takes an
8-octet initial value of the block counter.
Signed-off-by: Daiki Ueno
---
chacha-set-nonce.c | 7 +++
chacha.h| 5 +
nettle.texinfo | 12
testsuite/chacha-test.c | 37 +++--
4 files changed, 59 insertions(+), 2 deletions(-)
diff --git a/chacha-set-nonce.c b/chacha-set-nonce.c
index 607f176b..2c34e498 100644
--- a/chacha-set-nonce.c
+++ b/chacha-set-nonce.c
@@ -68,3 +68,10 @@ chacha_set_nonce96(struct chacha_ctx *ctx, const uint8_t
*nonce)
ctx->state[14] = LE_READ_UINT32(nonce + 4);
ctx->state[15] = LE_READ_UINT32(nonce + 8);
}
+
+void
+chacha_set_counter(struct chacha_ctx *ctx, const uint8_t *counter)
+{
+ ctx->state[12] = LE_READ_UINT32(counter + 0);
+ ctx->state[13] = LE_READ_UINT32(counter + 4);
+}
diff --git a/chacha.h b/chacha.h
index 429a55b6..440fe968 100644
--- a/chacha.h
+++ b/chacha.h
@@ -46,6 +46,7 @@ extern "C" {
#define chacha_set_key nettle_chacha_set_key
#define chacha_set_nonce nettle_chacha_set_nonce
#define chacha_set_nonce96 nettle_chacha_set_nonce96
+#define chacha_set_counter nettle_chacha_set_counter
#define chacha_crypt nettle_chacha_crypt
/* Currently, only 256-bit keys are supported. */
@@ -53,6 +54,7 @@ extern "C" {
#define CHACHA_BLOCK_SIZE 64
#define CHACHA_NONCE_SIZE 8
#define CHACHA_NONCE96_SIZE 12
+#define CHACHA_COUNTER_SIZE 8
#define _CHACHA_STATE_LENGTH 16
@@ -81,6 +83,9 @@ chacha_set_nonce(struct chacha_ctx *ctx, const uint8_t
*nonce);
void
chacha_set_nonce96(struct chacha_ctx *ctx, const uint8_t *nonce);
+void
+chacha_set_counter(struct chacha_ctx *ctx, const uint8_t *counter);
+
void
chacha_crypt(struct chacha_ctx *ctx, size_t length,
uint8_t *dst, const uint8_t *src);
diff --git a/nettle.texinfo b/nettle.texinfo
index 19eb6d34..0b339f51 100644
--- a/nettle.texinfo
+++ b/nettle.texinfo
@@ -1669,6 +1669,10 @@ ChaCha block size, 64.
Size of the nonce, 8.
@end defvr
+@defvr Constant CHACHA_COUNTER_SIZE
+Size of the counter, 8.
+@end defvr
+
@deftypefun void chacha_set_key (struct chacha_ctx *@var{ctx}, const uint8_t
*@var{key})
Initialize the cipher. The same function is used for both encryption and
decryption. Before using the cipher,
@@ -1681,6 +1685,14 @@ octets. This function also initializes the block
counter, setting it to
zero.
@end deftypefun
+@deftypefun void chacha_set_counter (struct chacha_ctx *@var{ctx}, const
uint8_t *@var{counter})
+Sets the block counter. It is always of size @code{CHACHA_COUNTER_SIZE},
+8 octets. This is rarely needed since @code{chacha_set_nonce}
+initializes the block counter to zero. When it is still necessary, this
+function must be called after @code{chacha_set_nonce}.
+
+@end deftypefun
+
@deftypefun void chacha_crypt (struct chacha_ctx *@var{ctx}, size_t
@var{length}, uint8_t *@var{dst}, const uint8_t *@var{src})
Encrypts or decrypts the data of a message, using ChaCha. When a
message is encrypted using a sequence of calls to @code{chacha_crypt},
diff --git a/testsuite/chacha-test.c b/testsuite/chacha-test.c
index d6489e9c..6875d4bb 100644
--- a/testsuite/chacha-test.c
+++ b/testsuite/chacha-test.c
@@ -38,8 +38,9 @@
#include "chacha-internal.h"
static void
-test_chacha(const struct tstring *key, const struct tstring *nonce,
- const struct tstring *expected, unsigned rounds)
+_test_chacha(const struct tstring *key, const struct tstring *nonce,
+const struct tstring *expected, unsigned rounds,
+const struct tstring *counter)
{
struct chacha_ctx ctx;
@@ -69,6 +70,9 @@ test_chacha(const struct tstring *key, const struct tstring
*nonce,
else
die ("Bad nonce size %u.\n", (unsigned) nonce->length);
+ if (counter)
+ chacha_set_counter(&ctx, counter->data);
+
chacha_crypt (&ctx, length, data, data);
ASSERT (data[-1] == 17);
@@ -98,6 +102,8 @@ test_chacha(const struct tstring *key, const struct tstring
*nonce,
ASSERT (nonce->length == CHACHA_NONCE_SIZE);
chacha_set_nonce(&ctx, nonce->data);
+ if (counter)
+ chacha_set_counter(&ctx, counter->data);
_chacha_core (out, ctx.state, rounds);
if (!MEMEQ(CHACHA_BLOCK_SIZE, out, expected->data))
@@ -117,6 +123,21 @@ test_chacha(const struct tstring *key, const struct
tstring *nonce,
}
}
+static void
+test_chacha(const struct tstring *key, const struct tstring *nonce,
+ const struct tstring *expected, unsigned rounds)
+{
+ _test_chacha(key, nonce, expected, rounds, NULL);
+}
+
+static void
+test_chacha_with_counter(c
[PATCH 2/2] doc: match ChaCha-Poly1305 documentation to the implementation
From: Daiki Ueno
While the documentation said the nonce size is 16 octets, the
implementation actually assumed 12 octets following RFC 7539.
Signed-off-by: Daiki Ueno
---
nettle.texinfo | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/nettle.texinfo b/nettle.texinfo
index 0b339f51..7d5e1780 100644
--- a/nettle.texinfo
+++ b/nettle.texinfo
@@ -3292,17 +3292,10 @@ except that @var{cipher} and @var{f} are replaced with
a context structure.
ChaCha-Poly1305 is a combination of the ChaCha stream cipher and the
poly1305 message authentication code (@pxref{Poly1305}). It originates
from the NaCl cryptographic library by D. J. Bernstein et al, which
-defines a similar construction but with Salsa20 instead of ChaCha.
-
-Nettle's implementation ChaCha-Poly1305 should be considered
-@strong{experimental}. At the time of this writing, there is no
-authoritative specification for ChaCha-Poly1305, and a couple of
-different incompatible variants. Nettle implements it using the original
-definition of ChaCha, with 64 bits (8 octets) each for the nonce and the
-block counter. Some protocols prefer to use nonces of 12 bytes, and it's
-a small change to ChaCha to use the upper 32 bits of the block counter
-as a nonce, instead limiting message size to @math{2^32} blocks or 256
-GBytes, but that variant is currently not supported.
+defines a similar construction but with Salsa20 instead of ChaCha.
+
+Nettle's implementation of ChaCha-Poly1305 follows @cite{RFC 7539}.
+Unlike the original definition of ChaCha, the nonces are of 12 bytes.
For ChaCha-Poly1305, the ChaCha cipher is initialized with a key, of 256
bits, and a per-message nonce. The first block of the key stream
@@ -3331,7 +3324,7 @@ ChaCha-Poly1305 key size, 32.
@end defvr
@defvr Constant CHACHA_POLY1305_NONCE_SIZE
-Same as the ChaCha nonce size, 16.
+ChaCha-Poly1305 nonce size, 12.
@end defvr
@defvr Constant CHACHA_POLY1305_DIGEST_SIZE
--
2.24.1
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] chacha: add function to set the initial value of counter
Hello, ni...@lysator.liu.se (Niels Möller) writes: > Daiki Ueno writes: > >> The ChaCha20 based header protection algorithm in QUIC requires a way >> to set the initial value of counter: >> https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#name-chacha20-based-header-prote > > Out of curiosity, are you aware on any quic implementation using Nettle? There is an ongoing effort to add an ngtcp2 backend based on GnuTLS, which surely uses Nettle under the hood: https://gitlab.com/gnutls/gnutls/-/merge_requests/1197 >> This will add a new function chacha_set_nonce128, which takes the >> counter value embedded in the nonce. > > I see two issues with this change as is. > > First is purely an interface design issue. It may be more useful to have > a separate function to set the 32-bit counter. E.g., that would be > convenient for random access to a chacha-encrypted file. > > The other is more subtle and with interop implications. The way the > counter is currently updated in chacha_crypt still assumes a 64-bit > counter (as in the original chacha papers with 64 bits each for nonce > and counter). This is compatible with RFC 8439, as long as the counter > is initialized to a small value such as 0 or 1. But if counter is > initialized to a random 32-bit value, and is expected to wrap around mod > 2^32, then Nettle will not work as expected but propagate carry into the > first 32-bits of the nonce. > > Not sure how to best deal with this. > > It looks like chacha was added in Nettle-3.0, and chacha_set_nonce96 > added in Nettle-3.1 (undocumented and used in the implementation of > ChaCha-Poly1305). The Nettle-3.1 release also updated chacha-poly1305 to > follow draft-irtf-cfrg-chacha20-poly1305-08 (which later evolved into > RFC 8439, if I understood the document history correstly). It seems this > change is not documented in the manual or in NEWS; the manual still says > that chacha-poly1305 use 64-bit nonce and is experimental. For the QUIC use, I guess it would be acceptable that the 32-bit counter value is only accessible from the chacha_poly1305_* interface (i.e., chacha_poly1305_set_counter), as we would just need to trim the Poly1305 tag at the end of the ciphertext. Regards, -- Daiki Ueno ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
[PATCH] chacha: add function to set the initial value of counter
From: Daiki Ueno
The ChaCha20 based header protection algorithm in QUIC requires a way
to set the initial value of counter:
https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#name-chacha20-based-header-prote
This will add a new function chacha_set_nonce128, which takes the
counter value embedded in the nonce.
Signed-off-by: Daiki Ueno
---
chacha-set-nonce.c | 9 +
chacha.h| 5 +
testsuite/chacha-test.c | 15 +++
3 files changed, 29 insertions(+)
diff --git a/chacha-set-nonce.c b/chacha-set-nonce.c
index 607f176b..7098de58 100644
--- a/chacha-set-nonce.c
+++ b/chacha-set-nonce.c
@@ -68,3 +68,12 @@ chacha_set_nonce96(struct chacha_ctx *ctx, const uint8_t
*nonce)
ctx->state[14] = LE_READ_UINT32(nonce + 4);
ctx->state[15] = LE_READ_UINT32(nonce + 8);
}
+
+void
+chacha_set_nonce128(struct chacha_ctx *ctx, const uint8_t *nonce)
+{
+ ctx->state[12] = LE_READ_UINT32(nonce + 0);
+ ctx->state[13] = LE_READ_UINT32(nonce + 4);
+ ctx->state[14] = LE_READ_UINT32(nonce + 8);
+ ctx->state[15] = LE_READ_UINT32(nonce + 12);
+}
diff --git a/chacha.h b/chacha.h
index 429a55b6..ff33f03d 100644
--- a/chacha.h
+++ b/chacha.h
@@ -46,6 +46,7 @@ extern "C" {
#define chacha_set_key nettle_chacha_set_key
#define chacha_set_nonce nettle_chacha_set_nonce
#define chacha_set_nonce96 nettle_chacha_set_nonce96
+#define chacha_set_nonce128 nettle_chacha_set_nonce128
#define chacha_crypt nettle_chacha_crypt
/* Currently, only 256-bit keys are supported. */
@@ -53,6 +54,7 @@ extern "C" {
#define CHACHA_BLOCK_SIZE 64
#define CHACHA_NONCE_SIZE 8
#define CHACHA_NONCE96_SIZE 12
+#define CHACHA_NONCE128_SIZE 16
#define _CHACHA_STATE_LENGTH 16
@@ -81,6 +83,9 @@ chacha_set_nonce(struct chacha_ctx *ctx, const uint8_t
*nonce);
void
chacha_set_nonce96(struct chacha_ctx *ctx, const uint8_t *nonce);
+void
+chacha_set_nonce128(struct chacha_ctx *ctx, const uint8_t *nonce);
+
void
chacha_crypt(struct chacha_ctx *ctx, size_t length,
uint8_t *dst, const uint8_t *src);
diff --git a/testsuite/chacha-test.c b/testsuite/chacha-test.c
index d6489e9c..4731598b 100644
--- a/testsuite/chacha-test.c
+++ b/testsuite/chacha-test.c
@@ -66,6 +66,10 @@ test_chacha(const struct tstring *key, const struct tstring
*nonce,
draft-irtf-cfrg-chacha20-poly1305-08 test cases. */
ctx.state[12]++;
}
+ else if (nonce->length == CHACHA_NONCE128_SIZE)
+ {
+ chacha_set_nonce128(&ctx, nonce->data);
+ }
else
die ("Bad nonce size %u.\n", (unsigned) nonce->length);
@@ -644,4 +648,15 @@ test_main(void)
"d2826446079faa09 14c2d705d98b02a2"
"b5129cd1de164eb9 cbd083e8a2503c4e"),
20);
+
+ /* This is identical to the 96-bit nonce test, but it manually sets
+ the counter value */
+ test_chacha(SHEX("0001020304050607 08090a0b0c0d0e0f"
+ "1011121314151617 18191a1b1c1d1e1f"),
+ SHEX("0109 004a"),
+ SHEX("10f1e7e4d13b5915 500fdd1fa32071c4"
+ "c7d1f4c733c06803 0422aa9ac3d46c4e"
+ "d2826446079faa09 14c2d705d98b02a2"
+ "b5129cd1de164eb9 cbd083e8a2503c4e"),
+ 20);
}
--
2.24.1
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH 0/8] Implement Curve448 ECDH and Ed448
Hello Niels,
Thank you very much for all the Curve448/SHAKE256 work for merging (I'm
slowly catching up).
ni...@lysator.liu.se (Niels Möller) writes:
> ni...@lysator.liu.se (Niels Möller) writes:
>
>> Daiki Ueno writes:
>>
>>> For curve25519, q is defined as:
>>>
>>> 2^252 + 0x14def9dea2f79cd65812631a5cf5d3ed
>>>
>>> whose bit pattern starts with 0x1000, so r - q * (r>>252) should
>>> work.
>>>
>>> On the other hand, for curve448, q is defined as:
>>>
>>> 2^446 - 0x8335dc163bb124b65129c96fde933d8d723a70aadc873d6d54a7bb0d
>>>
>>> whose bit pattern starts with 0x. In that case the formula (r - q *
>>> (r>>445)) could be incorrect due to the accumulated errors by
>>> multiplication (i.e. q * 0x7FFF...).
>>
>> Good catch! Right, this needs a bit more analysis. Fur curve25519, the
>> subtraction can underflow (unlikely), which is addressed with the
>> conditional addition a few lines down.
>
> For ecc_ah_to_a, this code was deleted, but it's still an issue for
> eddsa_sign. Maybe need special cases for both ed25519 and ed448 for now.
> Or some logic looking at the high limb of q.
>
> These corner cases are a bit hard to test.
For what it's worth, the original issue was reliably reproducible with
the GnuTLS port[1] against the OpenSSL client. Here is a test vector
extracted from the interaction:
test_one
("0cf87eb094bf46d161bde3b99d1d32856fecfae0142392cd98c091db206d174bbf8ef476a9cf746d94306c565f97ac50796f021eff8d779ca5"
"9addde61f668f2dbc0ac24874adb47a2aa6ad59fa888bdc5d430705ed0796a8c330782b51860785be63fd79b1c7cf58fd728b2bf3d77395100:"
"9addde61f668f2dbc0ac24874adb47a2aa6ad59fa888bdc5d430705ed0796a8c330782b51860785be63fd79b1c7cf58fd728b2bf3d77395100:"
"20202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020544c5320312e332c207365727665722043657274696669636174655665726966790090da2c6178a3019274ed029ba5ad28f25662a78d71e8429c19f96007df39d7a77d7cb80f221c76db5e1c397714f48692:"
"91554b9b85058d3d6885997adf47e1f766ae780018ca26873de854fb12d789f3bf1f85d3ce5b23265d8d8900f62906e2eb4a064887beaf9cea26f0edeff35be1e969df77ab1368ced966beb0c7b6242aa0d8844d773e254cfed823d3a5e53b3ef557e716ce7cc2aaca127e86798f2b00"
"20202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020544c5320312e332c207365727665722043657274696669636174655665726966790090da2c6178a3019274ed029ba5ad28f25662a78d71e8429c19f96007df39d7a77d7cb80f221c76db5e1c397714f48692:");
>> It might make sense to instead add a function pointer to struct
>> ecc_modulo to do canonical reduction; that's needed in a few different
>> places, not only here.
>
> I still think think this makes sense, but it's not clear to me what the
> usage really is.
Regards,
Footnotes:
[1] https://gitlab.com/gnutls/gnutls/merge_requests/984
--
Daiki Ueno
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH 0/8] Implement Curve448 ECDH and Ed448
ni...@lysator.liu.se (Niels Möller) writes:
> Daiki Ueno writes:
>
>> From 8bc6e735d4b40cbab5e187a28e01b63a04ecd92b Mon Sep 17 00:00:00 2001
>> From: Daiki Ueno
>> Date: Fri, 23 Jun 2017 17:26:18 +0200
>> Subject: [PATCH 2/4] Implement Curve448 primitives
>>
>> This patch adds the necessary primitives for "curve448", defined in
>> RFC 7748. Those primitives are namely: addition, doubling, scalar
>> multiplication of the generator or an arbitrary point, inversion, and
>> square root.
>
> At last, I've now merged this onto the curve448 branch.
That's a great news, thank you Niels!
> I see you've made some chenges to the needed scratch space, if I
> understand it correctly, you need to allow h_to_a_itch larger than
> mul_itch or mul_g_itch. You increase the value of ECC_ECDSA_SIGN_ITCH
> and add a new ECC_ECDSA_KEYGEN_ITCH. Can you comment on that?
>
> The only reason ECDSA is affected at all by curve448, is that we have
> tests for ecdsa over the curve25519 and curve448, even though that's
> not the way these curves are intended to be used. Maybe that should
> just be deleted.
Indeed, I agree to remove the tests and affected parts in the library.
> Performance for the scalar multiplication primitives seem to be slower
> than secp384 and slightly faster than secp521, and looking at point
> addition, it's slower than secp521. I hope that will be improved a quite
> a bit with an optimized mod operation for the curve448 prime.
>
>> While the interface is similar to curve25519, the implementation is
>> slightly different. For curve25519, the Pippenger tables are
>> generated through the coordinates on the Montgomery curve. On the
>> other hand, the tables for curve448 are directly generated from the
>> coordinates on the corresponding Edwards curve ("edwards448").
>
> This is no longer the case, since the handling curve 25519 was changed
> early on, based on your patches back then.
Thank you. By the way, one thing I realized in my past rebase attempts
is that, this commit doing the final reduction of a value by mod q seems
to be incorrect for curve448 and should probably be reverted:
commit 6cf6abd68eb3d6c8c8e5ab217be734f9c537037f
Author: Daiki Ueno
Date: Sat Aug 5 09:43:47 2017 +0200
ecc-eh-to-a, eddsa-sign: Parameterize hard-coded value
This allows the same code to be reused in curve448 and Ed448.
Signed-off-by: Daiki Ueno
- shift = 252 - GMP_NUMB_BITS * (ecc->p.size - 1);
+ shift = ecc->q.bit_size - 1 - GMP_NUMB_BITS * (ecc->p.size - 1);
cy = mpn_submul_1 (r, ecc->q.m, ecc->p.size,
r[ecc->p.size-1] >> shift);
For curve25519, q is defined as:
2^252 + 0x14def9dea2f79cd65812631a5cf5d3ed
whose bit pattern starts with 0x1000, so r - q * (r>>252) should
work.
On the other hand, for curve448, q is defined as:
2^446 - 0x8335dc163bb124b65129c96fde933d8d723a70aadc873d6d54a7bb0d
whose bit pattern starts with 0x. In that case the formula (r - q *
(r>>445)) could be incorrect due to the accumulated errors by
multiplication (i.e. q * 0x7FFF...).
Therefore, I suggest using r - q * (r>>446) instead, though it would
introduce another hard-coded value.
Regards,
--
Daiki Ueno
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] cfb8: don't truncate output IV if input is shorter than block size
ni...@lysator.liu.se (Niels Möller) writes:
> Daiki Ueno writes:
>
>> We realized that cfb8_decrypt doesn't update the IV correctly when the
>> input is shorter than AES block size. The attached patches should fix
>> it.
>
> For testing, I think it would be good to take the testvectors for cfb8,
> and split into multiple calls to cfb8_*crypt, in several ways. And check
> they all give the same result. A bit like it's done in arcfour-test.c,
> or the test_cipher_stream (#if:ed out, not sure if it's worth reviving).
Indeed, thank you for the suggestion. I'm attaching updated patches.
Regards,
--
Daiki Ueno
>From 2f6c2be5ec9668dc7691e5bf9e54f8ef1dde1d87 Mon Sep 17 00:00:00 2001
From: Daiki Ueno
Date: Fri, 27 Sep 2019 16:12:00 +0200
Subject: [PATCH 1/2] cfb8: don't truncate output IV if input is shorter than
block size
Previously cfb8_decrypt didn't update the IV if the input is shorter
than the AES block size. Reported by Stephan Mueller.
Signed-off-by: Daiki Ueno
---
cfb.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/cfb.c b/cfb.c
index 5429fc9c..b9da3159 100644
--- a/cfb.c
+++ b/cfb.c
@@ -226,10 +226,12 @@ cfb8_decrypt(const void *ctx, nettle_cipher_func *f,
src += i;
dst += i;
- memcpy(buffer, buffer + block_size, block_size);
- memcpy(buffer + block_size, src,
- length < block_size ? length : block_size);
-
+ if (i == block_size)
+ {
+ memcpy(buffer, buffer + block_size, block_size);
+ memcpy(buffer + block_size, src,
+ length < block_size ? length : block_size);
+ }
}
memcpy(iv, buffer + i, block_size);
--
2.21.0
>From e96bb66747ffd1dff9bded6cdb69ba866dc20f01 Mon Sep 17 00:00:00 2001
From: Daiki Ueno
Date: Tue, 1 Oct 2019 10:47:40 +0200
Subject: [PATCH 2/2] test: check all possible block sizes in test_cipher_cfb8
Signed-off-by: Daiki Ueno
---
testsuite/testutils.c | 77 ++-
1 file changed, 46 insertions(+), 31 deletions(-)
diff --git a/testsuite/testutils.c b/testsuite/testutils.c
index 2a19c0ac..b24b498a 100644
--- a/testsuite/testutils.c
+++ b/testsuite/testutils.c
@@ -434,6 +434,7 @@ test_cipher_cfb8(const struct nettle_cipher *cipher,
uint8_t *data, *data2;
uint8_t *iv = xalloc(cipher->block_size);
size_t length;
+ size_t block;
ASSERT (cleartext->length == ciphertext->length);
length = cleartext->length;
@@ -444,42 +445,56 @@ test_cipher_cfb8(const struct nettle_cipher *cipher,
data = xalloc(length);
data2 = xalloc(length);
- cipher->set_encrypt_key(ctx, key->data);
- memcpy(iv, iiv->data, cipher->block_size);
+ for (block = 1; block <= length; block++)
+{
+ size_t i;
- cfb8_encrypt(ctx, cipher->encrypt,
- cipher->block_size, iv,
- length, data, cleartext->data);
+ cipher->set_encrypt_key(ctx, key->data);
+ memcpy(iv, iiv->data, cipher->block_size);
- if (!MEMEQ(length, data, ciphertext->data))
-{
- fprintf(stderr, "CFB8 encrypt failed:\nInput:");
- tstring_print_hex(cleartext);
- fprintf(stderr, "\nOutput: ");
- print_hex(length, data);
- fprintf(stderr, "\nExpected:");
- tstring_print_hex(ciphertext);
- fprintf(stderr, "\n");
- FAIL();
-}
- cipher->set_encrypt_key(ctx, key->data);
- memcpy(iv, iiv->data, cipher->block_size);
+ for (i = 0; i + block <= length; i += block)
+ {
+ cfb8_encrypt(ctx, cipher->encrypt,
+ cipher->block_size, iv,
+ block, data + i, cleartext->data + i);
+ }
- cfb8_decrypt(ctx, cipher->encrypt,
- cipher->block_size, iv,
- length, data2, data);
+ if (!MEMEQ(length, data, ciphertext->data))
+ {
+ fprintf(stderr, "CFB8 encrypt failed, block size %lu:\nInput:",
+ block);
+ tstring_print_hex(cleartext);
+ fprintf(stderr, "\nOutput: ");
+ print_hex(length, data);
+ fprintf(stderr, "\nExpected:");
+ tstring_print_hex(ciphertext);
+ fprintf(stderr, "\n");
+ FAIL();
+ }
+ cipher->set_encrypt_key(ctx, key->data);
+ memcpy(iv, iiv->data, cipher->block_size);
- if (!MEMEQ(length, data2, cleartext->data))
-{
- fprintf(stderr, "CFB8 decrypt failed:\nInput:");
- tstring_print_hex(ciphertext);
- fprintf(stderr, "\nOutput: ");
- print_hex(length, data2);
- fprintf(stderr, "\nExpected:");
- tstring_print_hex(cleartext);
- fprintf(stderr, "\n");
- FAIL();
+ for (i = 0; i + block <= length; i += block)
+ {
+ cfb8_decrypt(ctx, cipher->encrypt,
+ cipher->block_size, iv,
+ block, data2 + i, data + i);
+ }
+
+ if (!MEMEQ(length, data2, cleartext->data))
+ {
+ fprintf(stderr, "CFB8 d
[PATCH] cfb8: don't truncate output IV if input is shorter than block size
Hello,
We realized that cfb8_decrypt doesn't update the IV correctly when the
input is shorter than AES block size. The attached patches should fix
it.
Samba is also affected by this and there are similar fixes:
https://git.samba.org/?p=gd/nettle;a=commit;h=c9926d319a44858d9bde5c28e37f37ed4e3ad39a
https://git.samba.org/?p=gd/nettle;a=commit;h=a2aa783012ab874eebe79d6150027118fc823f52
Regards,
--
Daiki Ueno
>From 69fffd761a08e7915a0b544ccb3d5e680571fc18 Mon Sep 17 00:00:00 2001
From: Daiki Ueno
Date: Mon, 30 Sep 2019 11:21:09 +0200
Subject: [PATCH 1/2] testsuite/cfb-test: check output IV
Signed-off-by: Daiki Ueno
---
testsuite/cfb-test.c | 18 --
testsuite/testutils.c | 42 --
testsuite/testutils.h | 6 --
3 files changed, 56 insertions(+), 10 deletions(-)
diff --git a/testsuite/cfb-test.c b/testsuite/cfb-test.c
index dbb24e8a..7c42bec5 100644
--- a/testsuite/cfb-test.c
+++ b/testsuite/cfb-test.c
@@ -137,7 +137,8 @@ test_main(void)
"ae2d"),
SHEX("3b79424c9c0dd436bace9e0ed4586a4f"
"32b9"),
- SHEX("000102030405060708090a0b0c0d0e0f"));
+ SHEX("000102030405060708090a0b0c0d0e0f"),
+ SHEX("424c9c0dd436bace9e0ed4586a4f32b9"));
/* From NIST spec 800-38a on AES modes.
*
@@ -152,7 +153,8 @@ test_main(void)
"ae2d"),
SHEX("cda2521ef0a905ca44cd057cbf0d47a0"
"678a"),
- SHEX("000102030405060708090a0b0c0d0e0f"));
+ SHEX("000102030405060708090a0b0c0d0e0f"),
+ SHEX("521ef0a905ca44cd057cbf0d47a0678a"));
/* From NIST spec 800-38a on AES modes.
*
@@ -167,7 +169,8 @@ test_main(void)
"ae2d"),
SHEX("dc1f1a8520a64db55fcc8ac554844e88"
"9700"),
- SHEX("000102030405060708090a0b0c0d0e0f"));
+ SHEX("000102030405060708090a0b0c0d0e0f"),
+ SHEX("1a8520a64db55fcc8ac554844e889700"));
/* From NIST spec 800-38a on AES modes.
*
@@ -192,7 +195,8 @@ test_main(void)
"c8a64537a0b3a93fcde3cdad9f1ce58b"
"26751f67a3cbb140b1808cf187a4f4df"
"c04b05357c5d1c0eeac4c66f9ff7f2e6"),
- SHEX("000102030405060708090a0b0c0d0e0f"));
+ SHEX("000102030405060708090a0b0c0d0e0f"),
+ SHEX("c04b05357c5d1c0eeac4c66f9ff7f2e6"));
/* F.3.15 CFB128-AES192.Encrypt */
@@ -215,7 +219,8 @@ test_main(void)
"67ce7f7f81173621961a2b70171d3d7a"
"2e1e8a1dd59b88b1c8e60fed1efac4c9"
"c05f9f9ca9834fa042ae8fba584b09ff"),
- SHEX("000102030405060708090a0b0c0d0e0f"));
+ SHEX("000102030405060708090a0b0c0d0e0f"),
+ SHEX("c05f9f9ca9834fa042ae8fba584b09ff"));
/* F.3.17 CFB128-AES256.Encrypt */
@@ -238,7 +243,8 @@ test_main(void)
"39ffed143b28b1c832113c6331e5407b"
"df10132415e54b92a13ed0a8267ae2f9"
"75a385741ab9cef82031623d55b1e471"),
- SHEX("000102030405060708090a0b0c0d0e0f"));
+ SHEX("000102030405060708090a0b0c0d0e0f"),
+ SHEX("75a385741ab9cef82031623d55b1e471"));
test_cfb_bulk();
test_cfb8_bulk();
diff --git a/testsuite/testutils.c b/testsuite/testutils.c
index 2a19c0ac..6f6974f9 100644
--- a/testsuite/testutils.c
+++ b/testsuite/testutils.c
@@ -250,7 +250,8 @@ test_cipher_cfb(const struct nettle_cipher *cipher,
const struct tstring *key,
const struct tstring *cleartext,
const struct tstring *ciphertext,
- const struct tstring *iiv)
+ const struct tstring *iiv,
+ const struct tstring *oiv)
{
void *ctx = xalloc(cipher->context_size);
uint8_t *data, *data2;
@@ -284,6 +285,15 @@ test_cipher_cfb(const struct nettle_cipher *cipher,
fprintf(stderr, "\n");
FAIL();
}
+ if (!MEMEQ(cipher->block_size, iv, oiv->data))
+{
+ fprintf(stderr, "CFB encrypt returned wrong IV:\nOutput:");
+ print_hex(cipher->block_size, iv);
+ fprintf(stderr, "\nExpected:");
+ tstring_print_hex(oiv);
+ fprintf(stderr, "\n");
+ FAIL();
+}
cipher->set_encrypt_key(ctx, key->data);
memcpy(iv, iiv->data, cipher->block_size);
@@ -302,6 +312,15 @@ test_cipher_cfb(const struct nettle_cipher *cipher,
fprintf(stderr, "\n");
FAIL();
}
+ if (!MEMEQ(cipher->block_size, iv, oiv->data))
+{
+ fprintf(stderr, "CFB decrypt returned wrong IV:\nOutput:");
+ print_hex(cipher->block_size, iv);
+ fprintf(stderr, "\nExpected:");
+ tstring_print_hex(oiv);
+ fprintf(stderr, "\n");
+ FAIL();
+}
cipher->set_encrypt_key(ctx, key->data);
memcpy(iv, iiv->data, cipher->block_size);
memcpy(
Re: [PATCH v2 0/6] Add meta interface for MAC algorithms
Hello, ni...@lysator.liu.se (Niels Möller) writes: > Dmitry Eremin-Solenikov writes: > >> There will be a nonce for GMAC. > > Ok. If we keep set_nonce, we have to clarify what it means. There are a > couple of cases, where the first two are relatively easy. > > nonce_size == 0, set_nonce == NULL: > Never call set_nonce. This is the HMAC case. > > nonce_size == 0, set_nonce != NULL: > This could mean that nonce is optional. Does that make any sense? > > nonce_size > 0, set_nonce != NULL: > Would then be used for UMAC and GMAC. > > For the last case, I have a couple of questions. > > 1. Comment says "suggested nonce_size", but I take it only that one size >is possible, since set_nonce is nettle_set_key_func, with no length >argument. Or do you intend to allow other sizes? > >I think I'd prefer fix size, to keep things simple. And treat >variants with different nonce size as separate mac algorithms, for >this abstraction. Just like with the key size. I think fixed size would be sufficient (the code was merely copied from the nettle_aead definition). > 2. What should be the behavior for usage like > >->set_key >->set_nonce >->update >->digest >->update >->digest > >with second set_nonce missing? > >Should it just keep the nonce from the first digest? (Sounds a bit >dangerous). Or autoincrement? (That's what umac does, because it's >defined in a way to make that more efficient). Or be specified as >invalid, triggering asserts whenever it is easy to detect? > >I think it has to be specified; it will be too confusing if UMAC >behaves in one way and GMAC behaves differently. Provided that the two types of MACs (nonces are required or not) are supposedly not intermixed, another option might be to provide a separate struct (say, nettle_nmac) for MACs that require nonces (UMAC and GMAC, not sure if there will be more to come), and mandate set_nonce != NULL: - nettle_mac (from the testutils.h definition) for HMAC, CMAC - nettle_nmac (nettle_nmac + set_nonce) for UMAC, GMAC That would be analogous to the distinction between nettle_cipher and nettle_aead and serve the documentation. Regards, -- Daiki Ueno ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
[PATCH v2 4/6] nettle-meta: Add meta interface for UMAC functions
From: Daiki Ueno
Signed-off-by: Daiki Ueno
---
Makefile.in| 1 +
nettle-meta.h | 17 +
umac128-meta.c | 47 +++
umac32-meta.c | 47 +++
umac64-meta.c | 47 +++
umac96-meta.c | 47 +++
6 files changed, 206 insertions(+)
create mode 100644 umac128-meta.c
create mode 100644 umac32-meta.c
create mode 100644 umac64-meta.c
create mode 100644 umac96-meta.c
diff --git a/Makefile.in b/Makefile.in
index 9031d959..4cfc5005 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -138,6 +138,7 @@ nettle_SOURCES = aes-decrypt-internal.c aes-decrypt.c \
umac-nh.c umac-nh-n.c umac-l2.c umac-l3.c \
umac-poly64.c umac-poly128.c umac-set-key.c \
umac32.c umac64.c umac96.c umac128.c \
+umac32-meta.c umac64-meta.c umac96-meta.c umac128-meta.c \
version.c \
write-be32.c write-le32.c write-le64.c \
yarrow256.c yarrow_key_event.c \
diff --git a/nettle-meta.h b/nettle-meta.h
index 20f5cd89..b51fb602 100644
--- a/nettle-meta.h
+++ b/nettle-meta.h
@@ -284,6 +284,18 @@ struct nettle_mac
(nettle_hash_digest_func *) name##_digest, \
}
+#define _NETTLE_UMAC(name, NAME) { \
+ #name, \
+ sizeof(struct name##_ctx), \
+ NAME##_DIGEST_SIZE, \
+ UMAC_BLOCK_SIZE, \
+ AES_BLOCK_SIZE, \
+ (nettle_set_key_func *) name##_set_key, \
+ name##_set_nonce_wrapper,\
+ (nettle_hash_update_func *) name##_update, \
+ (nettle_hash_digest_func *) name##_digest, \
+}
+
extern const struct nettle_mac nettle_cmac_aes128;
extern const struct nettle_mac nettle_cmac_aes256;
@@ -295,6 +307,11 @@ extern const struct nettle_mac nettle_hmac_sha256;
extern const struct nettle_mac nettle_hmac_sha384;
extern const struct nettle_mac nettle_hmac_sha512;
+extern const struct nettle_mac nettle_umac32;
+extern const struct nettle_mac nettle_umac64;
+extern const struct nettle_mac nettle_umac96;
+extern const struct nettle_mac nettle_umac128;
+
#ifdef __cplusplus
}
#endif
diff --git a/umac128-meta.c b/umac128-meta.c
new file mode 100644
index ..9f6a7e34
--- /dev/null
+++ b/umac128-meta.c
@@ -0,0 +1,47 @@
+/* umac128-meta.c
+
+ Copyright (C) 2013 Niels Möller
+
+ This file is part of GNU Nettle.
+
+ GNU Nettle is free software: you can redistribute it and/or
+ modify it under the terms of either:
+
+ * the GNU Lesser General Public License as published by the Free
+ Software Foundation; either version 3 of the License, or (at your
+ option) any later version.
+
+ or
+
+ * the GNU General Public License as published by the Free
+ Software Foundation; either version 2 of the License, or (at your
+ option) any later version.
+
+ or both in parallel, as here.
+
+ GNU Nettle 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
+ General Public License for more details.
+
+ You should have received copies of the GNU General Public License and
+ the GNU Lesser General Public License along with this program. If
+ not, see http://www.gnu.org/licenses/.
+*/
+
+#if HAVE_CONFIG_H
+# include "config.h"
+#endif
+
+#include "nettle-meta.h"
+
+#include "umac.h"
+
+static void
+umac128_set_nonce_wrapper (void *ctx, const uint8_t *key)
+{
+ umac128_set_nonce (ctx, AES_BLOCK_SIZE, key);
+}
+
+const struct nettle_mac nettle_umac128
+= _NETTLE_UMAC(umac128, UMAC128);
diff --git a/umac32-meta.c b/umac32-meta.c
new file mode 100644
index ..2b4f9c14
--- /dev/null
+++ b/umac32-meta.c
@@ -0,0 +1,47 @@
+/* umac32-meta.c
+
+ Copyright (C) 2013 Niels Möller
+
+ This file is part of GNU Nettle.
+
+ GNU Nettle is free software: you can redistribute it and/or
+ modify it under the terms of either:
+
+ * the GNU Lesser General Public License as published by the Free
+ Software Foundation; either version 3 of the License, or (at your
+ option) any later version.
+
+ or
+
+ * the GNU General Public License as published by the Free
+ Software Foundation; either version 2 of the License, or (at your
+ option) any later version.
+
+ or both in parallel, as here.
+
+ GNU Nettle 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
+ General Public License for more details.
+
+ You should have received copies of the GNU General Public License and
+ the GNU Lesser General Public Licens
[PATCH v2 1/6] nettle-meta: Move struct nettle_mac to nettle-meta.h
From: Daiki Ueno
The struct was defined in testutils.h as the interface was not
stable. This generalizes the interface to cover all defined MAC
algorithms in nettle.
Signed-off-by: Daiki Ueno
---
nettle-meta.h | 22 ++
testsuite/testutils.h | 29 -
2 files changed, 22 insertions(+), 29 deletions(-)
diff --git a/nettle-meta.h b/nettle-meta.h
index 74e50e59..b03da208 100644
--- a/nettle-meta.h
+++ b/nettle-meta.h
@@ -238,6 +238,28 @@ extern const struct nettle_armor nettle_base64;
extern const struct nettle_armor nettle_base64url;
extern const struct nettle_armor nettle_base16;
+struct nettle_mac
+{
+ const char *name;
+
+ /* Size of the context struct */
+ unsigned context_size;
+
+ /* Size of digests */
+ unsigned digest_size;
+
+ /* Suggested key size; other sizes are sometimes possible */
+ unsigned key_size;
+
+ /* Suggested nonce size; 0 if nonce is not used */
+ unsigned nonce_size;
+
+ nettle_set_key_func *set_key;
+ nettle_set_key_func *set_nonce;
+ nettle_hash_update_func *update;
+ nettle_hash_digest_func *digest;
+};
+
#ifdef __cplusplus
}
#endif
diff --git a/testsuite/testutils.h b/testsuite/testutils.h
index f4ea38da..78daf62b 100644
--- a/testsuite/testutils.h
+++ b/testsuite/testutils.h
@@ -79,35 +79,6 @@ test_main(void);
extern int verbose;
-/* FIXME: When interface stabilizes, move to nettle-meta.h */
-struct nettle_mac
-{
- const char *name;
-
- /* Size of the context struct */
- unsigned context_size;
-
- /* Size of digests */
- unsigned digest_size;
-
- /* Suggested key size; other sizes are sometimes possible. */
- unsigned key_size;
-
- nettle_set_key_func *set_key;
- nettle_hash_update_func *update;
- nettle_hash_digest_func *digest;
-};
-
-#define _NETTLE_HMAC(name, NAME, keysize) {\
- #name, \
- sizeof(struct hmac_##name##_ctx),\
- NAME##_DIGEST_SIZE, \
- NAME##_DIGEST_SIZE, \
- hmac_##name##_set_key, \
- hmac_##name##_update,\
- hmac_##name##_digest,\
-}
-
/* Test functions deallocate their inputs when finished.*/
void
test_cipher(const struct nettle_cipher *cipher,
--
2.21.0
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
[PATCH v2 3/6] nettle-meta: Add meta interface for HMAC functions
From: Daiki Ueno
Signed-off-by: Daiki Ueno
---
Makefile.in | 3 +++
hmac-md5-meta.c | 47 +++
hmac-ripemd160-meta.c | 47 +++
hmac-sha1-meta.c | 47 +++
hmac-sha224-meta.c| 47 +++
hmac-sha256-meta.c| 47 +++
hmac-sha384-meta.c| 47 +++
hmac-sha512-meta.c| 47 +++
nettle-meta.h | 20 ++
9 files changed, 352 insertions(+)
create mode 100644 hmac-md5-meta.c
create mode 100644 hmac-ripemd160-meta.c
create mode 100644 hmac-sha1-meta.c
create mode 100644 hmac-sha224-meta.c
create mode 100644 hmac-sha256-meta.c
create mode 100644 hmac-sha384-meta.c
create mode 100644 hmac-sha512-meta.c
diff --git a/Makefile.in b/Makefile.in
index 6a425e16..9031d959 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -107,6 +107,9 @@ nettle_SOURCES = aes-decrypt-internal.c aes-decrypt.c \
gosthash94.c gosthash94-meta.c \
hmac.c hmac-md5.c hmac-ripemd160.c hmac-sha1.c \
hmac-sha224.c hmac-sha256.c hmac-sha384.c hmac-sha512.c \
+hmac-md5-meta.c hmac-ripemd160-meta.c hmac-sha1-meta.c \
+hmac-sha224-meta.c hmac-sha256-meta.c hmac-sha384-meta.c \
+hmac-sha512-meta.c \
knuth-lfib.c hkdf.c \
md2.c md2-meta.c md4.c md4-meta.c \
md5.c md5-compress.c md5-compat.c md5-meta.c \
diff --git a/hmac-md5-meta.c b/hmac-md5-meta.c
new file mode 100644
index ..3933a455
--- /dev/null
+++ b/hmac-md5-meta.c
@@ -0,0 +1,47 @@
+/* hmac-md5-meta.c
+
+ Copyright (C) 2002 Niels Möller
+
+ This file is part of GNU Nettle.
+
+ GNU Nettle is free software: you can redistribute it and/or
+ modify it under the terms of either:
+
+ * the GNU Lesser General Public License as published by the Free
+ Software Foundation; either version 3 of the License, or (at your
+ option) any later version.
+
+ or
+
+ * the GNU General Public License as published by the Free
+ Software Foundation; either version 2 of the License, or (at your
+ option) any later version.
+
+ or both in parallel, as here.
+
+ GNU Nettle 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
+ General Public License for more details.
+
+ You should have received copies of the GNU General Public License and
+ the GNU Lesser General Public License along with this program. If
+ not, see http://www.gnu.org/licenses/.
+*/
+
+#if HAVE_CONFIG_H
+# include "config.h"
+#endif
+
+#include "nettle-meta.h"
+
+#include "hmac.h"
+
+static void
+hmac_md5_set_key_wrapper (void *ctx, const uint8_t *key)
+{
+ hmac_md5_set_key (ctx, MD5_BLOCK_SIZE, key);
+}
+
+const struct nettle_mac nettle_hmac_md5
+= _NETTLE_HMAC(hmac_md5, MD5);
diff --git a/hmac-ripemd160-meta.c b/hmac-ripemd160-meta.c
new file mode 100644
index ..86469650
--- /dev/null
+++ b/hmac-ripemd160-meta.c
@@ -0,0 +1,47 @@
+/* hmac-ripemd160-meta.c
+
+ Copyright (C) 2011 Andres Mejia
+
+ This file is part of GNU Nettle.
+
+ GNU Nettle is free software: you can redistribute it and/or
+ modify it under the terms of either:
+
+ * the GNU Lesser General Public License as published by the Free
+ Software Foundation; either version 3 of the License, or (at your
+ option) any later version.
+
+ or
+
+ * the GNU General Public License as published by the Free
+ Software Foundation; either version 2 of the License, or (at your
+ option) any later version.
+
+ or both in parallel, as here.
+
+ GNU Nettle 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
+ General Public License for more details.
+
+ You should have received copies of the GNU General Public License and
+ the GNU Lesser General Public License along with this program. If
+ not, see http://www.gnu.org/licenses/.
+*/
+
+#if HAVE_CONFIG_H
+# include "config.h"
+#endif
+
+#include "nettle-meta.h"
+
+#include "hmac.h"
+
+static void
+hmac_ripemd160_set_key_wrapper (void *ctx, const uint8_t *key)
+{
+ hmac_ripemd160_set_key (ctx, RIPEMD160_BLOCK_SIZE, key);
+}
+
+const struct nettle_mac nettle_hmac_ripemd160
+= _NETTLE_HMAC(hmac_ripemd160, RIPEMD160);
diff --git a/hmac-sha1-meta.c b/hmac-sha1-meta.c
new file mode 100644
index ..14d34d2b
--- /dev/null
+++ b/hmac-sha1-meta.c
@@ -0,0 +1,47 @@
+/* hmac-sha1-meta.c
+
+ Copyright (C) 2002 Niels Möller
+
+ This f
[PATCH v2 2/6] nettle-meta: Add meta interface for CMAC functions
From: Daiki Ueno
Signed-off-by: Daiki Ueno
---
Makefile.in | 1 +
cmac-aes128-meta.c| 43 +++
cmac-aes256-meta.c| 43 +++
nettle-meta.h | 15 +++
testsuite/cmac-test.c | 24
5 files changed, 102 insertions(+), 24 deletions(-)
create mode 100644 cmac-aes128-meta.c
create mode 100644 cmac-aes256-meta.c
diff --git a/Makefile.in b/Makefile.in
index b54e64b0..6a425e16 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -103,6 +103,7 @@ nettle_SOURCES = aes-decrypt-internal.c aes-decrypt.c \
gcm-camellia128.c gcm-camellia128-meta.c \
gcm-camellia256.c gcm-camellia256-meta.c \
cmac.c cmac-aes128.c cmac-aes256.c \
+cmac-aes128-meta.c cmac-aes256-meta.c \
gosthash94.c gosthash94-meta.c \
hmac.c hmac-md5.c hmac-ripemd160.c hmac-sha1.c \
hmac-sha224.c hmac-sha256.c hmac-sha384.c hmac-sha512.c \
diff --git a/cmac-aes128-meta.c b/cmac-aes128-meta.c
new file mode 100644
index ..6239984b
--- /dev/null
+++ b/cmac-aes128-meta.c
@@ -0,0 +1,43 @@
+/* cmac-aes128-meta.c
+
+ Copyright (C) 2013, 2014 Niels Möller
+
+ This file is part of GNU Nettle.
+
+ GNU Nettle is free software: you can redistribute it and/or
+ modify it under the terms of either:
+
+ * the GNU Lesser General Public License as published by the Free
+ Software Foundation; either version 3 of the License, or (at your
+ option) any later version.
+
+ or
+
+ * the GNU General Public License as published by the Free
+ Software Foundation; either version 2 of the License, or (at your
+ option) any later version.
+
+ or both in parallel, as here.
+
+ GNU Nettle 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
+ General Public License for more details.
+
+ You should have received copies of the GNU General Public License and
+ the GNU Lesser General Public License along with this program. If
+ not, see http://www.gnu.org/licenses/.
+*/
+
+#if HAVE_CONFIG_H
+# include "config.h"
+#endif
+
+#include
+
+#include "nettle-meta.h"
+
+#include "cmac.h"
+
+const struct nettle_mac nettle_cmac_aes128
+= _NETTLE_CMAC(cmac_aes128, AES128);
diff --git a/cmac-aes256-meta.c b/cmac-aes256-meta.c
new file mode 100644
index ..8f50f0d8
--- /dev/null
+++ b/cmac-aes256-meta.c
@@ -0,0 +1,43 @@
+/* cmac-aes256-meta.c
+
+ Copyright (C) 2013, 2014 Niels Möller
+
+ This file is part of GNU Nettle.
+
+ GNU Nettle is free software: you can redistribute it and/or
+ modify it under the terms of either:
+
+ * the GNU Lesser General Public License as published by the Free
+ Software Foundation; either version 3 of the License, or (at your
+ option) any later version.
+
+ or
+
+ * the GNU General Public License as published by the Free
+ Software Foundation; either version 2 of the License, or (at your
+ option) any later version.
+
+ or both in parallel, as here.
+
+ GNU Nettle 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
+ General Public License for more details.
+
+ You should have received copies of the GNU General Public License and
+ the GNU Lesser General Public License along with this program. If
+ not, see http://www.gnu.org/licenses/.
+*/
+
+#if HAVE_CONFIG_H
+# include "config.h"
+#endif
+
+#include
+
+#include "nettle-meta.h"
+
+#include "cmac.h"
+
+const struct nettle_mac nettle_cmac_aes256
+= _NETTLE_CMAC(cmac_aes256, AES256);
diff --git a/nettle-meta.h b/nettle-meta.h
index b03da208..783d80ce 100644
--- a/nettle-meta.h
+++ b/nettle-meta.h
@@ -260,6 +260,21 @@ struct nettle_mac
nettle_hash_digest_func *digest;
};
+#define _NETTLE_CMAC(name, AES) { \
+ #name, \
+ sizeof(struct name##_ctx), \
+ CMAC128_DIGEST_SIZE, \
+ AES##_KEY_SIZE, \
+ 0, \
+ (nettle_set_key_func *) name##_set_key, \
+ NULL,\
+ (nettle_hash_update_func *) name##_update, \
+ (nettle_hash_digest_func *) name##_digest, \
+}
+
+extern const struct nettle_mac nettle_cmac_aes128;
+extern const struct nettle_mac nettle_cmac_aes256;
+
#ifdef __cplusplus
}
#endif
diff --git a/testsuite/cmac-test.c b/testsuite/cmac-test.c
index b1d4aa30..42188ece 100644
--- a/testsuite/cmac-test.c
+++ b/testsuite/cmac-test.c
@@ -2,30 +2,6 @@
#include "nettle-internal.h"
#includ
[PATCH v2 5/6] nettle-meta: Expose all defined MACs through nettle_macs
From: Daiki Ueno
Signed-off-by: Daiki Ueno
---
Makefile.in| 2 +-
nettle-meta-macs.c | 61 ++
nettle-meta.h | 7 ++
3 files changed, 69 insertions(+), 1 deletion(-)
create mode 100644 nettle-meta-macs.c
diff --git a/Makefile.in b/Makefile.in
index 4cfc5005..8efe2f88 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -116,7 +116,7 @@ nettle_SOURCES = aes-decrypt-internal.c aes-decrypt.c \
memeql-sec.c memxor.c memxor3.c \
nettle-lookup-hash.c \
nettle-meta-aeads.c nettle-meta-armors.c \
-nettle-meta-ciphers.c nettle-meta-hashes.c \
+nettle-meta-ciphers.c nettle-meta-hashes.c nettle-meta-macs.c \
pbkdf2.c pbkdf2-hmac-sha1.c pbkdf2-hmac-sha256.c \
poly1305-aes.c poly1305-internal.c \
realloc.c \
diff --git a/nettle-meta-macs.c b/nettle-meta-macs.c
new file mode 100644
index ..6575ed66
--- /dev/null
+++ b/nettle-meta-macs.c
@@ -0,0 +1,61 @@
+/* nettle-meta-macs.c
+
+ Copyright (C) 2011 Daniel Kahn Gillmor
+
+ This file is part of GNU Nettle.
+
+ GNU Nettle is free software: you can redistribute it and/or
+ modify it under the terms of either:
+
+ * the GNU Lesser General Public License as published by the Free
+ Software Foundation; either version 3 of the License, or (at your
+ option) any later version.
+
+ or
+
+ * the GNU General Public License as published by the Free
+ Software Foundation; either version 2 of the License, or (at your
+ option) any later version.
+
+ or both in parallel, as here.
+
+ GNU Nettle 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
+ General Public License for more details.
+
+ You should have received copies of the GNU General Public License and
+ the GNU Lesser General Public License along with this program. If
+ not, see http://www.gnu.org/licenses/.
+*/
+
+#if HAVE_CONFIG_H
+# include "config.h"
+#endif
+
+#include
+
+#include "nettle-meta.h"
+
+const struct nettle_mac * const _nettle_macs[] = {
+ &nettle_cmac_aes128,
+ &nettle_cmac_aes256,
+ &nettle_hmac_md5,
+ &nettle_hmac_ripemd160,
+ &nettle_hmac_sha1,
+ &nettle_hmac_sha224,
+ &nettle_hmac_sha256,
+ &nettle_hmac_sha384,
+ &nettle_hmac_sha512,
+ &nettle_umac32,
+ &nettle_umac64,
+ &nettle_umac96,
+ &nettle_umac128,
+ NULL
+};
+
+const struct nettle_mac * const *
+nettle_get_macs (void)
+{
+ return _nettle_macs;
+}
diff --git a/nettle-meta.h b/nettle-meta.h
index b51fb602..4b4d312d 100644
--- a/nettle-meta.h
+++ b/nettle-meta.h
@@ -296,6 +296,13 @@ struct nettle_mac
(nettle_hash_digest_func *) name##_digest, \
}
+/* null-terminated list of macs implemented by this
+ version of nettle */
+const struct nettle_mac * const * _NETTLE_ATTRIBUTE_PURE
+nettle_get_macs (void);
+
+#define nettle_macs (nettle_get_macs())
+
extern const struct nettle_mac nettle_cmac_aes128;
extern const struct nettle_mac nettle_cmac_aes256;
--
2.21.0
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
[PATCH v2 6/6] tests: Add test for meta interface for MAC algorithms
From: Daiki Ueno
Signed-off-by: Daiki Ueno
---
testsuite/.gitignore | 1 +
testsuite/.test-rules.make | 3 +++
testsuite/Makefile.in | 2 +-
testsuite/meta-mac-test.c | 43 ++
4 files changed, 48 insertions(+), 1 deletion(-)
create mode 100644 testsuite/meta-mac-test.c
diff --git a/testsuite/.gitignore b/testsuite/.gitignore
index 066bcee2..a57feccb 100644
--- a/testsuite/.gitignore
+++ b/testsuite/.gitignore
@@ -56,6 +56,7 @@
/meta-armor-test
/meta-cipher-test
/meta-hash-test
+/meta-mac-test
/pbkdf2-test
/pkcs1-test
/pkcs1-sec-decrypt-test
diff --git a/testsuite/.test-rules.make b/testsuite/.test-rules.make
index efb7df3c..87e288c5 100644
--- a/testsuite/.test-rules.make
+++ b/testsuite/.test-rules.make
@@ -160,6 +160,9 @@ meta-aead-test$(EXEEXT): meta-aead-test.$(OBJEXT)
meta-armor-test$(EXEEXT): meta-armor-test.$(OBJEXT)
$(LINK) meta-armor-test.$(OBJEXT) $(TEST_OBJS) -o
meta-armor-test$(EXEEXT)
+meta-mac-test$(EXEEXT): meta-mac-test.$(OBJEXT)
+ $(LINK) meta-mac-test.$(OBJEXT) $(TEST_OBJS) -o meta-mac-test$(EXEEXT)
+
buffer-test$(EXEEXT): buffer-test.$(OBJEXT)
$(LINK) buffer-test.$(OBJEXT) $(TEST_OBJS) -o buffer-test$(EXEEXT)
diff --git a/testsuite/Makefile.in b/testsuite/Makefile.in
index f8f85701..d688c242 100644
--- a/testsuite/Makefile.in
+++ b/testsuite/Makefile.in
@@ -31,7 +31,7 @@ TS_NETTLE_SOURCES = aes-test.c arcfour-test.c arctwo-test.c \
poly1305-test.c chacha-poly1305-test.c \
hmac-test.c umac-test.c \
meta-hash-test.c meta-cipher-test.c\
- meta-aead-test.c meta-armor-test.c \
+ meta-aead-test.c meta-armor-test.c meta-mac-test.c \
buffer-test.c yarrow-test.c xts-test.c pbkdf2-test.c
TS_HOGWEED_SOURCES = sexp-test.c sexp-format-test.c \
diff --git a/testsuite/meta-mac-test.c b/testsuite/meta-mac-test.c
new file mode 100644
index ..09cb5e9f
--- /dev/null
+++ b/testsuite/meta-mac-test.c
@@ -0,0 +1,43 @@
+#include "testutils.h"
+#include "nettle-internal.h"
+#include "nettle-meta.h"
+
+const char* macs[] = {
+ "cmac_aes128",
+ "cmac_aes256",
+ "hmac_md5",
+ "hmac_ripemd160",
+ "hmac_sha1",
+ "hmac_sha224",
+ "hmac_sha256",
+ "hmac_sha384",
+ "hmac_sha512",
+ "umac32",
+ "umac64",
+ "umac96",
+ "umac128",
+};
+
+void
+test_main(void)
+{
+ int i, j;
+ int count = sizeof(macs)/sizeof(*macs);
+ for (i = 0; i < count; i++) {
+for (j = 0; NULL != nettle_macs[j]; j++) {
+ if (0 == strcmp(macs[i], nettle_macs[j]->name))
+ break;
+}
+ASSERT(NULL != nettle_macs[j]); /* make sure we found a matching mac */
+ }
+ for (i = 0; NULL != nettle_macs[i]; i++) {
+if (nettle_macs[i]->nonce_size > 0)
+ ASSERT(NULL != nettle_macs[i]->set_nonce);
+else
+ ASSERT(NULL == nettle_macs[i]->set_nonce);
+ }
+ i = 0;
+ while (NULL != nettle_macs[i])
+i++;
+ ASSERT(i == count); /* we are not missing testing any macs */
+}
--
2.21.0
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
[PATCH v2 0/6] Add meta interface for MAC algorithms
From: Daiki Ueno The changes from the previous series are: - remove the global hmac_*_set_key_expanded functions - leave out set_nonce member if the operation is not supported For the latter, I was wondering whether it is better to define a no-op set_nonce, but given the fact that that the caller nevertheless checks nonce_size, I chose to make the field blank. Daiki Ueno (6): nettle-meta: Move struct nettle_mac to nettle-meta.h nettle-meta: Add meta interface for CMAC functions nettle-meta: Add meta interface for HMAC functions nettle-meta: Add meta interface for UMAC functions nettle-meta: Expose all defined MACs through nettle_macs tests: Add test for meta interface for MAC algorithms Makefile.in| 7 +++- cmac-aes128-meta.c | 43 cmac-aes256-meta.c | 43 hmac-md5-meta.c| 47 ++ hmac-ripemd160-meta.c | 47 ++ hmac-sha1-meta.c | 47 ++ hmac-sha224-meta.c | 47 ++ hmac-sha256-meta.c | 47 ++ hmac-sha384-meta.c | 47 ++ hmac-sha512-meta.c | 47 ++ nettle-meta-macs.c | 61 nettle-meta.h | 81 ++ testsuite/.gitignore | 1 + testsuite/.test-rules.make | 3 ++ testsuite/Makefile.in | 2 +- testsuite/cmac-test.c | 24 --- testsuite/meta-mac-test.c | 43 testsuite/testutils.h | 29 -- umac128-meta.c | 47 ++ umac32-meta.c | 47 ++ umac64-meta.c | 47 ++ umac96-meta.c | 47 ++ 22 files changed, 799 insertions(+), 55 deletions(-) create mode 100644 cmac-aes128-meta.c create mode 100644 cmac-aes256-meta.c create mode 100644 hmac-md5-meta.c create mode 100644 hmac-ripemd160-meta.c create mode 100644 hmac-sha1-meta.c create mode 100644 hmac-sha224-meta.c create mode 100644 hmac-sha256-meta.c create mode 100644 hmac-sha384-meta.c create mode 100644 hmac-sha512-meta.c create mode 100644 nettle-meta-macs.c create mode 100644 testsuite/meta-mac-test.c create mode 100644 umac128-meta.c create mode 100644 umac32-meta.c create mode 100644 umac64-meta.c create mode 100644 umac96-meta.c -- 2.21.0 ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH 0/7] Add meta interface for MAC algorithms
Dmitry Eremin-Solenikov writes: >> Each meta interface shall provide the following 4 functions: >> >> nettle_set_key_func *set_key; >> nettle_set_key_func *set_nonce; >> nettle_hash_update_func *update; >> nettle_hash_digest_func *digest; >> >> where set_nonce is only used by UMAC, and expects that the nonce has >> always the same length as AES_BLOCK_SIZE. For CMAC and HMAC, a no-op >> set_nonce function is defined. > > Will it be usefull to support length + data as arguments of set_nonce > function? > Especially if we try to add AES-GMAC a first level citizen. Maybe I'm missing the context, but wouldn't AES-GMAC better fit in `struct nettle_aead` as it is a special case of AES-GCM? The struct also has set_nonce function defined as nettle_set_key_func *. > Also it might look good to define (internal) mac_set_nonce_null() function > and use it from the HMAC/CMAC meta interface. Indeed, it makes sense. I will update the series with it after making hmac_*_set_key_expanded internal as suggested. Thank you for the comments! Regards, -- Daiki Ueno ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
[PATCH 7/7] tests: Add test for meta interface for MAC algorithms
From: Daiki Ueno
Signed-off-by: Daiki Ueno
---
testsuite/.gitignore | 1 +
testsuite/.test-rules.make | 3 +++
testsuite/Makefile.in | 2 +-
testsuite/meta-mac-test.c | 37 +
4 files changed, 42 insertions(+), 1 deletion(-)
create mode 100644 testsuite/meta-mac-test.c
diff --git a/testsuite/.gitignore b/testsuite/.gitignore
index 066bcee2..a57feccb 100644
--- a/testsuite/.gitignore
+++ b/testsuite/.gitignore
@@ -56,6 +56,7 @@
/meta-armor-test
/meta-cipher-test
/meta-hash-test
+/meta-mac-test
/pbkdf2-test
/pkcs1-test
/pkcs1-sec-decrypt-test
diff --git a/testsuite/.test-rules.make b/testsuite/.test-rules.make
index efb7df3c..87e288c5 100644
--- a/testsuite/.test-rules.make
+++ b/testsuite/.test-rules.make
@@ -160,6 +160,9 @@ meta-aead-test$(EXEEXT): meta-aead-test.$(OBJEXT)
meta-armor-test$(EXEEXT): meta-armor-test.$(OBJEXT)
$(LINK) meta-armor-test.$(OBJEXT) $(TEST_OBJS) -o
meta-armor-test$(EXEEXT)
+meta-mac-test$(EXEEXT): meta-mac-test.$(OBJEXT)
+ $(LINK) meta-mac-test.$(OBJEXT) $(TEST_OBJS) -o meta-mac-test$(EXEEXT)
+
buffer-test$(EXEEXT): buffer-test.$(OBJEXT)
$(LINK) buffer-test.$(OBJEXT) $(TEST_OBJS) -o buffer-test$(EXEEXT)
diff --git a/testsuite/Makefile.in b/testsuite/Makefile.in
index f8f85701..d688c242 100644
--- a/testsuite/Makefile.in
+++ b/testsuite/Makefile.in
@@ -31,7 +31,7 @@ TS_NETTLE_SOURCES = aes-test.c arcfour-test.c arctwo-test.c \
poly1305-test.c chacha-poly1305-test.c \
hmac-test.c umac-test.c \
meta-hash-test.c meta-cipher-test.c\
- meta-aead-test.c meta-armor-test.c \
+ meta-aead-test.c meta-armor-test.c meta-mac-test.c \
buffer-test.c yarrow-test.c xts-test.c pbkdf2-test.c
TS_HOGWEED_SOURCES = sexp-test.c sexp-format-test.c \
diff --git a/testsuite/meta-mac-test.c b/testsuite/meta-mac-test.c
new file mode 100644
index ..dcc9fbca
--- /dev/null
+++ b/testsuite/meta-mac-test.c
@@ -0,0 +1,37 @@
+#include "testutils.h"
+#include "nettle-internal.h"
+#include "nettle-meta.h"
+
+const char* macs[] = {
+ "cmac_aes128",
+ "cmac_aes256",
+ "hmac_md5",
+ "hmac_ripemd160",
+ "hmac_sha1",
+ "hmac_sha224",
+ "hmac_sha256",
+ "hmac_sha384",
+ "hmac_sha512",
+ "umac32",
+ "umac64",
+ "umac96",
+ "umac128",
+};
+
+void
+test_main(void)
+{
+ int i, j;
+ int count = sizeof(macs)/sizeof(*macs);
+ for (i = 0; i < count; i++) {
+for (j = 0; NULL != nettle_macs[j]; j++) {
+ if (0 == strcmp(macs[i], nettle_macs[j]->name))
+ break;
+}
+ASSERT(NULL != nettle_macs[j]); /* make sure we found a matching aead */
+ }
+ i = 0;
+ while (NULL != nettle_macs[i])
+i++;
+ ASSERT(i == count); /* we are not missing testing any hashes */
+}
--
2.21.0
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
[PATCH 6/7] nettle-meta: Expose all defined MACs through nettle_macs
From: Daiki Ueno
Signed-off-by: Daiki Ueno
---
Makefile.in| 2 +-
nettle-meta-macs.c | 61 ++
nettle-meta.h | 7 ++
3 files changed, 69 insertions(+), 1 deletion(-)
create mode 100644 nettle-meta-macs.c
diff --git a/Makefile.in b/Makefile.in
index 4cfc5005..8efe2f88 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -116,7 +116,7 @@ nettle_SOURCES = aes-decrypt-internal.c aes-decrypt.c \
memeql-sec.c memxor.c memxor3.c \
nettle-lookup-hash.c \
nettle-meta-aeads.c nettle-meta-armors.c \
-nettle-meta-ciphers.c nettle-meta-hashes.c \
+nettle-meta-ciphers.c nettle-meta-hashes.c nettle-meta-macs.c \
pbkdf2.c pbkdf2-hmac-sha1.c pbkdf2-hmac-sha256.c \
poly1305-aes.c poly1305-internal.c \
realloc.c \
diff --git a/nettle-meta-macs.c b/nettle-meta-macs.c
new file mode 100644
index ..6575ed66
--- /dev/null
+++ b/nettle-meta-macs.c
@@ -0,0 +1,61 @@
+/* nettle-meta-macs.c
+
+ Copyright (C) 2011 Daniel Kahn Gillmor
+
+ This file is part of GNU Nettle.
+
+ GNU Nettle is free software: you can redistribute it and/or
+ modify it under the terms of either:
+
+ * the GNU Lesser General Public License as published by the Free
+ Software Foundation; either version 3 of the License, or (at your
+ option) any later version.
+
+ or
+
+ * the GNU General Public License as published by the Free
+ Software Foundation; either version 2 of the License, or (at your
+ option) any later version.
+
+ or both in parallel, as here.
+
+ GNU Nettle 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
+ General Public License for more details.
+
+ You should have received copies of the GNU General Public License and
+ the GNU Lesser General Public License along with this program. If
+ not, see http://www.gnu.org/licenses/.
+*/
+
+#if HAVE_CONFIG_H
+# include "config.h"
+#endif
+
+#include
+
+#include "nettle-meta.h"
+
+const struct nettle_mac * const _nettle_macs[] = {
+ &nettle_cmac_aes128,
+ &nettle_cmac_aes256,
+ &nettle_hmac_md5,
+ &nettle_hmac_ripemd160,
+ &nettle_hmac_sha1,
+ &nettle_hmac_sha224,
+ &nettle_hmac_sha256,
+ &nettle_hmac_sha384,
+ &nettle_hmac_sha512,
+ &nettle_umac32,
+ &nettle_umac64,
+ &nettle_umac96,
+ &nettle_umac128,
+ NULL
+};
+
+const struct nettle_mac * const *
+nettle_get_macs (void)
+{
+ return _nettle_macs;
+}
diff --git a/nettle-meta.h b/nettle-meta.h
index 55229501..c7e7ab0f 100644
--- a/nettle-meta.h
+++ b/nettle-meta.h
@@ -296,6 +296,13 @@ struct nettle_mac
(nettle_hash_digest_func *) name##_digest, \
}
+/* null-terminated list of macs implemented by this
+ version of nettle */
+const struct nettle_mac * const * _NETTLE_ATTRIBUTE_PURE
+nettle_get_macs (void);
+
+#define nettle_macs (nettle_get_macs())
+
extern const struct nettle_mac nettle_cmac_aes128;
extern const struct nettle_mac nettle_cmac_aes256;
--
2.21.0
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
[PATCH 0/7] Add meta interface for MAC algorithms
From: Daiki Ueno As discussed in: https://lists.lysator.liu.se/pipermail/nettle-bugs/2019/007662.html This moves `struct nettle_mac` to nettle-meta.h and provide the meta interface for all defined MAC algorithms. Each meta interface shall provide the following 4 functions: nettle_set_key_func *set_key; nettle_set_key_func *set_nonce; nettle_hash_update_func *update; nettle_hash_digest_func *digest; where set_nonce is only used by UMAC, and expects that the nonce has always the same length as AES_BLOCK_SIZE. For CMAC and HMAC, a no-op set_nonce function is defined. Also the signature of set_key is slightly different from hmac_*_set_key in that it doesn't take key length as an argument. A wrapper function is provided to clamp the length to hash block size. Daiki Ueno (7): hmac: Add set_key_expanded function nettle-meta: Move struct nettle_mac to nettle-meta.h nettle-meta: Add meta interface for CMAC functions nettle-meta: Add meta interface for HMAC functions nettle-meta: Add meta interface for UMAC functions nettle-meta: Expose all defined MACs through nettle_macs tests: Add test for meta interface for MAC algorithms Makefile.in| 7 +++- cmac-aes128-meta.c | 48 ++ cmac-aes256-meta.c | 48 ++ hmac-md5-meta.c| 46 ++ hmac-md5.c | 7 hmac-ripemd160-meta.c | 46 ++ hmac-ripemd160.c | 7 hmac-sha1-meta.c | 46 ++ hmac-sha1.c| 7 hmac-sha224-meta.c | 46 ++ hmac-sha224.c | 7 hmac-sha256-meta.c | 46 ++ hmac-sha256.c | 7 hmac-sha384-meta.c | 46 ++ hmac-sha384.c | 7 hmac-sha512-meta.c | 46 ++ hmac-sha512.c | 7 hmac.c | 48 ++ hmac.h | 45 + nettle-meta-macs.c | 61 nettle-meta.h | 81 ++ testsuite/.gitignore | 1 + testsuite/.test-rules.make | 3 ++ testsuite/Makefile.in | 2 +- testsuite/cmac-test.c | 24 --- testsuite/meta-mac-test.c | 37 + testsuite/testutils.h | 29 -- umac128-meta.c | 47 ++ umac32-meta.c | 47 ++ umac64-meta.c | 47 ++ umac96-meta.c | 47 ++ 31 files changed, 922 insertions(+), 71 deletions(-) create mode 100644 cmac-aes128-meta.c create mode 100644 cmac-aes256-meta.c create mode 100644 hmac-md5-meta.c create mode 100644 hmac-ripemd160-meta.c create mode 100644 hmac-sha1-meta.c create mode 100644 hmac-sha224-meta.c create mode 100644 hmac-sha256-meta.c create mode 100644 hmac-sha384-meta.c create mode 100644 hmac-sha512-meta.c create mode 100644 nettle-meta-macs.c create mode 100644 testsuite/meta-mac-test.c create mode 100644 umac128-meta.c create mode 100644 umac32-meta.c create mode 100644 umac64-meta.c create mode 100644 umac96-meta.c -- 2.21.0 ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
[PATCH 1/7] hmac: Add set_key_expanded function
From: Daiki Ueno
This adds a set_key_expanded to all HMACs, to provide a compatible
signature with nettle_set_key_func. This function is similar to
set_key, but assumes the input is already expanded to the hash block
size.
Signed-off-by: Daiki Ueno
---
hmac-md5.c | 7 +++
hmac-ripemd160.c | 7 +++
hmac-sha1.c | 7 +++
hmac-sha224.c| 7 +++
hmac-sha256.c| 7 +++
hmac-sha384.c| 7 +++
hmac-sha512.c| 7 +++
hmac.c | 48
hmac.h | 45 +
9 files changed, 126 insertions(+), 16 deletions(-)
diff --git a/hmac-md5.c b/hmac-md5.c
index a27e64f6..b5a9c4d0 100644
--- a/hmac-md5.c
+++ b/hmac-md5.c
@@ -44,6 +44,13 @@ hmac_md5_set_key(struct hmac_md5_ctx *ctx,
HMAC_SET_KEY(ctx, &nettle_md5, key_length, key);
}
+void
+hmac_md5_set_key_expanded(struct hmac_md5_ctx *ctx,
+ const uint8_t *key)
+{
+ HMAC_SET_KEY_EXPANDED(ctx, &nettle_md5, key);
+}
+
void
hmac_md5_update(struct hmac_md5_ctx *ctx,
size_t length, const uint8_t *data)
diff --git a/hmac-ripemd160.c b/hmac-ripemd160.c
index 24e2cbe7..d4ba5fea 100644
--- a/hmac-ripemd160.c
+++ b/hmac-ripemd160.c
@@ -44,6 +44,13 @@ hmac_ripemd160_set_key(struct hmac_ripemd160_ctx *ctx,
HMAC_SET_KEY(ctx, &nettle_ripemd160, key_length, key);
}
+void
+hmac_ripemd160_set_key_expanded(struct hmac_ripemd160_ctx *ctx,
+ const uint8_t *key)
+{
+ HMAC_SET_KEY_EXPANDED(ctx, &nettle_ripemd160, key);
+}
+
void
hmac_ripemd160_update(struct hmac_ripemd160_ctx *ctx,
size_t length, const uint8_t *data)
diff --git a/hmac-sha1.c b/hmac-sha1.c
index 5e7188f9..3d299b5d 100644
--- a/hmac-sha1.c
+++ b/hmac-sha1.c
@@ -44,6 +44,13 @@ hmac_sha1_set_key(struct hmac_sha1_ctx *ctx,
HMAC_SET_KEY(ctx, &nettle_sha1, key_length, key);
}
+void
+hmac_sha1_set_key_expanded(struct hmac_sha1_ctx *ctx,
+ const uint8_t *key)
+{
+ HMAC_SET_KEY_EXPANDED(ctx, &nettle_sha1, key);
+}
+
void
hmac_sha1_update(struct hmac_sha1_ctx *ctx,
size_t length, const uint8_t *data)
diff --git a/hmac-sha224.c b/hmac-sha224.c
index c5bc8750..18dc3307 100644
--- a/hmac-sha224.c
+++ b/hmac-sha224.c
@@ -44,6 +44,13 @@ hmac_sha224_set_key(struct hmac_sha224_ctx *ctx,
HMAC_SET_KEY(ctx, &nettle_sha224, key_length, key);
}
+void
+hmac_sha224_set_key_expanded(struct hmac_sha224_ctx *ctx,
+const uint8_t *key)
+{
+ HMAC_SET_KEY_EXPANDED(ctx, &nettle_sha224, key);
+}
+
void
hmac_sha224_digest(struct hmac_sha224_ctx *ctx,
size_t length, uint8_t *digest)
diff --git a/hmac-sha256.c b/hmac-sha256.c
index af5cc0f1..a89e0f6b 100644
--- a/hmac-sha256.c
+++ b/hmac-sha256.c
@@ -44,6 +44,13 @@ hmac_sha256_set_key(struct hmac_sha256_ctx *ctx,
HMAC_SET_KEY(ctx, &nettle_sha256, key_length, key);
}
+void
+hmac_sha256_set_key_expanded(struct hmac_sha256_ctx *ctx,
+const uint8_t *key)
+{
+ HMAC_SET_KEY_EXPANDED(ctx, &nettle_sha256, key);
+}
+
void
hmac_sha256_update(struct hmac_sha256_ctx *ctx,
size_t length, const uint8_t *data)
diff --git a/hmac-sha384.c b/hmac-sha384.c
index 30008b5f..c3904053 100644
--- a/hmac-sha384.c
+++ b/hmac-sha384.c
@@ -44,6 +44,13 @@ hmac_sha384_set_key(struct hmac_sha512_ctx *ctx,
HMAC_SET_KEY(ctx, &nettle_sha384, key_length, key);
}
+void
+hmac_sha384_set_key_expanded(struct hmac_sha512_ctx *ctx,
+const uint8_t *key)
+{
+ HMAC_SET_KEY_EXPANDED(ctx, &nettle_sha384, key);
+}
+
void
hmac_sha384_digest(struct hmac_sha512_ctx *ctx,
size_t length, uint8_t *digest)
diff --git a/hmac-sha512.c b/hmac-sha512.c
index de64637a..4fff1f35 100644
--- a/hmac-sha512.c
+++ b/hmac-sha512.c
@@ -44,6 +44,13 @@ hmac_sha512_set_key(struct hmac_sha512_ctx *ctx,
HMAC_SET_KEY(ctx, &nettle_sha512, key_length, key);
}
+void
+hmac_sha512_set_key_expanded(struct hmac_sha512_ctx *ctx,
+const uint8_t *key)
+{
+ HMAC_SET_KEY_EXPANDED(ctx, &nettle_sha512, key);
+}
+
void
hmac_sha512_update(struct hmac_sha512_ctx *ctx,
size_t length, const uint8_t *data)
diff --git a/hmac.c b/hmac.c
index 6ac5e11a..925b9c3b 100644
--- a/hmac.c
+++ b/hmac.c
@@ -48,10 +48,10 @@
#define IPAD 0x36
#define OPAD 0x5c
-void
-hmac_set_key(void *outer, void *inner, void *state,
-const struct nettle_hash *hash,
-size_t key_length, const uint8_t *key)
+static void
+_hmac_set_key(void *outer, void *inner, void *state,
+ const struct nettle_hash *hash,
+ size_t key_length, const uint8_t *key)
{
TMP_DECL(pad, uint8_t, NETTLE_MAX_HASH_BLOCK_SIZE);
TMP_ALLOC(pad, hash->block_size);
@@ -59,6 +59,26 @@ hmac_set_key(void *outer, vo
[PATCH 3/7] nettle-meta: Add meta interface for CMAC functions
From: Daiki Ueno
Signed-off-by: Daiki Ueno
---
Makefile.in | 1 +
cmac-aes128-meta.c| 48 +++
cmac-aes256-meta.c| 48 +++
nettle-meta.h | 15 ++
testsuite/cmac-test.c | 24 --
5 files changed, 112 insertions(+), 24 deletions(-)
create mode 100644 cmac-aes128-meta.c
create mode 100644 cmac-aes256-meta.c
diff --git a/Makefile.in b/Makefile.in
index b54e64b0..6a425e16 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -103,6 +103,7 @@ nettle_SOURCES = aes-decrypt-internal.c aes-decrypt.c \
gcm-camellia128.c gcm-camellia128-meta.c \
gcm-camellia256.c gcm-camellia256-meta.c \
cmac.c cmac-aes128.c cmac-aes256.c \
+cmac-aes128-meta.c cmac-aes256-meta.c \
gosthash94.c gosthash94-meta.c \
hmac.c hmac-md5.c hmac-ripemd160.c hmac-sha1.c \
hmac-sha224.c hmac-sha256.c hmac-sha384.c hmac-sha512.c \
diff --git a/cmac-aes128-meta.c b/cmac-aes128-meta.c
new file mode 100644
index ..73cf396c
--- /dev/null
+++ b/cmac-aes128-meta.c
@@ -0,0 +1,48 @@
+/* cmac-aes128-meta.c
+
+ Copyright (C) 2013, 2014 Niels Möller
+
+ This file is part of GNU Nettle.
+
+ GNU Nettle is free software: you can redistribute it and/or
+ modify it under the terms of either:
+
+ * the GNU Lesser General Public License as published by the Free
+ Software Foundation; either version 3 of the License, or (at your
+ option) any later version.
+
+ or
+
+ * the GNU General Public License as published by the Free
+ Software Foundation; either version 2 of the License, or (at your
+ option) any later version.
+
+ or both in parallel, as here.
+
+ GNU Nettle 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
+ General Public License for more details.
+
+ You should have received copies of the GNU General Public License and
+ the GNU Lesser General Public License along with this program. If
+ not, see http://www.gnu.org/licenses/.
+*/
+
+#if HAVE_CONFIG_H
+# include "config.h"
+#endif
+
+#include
+
+#include "nettle-meta.h"
+
+#include "cmac.h"
+
+static void
+cmac_aes128_set_nonce_wrapper (void *ctx UNUSED, const uint8_t *key UNUSED)
+{
+}
+
+const struct nettle_mac nettle_cmac_aes128
+= _NETTLE_CMAC(cmac_aes128, AES128);
diff --git a/cmac-aes256-meta.c b/cmac-aes256-meta.c
new file mode 100644
index ..e7bf745c
--- /dev/null
+++ b/cmac-aes256-meta.c
@@ -0,0 +1,48 @@
+/* cmac-aes256-meta.c
+
+ Copyright (C) 2013, 2014 Niels Möller
+
+ This file is part of GNU Nettle.
+
+ GNU Nettle is free software: you can redistribute it and/or
+ modify it under the terms of either:
+
+ * the GNU Lesser General Public License as published by the Free
+ Software Foundation; either version 3 of the License, or (at your
+ option) any later version.
+
+ or
+
+ * the GNU General Public License as published by the Free
+ Software Foundation; either version 2 of the License, or (at your
+ option) any later version.
+
+ or both in parallel, as here.
+
+ GNU Nettle 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
+ General Public License for more details.
+
+ You should have received copies of the GNU General Public License and
+ the GNU Lesser General Public License along with this program. If
+ not, see http://www.gnu.org/licenses/.
+*/
+
+#if HAVE_CONFIG_H
+# include "config.h"
+#endif
+
+#include
+
+#include "nettle-meta.h"
+
+#include "cmac.h"
+
+static void
+cmac_aes256_set_nonce_wrapper (void *ctx UNUSED, const uint8_t *key UNUSED)
+{
+}
+
+const struct nettle_mac nettle_cmac_aes256
+= _NETTLE_CMAC(cmac_aes256, AES256);
diff --git a/nettle-meta.h b/nettle-meta.h
index b03da208..656c30de 100644
--- a/nettle-meta.h
+++ b/nettle-meta.h
@@ -260,6 +260,21 @@ struct nettle_mac
nettle_hash_digest_func *digest;
};
+#define _NETTLE_CMAC(name, AES) { \
+ #name, \
+ sizeof(struct name##_ctx), \
+ CMAC128_DIGEST_SIZE, \
+ AES##_KEY_SIZE, \
+ 0, \
+ (nettle_set_key_func *) name##_set_key, \
+ name##_set_nonce_wrapper,\
+ (nettle_hash_update_func *) name##_update, \
+ (nettle_hash_digest_func *) name##_digest, \
+}
+
+extern const struct nettle_mac nettle_cmac_aes128;
+extern const struct nettle_mac nettle_cmac_aes256;
+
#ifdef __cplusplus
}
#endif
diff --git a/testsuite/
[PATCH 5/7] nettle-meta: Add meta interface for UMAC functions
From: Daiki Ueno
Signed-off-by: Daiki Ueno
---
Makefile.in| 1 +
nettle-meta.h | 17 +
umac128-meta.c | 47 +++
umac32-meta.c | 47 +++
umac64-meta.c | 47 +++
umac96-meta.c | 47 +++
6 files changed, 206 insertions(+)
create mode 100644 umac128-meta.c
create mode 100644 umac32-meta.c
create mode 100644 umac64-meta.c
create mode 100644 umac96-meta.c
diff --git a/Makefile.in b/Makefile.in
index 9031d959..4cfc5005 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -138,6 +138,7 @@ nettle_SOURCES = aes-decrypt-internal.c aes-decrypt.c \
umac-nh.c umac-nh-n.c umac-l2.c umac-l3.c \
umac-poly64.c umac-poly128.c umac-set-key.c \
umac32.c umac64.c umac96.c umac128.c \
+umac32-meta.c umac64-meta.c umac96-meta.c umac128-meta.c \
version.c \
write-be32.c write-le32.c write-le64.c \
yarrow256.c yarrow_key_event.c \
diff --git a/nettle-meta.h b/nettle-meta.h
index f2a73d9b..55229501 100644
--- a/nettle-meta.h
+++ b/nettle-meta.h
@@ -284,6 +284,18 @@ struct nettle_mac
(nettle_hash_digest_func *) name##_digest, \
}
+#define _NETTLE_UMAC(name, NAME) { \
+ #name, \
+ sizeof(struct name##_ctx), \
+ NAME##_DIGEST_SIZE, \
+ UMAC_BLOCK_SIZE, \
+ AES_BLOCK_SIZE, \
+ (nettle_set_key_func *) name##_set_key, \
+ name##_set_nonce_wrapper,\
+ (nettle_hash_update_func *) name##_update, \
+ (nettle_hash_digest_func *) name##_digest, \
+}
+
extern const struct nettle_mac nettle_cmac_aes128;
extern const struct nettle_mac nettle_cmac_aes256;
@@ -295,6 +307,11 @@ extern const struct nettle_mac nettle_hmac_sha256;
extern const struct nettle_mac nettle_hmac_sha384;
extern const struct nettle_mac nettle_hmac_sha512;
+extern const struct nettle_mac nettle_umac32;
+extern const struct nettle_mac nettle_umac64;
+extern const struct nettle_mac nettle_umac96;
+extern const struct nettle_mac nettle_umac128;
+
#ifdef __cplusplus
}
#endif
diff --git a/umac128-meta.c b/umac128-meta.c
new file mode 100644
index ..9f6a7e34
--- /dev/null
+++ b/umac128-meta.c
@@ -0,0 +1,47 @@
+/* umac128-meta.c
+
+ Copyright (C) 2013 Niels Möller
+
+ This file is part of GNU Nettle.
+
+ GNU Nettle is free software: you can redistribute it and/or
+ modify it under the terms of either:
+
+ * the GNU Lesser General Public License as published by the Free
+ Software Foundation; either version 3 of the License, or (at your
+ option) any later version.
+
+ or
+
+ * the GNU General Public License as published by the Free
+ Software Foundation; either version 2 of the License, or (at your
+ option) any later version.
+
+ or both in parallel, as here.
+
+ GNU Nettle 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
+ General Public License for more details.
+
+ You should have received copies of the GNU General Public License and
+ the GNU Lesser General Public License along with this program. If
+ not, see http://www.gnu.org/licenses/.
+*/
+
+#if HAVE_CONFIG_H
+# include "config.h"
+#endif
+
+#include "nettle-meta.h"
+
+#include "umac.h"
+
+static void
+umac128_set_nonce_wrapper (void *ctx, const uint8_t *key)
+{
+ umac128_set_nonce (ctx, AES_BLOCK_SIZE, key);
+}
+
+const struct nettle_mac nettle_umac128
+= _NETTLE_UMAC(umac128, UMAC128);
diff --git a/umac32-meta.c b/umac32-meta.c
new file mode 100644
index ..2b4f9c14
--- /dev/null
+++ b/umac32-meta.c
@@ -0,0 +1,47 @@
+/* umac32-meta.c
+
+ Copyright (C) 2013 Niels Möller
+
+ This file is part of GNU Nettle.
+
+ GNU Nettle is free software: you can redistribute it and/or
+ modify it under the terms of either:
+
+ * the GNU Lesser General Public License as published by the Free
+ Software Foundation; either version 3 of the License, or (at your
+ option) any later version.
+
+ or
+
+ * the GNU General Public License as published by the Free
+ Software Foundation; either version 2 of the License, or (at your
+ option) any later version.
+
+ or both in parallel, as here.
+
+ GNU Nettle 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
+ General Public License for more details.
+
+ You should have received copies of the GNU General Public License and
+ the GNU Lesser General
[PATCH 2/7] nettle-meta: Move struct nettle_mac to nettle-meta.h
From: Daiki Ueno
The struct was defined in testutils.h as the interface was not
stable. This generalizes the interface to cover all defined MAC
algorithms in nettle.
Signed-off-by: Daiki Ueno
---
nettle-meta.h | 22 ++
testsuite/testutils.h | 29 -
2 files changed, 22 insertions(+), 29 deletions(-)
diff --git a/nettle-meta.h b/nettle-meta.h
index 74e50e59..b03da208 100644
--- a/nettle-meta.h
+++ b/nettle-meta.h
@@ -238,6 +238,28 @@ extern const struct nettle_armor nettle_base64;
extern const struct nettle_armor nettle_base64url;
extern const struct nettle_armor nettle_base16;
+struct nettle_mac
+{
+ const char *name;
+
+ /* Size of the context struct */
+ unsigned context_size;
+
+ /* Size of digests */
+ unsigned digest_size;
+
+ /* Suggested key size; other sizes are sometimes possible */
+ unsigned key_size;
+
+ /* Suggested nonce size; 0 if nonce is not used */
+ unsigned nonce_size;
+
+ nettle_set_key_func *set_key;
+ nettle_set_key_func *set_nonce;
+ nettle_hash_update_func *update;
+ nettle_hash_digest_func *digest;
+};
+
#ifdef __cplusplus
}
#endif
diff --git a/testsuite/testutils.h b/testsuite/testutils.h
index f4ea38da..78daf62b 100644
--- a/testsuite/testutils.h
+++ b/testsuite/testutils.h
@@ -79,35 +79,6 @@ test_main(void);
extern int verbose;
-/* FIXME: When interface stabilizes, move to nettle-meta.h */
-struct nettle_mac
-{
- const char *name;
-
- /* Size of the context struct */
- unsigned context_size;
-
- /* Size of digests */
- unsigned digest_size;
-
- /* Suggested key size; other sizes are sometimes possible. */
- unsigned key_size;
-
- nettle_set_key_func *set_key;
- nettle_hash_update_func *update;
- nettle_hash_digest_func *digest;
-};
-
-#define _NETTLE_HMAC(name, NAME, keysize) {\
- #name, \
- sizeof(struct hmac_##name##_ctx),\
- NAME##_DIGEST_SIZE, \
- NAME##_DIGEST_SIZE, \
- hmac_##name##_set_key, \
- hmac_##name##_update,\
- hmac_##name##_digest,\
-}
-
/* Test functions deallocate their inputs when finished.*/
void
test_cipher(const struct nettle_cipher *cipher,
--
2.21.0
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
[PATCH 4/7] nettle-meta: Add meta interface for HMAC functions
From: Daiki Ueno
Signed-off-by: Daiki Ueno
---
Makefile.in | 3 +++
hmac-md5-meta.c | 46 +++
hmac-ripemd160-meta.c | 46 +++
hmac-sha1-meta.c | 46 +++
hmac-sha224-meta.c| 46 +++
hmac-sha256-meta.c| 46 +++
hmac-sha384-meta.c| 46 +++
hmac-sha512-meta.c| 46 +++
nettle-meta.h | 20 +++
9 files changed, 345 insertions(+)
create mode 100644 hmac-md5-meta.c
create mode 100644 hmac-ripemd160-meta.c
create mode 100644 hmac-sha1-meta.c
create mode 100644 hmac-sha224-meta.c
create mode 100644 hmac-sha256-meta.c
create mode 100644 hmac-sha384-meta.c
create mode 100644 hmac-sha512-meta.c
diff --git a/Makefile.in b/Makefile.in
index 6a425e16..9031d959 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -107,6 +107,9 @@ nettle_SOURCES = aes-decrypt-internal.c aes-decrypt.c \
gosthash94.c gosthash94-meta.c \
hmac.c hmac-md5.c hmac-ripemd160.c hmac-sha1.c \
hmac-sha224.c hmac-sha256.c hmac-sha384.c hmac-sha512.c \
+hmac-md5-meta.c hmac-ripemd160-meta.c hmac-sha1-meta.c \
+hmac-sha224-meta.c hmac-sha256-meta.c hmac-sha384-meta.c \
+hmac-sha512-meta.c \
knuth-lfib.c hkdf.c \
md2.c md2-meta.c md4.c md4-meta.c \
md5.c md5-compress.c md5-compat.c md5-meta.c \
diff --git a/hmac-md5-meta.c b/hmac-md5-meta.c
new file mode 100644
index ..4ed99b5e
--- /dev/null
+++ b/hmac-md5-meta.c
@@ -0,0 +1,46 @@
+/* hmac-md5-meta.c
+
+ Copyright (C) 2002 Niels Möller
+
+ This file is part of GNU Nettle.
+
+ GNU Nettle is free software: you can redistribute it and/or
+ modify it under the terms of either:
+
+ * the GNU Lesser General Public License as published by the Free
+ Software Foundation; either version 3 of the License, or (at your
+ option) any later version.
+
+ or
+
+ * the GNU General Public License as published by the Free
+ Software Foundation; either version 2 of the License, or (at your
+ option) any later version.
+
+ or both in parallel, as here.
+
+ GNU Nettle 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
+ General Public License for more details.
+
+ You should have received copies of the GNU General Public License and
+ the GNU Lesser General Public License along with this program. If
+ not, see http://www.gnu.org/licenses/.
+*/
+
+#if HAVE_CONFIG_H
+# include "config.h"
+#endif
+
+#include "nettle-meta.h"
+
+#include "hmac.h"
+
+static void
+hmac_md5_set_nonce_wrapper (void *ctx UNUSED, const uint8_t *key UNUSED)
+{
+}
+
+const struct nettle_mac nettle_hmac_md5
+= _NETTLE_HMAC(hmac_md5, MD5);
diff --git a/hmac-ripemd160-meta.c b/hmac-ripemd160-meta.c
new file mode 100644
index ..6c354ac2
--- /dev/null
+++ b/hmac-ripemd160-meta.c
@@ -0,0 +1,46 @@
+/* hmac-ripemd160-meta.c
+
+ Copyright (C) 2011 Andres Mejia
+
+ This file is part of GNU Nettle.
+
+ GNU Nettle is free software: you can redistribute it and/or
+ modify it under the terms of either:
+
+ * the GNU Lesser General Public License as published by the Free
+ Software Foundation; either version 3 of the License, or (at your
+ option) any later version.
+
+ or
+
+ * the GNU General Public License as published by the Free
+ Software Foundation; either version 2 of the License, or (at your
+ option) any later version.
+
+ or both in parallel, as here.
+
+ GNU Nettle 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
+ General Public License for more details.
+
+ You should have received copies of the GNU General Public License and
+ the GNU Lesser General Public License along with this program. If
+ not, see http://www.gnu.org/licenses/.
+*/
+
+#if HAVE_CONFIG_H
+# include "config.h"
+#endif
+
+#include "nettle-meta.h"
+
+#include "hmac.h"
+
+static void
+hmac_ripemd160_set_nonce_wrapper (void *ctx UNUSED, const uint8_t *key UNUSED)
+{
+}
+
+const struct nettle_mac nettle_hmac_ripemd160
+= _NETTLE_HMAC(hmac_ripemd160, RIPEMD160);
diff --git a/hmac-sha1-meta.c b/hmac-sha1-meta.c
new file mode 100644
index ..d6a70802
--- /dev/null
+++ b/hmac-sha1-meta.c
@@ -0,0 +1,46 @@
+/* hmac-sha1-meta.c
+
+ Copyright (C) 2002 Niels Möller
+
+ This file is part of GNU Nettle.
+
+ GNU Nettle is free software: you can re
Re: nettle-meta interface for MACs
ni...@lysator.liu.se (Niels Möller) writes: > It's also not directly usable with umac, which takes a nonce (and auto > increment in umac*_digest). Should the generic interface try to > accomodate macs that require a nonce? In terms of the meta interface, I guess we could add a set_nonce function to the structure and define it as no-op for other MACs. > I would consider doing it the other way around, and define nettle_hmac_* > with fixed key size, for the key sizes used by applications. E.g, > https://tools.ietf.org/html/rfc4253#section-6.4 defines 4 mac algorithms > based on hmac, with the main one being hmac-sha1, with a fixed key size > equal to the digest size of 160 bits. > > Is it common to use hmac, without context implying a fix key size ? Indeed, that would make more sense, given a short key is simply zero-padded to the hash block size. > Slightly related: HMAC is defined as allowing very long keys, by hashing > the key in case it's larger than the block size (e.g., 512 bits for > hmac-sha1 and hmac-sha256). That seems a bit obscure to me. Are there > any applications or protocols depending on that feature? I think this is a requirement of FIPS as the HMAC definition in FIPS 198-1 explicitly mentions this step. Regards, -- Daiki Ueno ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
nettle-meta interface for MACs
Hello,
In testutils.h, there is a nettle-meta definition for MACs, similar to
hashes and ciphers:
/* FIXME: When interface stabilizes, move to nettle-meta.h */
struct nettle_mac
{
const char *name;
/* Size of the context struct */
unsigned context_size;
/* Size of digests */
unsigned digest_size;
/* Suggested key size; other sizes are sometimes possible. */
unsigned key_size;
nettle_set_key_func *set_key;
nettle_hash_update_func *update;
nettle_hash_digest_func *digest;
};
This is, however, not usable for HMAC, because Nettle build uses
-Wcast-function-type and the set_key member has an incompatible type
with hmac_*_set_key, which requires a key length argument as HMAC allows
arbitrary key length up to the hash block size.
Is there any plan to make it more generic and eventually move it to
nettle-meta.h? That would be particularly useful in applications
passing around HMAC functions (e.g., HKDF, deterministic ECDSA).
For example, I'm thinking to use nettle_hash_update_func for set_key and
provide a wrapper around other MACs which don't take key length,
something like:
void
_cmac_aes128_set_key(struct cmac_aes128_ctx *ctx,
size_t length, const uint8_t *key)
{
assert (length == AES128_KEY_LENGTH);
cmac_aes128_set_key (ctx, length, key);
}
Regards,
--
Daiki Ueno
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
[PATCH v2 2/3] ecdsa: Add support for deterministic signature generation
From: Daiki Ueno
This adds the ecdsa_sign_deterministic function that calculates
signature without requiring entropy source. Instead, it uses the
deterministic construction described in RFC 6979, through
_dsa_compute_k.
Signed-off-by: Daiki Ueno
---
Makefile.in | 2 +-
ecdsa-sign-deterministic.c| 74 +++
ecdsa.h | 11 ++
testsuite/.gitignore | 1 +
testsuite/.test-rules.make| 3 +
testsuite/Makefile.in | 3 +-
testsuite/ecdsa-sign-deterministic-test.c | 230 ++
7 files changed, 322 insertions(+), 2 deletions(-)
create mode 100644 ecdsa-sign-deterministic.c
create mode 100644 testsuite/ecdsa-sign-deterministic-test.c
diff --git a/Makefile.in b/Makefile.in
index 36b2a182..27cbf93f 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -188,7 +188,7 @@ hogweed_SOURCES = sexp.c sexp-format.c \
eddsa-hash.c eddsa-pubkey.c eddsa-sign.c eddsa-verify.c \
ed25519-sha512-pubkey.c \
ed25519-sha512-sign.c ed25519-sha512-verify.c \
- dsa-compute-k.c
+ dsa-compute-k.c ecdsa-sign-deterministic.c
OPT_SOURCES = fat-x86_64.c fat-arm.c mini-gmp.c
diff --git a/ecdsa-sign-deterministic.c b/ecdsa-sign-deterministic.c
new file mode 100644
index ..11eef5f6
--- /dev/null
+++ b/ecdsa-sign-deterministic.c
@@ -0,0 +1,74 @@
+/* ecdsa-sign-deterministic.c
+
+ Copyright (C) 2013 Niels Möller
+ Copyright (C) 2019 Red Hat, Inc.
+
+ This file is part of GNU Nettle.
+
+ GNU Nettle is free software: you can redistribute it and/or
+ modify it under the terms of either:
+
+ * the GNU Lesser General Public License as published by the Free
+ Software Foundation; either version 3 of the License, or (at your
+ option) any later version.
+
+ or
+
+ * the GNU General Public License as published by the Free
+ Software Foundation; either version 2 of the License, or (at your
+ option) any later version.
+
+ or both in parallel, as here.
+
+ GNU Nettle 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
+ General Public License for more details.
+
+ You should have received copies of the GNU General Public License and
+ the GNU Lesser General Public License along with this program. If
+ not, see http://www.gnu.org/licenses/.
+*/
+
+/* Development of Nettle's ECC support was funded by the .SE Internet Fund. */
+
+#if HAVE_CONFIG_H
+# include "config.h"
+#endif
+
+#include
+#include
+
+#include "ecdsa.h"
+#include "ecc-internal.h"
+#include "nettle-internal.h"
+#include "dsa-compute-k.h"
+
+void
+ecdsa_sign_deterministic (const struct ecc_scalar *key,
+ void *mac_ctx,
+ nettle_hash_update_func *set_key,
+ nettle_hash_update_func *update,
+ nettle_hash_digest_func *digest,
+ size_t digest_length,
+ const uint8_t *digest_message,
+ struct dsa_signature *signature)
+{
+ /* At most 936 bytes. */
+ TMP_DECL(k, mp_limb_t, ECC_MAX_SIZE + ECC_ECDSA_SIGN_ITCH (ECC_MAX_SIZE));
+ mp_limb_t size = key->ecc->p.size;
+ mp_limb_t *rp = mpz_limbs_write (signature->r, size);
+ mp_limb_t *sp = mpz_limbs_write (signature->s, size);
+
+ TMP_ALLOC (k, size + ECC_ECDSA_SIGN_ITCH (size));
+
+ _dsa_compute_k (k, key->ecc->q.size, key->ecc->q.m, key->p,
+ mac_ctx, set_key, update, digest,
+ digest_length, digest_message);
+ ecc_ecdsa_sign (key->ecc, key->p, k, digest_length, digest_message,
+ rp, sp, k + size);
+ mpz_limbs_finish (signature->r, size);
+ mpz_limbs_finish (signature->s, size);
+
+ assert (!(mpz_sgn (signature->r) == 0 || mpz_sgn (signature->s) == 0));
+}
diff --git a/ecdsa.h b/ecdsa.h
index 693aca8b..7d590367 100644
--- a/ecdsa.h
+++ b/ecdsa.h
@@ -43,6 +43,7 @@ extern "C" {
/* Name mangling */
#define ecdsa_sign nettle_ecdsa_sign
+#define ecdsa_sign_deterministic nettle_ecdsa_sign_deterministic
#define ecdsa_verify nettle_ecdsa_verify
#define ecdsa_generate_keypair nettle_ecdsa_generate_keypair
#define ecc_ecdsa_sign nettle_ecc_ecdsa_sign
@@ -61,6 +62,16 @@ ecdsa_sign (const struct ecc_scalar *key,
const uint8_t *digest,
struct dsa_signature *signature);
+void
+ecdsa_sign_deterministic (const struct ecc_scalar *key,
+ void *mac_ctx,
+ nettle_hash_update_func *set_key,
+ nettle_hash_update_func *update,
+ nettle_hash_digest_func *d
[PATCH v2 1/3] dsa: Add a function to find k deterministically
From: Daiki Ueno
This adds the _dsa_compute_k function that generates DSA/ECDSA k value
from the private key and the hashed message, according to RFC 6979.
Signed-off-by: Daiki Ueno
---
Makefile.in| 5 +-
dsa-compute-k.c| 179 +
dsa-compute-k.h| 63
testsuite/.gitignore | 1 +
testsuite/.test-rules.make | 3 +
testsuite/Makefile.in | 3 +-
testsuite/dsa-compute-k-test.c | 127 +++
7 files changed, 378 insertions(+), 3 deletions(-)
create mode 100644 dsa-compute-k.c
create mode 100644 dsa-compute-k.h
create mode 100644 testsuite/dsa-compute-k-test.c
diff --git a/Makefile.in b/Makefile.in
index b54e64b0..36b2a182 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -187,7 +187,8 @@ hogweed_SOURCES = sexp.c sexp-format.c \
eddsa-compress.c eddsa-decompress.c eddsa-expand.c \
eddsa-hash.c eddsa-pubkey.c eddsa-sign.c eddsa-verify.c \
ed25519-sha512-pubkey.c \
- ed25519-sha512-sign.c ed25519-sha512-verify.c
+ ed25519-sha512-sign.c ed25519-sha512-verify.c \
+ dsa-compute-k.c
OPT_SOURCES = fat-x86_64.c fat-arm.c mini-gmp.c
@@ -237,7 +238,7 @@ DISTFILES = $(SOURCES) $(HEADERS) getopt.h getopt_int.h \
ctr-internal.h chacha-internal.h sha3-internal.h \
salsa20-internal.h umac-internal.h hogweed-internal.h \
rsa-internal.h pkcs1-internal.h dsa-internal.h eddsa-internal.h \
- gmp-glue.h ecc-internal.h fat-setup.h \
+ gmp-glue.h ecc-internal.h fat-setup.h dsa-compute-k.h \
mini-gmp.h asm.m4 \
nettle.texinfo nettle.info nettle.html nettle.pdf sha-example.c
diff --git a/dsa-compute-k.c b/dsa-compute-k.c
new file mode 100644
index ..105c500b
--- /dev/null
+++ b/dsa-compute-k.c
@@ -0,0 +1,179 @@
+/* dsa-compute-k.c
+
+ Deterministically find k value for ECDSA/DSA (RFC-6979).
+
+ Copyright (C) 2019 Red Hat, Inc.
+
+ This file is part of GNU Nettle.
+
+ GNU Nettle is free software: you can redistribute it and/or
+ modify it under the terms of either:
+
+ * the GNU Lesser General Public License as published by the Free
+ Software Foundation; either version 3 of the License, or (at your
+ option) any later version.
+
+ or
+
+ * the GNU General Public License as published by the Free
+ Software Foundation; either version 2 of the License, or (at your
+ option) any later version.
+
+ or both in parallel, as here.
+
+ GNU Nettle 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
+ General Public License for more details.
+
+ You should have received copies of the GNU General Public License and
+ the GNU Lesser General Public License along with this program. If
+ not, see http://www.gnu.org/licenses/.
+*/
+
+#if HAVE_CONFIG_H
+# include "config.h"
+#endif
+
+#include "dsa-compute-k.h"
+
+#include "gmp-glue.h"
+#include "nettle-internal.h"
+#include
+#include
+
+#define MIN(x, y) ((x) < (y) ? (x) : (y))
+#define MAX(x, y) ((x) > (y) ? (x) : (y))
+
+void
+_dsa_compute_k (mp_limb_t *k,
+ mp_size_t qn,
+ const mp_limb_t *q,
+ const mp_limb_t *x,
+ void *mac_ctx,
+ nettle_hash_update_func *set_key,
+ nettle_hash_update_func *update,
+ nettle_hash_digest_func *digest,
+ size_t digest_length,
+ const uint8_t *digest_message)
+{
+ TMP_DECL(V, uint8_t, NETTLE_MAX_HASH_DIGEST_SIZE);
+ TMP_DECL(K, uint8_t, NETTLE_MAX_HASH_DIGEST_SIZE);
+ TMP_GMP_DECL(xp, uint8_t);
+ TMP_GMP_DECL(hp, uint8_t);
+ TMP_GMP_DECL(tp, uint8_t);
+ TMP_GMP_DECL(h, mp_limb_t);
+ mp_size_t hn = (digest_length + sizeof(mp_limb_t) - 1) / sizeof(mp_limb_t);
+ mp_bitcnt_t q_bits = mpn_sizeinbase (q, qn, 2);
+ mp_bitcnt_t h_bits = digest_length * 8;
+ size_t nbytes = (q_bits + 7) / 8;
+ const uint8_t c0 = 0x00;
+ const uint8_t c1 = 0x01;
+ mp_limb_t cy;
+
+ TMP_ALLOC(V, digest_length);
+ TMP_ALLOC(K, digest_length);
+ TMP_GMP_ALLOC(xp, nbytes);
+ TMP_GMP_ALLOC(hp, nbytes);
+ TMP_GMP_ALLOC(tp, nbytes);
+ TMP_GMP_ALLOC(h, MAX (qn, hn) * sizeof(mp_limb_t));
+
+ /* int2octets(x) */
+ mpn_get_base256 (xp, nbytes, x, qn);
+
+ /* bits2octets(h) */
+ mpn_set_base256 (h, hn, digest_message, digest_length);
+
+ if (hn < qn)
+/* qlen > blen: add zero bits to the left */
+mpn_zero (&h[hn], qn - hn);
+ else if (h_bits > q_bits)
+{
+ /* qlen < blen: keep the leftmost qlen bits. We do this in 2
+ * steps because mpn_rshift only accepts shift count in the
+ * range 1 to mp_bits_per_limb-1.
+ */
+ mp_bitcnt_t s
[PATCH v2 0/3] Add support for deterministic DSA/ECDSA (RFC 6979)
From: Daiki Ueno It turned out that the initial version of _dsa_compute_k was not constant time with the input message. In this version it is checked with a valgrind-based check. Also the ecdsa-sign-deterministic test has been reorganized using a similar abstraction to struct nettle_mac in testutils.h. Daiki Ueno (3): dsa: Add a function to find k deterministically ecdsa: Add support for deterministic signature generation dsa: Add support for deterministic signature generation Makefile.in | 6 +- dsa-compute-k.c | 179 + dsa-compute-k.h | 63 ++ dsa-sign-deterministic.c | 107 ++ dsa.h | 12 ++ ecdsa-sign-deterministic.c| 74 +++ ecdsa.h | 11 ++ testsuite/.gitignore | 2 + testsuite/.test-rules.make| 6 + testsuite/Makefile.in | 4 +- testsuite/dsa-compute-k-test.c| 127 testsuite/dsa-test.c | 148 +- testsuite/ecdsa-sign-deterministic-test.c | 230 ++ 13 files changed, 965 insertions(+), 4 deletions(-) create mode 100644 dsa-compute-k.c create mode 100644 dsa-compute-k.h create mode 100644 dsa-sign-deterministic.c create mode 100644 ecdsa-sign-deterministic.c create mode 100644 testsuite/dsa-compute-k-test.c create mode 100644 testsuite/ecdsa-sign-deterministic-test.c -- 2.21.0 ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
[PATCH v2 3/3] dsa: Add support for deterministic signature generation
From: Daiki Ueno
This adds the dsa_sign_deterministic function that calculates
signature without requiring entropy source. Instead, it uses the
deterministic construction described in RFC 6979, through
_dsa_compute_k.
Signed-off-by: Daiki Ueno
---
Makefile.in | 3 +-
dsa-sign-deterministic.c | 107
dsa.h| 12
testsuite/dsa-test.c | 148 ++-
4 files changed, 268 insertions(+), 2 deletions(-)
create mode 100644 dsa-sign-deterministic.c
diff --git a/Makefile.in b/Makefile.in
index 27cbf93f..38b2a9a6 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -188,7 +188,8 @@ hogweed_SOURCES = sexp.c sexp-format.c \
eddsa-hash.c eddsa-pubkey.c eddsa-sign.c eddsa-verify.c \
ed25519-sha512-pubkey.c \
ed25519-sha512-sign.c ed25519-sha512-verify.c \
- dsa-compute-k.c ecdsa-sign-deterministic.c
+ dsa-compute-k.c ecdsa-sign-deterministic.c \
+ dsa-sign-deterministic.c
OPT_SOURCES = fat-x86_64.c fat-arm.c mini-gmp.c
diff --git a/dsa-sign-deterministic.c b/dsa-sign-deterministic.c
new file mode 100644
index ..8c75b80f
--- /dev/null
+++ b/dsa-sign-deterministic.c
@@ -0,0 +1,107 @@
+/* dsa-sign-deterministic.c
+
+ Copyright (C) 2002, 2010 Niels Möller
+ Copyright (C) 2019 Red Hat, Inc.
+
+ This file is part of GNU Nettle.
+
+ GNU Nettle is free software: you can redistribute it and/or
+ modify it under the terms of either:
+
+ * the GNU Lesser General Public License as published by the Free
+ Software Foundation; either version 3 of the License, or (at your
+ option) any later version.
+
+ or
+
+ * the GNU General Public License as published by the Free
+ Software Foundation; either version 2 of the License, or (at your
+ option) any later version.
+
+ or both in parallel, as here.
+
+ GNU Nettle 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
+ General Public License for more details.
+
+ You should have received copies of the GNU General Public License and
+ the GNU Lesser General Public License along with this program. If
+ not, see http://www.gnu.org/licenses/.
+*/
+
+#if HAVE_CONFIG_H
+# include "config.h"
+#endif
+
+#include
+#include
+
+#include "dsa.h"
+#include "dsa-internal.h"
+#include "dsa-compute-k.h"
+
+#include "bignum.h"
+
+
+int
+dsa_sign_deterministic (const struct dsa_params *params,
+ const mpz_t x,
+ void *mac_ctx,
+ nettle_hash_update_func *set_key,
+ nettle_hash_update_func *update,
+ nettle_hash_digest_func *digest,
+ size_t digest_length,
+ const uint8_t *digest_message,
+ struct dsa_signature *signature)
+{
+ mpz_t k;
+ mpz_t h;
+ mpz_t tmp;
+ int res;
+
+ /* Check that p is odd, so that invalid keys don't result in a crash
+ inside mpz_powm_sec. */
+ if (mpz_even_p (params->p))
+return 0;
+
+ /* Select k, 0q)),
+ mpz_size (params->q),
+ mpz_limbs_read (params->q),
+ mpz_limbs_read (x),
+ mac_ctx, set_key, update, digest,
+ digest_length, digest_message);
+ mpz_limbs_finish (k, mpz_size (params->q));
+
+ /* Compute r = (g^k (mod p)) (mod q) */
+ mpz_init (tmp);
+ mpz_powm_sec(tmp, params->g, k, params->p);
+ mpz_fdiv_r(signature->r, tmp, params->q);
+
+ /* Compute hash */
+ mpz_init(h);
+ _dsa_hash (h, mpz_sizeinbase(params->q, 2), digest_length, digest_message);
+
+ /* Compute k^-1 (mod q) */
+ if (mpz_invert(k, k, params->q))
+{
+ /* Compute signature s = k^-1 (h + xr) (mod q) */
+ mpz_mul(tmp, signature->r, x);
+ mpz_fdiv_r(tmp, tmp, params->q);
+ mpz_add(tmp, tmp, h);
+ mpz_mul(tmp, tmp, k);
+ mpz_fdiv_r(signature->s, tmp, params->q);
+ res = 1;
+}
+ else
+/* What do we do now? The key is invalid. */
+res = 0;
+
+ mpz_clear(k);
+ mpz_clear(h);
+ mpz_clear(tmp);
+
+ return res;
+}
diff --git a/dsa.h b/dsa.h
index 553ef327..fddaea9d 100644
--- a/dsa.h
+++ b/dsa.h
@@ -47,6 +47,7 @@ extern "C" {
#define dsa_signature_init nettle_dsa_signature_init
#define dsa_signature_clear nettle_dsa_signature_clear
#define dsa_sign nettle_dsa_sign
+#define dsa_sign_deterministic nettle_dsa_sign_deterministic
#define dsa_verify nettle_dsa_verify
#define dsa_generate_params nettle_dsa_generate_params
#define dsa_generate_keypair nettle_dsa_generate_keypair
@@ -109,6 +110,17 @@ dsa_sign(const struct dsa_params *params,
const uint8_t *digest,
[PATCH 3/3] dsa: Add support for deterministic signature generation
From: Daiki Ueno
This adds the ecdsa_sign_deterministic function that calculates
signature without requiring entropy source. Instead, it uses the
deterministic construction described in RFC 6979, through
_dsa_compute_k.
Signed-off-by: Daiki Ueno
---
Makefile.in | 3 +-
dsa-sign-deterministic.c | 107
dsa.h| 12
testsuite/dsa-test.c | 148 ++-
4 files changed, 268 insertions(+), 2 deletions(-)
create mode 100644 dsa-sign-deterministic.c
diff --git a/Makefile.in b/Makefile.in
index 5f77b98d..856f9d9e 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -187,7 +187,8 @@ hogweed_SOURCES = sexp.c sexp-format.c \
eddsa-hash.c eddsa-pubkey.c eddsa-sign.c eddsa-verify.c \
ed25519-sha512-pubkey.c \
ed25519-sha512-sign.c ed25519-sha512-verify.c \
- dsa-compute-k.c ecdsa-sign-deterministic.c
+ dsa-compute-k.c ecdsa-sign-deterministic.c \
+ dsa-sign-deterministic.c
OPT_SOURCES = fat-x86_64.c fat-arm.c mini-gmp.c
diff --git a/dsa-sign-deterministic.c b/dsa-sign-deterministic.c
new file mode 100644
index ..8c75b80f
--- /dev/null
+++ b/dsa-sign-deterministic.c
@@ -0,0 +1,107 @@
+/* dsa-sign-deterministic.c
+
+ Copyright (C) 2002, 2010 Niels Möller
+ Copyright (C) 2019 Red Hat, Inc.
+
+ This file is part of GNU Nettle.
+
+ GNU Nettle is free software: you can redistribute it and/or
+ modify it under the terms of either:
+
+ * the GNU Lesser General Public License as published by the Free
+ Software Foundation; either version 3 of the License, or (at your
+ option) any later version.
+
+ or
+
+ * the GNU General Public License as published by the Free
+ Software Foundation; either version 2 of the License, or (at your
+ option) any later version.
+
+ or both in parallel, as here.
+
+ GNU Nettle 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
+ General Public License for more details.
+
+ You should have received copies of the GNU General Public License and
+ the GNU Lesser General Public License along with this program. If
+ not, see http://www.gnu.org/licenses/.
+*/
+
+#if HAVE_CONFIG_H
+# include "config.h"
+#endif
+
+#include
+#include
+
+#include "dsa.h"
+#include "dsa-internal.h"
+#include "dsa-compute-k.h"
+
+#include "bignum.h"
+
+
+int
+dsa_sign_deterministic (const struct dsa_params *params,
+ const mpz_t x,
+ void *mac_ctx,
+ nettle_hash_update_func *set_key,
+ nettle_hash_update_func *update,
+ nettle_hash_digest_func *digest,
+ size_t digest_length,
+ const uint8_t *digest_message,
+ struct dsa_signature *signature)
+{
+ mpz_t k;
+ mpz_t h;
+ mpz_t tmp;
+ int res;
+
+ /* Check that p is odd, so that invalid keys don't result in a crash
+ inside mpz_powm_sec. */
+ if (mpz_even_p (params->p))
+return 0;
+
+ /* Select k, 0q)),
+ mpz_size (params->q),
+ mpz_limbs_read (params->q),
+ mpz_limbs_read (x),
+ mac_ctx, set_key, update, digest,
+ digest_length, digest_message);
+ mpz_limbs_finish (k, mpz_size (params->q));
+
+ /* Compute r = (g^k (mod p)) (mod q) */
+ mpz_init (tmp);
+ mpz_powm_sec(tmp, params->g, k, params->p);
+ mpz_fdiv_r(signature->r, tmp, params->q);
+
+ /* Compute hash */
+ mpz_init(h);
+ _dsa_hash (h, mpz_sizeinbase(params->q, 2), digest_length, digest_message);
+
+ /* Compute k^-1 (mod q) */
+ if (mpz_invert(k, k, params->q))
+{
+ /* Compute signature s = k^-1 (h + xr) (mod q) */
+ mpz_mul(tmp, signature->r, x);
+ mpz_fdiv_r(tmp, tmp, params->q);
+ mpz_add(tmp, tmp, h);
+ mpz_mul(tmp, tmp, k);
+ mpz_fdiv_r(signature->s, tmp, params->q);
+ res = 1;
+}
+ else
+/* What do we do now? The key is invalid. */
+res = 0;
+
+ mpz_clear(k);
+ mpz_clear(h);
+ mpz_clear(tmp);
+
+ return res;
+}
diff --git a/dsa.h b/dsa.h
index 553ef327..fddaea9d 100644
--- a/dsa.h
+++ b/dsa.h
@@ -47,6 +47,7 @@ extern "C" {
#define dsa_signature_init nettle_dsa_signature_init
#define dsa_signature_clear nettle_dsa_signature_clear
#define dsa_sign nettle_dsa_sign
+#define dsa_sign_deterministic nettle_dsa_sign_deterministic
#define dsa_verify nettle_dsa_verify
#define dsa_generate_params nettle_dsa_generate_params
#define dsa_generate_keypair nettle_dsa_generate_keypair
@@ -109,6 +110,17 @@ dsa_sign(const struct dsa_params *params,
const uint8_t *digest,
[PATCH 1/3] dsa: Add a function to find k deterministically
From: Daiki Ueno
This adds the _dsa_compute_k function that generates DSA/ECDSA k value
from the private key and the hashed message, according to RFC 6979.
Signed-off-by: Daiki Ueno
---
Makefile.in| 5 +-
dsa-compute-k.c| 169 +
dsa-compute-k.h| 63
testsuite/.gitignore | 1 +
testsuite/.test-rules.make | 3 +
testsuite/Makefile.in | 3 +-
testsuite/dsa-compute-k-test.c | 85 +
7 files changed, 326 insertions(+), 3 deletions(-)
create mode 100644 dsa-compute-k.c
create mode 100644 dsa-compute-k.h
create mode 100644 testsuite/dsa-compute-k-test.c
diff --git a/Makefile.in b/Makefile.in
index a6b8ffd6..b0adcb3c 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -186,7 +186,8 @@ hogweed_SOURCES = sexp.c sexp-format.c \
eddsa-compress.c eddsa-decompress.c eddsa-expand.c \
eddsa-hash.c eddsa-pubkey.c eddsa-sign.c eddsa-verify.c \
ed25519-sha512-pubkey.c \
- ed25519-sha512-sign.c ed25519-sha512-verify.c
+ ed25519-sha512-sign.c ed25519-sha512-verify.c \
+ dsa-compute-k.c
OPT_SOURCES = fat-x86_64.c fat-arm.c mini-gmp.c
@@ -236,7 +237,7 @@ DISTFILES = $(SOURCES) $(HEADERS) getopt.h getopt_int.h \
ctr-internal.h chacha-internal.h sha3-internal.h \
salsa20-internal.h umac-internal.h hogweed-internal.h \
rsa-internal.h pkcs1-internal.h dsa-internal.h eddsa-internal.h \
- gmp-glue.h ecc-internal.h fat-setup.h \
+ gmp-glue.h ecc-internal.h fat-setup.h dsa-compute-k.h \
mini-gmp.h asm.m4 \
nettle.texinfo nettle.info nettle.html nettle.pdf sha-example.c
diff --git a/dsa-compute-k.c b/dsa-compute-k.c
new file mode 100644
index ..ba9b50df
--- /dev/null
+++ b/dsa-compute-k.c
@@ -0,0 +1,169 @@
+/* dsa-compute-k.c
+
+ Deterministically find k value for ECDSA/DSA (RFC-6979).
+
+ Copyright (C) 2019 Red Hat, Inc.
+
+ This file is part of GNU Nettle.
+
+ GNU Nettle is free software: you can redistribute it and/or
+ modify it under the terms of either:
+
+ * the GNU Lesser General Public License as published by the Free
+ Software Foundation; either version 3 of the License, or (at your
+ option) any later version.
+
+ or
+
+ * the GNU General Public License as published by the Free
+ Software Foundation; either version 2 of the License, or (at your
+ option) any later version.
+
+ or both in parallel, as here.
+
+ GNU Nettle 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
+ General Public License for more details.
+
+ You should have received copies of the GNU General Public License and
+ the GNU Lesser General Public License along with this program. If
+ not, see http://www.gnu.org/licenses/.
+*/
+
+#if HAVE_CONFIG_H
+# include "config.h"
+#endif
+
+#include "dsa-compute-k.h"
+
+#include "gmp-glue.h"
+#include "nettle-internal.h"
+#include
+
+#define MIN(x, y) ((x) < (y) ? (x) : (y))
+#define MAX(x, y) ((x) < (y) ? (y) : (x))
+
+void
+_dsa_compute_k (mp_limb_t *k,
+ mp_size_t qn,
+ const mp_limb_t *q,
+ const mp_limb_t *x,
+ void *mac_ctx,
+ nettle_hash_update_func *set_key,
+ nettle_hash_update_func *update,
+ nettle_hash_digest_func *digest,
+ size_t digest_length,
+ const uint8_t *digest_message)
+{
+ TMP_DECL(V, uint8_t, NETTLE_MAX_HASH_DIGEST_SIZE);
+ TMP_DECL(K, uint8_t, NETTLE_MAX_HASH_DIGEST_SIZE);
+ TMP_GMP_DECL(xp, uint8_t);
+ TMP_GMP_DECL(hp, uint8_t);
+ TMP_GMP_DECL(tp, uint8_t);
+ TMP_GMP_DECL(h, mp_limb_t);
+ mp_size_t hn = (digest_length + sizeof(mp_limb_t) - 1) / sizeof(mp_limb_t);
+ mp_bitcnt_t q_bits = mpn_sizeinbase (q, qn, 2);
+ mp_bitcnt_t h_bits;
+ mp_bitcnt_t k_bits;
+ size_t nbytes = (q_bits + 7) / 8;
+ const uint8_t c0 = 0x00;
+ const uint8_t c1 = 0x01;
+
+ TMP_ALLOC(V, digest_length);
+ TMP_ALLOC(K, digest_length);
+ TMP_GMP_ALLOC(xp, nbytes);
+ TMP_GMP_ALLOC(hp, nbytes);
+ TMP_GMP_ALLOC(tp, nbytes);
+ TMP_GMP_ALLOC(h, MAX(hn, qn) * sizeof(mp_limb_t));
+
+ /* int2octets(x) */
+ mpn_get_base256 (xp, nbytes, x, qn);
+
+ /* bits2octets(h) */
+ mpn_set_base256 (h, hn, digest_message, digest_length);
+ if (hn > qn)
+mpn_copyi (h, &h[hn - qn], qn);
+ else if (hn < qn)
+mpn_zero (&h[hn], qn - hn);
+ if (h[qn - 1] > 0)
+{
+ h_bits = ((mpn_sizeinbase (h, qn, 2) + 7) / 8) * 8;
+ if (h_bits > q_bits)
+ mpn_rshift (h, h, qn, h_bits - q_bits);
+}
+ cnd_sub_n (mpn_cmp (h, q, qn) > 0, h, q, qn);
+ mpn_get_base256 (hp, nbytes, h, qn);
+
+ /* Step b */
[PATCH 2/3] ecdsa: Add support for deterministic signature generation
From: Daiki Ueno
This adds the ecdsa_sign_deterministic function that calculates
signature without requiring entropy source. Instead, it uses the
deterministic construction described in RFC 6979, through
_dsa_compute_k.
Signed-off-by: Daiki Ueno
---
Makefile.in | 2 +-
ecdsa-sign-deterministic.c| 78 ++
ecdsa.h | 11 ++
testsuite/.gitignore | 1 +
testsuite/.test-rules.make| 3 +
testsuite/Makefile.in | 3 +-
testsuite/ecdsa-sign-deterministic-test.c | 164 ++
7 files changed, 260 insertions(+), 2 deletions(-)
create mode 100644 ecdsa-sign-deterministic.c
create mode 100644 testsuite/ecdsa-sign-deterministic-test.c
diff --git a/Makefile.in b/Makefile.in
index b0adcb3c..5f77b98d 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -187,7 +187,7 @@ hogweed_SOURCES = sexp.c sexp-format.c \
eddsa-hash.c eddsa-pubkey.c eddsa-sign.c eddsa-verify.c \
ed25519-sha512-pubkey.c \
ed25519-sha512-sign.c ed25519-sha512-verify.c \
- dsa-compute-k.c
+ dsa-compute-k.c ecdsa-sign-deterministic.c
OPT_SOURCES = fat-x86_64.c fat-arm.c mini-gmp.c
diff --git a/ecdsa-sign-deterministic.c b/ecdsa-sign-deterministic.c
new file mode 100644
index ..dd5b88d9
--- /dev/null
+++ b/ecdsa-sign-deterministic.c
@@ -0,0 +1,78 @@
+/* ecdsa-sign-deterministic.c
+
+ Copyright (C) 2013 Niels Möller
+ Copyright (C) 2019 Red Hat, Inc.
+
+ This file is part of GNU Nettle.
+
+ GNU Nettle is free software: you can redistribute it and/or
+ modify it under the terms of either:
+
+ * the GNU Lesser General Public License as published by the Free
+ Software Foundation; either version 3 of the License, or (at your
+ option) any later version.
+
+ or
+
+ * the GNU General Public License as published by the Free
+ Software Foundation; either version 2 of the License, or (at your
+ option) any later version.
+
+ or both in parallel, as here.
+
+ GNU Nettle 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
+ General Public License for more details.
+
+ You should have received copies of the GNU General Public License and
+ the GNU Lesser General Public License along with this program. If
+ not, see http://www.gnu.org/licenses/.
+*/
+
+/* Development of Nettle's ECC support was funded by the .SE Internet Fund. */
+
+#if HAVE_CONFIG_H
+# include "config.h"
+#endif
+
+#include
+#include
+
+#include "ecdsa.h"
+#include "ecc-internal.h"
+#include "nettle-internal.h"
+#include "dsa-compute-k.h"
+
+void
+ecdsa_sign_deterministic (const struct ecc_scalar *key,
+ void *mac_ctx,
+ nettle_hash_update_func *set_key,
+ nettle_hash_update_func *update,
+ nettle_hash_digest_func *digest,
+ size_t digest_length,
+ const uint8_t *digest_message,
+ struct dsa_signature *signature)
+{
+ /* At most 936 bytes. */
+ TMP_DECL(k, mp_limb_t, ECC_MAX_SIZE + ECC_ECDSA_SIGN_ITCH (ECC_MAX_SIZE));
+ mp_limb_t size = key->ecc->p.size;
+ mp_limb_t *rp = mpz_limbs_write (signature->r, size);
+ mp_limb_t *sp = mpz_limbs_write (signature->s, size);
+
+ TMP_ALLOC (k, size + ECC_ECDSA_SIGN_ITCH (size));
+
+ /* Timing reveals the number of rounds through this loop, but the
+ timing is still independent of the secret k finally used. */
+ do
+{
+ _dsa_compute_k (k, key->ecc->q.size, key->ecc->q.m, key->p,
+ mac_ctx, set_key, update, digest,
+ digest_length, digest_message);
+ ecc_ecdsa_sign (key->ecc, key->p, k, digest_length, digest_message,
+ rp, sp, k + size);
+ mpz_limbs_finish (signature->r, size);
+ mpz_limbs_finish (signature->s, size);
+}
+ while (mpz_sgn (signature->r) == 0 || mpz_sgn (signature->s) == 0);
+}
diff --git a/ecdsa.h b/ecdsa.h
index 693aca8b..7d590367 100644
--- a/ecdsa.h
+++ b/ecdsa.h
@@ -43,6 +43,7 @@ extern "C" {
/* Name mangling */
#define ecdsa_sign nettle_ecdsa_sign
+#define ecdsa_sign_deterministic nettle_ecdsa_sign_deterministic
#define ecdsa_verify nettle_ecdsa_verify
#define ecdsa_generate_keypair nettle_ecdsa_generate_keypair
#define ecc_ecdsa_sign nettle_ecc_ecdsa_sign
@@ -61,6 +62,16 @@ ecdsa_sign (const struct ecc_scalar *key,
const uint8_t *digest,
struct dsa_signature *signature);
+void
+ecdsa_sign_deterministic (const struct ecc_scalar *key,
+ void *mac_ctx,
+
[PATCH 0/3] Add support for deterministic DSA/ECDSA (RFC 6979)
From: Daiki Ueno This series adds a variant of DSA/ECDSA signing functions that doesn't require random source to generate signature. The construction of the random parameter k is implemented according to RFC 6979, which will be part of FIPS 186-5: https://csrc.nist.gov/CSRC/media/Presentations/NIST-Status-Update-on-Elliptic-Curves-and-Post-Qua/images-media/moody-dustin-threshold-crypto-workshop-March-2019.pdf The motivation behind this is to make it easier to check the DSA/ECDSA functionality in the circumstances where no proper random sources are available, e.g., in the libary self-tests at early boot stage. Daiki Ueno (3): dsa: Add a function to find k deterministically ecdsa: Add support for deterministic signature generation dsa: Add support for deterministic signature generation Makefile.in | 6 +- dsa-compute-k.c | 169 ++ dsa-compute-k.h | 63 dsa-sign-deterministic.c | 107 ++ dsa.h | 12 ++ ecdsa-sign-deterministic.c| 78 ++ ecdsa.h | 11 ++ testsuite/.gitignore | 2 + testsuite/.test-rules.make| 6 + testsuite/Makefile.in | 4 +- testsuite/dsa-compute-k-test.c| 85 +++ testsuite/dsa-test.c | 148 ++- testsuite/ecdsa-sign-deterministic-test.c | 164 + 13 files changed, 851 insertions(+), 4 deletions(-) create mode 100644 dsa-compute-k.c create mode 100644 dsa-compute-k.h create mode 100644 dsa-sign-deterministic.c create mode 100644 ecdsa-sign-deterministic.c create mode 100644 testsuite/dsa-compute-k-test.c create mode 100644 testsuite/ecdsa-sign-deterministic-test.c -- 2.20.1 ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
[PATCH 0/3] Add support for deterministic DSA/ECDSA (RFC 6979)
From: Daiki Ueno This series adds a variant of DSA/ECDSA signing functions that doesn't require random source to generate signature. The construction of the random parameter k is implemented according to RFC 6979, which will be part of FIPS 186-5: https://csrc.nist.gov/CSRC/media/Presentations/NIST-Status-Update-on-Elliptic-Curves-and-Post-Qua/images-media/moody-dustin-threshold-crypto-workshop-March-2019.pdf The motivation behind this is to make it easier to check the DSA/ECDSA functionality in the circumstances where no proper random sources are available, e.g., in the libary self-tests at early boot stage. Daiki Ueno (3): dsa: Add a function to find k deterministically ecdsa: Add support for deterministic signature generation dsa: Add support for deterministic signature generation Makefile.in | 6 +- dsa-compute-k.c | 169 ++ dsa-compute-k.h | 63 dsa-sign-deterministic.c | 107 ++ dsa.h | 12 ++ ecdsa-sign-deterministic.c| 78 ++ ecdsa.h | 11 ++ testsuite/.gitignore | 2 + testsuite/.test-rules.make| 6 + testsuite/Makefile.in | 4 +- testsuite/dsa-compute-k-test.c| 85 +++ testsuite/dsa-test.c | 148 ++- testsuite/ecdsa-sign-deterministic-test.c | 164 + 13 files changed, 851 insertions(+), 4 deletions(-) create mode 100644 dsa-compute-k.c create mode 100644 dsa-compute-k.h create mode 100644 dsa-sign-deterministic.c create mode 100644 ecdsa-sign-deterministic.c create mode 100644 testsuite/dsa-compute-k-test.c create mode 100644 testsuite/ecdsa-sign-deterministic-test.c -- 2.20.1 ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH 0/8] Implement Curve448 ECDH and Ed448
Hello Niels, Daiki Ueno writes: > ni...@lysator.liu.se (Niels Möller) writes: > >> I think there are three main pieces left to integrate. >> >> 1. Curve operations to support Curve448 (i.e., diffie-hellman >>operations). I have made some progress, on my curve448 branch, >> >> 2. SHAKE 128/256. I think I had some question on the interface design. >> >> 3. EdDSA 448. >> >> Optimization of the mod p arithmetic isn't that important yet, Is there anything I can do to get this merged in upstream? Now that OpenSSL supports the curve and EdDSA, it would be interesting to add it in GnuTLS. I tried to integrate it into GnuTLS bundling the current code, and it can interoperate with OpenSSL: https://gitlab.com/gnutls/gnutls/merge_requests/984 For convenience I am attaching the remaining patches for nettle. Regards, -- Daiki Ueno ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH 0/8] Implement Curve448 ECDH and Ed448
ni...@lysator.liu.se (Niels Möller) writes: > I think there are three main pieces left to integrate. > > 1. Curve operations to support Curve448 (i.e., diffie-hellman >operations). I have made some progress, on my curve448 branch, > > 2. SHAKE 128/256. I think I had some question on the interface design. > > 3. EdDSA 448. > > Optimization of the mod p arithmetic isn't that important yet, I see. I thought that the performance of curve operations should at least be comparable to P-521. However, even with the generic ecc_mod for mod p, those are already close. So let's look at the above items first. I have rebased my patch implementing (1) on the curve448 branch: https://gitlab.com/dueno/nettle/commits/wip/dueno/curve448-2 One thing I noticed is that the point addition formula for untwisted curves doesn't look correct: https://gitlab.com/dueno/nettle/commit/4e3a50f4a50d8d03536dc107d7b77c84462e3068#6c80341e16ba39077bf2507d8450393d7e7e677a_261_262 > but I'll nevertheless try to explain how I think about it. Thank you for the detailed explanation. I ran the benchmark for those 3 variants: (1) the original version using ecc_mod, (2) the two step reduction as you suggest, and (3) my formula optimized with single 7-limbs operations: size modp reduce modq modinv mi_gcd mi_pow dup_jj ad_jja ad_hhh mul_g mul_a (us) 448 0.0727 0.0720 0.0739 44.01 1.451 52.92 1.088 1.456 1.406 299.6 557.6 521 0.0139 0.0151 0.1003 77.72 1.703 101.59 0.728 0.995 1.277 255.8 588.4 448 0.0496 0.0497 0.0764 34.77 1.500 49.59 0.923 1.158 1.169 273.5 500.1 521 0.0147 0.0144 0.1027 77.63 1.816 88.57 0.716 0.934 1.276 237.2 589.9 448 0.0641 0.0644 0.0809 52.76 1.570 49.42 1.007 1.340 1.343 288.1 570.5 521 0.0139 0.0141 0.0967 78.22 1.697 99.44 0.714 1.012 1.264 235.8 589.2 on Core i7-6600U CPU @ 2.60GHz. My code could be wrong or inefficient, but actually (2) is the fastest. (3) is slower due to the final carry handling; the carry is accumulated at most 3 and wrapping around it with cnd_add_n seems to be costly. Regards, -- Daiki Ueno ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH 0/8] Implement Curve448 ECDH and Ed448
Hello,
Thank you for the suggestions and sorry for the shameless delay.
ni...@lysator.liu.se (Niels Möller) writes:
>> Also, optimized implementation of modular reduction is currently
>> missing, which is beyond my expertise. I would appreciate any
>> suggestions regarding that.
>
> If we do Euclidean reduction, we should use the property that
>
> 2^448 = 2^224 + 1 (mod)
>
> And we'd need to use this twice to reduce a 896-bit product to 448 bits.
> On 64-bit machines, we'll get some shifting since 224 isn't a multiple
> of 64.
Due to my ignorance, I probably don't get what you mean, but as far as I
read the implementations of other curves in Nettle, some of them seem to
use the property of generalized Mersenne numbers described in:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.46.2133
and it's also applicable to the Curve448 prime.
So a 896-bit product here:
a0 + a1 * 2^k + a2 * 2^2k + a3 * 2^3k (k = 224)
can be reduced to:
b0 + b1 * 2^k (mod p)
through modular additions of the smaller numbers:
b0 = a0 + a2 + a3 (mod p)
b1 = a1 + a2 + a3 + a3 (mod p)
I tried to implement it (as attached) and got 20-30% speed-up with
mini-gmp.
size modp reduce modq modinv mi_gcd mi_pow dup_jj ad_jja ad_hhh mul_g
mul_a (us)
192 0.0066 0.0061 0.0770 28.90 0.000 0.00 0.698 0.811 1.014 44.2
188.5
224 0.0091 0.0091 0.1231 47.57 0.000 0.00 0.969 1.285 1.566 90.2
329.1
255 0.0081 0.0078 0.1550 18.70 0.000 0.00 0.767 1.014 1.082 88.7
278.4
256 0.1288 0.0115 0.1464 50.22 0.000 0.00 1.004 1.457 1.701 105.6
380.1
384 0.0170 0.0170 0.1260 106.51 0.000 0.00 1.791 2.240 3.113 305.9
1015.7
448 0.1892 0.1886 0.1886 171.57 0.000 0.00 3.630 4.914 4.940 842.1
1966.8
521 0.0163 0.0158 0.2821 217.44 0.000 0.00 3.555 4.507 6.107 788.8
2637.8
size modp reduce modq modinv mi_gcd mi_pow dup_jj ad_jja ad_hhh mul_g
mul_a (us)
192 0.0080 0.0082 0.0748 30.61 0.000 0.00 0.663 0.810 1.007 43.9
189.9
224 0.0103 0.0108 0.1281 47.48 0.000 0.00 0.968 1.481 1.632 89.4
323.2
255 0.0095 0.0090 0.1545 18.71 0.000 0.00 0.828 1.081 1.085 90.8
284.9
256 0.1353 0.0123 0.1423 51.25 0.000 0.00 0.992 1.326 1.726 107.4
379.3
384 0.0174 0.0171 0.1253 108.82 0.000 0.00 1.760 2.233 2.991 302.9
1004.2
448 0.1382 0.1380 0.1865 147.87 0.000 0.00 3.167 4.161 4.211 738.6
1668.3
521 0.0186 0.0179 0.2750 216.30 0.000 0.00 3.438 4.249 5.756 743.5
2510.6
Do you think this is acceptable or need further optimization?
Regards,
--
Daiki Ueno
>From bc210d94144d6b5d1e050f78b7261d58a58d8f19 Mon Sep 17 00:00:00 2001
From: Daiki Ueno
Date: Tue, 9 Jan 2018 16:13:53 +0100
Subject: [PATCH] ecc: Add optimized modp implementation for curve448
Signed-off-by: Daiki Ueno
---
ecc-448.c | 72 +--
1 file changed, 70 insertions(+), 2 deletions(-)
diff --git a/ecc-448.c b/ecc-448.c
index f98616d8..d62e8e1b 100644
--- a/ecc-448.c
+++ b/ecc-448.c
@@ -45,6 +45,74 @@
#include "ecc-448.h"
+#if HAVE_NATIVE_ecc_448_modp
+
+#define ecc_448_modp nettle_ecc_448_modp
+void
+ecc_448_modp (const struct ecc_modulo *m, mp_limb_t *rp);
+
+#elif GMP_NUMB_BITS == 64
+/*
+ * Use 2^448 = 2^224 + 1 (mod p), compute:
+ * b0 + b1 * 2^224 = a0 + a1 * 2^224 + a2 * 2^448 + a3 * 2^672 (mod p)
+ *
+ * as p is considered as a generalized Mersenne number, b0 and b1 can
+ * be calculated with the following shortcut:
+ *
+ * b0 = a0 + a2 + a3 (mod p)
+ * b1 = a1 + a2 + a3 + a3 (mod p)
+ */
+static void
+ecc_448_modp (const struct ecc_modulo *m, mp_limb_t *rp)
+{
+ mp_limb_t a1[4], a3[4], cy, mask;
+
+ /* Extract a1 */
+ mpn_copyi (a1, rp + 3, 4);
+ mpn_rshift (a1, a1, 4, 32);
+ rp[3] &= 0x;
+
+ /* Extract a3 */
+ mpn_copyi (a3, rp + 10, 4);
+ mpn_rshift (a3, a3, 4, 32);
+ rp[10] &= 0x;
+
+ /* a2 = a2 + a3 */
+ mpn_add_n (rp + 7, rp + 7, a3, 4);
+
+ /* a0 = a0 + a2 (carry propagated to a2) */
+ mpn_add_n (rp, rp, rp + 7, 4);
+ mpn_rshift (&cy, rp + 3, 1, 32);
+ sec_add_1 (rp + 7, rp + 7, 4, cy);
+
+ /* a2 = a2 + a1 */
+ mpn_add_n (rp + 7, rp + 7, a1, 4);
+
+ /* a2 = a2 + a3 */
+ mpn_add_n (rp + 7, rp + 7, a3, 4);
+ mpn_rshift (&cy, rp + 10, 1, 32);
+
+ /* Move a2 next to a0 */
+ rp[6] = 0;
+ mpn_lshift (rp + 6, rp + 7, 4, 32);
+ rp[3] &= 0x;
+ rp[3] |= rp[6];
+ mpn_copyi (rp + 4, rp + 7, 3);
+
+ assert (cy <= 3);
+ mask = (1 << cy) - 1;
+ cy = cnd_add_n (mask & 1, rp, ecc_Bmodp, 7);
+ assert (cy == 0);
+ cy = cnd_add_n (mask & 2, rp, ecc_Bmodp, 7);
+ assert (cy == 0);
+ cy = cnd_add_n (mask & 4, rp, ecc_Bmodp, 7);
+ assert (cy == 0);
+}
+
+#else
+#define ecc_448_modp ecc_mod
+#endif
+
/* Needs 2*ecc->size limbs at rp, and 2*ecc->size additional limbs of
scratch sp
[PATCH 8/8] Implement Ed448 signature scheme
From: Daiki Ueno Signed-off-by: Daiki Ueno --- Makefile.in | 4 +- ecc-192.c | 1 + ecc-224.c | 1 + ecc-25519.c | 1 + ecc-256.c | 1 + ecc-384.c | 1 + ecc-448.c | 1 + ecc-521.c | 1 + ecc-internal.h | 18 +++ ed25519-sha512-sign.c | 15 +++ ed448-shake256-pubkey.c | 60 ++ ed448-shake256-sign.c | 92 +++ ed448-shake256-verify.c | 66 +++ eddsa-compress.c| 11 +- eddsa-decompress.c | 17 ++- eddsa-expand.c | 20 +++- eddsa-hash.c| 35 ++ eddsa-pubkey.c | 2 +- eddsa-sign.c| 16 +-- eddsa-verify.c | 16 ++- eddsa.h | 24 nettle.texinfo | 25 + testsuite/.test-rules.make | 3 + testsuite/Makefile.in | 2 +- testsuite/ed448-test.c | 240 testsuite/eddsa-compress-test.c | 137 --- testsuite/eddsa-sign-test.c | 66 ++- testsuite/eddsa-verify-test.c | 49 +++- 28 files changed, 833 insertions(+), 92 deletions(-) create mode 100644 ed448-shake256-pubkey.c create mode 100644 ed448-shake256-sign.c create mode 100644 ed448-shake256-verify.c create mode 100644 testsuite/ed448-test.c diff --git a/Makefile.in b/Makefile.in index 80c66ce8..10185bb8 100644 --- a/Makefile.in +++ b/Makefile.in @@ -185,7 +185,9 @@ hogweed_SOURCES = sexp.c sexp-format.c \ eddsa-compress.c eddsa-decompress.c eddsa-expand.c \ eddsa-hash.c eddsa-pubkey.c eddsa-sign.c eddsa-verify.c \ ed25519-sha512-pubkey.c \ - ed25519-sha512-sign.c ed25519-sha512-verify.c + ed25519-sha512-sign.c ed25519-sha512-verify.c \ + ed448-shake256-pubkey.c \ + ed448-shake256-sign.c ed448-shake256-verify.c OPT_SOURCES = fat-x86_64.c fat-arm.c mini-gmp.c diff --git a/ecc-192.c b/ecc-192.c index 1fbbcded..319d1418 100644 --- a/ecc-192.c +++ b/ecc-192.c @@ -172,6 +172,7 @@ const struct ecc_curve nettle_secp_192r1 = ecc_b, ecc_g, NULL, + NULL, ecc_unit, ecc_table }; diff --git a/ecc-224.c b/ecc-224.c index b1ff0578..f679c01a 100644 --- a/ecc-224.c +++ b/ecc-224.c @@ -124,6 +124,7 @@ const struct ecc_curve nettle_secp_224r1 = ecc_b, ecc_g, NULL, + NULL, ecc_unit, ecc_table }; diff --git a/ecc-25519.c b/ecc-25519.c index 16073ecf..ac5638a6 100644 --- a/ecc-25519.c +++ b/ecc-25519.c @@ -352,6 +352,7 @@ const struct ecc_curve _nettle_curve25519 = ecc_d, /* Use the Edwards curve constant. */ ecc_g, ecc_edwards, + &_nettle_ed25519_sha512, ecc_unit, ecc_table }; diff --git a/ecc-256.c b/ecc-256.c index d0870657..e9268e76 100644 --- a/ecc-256.c +++ b/ecc-256.c @@ -301,6 +301,7 @@ const struct ecc_curve nettle_secp_256r1 = ecc_b, ecc_g, NULL, + NULL, ecc_unit, ecc_table }; diff --git a/ecc-384.c b/ecc-384.c index 006c4568..4aa7f96e 100644 --- a/ecc-384.c +++ b/ecc-384.c @@ -209,6 +209,7 @@ const struct ecc_curve nettle_secp_384r1 = ecc_b, ecc_g, NULL, + NULL, ecc_unit, ecc_table }; diff --git a/ecc-448.c b/ecc-448.c index a70ff7cc..f98616d8 100644 --- a/ecc-448.c +++ b/ecc-448.c @@ -267,6 +267,7 @@ const struct ecc_curve _nettle_curve448 = ecc_b, ecc_g, NULL, + &_nettle_ed448_shake256, ecc_unit, ecc_table }; diff --git a/ecc-521.c b/ecc-521.c index 9d32b54e..396f66e0 100644 --- a/ecc-521.c +++ b/ecc-521.c @@ -137,6 +137,7 @@ const struct ecc_curve nettle_secp_521r1 = ecc_b, ecc_g, NULL, + NULL, ecc_unit, ecc_table }; diff --git a/ecc-internal.h b/ecc-internal.h index b58093ee..1ddec986 100644 --- a/ecc-internal.h +++ b/ecc-internal.h @@ -84,6 +84,9 @@ extern const struct ecc_curve _nettle_curve25519; extern const struct ecc_curve _nettle_curve448; +extern const struct ecc_eddsa _nettle_ed25519_sha512; +extern const struct ecc_eddsa _nettle_ed448_shake256; + #define ECC_MAX_SIZE ((521 + GMP_NUMB_BITS - 1) / GMP_NUMB_BITS) /* Window size for ecc_mul_a. Using 4 bits seems like a good choice, @@ -200,6 +203,9 @@ struct ecc_curve equivalent Edwards curve. */ const mp_limb_t *edwards_root; + /* EdDSA parameters; NULL if the curve is not usable in EdDSA. */ + const struct ecc_eddsa *eddsa; + /* For redc, same as B mod p, otherwise 1. */ const mp_limb_t *unit; @@ -216,6 +222,18 @@ struct ecc_curve const mp_limb_t *pippenger_table; }; +/* EdDSA parameters. */ +typedef void ecc_eddsa_dom_func (int phflag, size_t length, uint8_t *context, +const struct nettle_hash *hash, +v
[PATCH 5/8] ecc-eh-to-a, eddsa-sign: Parameterize hard-coded value
From: Daiki Ueno This allows the same code to be reused in curve448 and Ed448. Signed-off-by: Daiki Ueno --- ecc-eh-to-a.c | 2 +- eddsa-sign.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/ecc-eh-to-a.c b/ecc-eh-to-a.c index 2acaacb1..b9d412d2 100644 --- a/ecc-eh-to-a.c +++ b/ecc-eh-to-a.c @@ -73,7 +73,7 @@ ecc_eh_to_a (const struct ecc_curve *ecc, at all? Full reduction mod p is maybe sufficient. */ unsigned shift; assert (ecc->p.bit_size == 255); - shift = 252 - GMP_NUMB_BITS * (ecc->p.size - 1); + shift = ecc->q.bit_size - 1 - GMP_NUMB_BITS * (ecc->p.size - 1); cy = mpn_submul_1 (r, ecc->q.m, ecc->p.size, r[ecc->p.size-1] >> shift); assert (cy < 2); diff --git a/eddsa-sign.c b/eddsa-sign.c index c1404f67..e5dc0e9d 100644 --- a/eddsa-sign.c +++ b/eddsa-sign.c @@ -92,7 +92,7 @@ _eddsa_sign (const struct ecc_curve *ecc, unsigned shift; mp_limb_t cy; assert (ecc->p.bit_size == 255); -shift = 252 - GMP_NUMB_BITS * (ecc->p.size - 1); +shift = ecc->q.bit_size - 1 - GMP_NUMB_BITS * (ecc->p.size - 1); cy = mpn_submul_1 (sp, ecc->q.m, ecc->p.size, sp[ecc->p.size-1] >> shift); assert (cy < 2); -- 2.13.3 ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
[PATCH 2/8] eccdata: Emit correct ecc_Bmodq_shifted for curve448
From: Daiki Ueno
In curve448, the bit size of the order is slightly smaller than the
one of p's. Adjust ecc_Bmodq_shifted accordingly.
Signed-off-by: Daiki Ueno
---
eccdata.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/eccdata.c b/eccdata.c
index 9533d783..9be9afb5 100644
--- a/eccdata.c
+++ b/eccdata.c
@@ -1014,16 +1014,19 @@ output_curve (const struct ecc_curve *ecc, unsigned
bits_per_limb)
exit (EXIT_FAILURE);
}
}
+}
+ else
+printf ("#define ecc_Bmodp_shifted ecc_Bmodp\n");
+
+ if (bits < limb_size * bits_per_limb)
+{
mpz_set_ui (t, 0);
- mpz_setbit (t, ecc->bit_size);
+ mpz_setbit (t, bits);
mpz_sub (t, t, ecc->q);
output_bignum ("ecc_Bmodq_shifted", t, limb_size, bits_per_limb);
}
else
-{
- printf ("#define ecc_Bmodp_shifted ecc_Bmodp\n");
- printf ("#define ecc_Bmodq_shifted ecc_Bmodq\n");
-}
+printf ("#define ecc_Bmodq_shifted ecc_Bmodq\n");
mpz_add_ui (t, ecc->p, 1);
mpz_fdiv_q_2exp (t, t, 1);
--
2.13.3
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
[PATCH 4/8] ecc: Add add_hh and dup members to ecc_curve
From: Daiki Ueno This makes it possible to share the same code for curve25519 and curve448 primitives, which use different underlying formulas for addition and doubling. Signed-off-by: Daiki Ueno --- ecc-192.c| 4 ecc-224.c| 4 ecc-25519.c | 4 ecc-256.c| 4 ecc-384.c| 4 ecc-521.c| 4 ecc-internal.h | 8 ecc-mul-a-eh.c | 12 ++-- ecc-mul-g-eh.c | 4 ++-- testsuite/ecc-add-test.c | 43 +-- testsuite/ecc-dup-test.c | 10 +- 11 files changed, 70 insertions(+), 31 deletions(-) diff --git a/ecc-192.c b/ecc-192.c index 5c52b043..1fbbcded 100644 --- a/ecc-192.c +++ b/ecc-192.c @@ -155,12 +155,16 @@ const struct ecc_curve nettle_secp_192r1 = ECC_PIPPENGER_K, ECC_PIPPENGER_C, + ECC_ADD_JJA_ITCH (ECC_LIMB_SIZE), ECC_ADD_JJJ_ITCH (ECC_LIMB_SIZE), + ECC_DUP_JJ_ITCH (ECC_LIMB_SIZE), ECC_MUL_A_ITCH (ECC_LIMB_SIZE), ECC_MUL_G_ITCH (ECC_LIMB_SIZE), ECC_J_TO_A_ITCH (ECC_LIMB_SIZE), + ecc_add_jja, ecc_add_jjj, + ecc_dup_jj, ecc_mul_a, ecc_mul_g, ecc_j_to_a, diff --git a/ecc-224.c b/ecc-224.c index cdb42197..b1ff0578 100644 --- a/ecc-224.c +++ b/ecc-224.c @@ -107,12 +107,16 @@ const struct ecc_curve nettle_secp_224r1 = ECC_PIPPENGER_K, ECC_PIPPENGER_C, + ECC_ADD_JJA_ITCH (ECC_LIMB_SIZE), ECC_ADD_JJJ_ITCH (ECC_LIMB_SIZE), + ECC_DUP_JJ_ITCH (ECC_LIMB_SIZE), ECC_MUL_A_ITCH (ECC_LIMB_SIZE), ECC_MUL_G_ITCH (ECC_LIMB_SIZE), ECC_J_TO_A_ITCH (ECC_LIMB_SIZE), + ecc_add_jja, ecc_add_jjj, + ecc_dup_jj, ecc_mul_a, ecc_mul_g, ecc_j_to_a, diff --git a/ecc-25519.c b/ecc-25519.c index 92de49be..16073ecf 100644 --- a/ecc-25519.c +++ b/ecc-25519.c @@ -335,12 +335,16 @@ const struct ecc_curve _nettle_curve25519 = ECC_PIPPENGER_K, ECC_PIPPENGER_C, + ECC_ADD_EH_ITCH (ECC_LIMB_SIZE), ECC_ADD_EHH_ITCH (ECC_LIMB_SIZE), + ECC_DUP_EH_ITCH (ECC_LIMB_SIZE), ECC_MUL_A_EH_ITCH (ECC_LIMB_SIZE), ECC_MUL_G_EH_ITCH (ECC_LIMB_SIZE), ECC_EH_TO_A_ITCH (ECC_LIMB_SIZE, ECC_25519_INV_ITCH), + ecc_add_eh, ecc_add_ehh, + ecc_dup_eh, ecc_mul_a_eh, ecc_mul_g_eh, ecc_eh_to_a, diff --git a/ecc-256.c b/ecc-256.c index e757985c..d0870657 100644 --- a/ecc-256.c +++ b/ecc-256.c @@ -284,12 +284,16 @@ const struct ecc_curve nettle_secp_256r1 = ECC_PIPPENGER_K, ECC_PIPPENGER_C, + ECC_ADD_JJA_ITCH (ECC_LIMB_SIZE), ECC_ADD_JJJ_ITCH (ECC_LIMB_SIZE), + ECC_DUP_JJ_ITCH (ECC_LIMB_SIZE), ECC_MUL_A_ITCH (ECC_LIMB_SIZE), ECC_MUL_G_ITCH (ECC_LIMB_SIZE), ECC_J_TO_A_ITCH (ECC_LIMB_SIZE), + ecc_add_jja, ecc_add_jjj, + ecc_dup_jj, ecc_mul_a, ecc_mul_g, ecc_j_to_a, diff --git a/ecc-384.c b/ecc-384.c index a393c61f..006c4568 100644 --- a/ecc-384.c +++ b/ecc-384.c @@ -192,12 +192,16 @@ const struct ecc_curve nettle_secp_384r1 = ECC_PIPPENGER_K, ECC_PIPPENGER_C, + ECC_ADD_JJA_ITCH (ECC_LIMB_SIZE), ECC_ADD_JJJ_ITCH (ECC_LIMB_SIZE), + ECC_DUP_JJ_ITCH (ECC_LIMB_SIZE), ECC_MUL_A_ITCH (ECC_LIMB_SIZE), ECC_MUL_G_ITCH (ECC_LIMB_SIZE), ECC_J_TO_A_ITCH (ECC_LIMB_SIZE), + ecc_add_jja, ecc_add_jjj, + ecc_dup_jj, ecc_mul_a, ecc_mul_g, ecc_j_to_a, diff --git a/ecc-521.c b/ecc-521.c index 1a08f209..9d32b54e 100644 --- a/ecc-521.c +++ b/ecc-521.c @@ -120,12 +120,16 @@ const struct ecc_curve nettle_secp_521r1 = ECC_PIPPENGER_K, ECC_PIPPENGER_C, + ECC_ADD_JJA_ITCH (ECC_LIMB_SIZE), ECC_ADD_JJJ_ITCH (ECC_LIMB_SIZE), + ECC_DUP_JJ_ITCH (ECC_LIMB_SIZE), ECC_MUL_A_ITCH (ECC_LIMB_SIZE), ECC_MUL_G_ITCH (ECC_LIMB_SIZE), ECC_J_TO_A_ITCH (ECC_LIMB_SIZE), + ecc_add_jja, ecc_add_jjj, + ecc_dup_jj, ecc_mul_a, ecc_mul_g, ecc_j_to_a, diff --git a/ecc-internal.h b/ecc-internal.h index ce1e34fb..643277c0 100644 --- a/ecc-internal.h +++ b/ecc-internal.h @@ -112,6 +112,10 @@ typedef void ecc_add_func (const struct ecc_curve *ecc, const mp_limb_t *p, const mp_limb_t *q, mp_limb_t *scratch); +typedef void ecc_dup_func (const struct ecc_curve *ecc, + mp_limb_t *r, const mp_limb_t *p, + mp_limb_t *scratch); + typedef void ecc_mul_g_func (const struct ecc_curve *ecc, mp_limb_t *r, const mp_limb_t *np, mp_limb_t *scratch); @@ -168,12 +172,16 @@ struct ecc_curve unsigned short pippenger_k; unsigned short pippenger_c; + unsigned short add_hh_itch; unsigned short add_hhh_itch; + unsigned short dup_itch; unsigned short mul_itch; unsigned short mul_g_itch; unsigned short h_to_a_itch; + ecc_add_func *add_hh; ecc_add_func *add_hhh; + ecc_dup_func *dup; ecc_mul_func *mul; ecc_mul_g_func *mul_g; ecc_h_to_a_func *h_to_a; diff --git a/ecc-mul-a-eh.c b/ecc-mul-a-eh.c index cf743236..e9b22cd4 100644 --- a/ecc-mul-a-eh.c
[PATCH 3/8] eccdata: Redirect ecc_point_out to given stream, instead of stderr
From: Daiki Ueno
Signed-off-by: Daiki Ueno
---
eccdata.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/eccdata.c b/eccdata.c
index 9be9afb5..97a61941 100644
--- a/eccdata.c
+++ b/eccdata.c
@@ -694,11 +694,11 @@ ecc_point_out (FILE *f, const struct ecc_point *p)
fprintf (f, "zero");
else
{
- fprintf (stderr, "(");
- mpz_out_str (stderr, 16, p->x);
- fprintf (stderr, ",\n ");
- mpz_out_str (stderr, 16, (p)->y);
- fprintf (stderr, ")");
+ fprintf (f, "(");
+ mpz_out_str (f, 16, p->x);
+ fprintf (f, ",\n ");
+ mpz_out_str (f, 16, (p)->y);
+ fprintf (f, ")");
}
}
#define ASSERT_EQUAL(p, q) do {
\
--
2.13.3
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
[PATCH 6/8] Implement curve448 primitives
From: Daiki Ueno
This patch adds the necessary primitives for "curve448": namely,
addition, doubling, scalar multiplication of the generator
or an arbitrary point, inversion, and square root.
Although the interface is similar to curve25519, the implementation is
slightly different. For curve25519, the Pippenger tables are
generated through the coordinates on the Montgomery curve. On the
other hand, for curve448 the tables are directly generated from the
coordinates on the corresponding Edwards curve ("edwards448").
The motivation behind this is that the formula converting the Edwards
curve coordinates to the Montgomery curve coordinates is simpler than
the other way around for curve448/edwards448.
Signed-off-by: Daiki Ueno
---
.gitignore| 1 +
Makefile.in | 10 +-
curve448-eh-to-x.c| 73
curve448-mul-g.c | 74
curve448-mul.c| 148 +++
curve448.h| 58 +
ecc-448.c | 272 ++
ecc-add-eh.c | 74 +++-
ecc-add-ehh.c | 77 +++-
ecc-dup-eh.c | 55 -
ecc-eh-to-a.c | 2 +-
ecc-internal.h| 31 -
ecc-point-mul-g.c | 7 +-
ecc-point-mul.c | 2 +-
ecc-point.c | 15 +++
eccdata.c | 160 -
ecdsa-keygen.c| 4 +-
examples/ecc-benchmark.c | 1 +
nettle.texinfo| 59 +++--
testsuite/.test-rules.make| 3 +
testsuite/Makefile.in | 2 +-
testsuite/curve448-dh-test.c | 100
testsuite/ecc-add-test.c | 9 +-
testsuite/ecc-dup-test.c | 2 +-
testsuite/ecc-mul-a-test.c| 4 +-
testsuite/ecc-mul-g-test.c| 4 +-
testsuite/ecdh-test.c | 16 ++-
testsuite/ecdsa-keygen-test.c | 16 +++
testsuite/testutils.c | 14 ++-
29 files changed, 1248 insertions(+), 45 deletions(-)
create mode 100644 curve448-eh-to-x.c
create mode 100644 curve448-mul-g.c
create mode 100644 curve448-mul.c
create mode 100644 curve448.h
create mode 100644 ecc-448.c
create mode 100644 testsuite/curve448-dh-test.c
diff --git a/.gitignore b/.gitignore
index 1f3b92b9..92af6a46 100644
--- a/.gitignore
+++ b/.gitignore
@@ -50,6 +50,7 @@ core
/ecc-384.h
/ecc-521.h
/ecc-25519.h
+/ecc-448.h
/nettle.aux
/nettle.cp
/nettle.cps
diff --git a/Makefile.in b/Makefile.in
index 7e8f29c2..2cf44a31 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -168,7 +168,7 @@ hogweed_SOURCES = sexp.c sexp-format.c \
ecc-mod.c ecc-mod-inv.c \
ecc-mod-arith.c ecc-pp1-redc.c ecc-pm1-redc.c \
ecc-192.c ecc-224.c ecc-256.c ecc-384.c ecc-521.c \
- ecc-25519.c \
+ ecc-25519.c ecc-448.c \
ecc-size.c ecc-j-to-a.c ecc-a-to-j.c \
ecc-dup-jj.c ecc-add-jja.c ecc-add-jjj.c \
ecc-eh-to-a.c \
@@ -179,6 +179,7 @@ hogweed_SOURCES = sexp.c sexp-format.c \
ecc-ecdsa-sign.c ecdsa-sign.c \
ecc-ecdsa-verify.c ecdsa-verify.c ecdsa-keygen.c \
curve25519-mul-g.c curve25519-mul.c curve25519-eh-to-x.c \
+ curve448-mul-g.c curve448-mul.c curve448-eh-to-x.c \
eddsa-compress.c eddsa-decompress.c eddsa-expand.c \
eddsa-hash.c eddsa-pubkey.c eddsa-sign.c eddsa-verify.c \
ed25519-sha512-pubkey.c \
@@ -189,7 +190,7 @@ OPT_SOURCES = fat-x86_64.c fat-arm.c mini-gmp.c
HEADERS = aes.h arcfour.h arctwo.h asn1.h blowfish.h \
base16.h base64.h bignum.h buffer.h camellia.h cast128.h \
cbc.h ccm.h chacha.h chacha-poly1305.h ctr.h \
- curve25519.h des.h des-compat.h dsa.h dsa-compat.h eax.h \
+ curve25519.h curve448.h des.h des-compat.h dsa.h dsa-compat.h eax.h \
ecc-curve.h ecc.h ecdsa.h eddsa.h \
gcm.h gosthash94.h hmac.h \
knuth-lfib.h \
@@ -363,6 +364,9 @@ ecc-521.h: eccdata.stamp
ecc-25519.h: eccdata.stamp
./eccdata$(EXEEXT_FOR_BUILD) 255 14 6 $(GMP_NUMB_BITS) > $@T && mv $@T
$@
+ecc-448.h: eccdata.stamp
+ ./eccdata$(EXEEXT_FOR_BUILD) 448 64 6 $(GMP_NUMB_BITS) > $@T && mv $@T
$@
+
eccdata.stamp: eccdata.c
$(MAKE) eccdata$(EXEEXT_FOR_BUILD)
echo stamp > eccdata.stamp
@@ -373,6 +377,7 @@ ecc-256.$(OBJEXT): ecc-256.h
ecc-384.$(OBJEXT): ecc-384.h
ecc-521.$(OBJEXT): ecc-521.h
ecc-25519.$(OBJEXT): ecc-25519.h
+ecc-448.$(OBJEXT): ecc-448.h
.asm.$(OBJEXT): $(srcdir)/asm.m4 machine.m4 config.m4
$(M4) $(srcdir)/asm.m4 machine.m4 config.m4 $< >$*.s
@@ -626,6 +631,7 @@ distcheck: dist
clean-here:
-rm -f $(TARGETS) *.$(OBJEXT) *.s *.so *.dll *.a \
[PATCH 0/8] Implement Curve448 ECDH and Ed448
Hello, This patch series implements the Curve448 Diffie-Hellman protocol (RFC 7748) and the Ed448 signature scheme (RFC 8032). Although I tried to make it as close as possible to the Curve25519 and Ed25519 implementations, I had to add a few special cases, namely: - for Curve448, eccdata directly calculates points on the Edwards curve instead of the equivalent Montgomery curve - untwisted versions of ecc_add_eh* and ecc_dup_eh are added - the point decoding for Ed448 uses a different formula to recover u and v Also, optimized implementation of modular reduction is currently missing, which is beyond my expertise. I would appreciate any suggestions regarding that. The patches are also available on: https://gitlab.com/dueno/nettle/commits/wip/dueno/ed448 Thanks to Hubert Kario and Nikos Mavrogiannopoulos for initial reviews. Daiki Ueno (8): ecc-mul-test: Fix mpn_cmp calls eccdata: Emit correct ecc_Bmodq_shifted for curve448 eccdata: Redirect ecc_point_out to given stream, instead of stderr ecc: Add add_hh and dup members to ecc_curve ecc-eh-to-a, eddsa-sign: Parameterize hard-coded value Implement curve448 primitives Implement SHAKE128/256 functions Implement Ed448 signature scheme .gitignore |1 + Makefile.in | 18 +- curve448-eh-to-x.c | 73 + curve448-mul-g.c| 74 + curve448-mul.c | 148 + curve448.h | 58 + ecc-192.c |5 + ecc-224.c |5 + ecc-25519.c |5 + ecc-256.c |5 + ecc-384.c |5 + ecc-448.c | 273 ++ ecc-521.c |5 + ecc-add-eh.c| 74 +- ecc-add-ehh.c | 77 +- ecc-dup-eh.c| 55 +- ecc-eh-to-a.c |4 +- ecc-internal.h | 57 +- ecc-mul-a-eh.c | 12 +- ecc-mul-g-eh.c |4 +- ecc-point-mul-g.c |7 +- ecc-point-mul.c |2 +- ecc-point.c | 15 + eccdata.c | 183 +- ecdsa-keygen.c |4 +- ed25519-sha512-sign.c | 15 + ed448-shake256-pubkey.c | 60 + ed448-shake256-sign.c | 92 + ed448-shake256-verify.c | 66 + eddsa-compress.c| 11 +- eddsa-decompress.c | 15 +- eddsa-expand.c | 20 +- eddsa-hash.c| 35 + eddsa-pubkey.c |2 +- eddsa-sign.c| 18 +- eddsa-verify.c | 16 +- eddsa.h | 24 + examples/ecc-benchmark.c|1 + nettle-internal.h |2 +- nettle-meta-hashes.c|2 + nettle-meta.h |2 + nettle.texinfo | 152 +- sha3.c | 13 + sha3.h | 56 + shake128-meta.c | 42 + shake128.c | 84 + shake256-meta.c | 42 + shake256.c | 84 + testsuite/.test-rules.make | 12 + testsuite/Makefile.in |5 +- testsuite/curve448-dh-test.c| 100 + testsuite/ecc-add-test.c| 48 +- testsuite/ecc-dup-test.c| 12 +- testsuite/ecc-mul-a-test.c |6 +- testsuite/ecc-mul-g-test.c |6 +- testsuite/ecdh-test.c | 16 +- testsuite/ecdsa-keygen-test.c | 16 + testsuite/ed448-test.c | 240 ++ testsuite/eddsa-compress-test.c | 137 +- testsuite/eddsa-sign-test.c | 66 +- testsuite/eddsa-verify-test.c | 49 +- testsuite/meta-hash-test.c |2 + testsuite/shake.awk | 14 + testsuite/shake128-test.c | 6183 +++ testsuite/shake256-test.c | 6183 +++ testsuite/testutils.c | 57 +- 66 files changed, 14976 insertions(+), 199 deletions(-) create mode 100644 curve448-eh-to-x.c create mode 100644 curve448-mul-g.c create mode 100644 curve448-mul.c create mode 100644 curve448.h create mode 100644 ecc-448.c create mode 100644 ed448-shake256-pubkey.c create mode 100644 ed448-shake256-sign.c create mode 100644 ed448-shake256-verify.c create mode 100644 shake128-meta.c create mode 100644 shake128.c create mode 100644 shake256-meta.c create mode 100644 shake256.c create mode 100644 testsuite/curve448-dh-test.c create mode 100644 testsuite/ed448-test.c create mode 100755 testsuite/shake.awk create mode 100644 testsuite/shake128-test.c create mode 100644 testsuite/shake256-test.c -- 2.13.3 ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
[PATCH 1/8] ecc-mul-test: Fix mpn_cmp calls
From: Daiki Ueno
Signed-off-by: Daiki Ueno
---
testsuite/ecc-mul-a-test.c | 2 +-
testsuite/ecc-mul-g-test.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/testsuite/ecc-mul-a-test.c b/testsuite/ecc-mul-a-test.c
index b206b848..245016aa 100644
--- a/testsuite/ecc-mul-a-test.c
+++ b/testsuite/ecc-mul-a-test.c
@@ -26,7 +26,7 @@ test_main (void)
ecc->mul (ecc, p, n, ecc->g, scratch);
ecc->h_to_a (ecc, 0, p, p, scratch);
- if (mpn_cmp (p, ecc->g, 2*size != 0))
+ if (mpn_cmp (p, ecc->g, 2*size) != 0)
die ("curve %d: ecc->mul with n = 1 failed.\n", ecc->p.bit_size);
for (n[0] = 2; n[0] <= 4; n[0]++)
diff --git a/testsuite/ecc-mul-g-test.c b/testsuite/ecc-mul-g-test.c
index 1c4d0c05..27239484 100644
--- a/testsuite/ecc-mul-g-test.c
+++ b/testsuite/ecc-mul-g-test.c
@@ -25,7 +25,7 @@ test_main (void)
ecc->mul_g (ecc, p, n, scratch);
ecc->h_to_a (ecc, 0, p, p, scratch);
- if (mpn_cmp (p, ecc->g, 2*size != 0))
+ if (mpn_cmp (p, ecc->g, 2*size) != 0)
{
fprintf (stderr, "ecc->mul_g with n = 1 failed.\n");
abort ();
--
2.13.3
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] Avoid assertion failure in pss_verify_mgf1
ni...@lysator.liu.se (Niels Möller) writes: > Daiki Ueno writes: > >> ni...@lysator.liu.se (Niels Möller) writes: >> >>> if (mpz_sizeinbase(m, 2) > bits) >>> goto cleanup; >>> >>> (one might also move initial size checks before the allocations). > >> I think the above check is too rigid, since it is based on bit-length, >> it wouldn't tolerate some cases such as m is 1016 bits and bits is 1015, >> where both can be represented in 127 octets. > > I see, a bit odd to tolerate that case. Can it ever happen for a valid > signature created according to spec? Section 8.1.1 on signing says > > 1. EMSA-PSS encoding: Apply the EMSA-PSS encoding operation (Section > 9.1.1) to the message M to produce an encoded message EM of length > \ceil ((modBits - 1)/8) octets such that the bit length of the > integer OS2IP (EM) (see Section 4.2) is at most modBits - 1, where > modBits is the length in bits of the RSA modulus n > > If this EM is the same EM recovered when verifying the signature, then > it must still correspond to an integer of size at most modBits - 1. Yes, that seems to be correct, as both EMSA-PSS-ENCODE and EMSA-PSS-VERIFY takes emBits (= modBits - 1), which is defined as "maximal bit length of the integer OS2IP (EM)". I am sorry for the confusion. Regards, -- Daiki Ueno ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] Avoid assertion failure in pss_verify_mgf1
ni...@lysator.liu.se (Niels Möller) writes: >> + /* Check "integer too long" error of I2OSP. */ >> + if (key_size < nettle_mpz_sizeinbase_256_u(m)) >> +goto cleanup; >> + > > I don't understand the I2OSP acronym. And I think this check would be > more explicit as > > if (mpz_sizeinbase(m, 2) > bits) > goto cleanup; > > (one might also move initial size checks before the allocations). I2OSP is the procedure defined in RFC 3447, which converts a nonnegative integer to an octet string of a specified length. It is based on octets rather than bits. I think the above check is too rigid, since it is based on bit-length, it wouldn't tolerate some cases such as m is 1016 bits and bits is 1015, where both can be represented in 127 octets. Regards, -- Daiki Ueno ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
[PATCH] Avoid assertion failure in pss_verify_mgf1
Hello,
Nikos told me that there is a case where RSA-PSS signature verification
leads to an assertion failure:
bignum.c:120: nettle_mpz_get_str_256: Assertion
`nettle_mpz_sizeinbase_256_u(x) <= length' failed.
I thought it wouldn't be possible because 'x' is already rounded by the
RSA modulus and 'length' is bound to the modulus.
However, actually 'length' is calculated as ((modBits - 1) + 7) / 8,
i.e. one bit less than the original modulus. Thus, it would be possible
that the octet length of 'x' exceeds 'length'.
I am attaching a patch for this.
Regards,
--
Daiki Ueno
>From 10c86090e6ee33d6016ee6c21eb2dd38363ca8ba Mon Sep 17 00:00:00 2001
From: Daiki Ueno
Date: Thu, 8 Jun 2017 11:36:11 +0200
Subject: [PATCH] Avoid assertion failure in pss_verify_mgf1
Even if M is rounded by the RSA modulus, it is possible that the
number of octets needed to represent M exceeds key_size, when the
value of M is close to the RSA modulus.
Spotted by oss-fuzz at:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=2132
---
pss.c| 4
testsuite/rsa-pss-sign-tr-test.c | 25 +
2 files changed, 29 insertions(+)
diff --git a/pss.c b/pss.c
index 9af72e5..96e029f 100644
--- a/pss.c
+++ b/pss.c
@@ -143,6 +143,10 @@ pss_verify_mgf1(const mpz_t m, size_t bits,
if (key_size < hash->digest_size + salt_length + 2)
goto cleanup;
+ /* Check "integer too long" error of I2OSP. */
+ if (key_size < nettle_mpz_sizeinbase_256_u(m))
+goto cleanup;
+
nettle_mpz_get_str_256(key_size, em, m);
/* Check the trailer field. */
diff --git a/testsuite/rsa-pss-sign-tr-test.c b/testsuite/rsa-pss-sign-tr-test.c
index 2ba043c..2cebc30 100644
--- a/testsuite/rsa-pss-sign-tr-test.c
+++ b/testsuite/rsa-pss-sign-tr-test.c
@@ -321,6 +321,31 @@ test_main(void)
salt->length, salt->data, msg->length, msg->data,
expected);
+ /* The case previously caused assertion failure
+ * nettle_mpz_sizeinbase_256_u(x) <= length
+ * in nettle_mpz_get_str_256.
+ */
+ mpz_set_str(pub.n,
+ "1d64559685aad3490e976b48aacf442ecee847268f882341eafe78"
+ "a0ca4ef88f66edbaf55b70e5285cc117aa9ceb322a4227c17e9e89"
+ "27bf38e5672faecf79e2983d92766fbb6624522f072ae0e4e46d37"
+ "052ce1e5745c2dd8fd67de3862e4711161e359b96bda85911ebf4e"
+ "6ce1bea625970269c77004a3cb03f9c382c5f79", 16);
+ mpz_set_str(pub.e, "10001", 16);
+
+ ASSERT (rsa_public_key_prepare(&pub));
+
+ msg = SHEX("7f85e4909ff7bb29536e540a53031ef03ddcb129e553a43273fa1f"
+ "ed28c22a8b57c7bde101ff746f335ba69b29642019");
+ mpz_set_str(expected,
+ "00"
+ "000505"
+ "00"
+ "00"
+ "", 16);
+
+ rsa_pss_sha384_verify_digest(&pub, 48, msg->data, expected);
+
rsa_private_key_clear(&key);
rsa_public_key_clear(&pub);
mpz_clear(expected);
--
2.9.4
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH v2 1/2] Implement PSS encoding functions
Daiki Ueno writes:
> ni...@lysator.liu.se (Niels Möller) writes:
>
>> I've tried to actually enable use of this function, by replacing
>> pss_encode_mgf1 by pss_encode_mgf1_for_test below in the pss-test.c
>> file.
>
> I am sorry for forgetting to update the test code after introducing the
> valgrind check.
>
>> It's curious that pkcs#1 v1.5 signatures don't have this particular
>> issue, since v1.5 padding always puts the most significant 1 bit at the
>> same position.
>>
>> So I guess we'll unfortunately have to take out the valgrind magic
>> from this test.
How about the following workaround?
The idea is: the first bytes of EM comes from MGF1, that actually comes
from the underlying hash function. In this test, we know that the bytes
will never be zero. Thus, clearing the "undefined" client request on
the first few bytes of digest would remove the warning.
diff --git a/testsuite/pss-test.c b/testsuite/pss-test.c
index 8122655..42f7843 100644
--- a/testsuite/pss-test.c
+++ b/testsuite/pss-test.c
@@ -2,14 +2,49 @@
#include "pss.h"
+struct nettle_hash nettle_test_sha1;
+struct nettle_hash nettle_test_sha256;
+
#if HAVE_VALGRIND_MEMCHECK_H
# include
+/* Workaround, to prevent false-positive "Conditional jump based on
+ uninitialized value". mpz_import removes the leading zero limbs
+ from an mpz value. That logic depends on the salt input. In this
+ test, however, we know that the first limb of the mpz is not zero,
+ and the limb comes from the output of the hash function. Clear the
+ "undefined" request on the first few bytes corresponding to the limb. */
+static void
+nettle_test_sha1_digest(struct sha1_ctx *ctx,
+ size_t length,
+ uint8_t *digest)
+{
+ sha1_digest(ctx, length, digest);
+
+ /* If LENGTH equals to the digest size, the output may be placed at
+ the beginning of the mask generated by pss_mgf1. */
+ if (length == SHA1_DIGEST_SIZE)
+VALGRIND_MAKE_MEM_DEFINED (digest, sizeof (mp_limb_t));
+}
+
+static void
+nettle_test_sha256_digest(struct sha256_ctx *ctx,
+ size_t length,
+ uint8_t *digest)
+{
+ sha256_digest(ctx, length, digest);
+
+ /* If LENGTH equals to the digest size, the output may be placed at
+ the beginning of the mask generated by pss_mgf1. */
+ if (length == SHA256_DIGEST_SIZE)
+VALGRIND_MAKE_MEM_DEFINED (digest, sizeof (mp_limb_t));
+}
+
static void
test_unmark_mpz(mpz_t m)
{
VALGRIND_MAKE_MEM_DEFINED (m, sizeof(*m));
- VALGRIND_MAKE_MEM_DEFINED (&m->_mp_d, sizeof(mp_limb_t) * mpz_size(m));
+ VALGRIND_MAKE_MEM_DEFINED (m->_mp_d, sizeof(mp_limb_t) * mpz_size(m));
}
static int
@@ -27,11 +62,16 @@ pss_encode_mgf1_for_test(mpz_t m, size_t bits,
res = pss_encode_mgf1 (m, bits, hash, salt_length, salt, digest);
VALGRIND_MAKE_MEM_DEFINED (&res, sizeof(res));
+
+ /* DIGEST is reused in the calls to pss_verify_mgf1. */
+ VALGRIND_MAKE_MEM_DEFINED (digest, hash->digest_size);
test_unmark_mpz (m);
return res;
}
#else
#define pss_encode_mgf1_for_test pss_encode_mgf1
+#define nettle_test_sha1_digest nettle_sha1_digest
+#define nettle_test_sha256_digest nettle_sha256_digest
#endif
void
@@ -42,14 +82,20 @@ test_main(void)
mpz_t m;
mpz_t expected;
+ memcpy(&nettle_test_sha1, &nettle_sha1, sizeof(struct nettle_hash));
+ nettle_test_sha1.digest = (nettle_hash_digest_func *)
nettle_test_sha1_digest;
+
+ memcpy(&nettle_test_sha256, &nettle_sha256, sizeof(struct nettle_hash));
+ nettle_test_sha256.digest = (nettle_hash_digest_func *)
nettle_test_sha256_digest;
+
/* From ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1d2-vec.zip */
mpz_init(m);
mpz_init(expected);
salt = SHEX("e3b5d5d002c1bce50c2b65ef88a188d83bce7e61");
digest = SHEX("37b66ae0445843353d47ecb0b4fd14c110e62d6a");
- ASSERT(pss_encode_mgf1(m, 1024, &nettle_sha1,
-salt->length, salt->data, digest->data));
+ ASSERT(pss_encode_mgf1_for_test(m, 1024, &nettle_test_sha1,
+ salt->length, salt->data, digest->data));
mpz_set_str(expected,
"66e4672e836ad121ba244bed6576b867d9a447c28a6e66a5b87dee"
@@ -87,13 +133,13 @@ test_main(void)
/* Try bad salt */
salt->data[6] = 0x00;
- ASSERT(pss_encode_mgf1(m, 1024, &nettle_sha256,
+ ASSERT(pss_encode_mgf1(m, 1024, &nettle_test_sha256,
salt->length, salt->data, digest->data));
ASSERT(mpz_cmp(m, expected) != 0);
/* Try the good salt */
salt->data[6] = 0x77;
- ASSERT(pss_encode_mgf1(m, 1024, &nettle_sha256,
+ ASSERT(pss_encode_mgf1(m, 1024, &nettle_test_sha256,
salt->length, salt->data, digest->data));
ASSERT(mpz_cmp(m, expected) == 0);
Regards,
--
Daiki Ueno
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH v2 1/2] Implement PSS encoding functions
ni...@lysator.liu.se (Niels Möller) writes:
> I've added these changes on a branch merge-pss in the main repo,
> together with some smaller post-merge cleanups.
Thank you!
> I'm considering renaming some of the pss files and functions to use a
> "pkcs1" prefix, and perhaps move declarations to pkcs1.h, do you think
> that's appropriate?
Considering that PSS is part of PKCS#1, I agree to move the declaration
to pkcs1.h. On the other hand, some people refer to the PKCS#1 v1.5
padding as "pkcs1", which might cause confusion.
>> "These variants
>> take advantage of a randomly choosen salt value, which could enhance the
>> security by causing output to be different for equivalent inputs.
>>
>> However, assuming the same security level as inverting the @acronym{RSA}
>> algorithm, a longer salt value does not always mean a better security
>> @uref{http://www.iacr.org/archive/eurocrypt2002/23320268/coron.pdf}.
>> The typical choices of the length are between 0 and the digest size of
>> the underlying hash function."
>
> That's better, but still not crystal clear. In what scenarios does the
> salt provide additional security? If the attacker gets to see signatures
> but not the corresponding messages?
I am no expert in math, but having a look at the original paper[1]
(section 1.4), I got an impression that introducing salt does not
directly correspond to any practical attacks, but is to ensure the same
level of security with smaller RSA modulus (than the one required by
zero-salt version).
ni...@lysator.liu.se (Niels Möller) writes:
> I've tried to actually enable use of this function, by replacing
> pss_encode_mgf1 by pss_encode_mgf1_for_test below in the pss-test.c
> file.
I am sorry for forgetting to update the test code after introducing the
valgrind check.
> It's curious that pkcs#1 v1.5 signatures don't have this particular
> issue, since v1.5 padding always puts the most significant 1 bit at the
> same position.
>
> So I guess we'll unfortunately have to take out the valgrind magic
> from this test.
That's unfortunate, but I can't think of any other idea either.
Footnotes:
[1] http://web.cs.ucdavis.edu/~rogaway/papers/exact.pdf
Regards,
--
Daiki Ueno
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH v2 1/2] Implement PSS encoding functions
Hello,
ni...@lysator.liu.se (Niels Möller) writes:
> I hope you're ok if we do this piecewise. Here are comments on some on
> the pieces.
Sure, I really appreciate that :-)
I have incorporated the suggested changes here:
https://gitlab.com/dueno/nettle/commits/wip/dueno/rsa-padding
If you prefer, I can post those to the list.
> Maybe rename it pkcs1-mgf1.h, then? I feel "mgf1.h" is a bit too obscure
> for a short name.
Renamed.
>> +#define NETTLE_MAX_HASH_CONTEXT_SIZE 512
>
> It's not so nice with a literal constant, since sizes are somewhat
> platform dependent. I'm considering the patch at the end of this message
> instead. It uses sizeof(sha3_224_ctx), which turns out to be the largest
> one by a quite large margin (and 352 bytes, on x86_64). The drawback is
> that code using this constant needs to include sha3.h to get the size,
> but I think that's ok for implementation files.
Yes, that seems like a good idea.
> I'd suggest
>
> VALGRIND_MAKE_MEM_DEFINED(m, sizeof(*m));
> VALGRIND_MAKE_MEM_DEFINED(m->_mp_d, sizeof(mp_limb_t) * mpz_size(m));
>
> The first is a bit tricky since the mpz_t is a typedef:ed array, I hope
> I got it right.
Fixed, thanks for pointing that out.
>> +While the above functions for the RSA signature operations use the
>> +@cite{PKCS#1} padding scheme, Nettle also provides the variants based on
>> +the PSS padding scheme, specified in @cite{RFC 3447}.
>> +
>> +Creating an RSA signature with the PSS padding scheme is done with one
>> +of the following functions:
>
> It would be nice if the documentation gave some explanation of the
> purpose of the salt input, and some guidance on how to select the salt
> length and contents.
I have added the following:
"These variants
take advantage of a randomly choosen salt value, which could enhance the
security by causing output to be different for equivalent inputs.
However, assuming the same security level as inverting the @acronym{RSA}
algorithm, a longer salt value does not always mean a better security
@uref{http://www.iacr.org/archive/eurocrypt2002/23320268/coron.pdf}.
The typical choices of the length are between 0 and the digest size of
the underlying hash function."
Hanno Böck writes:
> I'd recommend adding test cases for key sizes like 2049 bits, 2047 bits
> that are not divisible by 8. Such keys aren't common, but they do
> sometimes appear in the wild in TLS certificates. So this could easily
> lead to bugs that rarely show up and are hard to debug.
Thank you for the suggestion. The current test includes a case for a
777-bit key, though it is self-generated. Would this be sufficient, or
is there any test vector for such keys?
By the way, I have added (partial) verification support for gnutls:
https://gitlab.com/dueno/gnutls/commits/wip/dueno/rsa-padding
For testing RSA-PSS certificate verification, one can do:
$ certtool --verify --load-ca-certificate ca.crt --infile ca.crt
Regards,
--
Daiki Ueno
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH v2 1/2] Implement PSS encoding functions
rent ways this function can
> fail. What are the consequences if one of the falure cases is handled
> incorrectly, do we need tests for them all?
>
>> --- /dev/null
>> +++ b/testsuite/pss-test.c
>> @@ -0,0 +1,35 @@
>> +#include "testutils.h"
>> +
>> +#include "pss.h"
>> +
>> +void
>> +test_main(void)
>> +{
>> + struct tstring *salt;
>> + struct tstring *digest;
>> + mpz_t m;
>> + mpz_t expected;
>> + int ret;
>> +
>> + mpz_init(m);
>> + mpz_init(expected);
>> +
>> + salt = SHEX("11223344556677889900");
>> + /* From sha256-test.c */
>> + digest = SHEX("ba7816bf8f01cfea 414140de5dae2223"
>> +"b00361a396177a9c b410ff61f20015ad");
>> + ret = pss_sha256_encode(m, 1024, salt->length, salt->data, digest->data);
>> + ASSERT(ret == 1);
>> +
>> + mpz_set_str(expected,
>> + "76b9a52705c8382c5367732f993184eff340b6305c9f73e7e308c8"
>> + "004fcc15cbbaab01e976bae4b774628595379a2d448a36b3ea6fa8"
>> + "353b97eeea7bdac93b4b7807ac98cd4b3bebfb31f3718e1dd3625f"
>> + "227fbb8696606498e7070e21c3cbbd7386ea20eb81ac7927e0c6d1"
>> + "d7788826a63af767f301bcc05dd65b00da862cbc", 16);
>
> Nice with unit tests for this function too. Thanks! Are there any
> official test vectors?
There are (historical?) test vectors from RSA for these intermediate
primitives:
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1d2-vec.zip
The reason I didn't use them was that those test vectors use SHA-1 as
the underlying hash algorithm, while the previous patch only provides
SHA-2 variants of the pss_*_encode() functions.
Now that the generic pss_encode_mgf1() is provided, it is possible to
use SHA-1 in the tests, so I just added them.
>> + ASSERT(mpz_cmp(m, expected) == 0);
>> +
>> + ret = pss_sha256_verify(m, 1024, salt->length, digest->data);
>> + ASSERT(ret == 1);
>
> Simpler with just ASSERT(pss_sha256_verify(...));
Done.
> Some test also for the failure case is desirable. Three reasonably
> simple checks are to try flipping some bit of m, digest or salt and
> check that it returns failure.
Done.
Regards,
--
Daiki Ueno
>From c254abe6d87e2342556f67d8f04dee411090c243 Mon Sep 17 00:00:00 2001
From: Daiki Ueno
Date: Mon, 13 Mar 2017 16:32:11 +0100
Subject: [PATCH 1/3] New constant NETTLE_MAX_HASH_CONTEXT_SIZE
Signed-off-by: Daiki Ueno
---
nettle-internal.h | 1 +
testsuite/meta-hash-test.c | 5 -
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/nettle-internal.h b/nettle-internal.h
index 4e3098b..47b35c2 100644
--- a/nettle-internal.h
+++ b/nettle-internal.h
@@ -54,6 +54,7 @@
/* Arbitrary limits which apply to systems that don't have alloca */
#define NETTLE_MAX_HASH_BLOCK_SIZE 128
#define NETTLE_MAX_HASH_DIGEST_SIZE 64
+#define NETTLE_MAX_HASH_CONTEXT_SIZE 512
#define NETTLE_MAX_SEXP_ASSOC 17
#define NETTLE_MAX_CIPHER_BLOCK_SIZE 32
diff --git a/testsuite/meta-hash-test.c b/testsuite/meta-hash-test.c
index 0dcd1b9..d12b5fd 100644
--- a/testsuite/meta-hash-test.c
+++ b/testsuite/meta-hash-test.c
@@ -35,6 +35,9 @@ test_main(void)
j++;
ASSERT(j == count); /* we are not missing testing any hashes */
for (j = 0; NULL != nettle_hashes[j]; j++)
-ASSERT(nettle_hashes[j]->digest_size <= NETTLE_MAX_HASH_DIGEST_SIZE);
+{
+ ASSERT(nettle_hashes[j]->digest_size <= NETTLE_MAX_HASH_DIGEST_SIZE);
+ ASSERT(nettle_hashes[j]->context_size <= NETTLE_MAX_HASH_CONTEXT_SIZE);
+}
}
--
2.9.3
>From f31e7146a0cb7f1dec85df86edb1b6669068722a Mon Sep 17 00:00:00 2001
From: Daiki Ueno
Date: Thu, 23 Feb 2017 11:30:27 +0100
Subject: [PATCH 2/3] Implement PSS encoding functions
Signed-off-by: Daiki Ueno
---
Makefile.in| 5 +-
mgf1.c | 73 ++
mgf1.h | 58 ++
pss.c | 184 +
pss.h | 67 +
testsuite/.test-rules.make | 6 ++
testsuite/Makefile.in | 4 +-
testsuite/mgf1-test.c | 37 +
testsuite/pss-test.c | 101 +
9 files changed, 532 insertions(+), 3 deletions(-)
create mode 100644 mgf1.c
create mode 100644 mgf1.h
create mode 100644 pss.c
create mode 100644 pss.h
create mode 100644 testsuite/mgf1-test.c
create mode 100644 testsuite/pss-test.c
diff --git a/Makefile.in b/Makefile.in
index 135542f..0ce539b 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -110,6 +110,7 @@ nettle_SOURCES = aes-decrypt-internal.c aes-decrypt.c \
md2.c md2-meta.c md4.c md4-meta.c \
md5.c md5-compress.c md5-compat.c md5-
Re: [PATCH 0/2] Implement RSA-PSS signature scheme
ni...@lysator.liu.se (Niels Möller) writes: > Daiki Ueno writes: > >> This series of patches implements the RSA-PSS signature scheme, as >> specified in RFC 3447. To keep the interface minimal but to allow TLS >> 1.3 implementations on top of this, only SHA256/384/512 variants are >> provided. > > Thanks! Sorry I've been a bit offline and not able to comment earlier. No problem, thank you for the thorough review. I will send an update of the patches reflecting the comments. >> The prototypes of the top-level functions are as follows: >> >> int >> rsa_pss_shaXXX_sign_digest_tr(const struct rsa_public_key *pub, >>const struct rsa_private_key *key, >>void *random_ctx, nettle_random_func *random, >>size_t salt_length, const uint8_t *salt, >>const uint8_t *digest, >>mpz_t s); > > Are you confident all pieces are side-channel silent, as indicated by > the _tr suffix? Yes, I think so, at least for the PSS encoding functions, as long as all underlying constructs (hashes, memxor, etc) are side-channel silent. > It's possible to do some testing of that using valgrind; that's not > done as thoroughly as I'd like, but one example is in > testsuite/memeql-test.c. Thank you for the tip. I have added a similar client requests for SALT and DIGEST in pss-test.c, and confirmed that valgrind didn't report any "... depends on uninitialized value(s)" error. Regards, -- Daiki Ueno ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
[PATCH v2 2/2] Add PSS variants for RSA sign/verify functions
From: Daiki Ueno
Signed-off-by: Daiki Ueno
---
rsa-pss-sign-tr-test.c now checks SHA-384/SHA-512 variants as well as SHA-256.
---
Makefile.in | 2 +
nettle.texinfo | 30
rsa-pss-sha256-sign-tr.c | 64
rsa-pss-sha256-verify.c | 60 +++
rsa-pss-sha512-sign-tr.c | 87 +++
rsa-pss-sha512-verify.c | 79 ++
rsa-verify.c | 14 ++
rsa.h| 55 +++
testsuite/.test-rules.make | 3 +
testsuite/Makefile.in| 1 +
testsuite/rsa-pss-sign-tr-test.c | 327 +++
11 files changed, 722 insertions(+)
create mode 100644 rsa-pss-sha256-sign-tr.c
create mode 100644 rsa-pss-sha256-verify.c
create mode 100644 rsa-pss-sha512-sign-tr.c
create mode 100644 rsa-pss-sha512-verify.c
create mode 100644 testsuite/rsa-pss-sign-tr-test.c
diff --git a/Makefile.in b/Makefile.in
index 035074c..2075390 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -152,6 +152,8 @@ hogweed_SOURCES = sexp.c sexp-format.c \
rsa-sha1-sign.c rsa-sha1-sign-tr.c rsa-sha1-verify.c \
rsa-sha256-sign.c rsa-sha256-sign-tr.c rsa-sha256-verify.c \
rsa-sha512-sign.c rsa-sha512-sign-tr.c rsa-sha512-verify.c \
+ rsa-pss-sha256-sign-tr.c rsa-pss-sha256-verify.c \
+ rsa-pss-sha512-sign-tr.c rsa-pss-sha512-verify.c \
rsa-encrypt.c rsa-decrypt.c rsa-decrypt-tr.c \
rsa-keygen.c rsa-blind.c \
rsa2sexp.c sexp2rsa.c \
diff --git a/nettle.texinfo b/nettle.texinfo
index 9cfaf43..529a8e6 100644
--- a/nettle.texinfo
+++ b/nettle.texinfo
@@ -3770,6 +3770,36 @@ of the digest together with an object identifier for the
used hash
algorithm.
@end deftypefun
+While the above functions for the RSA signature operations use the
+@cite{PKCS#1} padding scheme, Nettle also provides the variants based on
+the PSS padding scheme, specified in @cite{RFC 3447}.
+
+Creating an RSA signature with the PSS padding scheme is done with one
+of the following functions:
+
+@deftypefun int rsa_pss_sha256_sign_digest_tr(const struct rsa_public_key
*@var{pub}, const struct rsa_private_key *@var{key}, void *@var{random_ctx},
nettle_random_func *@var{random}, size_t @var{salt_length}, const uint8_t
*@var{salt}, const uint8_t *@var{digest}, mpz_t @var{signature})
+@deftypefunx int rsa_pss_sha384_sign_digest_tr(const struct rsa_public_key
*@var{pub}, const struct rsa_private_key *@var{key}, void *@var{random_ctx},
nettle_random_func *@var{random}, size_t @var{salt_length}, const uint8_t
*@var{salt}, const uint8_t *@var{digest}, mpz_t @var{signature})
+@deftypefunx int rsa_pss_sha512_sign_digest_tr(const struct rsa_public_key
*@var{pub}, const struct rsa_private_key *@var{key}, void *@var{random_ctx},
nettle_random_func *@var{random}, size_t @var{salt_length}, const uint8_t
*@var{salt}, const uint8_t *@var{digest}, mpz_t @var{signature})
+Creates a signature using the PSS padding scheme. @var{salt} should
+point to a salt string of size @var{salt_length}. @var{digest} should
+point to a digest of size @code{SHA256_DIGEST_SIZE},
+@code{SHA384_DIGEST_SIZE}, or @code{SHA512_DIGEST_SIZE}respectively. The
+signature is stored in @var{signature} (which must have been
+@code{mpz_init}:ed earlier).
+Returns one on success, or zero on failure.
+@end deftypefun
+
+Verifying an RSA signature with the PSS padding scheme is done with one
+of the following functions:
+
+@deftypefun int rsa_pss_sha256_verify_digest (const struct rsa_public_key
*@var{key}, size_t @var{salt_length}, const uint8_t *@var{digest}, const mpz_t
@var{signature})
+@deftypefunx int rsa_pss_sha384_verify_digest (const struct rsa_public_key
*@var{key}, size_t @var{salt_length}, const uint8_t *@var{digest}, const mpz_t
@var{signature})
+@deftypefunx int rsa_pss_sha512_verify_digest (const struct rsa_public_key
*@var{key}, size_t @var{salt_length}, const uint8_t *@var{digest}, const mpz_t
@var{signature})
+Returns 1 if the signature is valid, or 0 if it isn't. @var{digest}
+should point to a digest of size @code{SHA256_DIGEST_SIZE},
+@code{SHA384_DIGEST_SIZE}, or @code{SHA512_DIGEST_SIZE} respectively.
+@end deftypefun
+
The following function is used to encrypt a clear text message using RSA.
@deftypefun int rsa_encrypt (const struct rsa_public_key *@var{key}, void
*@var{random_ctx}, nettle_random_func *@var{random}, size_t @var{length}, const
uint8_t *@var{cleartext}, mpz_t @var{ciphertext})
Returns 1 on success, 0 on failure. If the message is too long then this
diff --git a/rsa-pss-sha256-sign-tr.c b/rsa-pss-sha256-sign-tr.c
new file mode 100644
index 000..4284fe3
--- /dev/null
+++ b/rsa-pss-sha256-sign-tr.c
@@ -0,0 +1,64 @@
+/* rsa-pss-sha256-sign-tr.c
+
+ Signatures using RSA and SHA-256, with PSS padding.
+
+ Copyright (C) 2017 Daiki Ueno
+
+ This file is
[PATCH v2 1/2] Implement PSS encoding functions
From: Daiki Ueno
Signed-off-by: Daiki Ueno
---
There was an obvious buffer overrun in mgf1-test.c, which should be
fixed in this version.
---
Makefile.in| 5 +-
mgf1-sha256.c | 47 +++
mgf1-sha384.c | 47 +++
mgf1-sha512.c | 47 +++
mgf1.c | 72 +
mgf1.h | 70
nettle-types.h | 3 +
pss-sha256.c | 64 +++
pss-sha512.c | 90 +
pss.c | 195 +
pss.h | 105
testsuite/.test-rules.make | 6 ++
testsuite/Makefile.in | 4 +-
testsuite/mgf1-test.c | 23 ++
testsuite/pss-test.c | 35
15 files changed, 810 insertions(+), 3 deletions(-)
create mode 100644 mgf1-sha256.c
create mode 100644 mgf1-sha384.c
create mode 100644 mgf1-sha512.c
create mode 100644 mgf1.c
create mode 100644 mgf1.h
create mode 100644 pss-sha256.c
create mode 100644 pss-sha512.c
create mode 100644 pss.c
create mode 100644 pss.h
create mode 100644 testsuite/mgf1-test.c
create mode 100644 testsuite/pss-test.c
diff --git a/Makefile.in b/Makefile.in
index 135542f..035074c 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -110,6 +110,7 @@ nettle_SOURCES = aes-decrypt-internal.c aes-decrypt.c \
md2.c md2-meta.c md4.c md4-meta.c \
md5.c md5-compress.c md5-compat.c md5-meta.c \
memeql-sec.c memxor.c memxor3.c \
+mgf1.c mgf1-sha256.c mgf1-sha384.c mgf1-sha512.c \
nettle-meta-aeads.c nettle-meta-armors.c \
nettle-meta-ciphers.c nettle-meta-hashes.c \
pbkdf2.c pbkdf2-hmac-sha1.c pbkdf2-hmac-sha256.c \
@@ -144,6 +145,7 @@ hogweed_SOURCES = sexp.c sexp-format.c \
pkcs1.c pkcs1-encrypt.c pkcs1-decrypt.c \
pkcs1-rsa-digest.c pkcs1-rsa-md5.c pkcs1-rsa-sha1.c \
pkcs1-rsa-sha256.c pkcs1-rsa-sha512.c \
+ pss.c pss-sha256.c pss-sha512.c \
rsa.c rsa-sign.c rsa-sign-tr.c rsa-verify.c \
rsa-pkcs1-sign.c rsa-pkcs1-sign-tr.c rsa-pkcs1-verify.c \
rsa-md5-sign.c rsa-md5-sign-tr.c rsa-md5-verify.c \
@@ -194,9 +196,10 @@ HEADERS = aes.h arcfour.h arctwo.h asn1.h blowfish.h \
md2.h md4.h \
md5.h md5-compat.h \
memops.h memxor.h \
+ mgf1.h \
nettle-meta.h nettle-types.h \
pbkdf2.h \
- pgp.h pkcs1.h realloc.h ripemd160.h rsa.h \
+ pgp.h pkcs1.h pss.h realloc.h ripemd160.h rsa.h \
salsa20.h sexp.h \
serpent.h sha.h sha1.h sha2.h sha3.h twofish.h \
umac.h yarrow.h poly1305.h
diff --git a/mgf1-sha256.c b/mgf1-sha256.c
new file mode 100644
index 000..11e908c
--- /dev/null
+++ b/mgf1-sha256.c
@@ -0,0 +1,47 @@
+/* mgf1-sha256.c
+
+ PKCS#1 mask generation function 1, based on SHA-256.
+
+ Copyright (C) 2017 Daiki Ueno
+
+ This file is part of GNU Nettle.
+
+ GNU Nettle is free software: you can redistribute it and/or
+ modify it under the terms of either:
+
+ * the GNU Lesser General Public License as published by the Free
+ Software Foundation; either version 3 of the License, or (at your
+ option) any later version.
+
+ or
+
+ * the GNU General Public License as published by the Free
+ Software Foundation; either version 2 of the License, or (at your
+ option) any later version.
+
+ or both in parallel, as here.
+
+ GNU Nettle 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
+ General Public License for more details.
+
+ You should have received copies of the GNU General Public License and
+ the GNU Lesser General Public License along with this program. If
+ not, see http://www.gnu.org/licenses/.
+*/
+
+#if HAVE_CONFIG_H
+# include "config.h"
+#endif
+
+#include "mgf1.h"
+
+#include "nettle-meta.h"
+
+int
+mgf1_sha256(const struct sha256_ctx *hash, size_t mask_length, uint8_t *mask)
+{
+ struct sha256_ctx state;
+ return mgf1(hash, &state, &nettle_sha256, mask_length, mask);
+}
diff --git a/mgf1-sha384.c b/mgf1-sha384.c
new file mode 100644
index 000..5dd2b07
--- /dev/null
+++ b/mgf1-sha384.c
@@ -0,0 +1,47 @@
+/* mgf1-sha384.c
+
+ PKCS#1 mask generation function 1, based on SHA-384.
+
+ Copyright (C) 2017 Daiki Ueno
+
+ This file is part of GNU Nettle.
+
+ GNU Nettle is free software: you can redistribute it and/or
+ modify it under the terms of either:
+
+ * the GNU Lesser General Public License as published by the Free
+ Software Foundation; either version 3 of the License, or (at your
+
[PATCH 0/2] Implement RSA-PSS signature scheme
From: Daiki Ueno
Hello,
This series of patches implements the RSA-PSS signature scheme, as
specified in RFC 3447. To keep the interface minimal but to allow TLS
1.3 implementations on top of this, only SHA256/384/512 variants are
provided.
The prototypes of the top-level functions are as follows:
int
rsa_pss_shaXXX_sign_digest_tr(const struct rsa_public_key *pub,
const struct rsa_private_key *key,
void *random_ctx, nettle_random_func *random,
size_t salt_length, const uint8_t *salt,
const uint8_t *digest,
mpz_t s);
int
rsa_pss_shaXXX_verify_digest(const struct rsa_public_key *key,
size_t salt_length,
const uint8_t *digest,
const mpz_t signature);
For MGF, "mask generation function 1" backed by the same hash
algorithm is always used, as indicated in [1]. I thought it might
make sense to provide more flexible variants, such as
rsa_pss_{sign_tr,verify} analogous to rsa_pkcs1_*, but realized that
parsing ASN.1 encoded parameters would require extra complexity.
Suggestions appreciated.
Daiki Ueno (2):
Implement PSS encoding functions
Add PSS variants for RSA sign/verify functions
Makefile.in | 7 +-
mgf1-sha256.c| 47 +++
mgf1-sha384.c| 47 +++
mgf1-sha512.c| 47 +++
mgf1.c | 72 +++
mgf1.h | 70 ++
nettle-types.h | 3 +
nettle.texinfo | 30 +
pss-sha256.c | 64 ++
pss-sha512.c | 90 +
pss.c| 195
pss.h| 105 +++
rsa-pss-sha256-sign-tr.c | 64 ++
rsa-pss-sha256-verify.c | 60 +
rsa-pss-sha512-sign-tr.c | 87 +
rsa-pss-sha512-verify.c | 79
rsa-verify.c | 14 ++
rsa.h| 55
testsuite/.test-rules.make | 9 ++
testsuite/Makefile.in| 5 +-
testsuite/mgf1-test.c| 23
testsuite/pss-test.c | 35 +
testsuite/rsa-pss-sign-tr-test.c | 268 +++
23 files changed, 1473 insertions(+), 3 deletions(-)
create mode 100644 mgf1-sha256.c
create mode 100644 mgf1-sha384.c
create mode 100644 mgf1-sha512.c
create mode 100644 mgf1.c
create mode 100644 mgf1.h
create mode 100644 pss-sha256.c
create mode 100644 pss-sha512.c
create mode 100644 pss.c
create mode 100644 pss.h
create mode 100644 rsa-pss-sha256-sign-tr.c
create mode 100644 rsa-pss-sha256-verify.c
create mode 100644 rsa-pss-sha512-sign-tr.c
create mode 100644 rsa-pss-sha512-verify.c
create mode 100644 testsuite/mgf1-test.c
create mode 100644 testsuite/pss-test.c
create mode 100644 testsuite/rsa-pss-sign-tr-test.c
Footnotes:
[1] https://tlswg.github.io/tls13-spec/#signature-algorithms
--
2.9.3
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
[PATCH 2/2] Add PSS variants for RSA sign/verify functions
From: Daiki Ueno
Signed-off-by: Daiki Ueno
---
Makefile.in | 2 +
nettle.texinfo | 30 +
rsa-pss-sha256-sign-tr.c | 64 ++
rsa-pss-sha256-verify.c | 60 +
rsa-pss-sha512-sign-tr.c | 87 +
rsa-pss-sha512-verify.c | 79
rsa-verify.c | 14 ++
rsa.h| 55
testsuite/.test-rules.make | 3 +
testsuite/Makefile.in| 1 +
testsuite/rsa-pss-sign-tr-test.c | 268 +++
11 files changed, 663 insertions(+)
create mode 100644 rsa-pss-sha256-sign-tr.c
create mode 100644 rsa-pss-sha256-verify.c
create mode 100644 rsa-pss-sha512-sign-tr.c
create mode 100644 rsa-pss-sha512-verify.c
create mode 100644 testsuite/rsa-pss-sign-tr-test.c
diff --git a/Makefile.in b/Makefile.in
index 035074c..2075390 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -152,6 +152,8 @@ hogweed_SOURCES = sexp.c sexp-format.c \
rsa-sha1-sign.c rsa-sha1-sign-tr.c rsa-sha1-verify.c \
rsa-sha256-sign.c rsa-sha256-sign-tr.c rsa-sha256-verify.c \
rsa-sha512-sign.c rsa-sha512-sign-tr.c rsa-sha512-verify.c \
+ rsa-pss-sha256-sign-tr.c rsa-pss-sha256-verify.c \
+ rsa-pss-sha512-sign-tr.c rsa-pss-sha512-verify.c \
rsa-encrypt.c rsa-decrypt.c rsa-decrypt-tr.c \
rsa-keygen.c rsa-blind.c \
rsa2sexp.c sexp2rsa.c \
diff --git a/nettle.texinfo b/nettle.texinfo
index 9cfaf43..529a8e6 100644
--- a/nettle.texinfo
+++ b/nettle.texinfo
@@ -3770,6 +3770,36 @@ of the digest together with an object identifier for the
used hash
algorithm.
@end deftypefun
+While the above functions for the RSA signature operations use the
+@cite{PKCS#1} padding scheme, Nettle also provides the variants based on
+the PSS padding scheme, specified in @cite{RFC 3447}.
+
+Creating an RSA signature with the PSS padding scheme is done with one
+of the following functions:
+
+@deftypefun int rsa_pss_sha256_sign_digest_tr(const struct rsa_public_key
*@var{pub}, const struct rsa_private_key *@var{key}, void *@var{random_ctx},
nettle_random_func *@var{random}, size_t @var{salt_length}, const uint8_t
*@var{salt}, const uint8_t *@var{digest}, mpz_t @var{signature})
+@deftypefunx int rsa_pss_sha384_sign_digest_tr(const struct rsa_public_key
*@var{pub}, const struct rsa_private_key *@var{key}, void *@var{random_ctx},
nettle_random_func *@var{random}, size_t @var{salt_length}, const uint8_t
*@var{salt}, const uint8_t *@var{digest}, mpz_t @var{signature})
+@deftypefunx int rsa_pss_sha512_sign_digest_tr(const struct rsa_public_key
*@var{pub}, const struct rsa_private_key *@var{key}, void *@var{random_ctx},
nettle_random_func *@var{random}, size_t @var{salt_length}, const uint8_t
*@var{salt}, const uint8_t *@var{digest}, mpz_t @var{signature})
+Creates a signature using the PSS padding scheme. @var{salt} should
+point to a salt string of size @var{salt_length}. @var{digest} should
+point to a digest of size @code{SHA256_DIGEST_SIZE},
+@code{SHA384_DIGEST_SIZE}, or @code{SHA512_DIGEST_SIZE}respectively. The
+signature is stored in @var{signature} (which must have been
+@code{mpz_init}:ed earlier).
+Returns one on success, or zero on failure.
+@end deftypefun
+
+Verifying an RSA signature with the PSS padding scheme is done with one
+of the following functions:
+
+@deftypefun int rsa_pss_sha256_verify_digest (const struct rsa_public_key
*@var{key}, size_t @var{salt_length}, const uint8_t *@var{digest}, const mpz_t
@var{signature})
+@deftypefunx int rsa_pss_sha384_verify_digest (const struct rsa_public_key
*@var{key}, size_t @var{salt_length}, const uint8_t *@var{digest}, const mpz_t
@var{signature})
+@deftypefunx int rsa_pss_sha512_verify_digest (const struct rsa_public_key
*@var{key}, size_t @var{salt_length}, const uint8_t *@var{digest}, const mpz_t
@var{signature})
+Returns 1 if the signature is valid, or 0 if it isn't. @var{digest}
+should point to a digest of size @code{SHA256_DIGEST_SIZE},
+@code{SHA384_DIGEST_SIZE}, or @code{SHA512_DIGEST_SIZE} respectively.
+@end deftypefun
+
The following function is used to encrypt a clear text message using RSA.
@deftypefun int rsa_encrypt (const struct rsa_public_key *@var{key}, void
*@var{random_ctx}, nettle_random_func *@var{random}, size_t @var{length}, const
uint8_t *@var{cleartext}, mpz_t @var{ciphertext})
Returns 1 on success, 0 on failure. If the message is too long then this
diff --git a/rsa-pss-sha256-sign-tr.c b/rsa-pss-sha256-sign-tr.c
new file mode 100644
index 000..4284fe3
--- /dev/null
+++ b/rsa-pss-sha256-sign-tr.c
@@ -0,0 +1,64 @@
+/* rsa-pss-sha256-sign-tr.c
+
+ Signatures using RSA and SHA-256, with PSS padding.
+
+ Copyright (C) 2017 Daiki Ueno
+
+ This file is part of GNU Nettle.
+
+ GNU Nettle is free software: you can redistr
[PATCH 1/2] Implement PSS encoding functions
From: Daiki Ueno
Signed-off-by: Daiki Ueno
---
Makefile.in| 5 +-
mgf1-sha256.c | 47 +++
mgf1-sha384.c | 47 +++
mgf1-sha512.c | 47 +++
mgf1.c | 72 +
mgf1.h | 70
nettle-types.h | 3 +
pss-sha256.c | 64 +++
pss-sha512.c | 90 +
pss.c | 195 +
pss.h | 105
testsuite/.test-rules.make | 6 ++
testsuite/Makefile.in | 4 +-
testsuite/mgf1-test.c | 23 ++
testsuite/pss-test.c | 35
15 files changed, 810 insertions(+), 3 deletions(-)
create mode 100644 mgf1-sha256.c
create mode 100644 mgf1-sha384.c
create mode 100644 mgf1-sha512.c
create mode 100644 mgf1.c
create mode 100644 mgf1.h
create mode 100644 pss-sha256.c
create mode 100644 pss-sha512.c
create mode 100644 pss.c
create mode 100644 pss.h
create mode 100644 testsuite/mgf1-test.c
create mode 100644 testsuite/pss-test.c
diff --git a/Makefile.in b/Makefile.in
index 135542f..035074c 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -110,6 +110,7 @@ nettle_SOURCES = aes-decrypt-internal.c aes-decrypt.c \
md2.c md2-meta.c md4.c md4-meta.c \
md5.c md5-compress.c md5-compat.c md5-meta.c \
memeql-sec.c memxor.c memxor3.c \
+mgf1.c mgf1-sha256.c mgf1-sha384.c mgf1-sha512.c \
nettle-meta-aeads.c nettle-meta-armors.c \
nettle-meta-ciphers.c nettle-meta-hashes.c \
pbkdf2.c pbkdf2-hmac-sha1.c pbkdf2-hmac-sha256.c \
@@ -144,6 +145,7 @@ hogweed_SOURCES = sexp.c sexp-format.c \
pkcs1.c pkcs1-encrypt.c pkcs1-decrypt.c \
pkcs1-rsa-digest.c pkcs1-rsa-md5.c pkcs1-rsa-sha1.c \
pkcs1-rsa-sha256.c pkcs1-rsa-sha512.c \
+ pss.c pss-sha256.c pss-sha512.c \
rsa.c rsa-sign.c rsa-sign-tr.c rsa-verify.c \
rsa-pkcs1-sign.c rsa-pkcs1-sign-tr.c rsa-pkcs1-verify.c \
rsa-md5-sign.c rsa-md5-sign-tr.c rsa-md5-verify.c \
@@ -194,9 +196,10 @@ HEADERS = aes.h arcfour.h arctwo.h asn1.h blowfish.h \
md2.h md4.h \
md5.h md5-compat.h \
memops.h memxor.h \
+ mgf1.h \
nettle-meta.h nettle-types.h \
pbkdf2.h \
- pgp.h pkcs1.h realloc.h ripemd160.h rsa.h \
+ pgp.h pkcs1.h pss.h realloc.h ripemd160.h rsa.h \
salsa20.h sexp.h \
serpent.h sha.h sha1.h sha2.h sha3.h twofish.h \
umac.h yarrow.h poly1305.h
diff --git a/mgf1-sha256.c b/mgf1-sha256.c
new file mode 100644
index 000..11e908c
--- /dev/null
+++ b/mgf1-sha256.c
@@ -0,0 +1,47 @@
+/* mgf1-sha256.c
+
+ PKCS#1 mask generation function 1, based on SHA-256.
+
+ Copyright (C) 2017 Daiki Ueno
+
+ This file is part of GNU Nettle.
+
+ GNU Nettle is free software: you can redistribute it and/or
+ modify it under the terms of either:
+
+ * the GNU Lesser General Public License as published by the Free
+ Software Foundation; either version 3 of the License, or (at your
+ option) any later version.
+
+ or
+
+ * the GNU General Public License as published by the Free
+ Software Foundation; either version 2 of the License, or (at your
+ option) any later version.
+
+ or both in parallel, as here.
+
+ GNU Nettle 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
+ General Public License for more details.
+
+ You should have received copies of the GNU General Public License and
+ the GNU Lesser General Public License along with this program. If
+ not, see http://www.gnu.org/licenses/.
+*/
+
+#if HAVE_CONFIG_H
+# include "config.h"
+#endif
+
+#include "mgf1.h"
+
+#include "nettle-meta.h"
+
+int
+mgf1_sha256(const struct sha256_ctx *hash, size_t mask_length, uint8_t *mask)
+{
+ struct sha256_ctx state;
+ return mgf1(hash, &state, &nettle_sha256, mask_length, mask);
+}
diff --git a/mgf1-sha384.c b/mgf1-sha384.c
new file mode 100644
index 000..5dd2b07
--- /dev/null
+++ b/mgf1-sha384.c
@@ -0,0 +1,47 @@
+/* mgf1-sha384.c
+
+ PKCS#1 mask generation function 1, based on SHA-384.
+
+ Copyright (C) 2017 Daiki Ueno
+
+ This file is part of GNU Nettle.
+
+ GNU Nettle is free software: you can redistribute it and/or
+ modify it under the terms of either:
+
+ * the GNU Lesser General Public License as published by the Free
+ Software Foundation; either version 3 of the License, or (at your
+ option) any later version.
+
+ or
+
+ * the GNU General Public License as published by the Fr
