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
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
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
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
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
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
"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 fo
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/
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
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
nded 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'.
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
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 th
, 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
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
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
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
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
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 diffe
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
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
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 bc210d94144d6b5d1e
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
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
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/Presenta
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/Presenta
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
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
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
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
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
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
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
8_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.lysa
?
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
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
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
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
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
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
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
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
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
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
__
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
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
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
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
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
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
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
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
mit;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 o
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 go
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
>&
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,
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
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
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
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
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
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
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
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 t
6: _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);
mation; 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== C
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
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
lace 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
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, i
://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
_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&#x
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
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
>>
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
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
icitly 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 U
t 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 9ffbac0
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
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
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 th
gt;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 +
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 inste
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)
> 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
u 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
responds 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 desc
/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 0b9860dfa63becdc2e2d8468889c35a2991c
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 adde
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 the
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, tha
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
age_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 archite
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.l
94 matches
Mail list logo
