Re: ppc64 micro optimization
Niels Möller writes: > One other question: In the counter updates, > >> C increase ctr value as input to aes_encrypt >> vaddudm S1, S0, CNT1 >> vaddudm S2, S1, CNT1 >> vaddudm S3, S2, CNT1 >> vaddudm S4, S3, CNT1 >> vaddudm S5, S4, CNT1 >> vaddudm S6, S5, CNT1 >> vaddudm S7, S6, CNT1 > > shouldn't that be vadduwm (32-bit word addition, rather than 64-bit > dword addition)? As I understand it, gcm uses a 32-bit counter, which > should wrap around without any carry to higher bits if the initial value > is just below 2^32. I've added tests that set the intial counter so that the four counter bytes wraps around 2^32, and I've verified that if these instructions should be changed to vadduwm, to get output that agrees with nettle's other gcm implementations. Another question on powerpc64 assembly: For the byte swapping, currently done using the vperm instruction and a mask word, is there any reason to not use the xxbrd instruction (VSX Vector Byte-Reverse Doubleword) instead? That applies to more functions than the new gcm-aes code. Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se To unsubscribe send an email to nettle-bugs-le...@lists.lysator.liu.se
KEM-interface (was: Re: HPKE ready for Merge!)
Norbert Pócs writes:
> I took an another look at the PR, if there is anything possible to delete
> without loosing the functionality, but unfortunately didn't find anything.
To get a better understanding of the HPKE spec and its complexities,
I've tried to implement KEM x25519-sha256 (and nothing else from the
spec). Patch below.
Some notes:
1. Nettle's hkdf interface isn't that a good fit, if one wants to avoid
memcpy calls to assemble the inputs. Below, I haven't used Nettle's
hkdf_extract / hkdf_expand, instead doing corresponding operations
directly on hmac_sha256. Unless I'm missing something, it seems a
LabeledExpand function limited to at most 32 octets of output (the
sha256 digest size) is sufficient for everything in hpke, except for
the Export feature.
2. I don't quite like that some functions (in particular DeriveKeyPair)
are defined so that it can fail (not for x25519, though). Having a
success/failure indication there forces applications to have an error
handling path, that it's rather difficult to test. I see no obvious
way for Nettle to shield applications from that, though.
3. For those of you who have looked closer at proposed post-quantum KEM
mechanisms, is the interface suitable for those too?
4. It seems that HPKE defines a very clean interface between the KEM and
the rest of the message handling, with the shared_secret the only
piece of data shered between KEM and the rest of the processing.
Regards,
/Niels
diff --git a/Makefile.in b/Makefile.in
index f027e762..eb520f7a 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 \
+ kem-x25519-sha256.c
OPT_SOURCES = fat-arm.c fat-arm64.c fat-ppc.c fat-s390x.c fat-x86_64.c
mini-gmp.c
diff --git a/hpke-kem.h b/hpke-kem.h
new file mode 100644
index ..00b4610b
--- /dev/null
+++ b/hpke-kem.h
@@ -0,0 +1,71 @@
+/* hpke-kem.h
+
+ Key encapsulation mechanism, suitable for HPKE (RFC 9180).
+
+ Copyright (C) 2024 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/.
+*/
+
+#ifndef NETTLE_HPKE_KEM_H_INCLUDED
+#define NETTLE_HPKE_KEM_H_INCLUDED
+
+#include "nettle-types.h"
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/* Name mangling */
+#define get_kem_x25519_sha256 nettle_get_kem_x25519_sha256
+
+typedef int kem_derive_keypair_func (uint8_t *public_key, uint8_t *private_key,
+size_t seed_size, const uint8_t *seed);
+/* Take randomness source instead? Passing seed suites deterministic tests. */
+typedef void kem_encapsulate_func (uint8_t *shared_secret, uint8_t
*encapsulation,
+ const uint8_t *receiver_public_key,
+ void *random_ctx, nettle_random_func
*random);
+typedef void kem_decapsulate_func (uint8_t *shared_secret, const uint8_t
*encapsulation,
+ const uint8_t *private_key);
+
+struct hpke_kem {
+ unsigned public_key_size;
+ unsigned private_key_size;
+ unsigned encapsulation_size;
+ unsigned shared_secret_size;
+ kem_derive_keypair_func *derive_keypair;
+ kem_encapsulate_func *encapsulate;
+ kem_decapsulate_func *decapsulate;
+};
+
+const struct hpke_kem *get_kem_x25519_sha256 (void);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* NETTLE_HPKE_KEM_H_INCLUDED */
diff --git a/kem-x25519-sha256.c b/kem-x25519-sha256.c
new file mode 100644
index ..186ced6c
--- /dev/null
+++ b/kem-x25519-sha256.c
@@ -0,0 +1,170 @@
+/* kem-x25519-sha256.c
+
+ KEM using curve25519, suitable for HPKE (RFC 9180).
+
+ Copyright (C) 2024 Niels Möller
+
+ This file is part of GNU Nettle.
+
+ GNU Nettle is free software: you can redistribute it
Re: additional API for SHAKE streaming read
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 1. Decide what should be renamed sha3_shake256_* 2. Implement shake128. 3. Update docs. Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance. ___ 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
Daiki Ueno writes: > 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: Thanks for moving this forward. I haven't had time to share my recent patches either. I have a few concerns, though. > - Apply my changes in the previous post to count index from zero, not > the end of the block I'm not yet convinced this is a net win, it looks like you need a "% sizeof (ctx->block)" to make that work, and I'd like to avoid divisions, in particular, since when general generalizing this to also support shake128, the divisor will no longer be constant. > - 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. I'm fine with adding new sha3_shake256_* names, but I think we should keep old name (which you added for Nettle-3.6). And I think we can use the same context struct, possibly with convenience aliases like #define sha3_shake256_ctx sha3_256_ctx #define sha3_shake256_init sha3_256_init I agree we shouldn't define sha3_128_digest now (as far as I'm aware, there's no authoritative spec for that), but I think we should design the api so that it fits if added later. I'm a bit confused by the choice of shake128 for ML-KEM, and I would expect that if there are applications where shake128 is a reasonable security tradeoff, then there likely are reasonable applications of sha3_128 too. I don't understand the fine details of sha3 security analysis, but I'd guess that for applications where second preimage (in contrast to arbitrary collisions) is the relevant attack, sha3_128 should be as secure as sha3_shake128 with a larger output size. > - Generalize _shake_output function independent of the underlying SHA-3 > algorithm. Certainly needed. I don't think the all-in-one shake function should be deprecated, it seems like a nice utility. What I'm not sur about about is if it should be implemented as _output + _init (very cheap implementation) or its own function (with less runtime overhead than _output). I'll try to clean up and post or commit some of my changes, I'm sorry that will cause some conflicts. Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se To unsubscribe send an email to nettle-bugs-le...@lists.lysator.liu.se
