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

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

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 som

Deterministic (EC)DSA

/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

Re: additional API for SHAKE streaming read

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 descripti

Re: additional API for SHAKE streaming read

th 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 da9c

Re: additional API for SHAKE streaming read

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 &l

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 ins

Re: additional API for SHAKE streaming read

_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) &

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

Support for ML-KEM (Kyber)

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

additional API for SHAKE streaming read

://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_read

Re: Add RSA-OAEP encryption/decryption to Nettle

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 M

Re: Add RSA-OAEP encryption/decryption to Nettle

*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,

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

Re: Add RSA-OAEP encryption/decryption to Nettle

Niels Möller writes: > Daiki Ueno writes: > >> Added `mark_bytes_undefined (1, [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.

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 >>

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

Re: Add RSA-OAEP encryption/decryption to Nettle

pt. 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 interfa

Re: Add RSA-OAEP encryption/decryption to Nettle

://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

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 ha

Re: Nettle AUTHORS list

at. > > 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

Re: Status update

: [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

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

sed 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'

checking ECC point at infinity

(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

Re: Nettle-3.6 soon

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. Contribu

[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

[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

[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

[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

[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

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-ba

[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

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

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 >&

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

[PATCH] cfb8: don't truncate output IV if input is shorter than block size

=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

Re: [PATCH v2 0/6] Add meta interface for MAC algorithms

), 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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

Re: nettle-meta interface for MACs

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

, 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

[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

[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

[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

[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

[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

[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

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 curve

Re: [PATCH 0/8] Implement Curve448 ECDH and Ed448

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

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

[PATCH 8/8] Implement Ed448 signature scheme

From: Daiki Ueno <du...@redhat.com> Signed-off-by: Daiki Ueno <du...@redhat.com> --- Makefile.in | 4 +- ecc-192.c | 1 + ecc-224.c | 1 + ecc-25519.c | 1 + ecc-256.c

[PATCH 5/8] ecc-eh-to-a, eddsa-sign: Parameterize hard-coded value

From: Daiki Ueno <du...@redhat.com> This allows the same code to be reused in curve448 and Ed448. Signed-off-by: Daiki Ueno <du...@redhat.com> --- 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-

[PATCH 2/8] eccdata: Emit correct ecc_Bmodq_shifted for curve448

From: Daiki Ueno <du...@redhat.com> 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 <du...@redhat.com> --- eccdata.c | 13 - 1 file changed, 8 insertions(+), 5 deletions(-)

[PATCH 3/8] eccdata: Redirect ecc_point_out to given stream, instead of stderr

From: Daiki Ueno <du...@redhat.com> Signed-off-by: Daiki Ueno <du...@redhat.com> --- 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 @@ e

[PATCH 6/8] Implement curve448 primitives

From: Daiki Ueno <du...@redhat.com> 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 implementa

[PATCH 0/8] Implement Curve448 ECDH and Ed448

, 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

[PATCH 1/8] ecc-mul-test: Fix mpn_cmp calls

From: Daiki Ueno <du...@redhat.com> Signed-off-by: Daiki Ueno <du...@redhat.com> --- 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 in

Re: [PATCH] Avoid assertion failure in pss_verify_mgf1

ased 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 __

[PATCH] Avoid assertion failure in pss_verify_mgf1

lus 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 &g

Re: [PATCH v2 1/2] Implement PSS encoding functions

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

Re: [PATCH v2 1/2] Implement PSS encoding functions

" >> + "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-

Re: [PATCH 0/2] Implement RSA-PSS signature scheme

ni...@lysator.liu.se (Niels Möller) writes: > Daiki Ueno <u...@gnu.org> 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

[PATCH v2 2/2] Add PSS variants for RSA sign/verify functions

From: Daiki Ueno <du...@redhat.com> Signed-off-by: Daiki Ueno <du...@redhat.com> --- 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

[PATCH v2 1/2] Implement PSS encoding functions

From: Daiki Ueno <du...@redhat.com> Signed-off-by: Daiki Ueno <du...@redhat.com> --- 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

[PATCH 0/2] Implement RSA-PSS signature scheme

From: Daiki Ueno <du...@redhat.com> 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

[PATCH 2/2] Add PSS variants for RSA sign/verify functions

From: Daiki Ueno <du...@redhat.com> Signed-off-by: Daiki Ueno <du...@redhat.com> --- Makefile.in | 2 + nettle.texinfo | 30 + rsa-pss-sha256-sign-tr.c | 64 ++ rsa-pss-sha256-verify.c | 60 + rsa-pss