nettle-bugs

nettle-bugs@lists.lysator.liu.se

2196 discussions

additional API for SHAKE streaming read
by Daiki Ueno 14 Apr '24

14 Apr '24

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-kybe… -- Daiki Ueno #include "sha3.h" #include <stdio.h> 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; }

2 16

Issue tracker
by Niels Möller 29 Mar '24

29 Mar '24

Hi, I've enabled the issue tracker at https://git.lysator.liu.se/nettle/nettle/-/issues, and filed a few issues for old TODO items, most of which imply ABI and/or API changes. Feel free to file aditional issues for bugs, feature requests, or to track work you are doing or planning. My intention is to (i) keep track of desirable or in-progress changes, and (ii) use for release planning, e.g., use a tag or "milestone" to attach to issues that we want to be included in the next release, similar to how misc/plan.html has been use for some of the releases in the past. Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

1 0

Naming for names in struct nettle_hash
by Niels Möller 28 Mar '24

28 Mar '24

Hi, I've got a bug report that sha512_224 and sha512_256 are missing in the list returned by nettle_get_hashes, and I'm about to add them. But then there's a question of naming convention. Currently, the extern const struct nettle_hash nettle_sha512_256; includes a name field set to the string "sha512-256", which is somewhat inconsistent with, e.g., the struct nettle_sha3_256 which includes the name "sha3_256". Should I just change this (patch below)? Honestly, I haven't given much thought to the conventions used here, but perhaps it makes the most sense that naming match the names of corresponding C symbols (with underscore rather than dash)? Regards, /Niels diff --git a/nettle-meta-hashes.c b/nettle-meta-hashes.c index 4d421182..2245dfb7 100644 --- a/nettle-meta-hashes.c +++ b/nettle-meta-hashes.c @@ -49,6 +49,8 @@ const struct nettle_hash * const _nettle_hashes[] = { &nettle_sha256, &nettle_sha384, &nettle_sha512, + &nettle_sha512_224, + &nettle_sha512_256, &nettle_sha3_224, &nettle_sha3_256, &nettle_sha3_384, diff --git a/sha512-224-meta.c b/sha512-224-meta.c index 24c42bfc..f3751e14 100644 --- a/sha512-224-meta.c +++ b/sha512-224-meta.c @@ -39,7 +39,7 @@ const struct nettle_hash nettle_sha512_224 = { - "sha512-224", sizeof(struct sha512_ctx), + "sha512_224", sizeof(struct sha512_ctx), SHA512_224_DIGEST_SIZE, SHA512_224_BLOCK_SIZE, (nettle_hash_init_func *) sha512_224_init, diff --git a/sha512-256-meta.c b/sha512-256-meta.c index 37d17c35..181f2874 100644 --- a/sha512-256-meta.c +++ b/sha512-256-meta.c @@ -39,7 +39,7 @@ const struct nettle_hash nettle_sha512_256 = { - "sha512-256", sizeof(struct sha512_ctx), + "sha512_256", sizeof(struct sha512_ctx), SHA512_256_DIGEST_SIZE, SHA512_256_BLOCK_SIZE, (nettle_hash_init_func *) sha512_256_init, diff --git a/testsuite/meta-hash-test.c b/testsuite/meta-hash-test.c index 6a15e7db..ec4e0d1e 100644 --- a/testsuite/meta-hash-test.c +++ b/testsuite/meta-hash-test.c @@ -16,6 +16,8 @@ const char* hashes[] = { "sha256", "sha384", "sha512", + "sha512_224", + "sha512_256", "sha3_224", "sha3_256", "sha3_384", -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

1 1

Adding MD5/SHA1 support to RSA OAEP
by Hans Leidekker 27 Mar '24

27 Mar '24

Hello, I noticed the arrival of an RSA OAEP implementation in GnuTLS and wanted to use that to support the algorithm in Wine. Windows supports it using the old MD5 and SHA1 hash functions, so my question is: would you accept a patch like below that adds these hashes?

2 4

HPKE ready for Merge!
by Ajit singh 24 Mar '24

24 Mar '24

Hi all, I trust this message finds you well. Notably, HPKE has already been successfully implemented, and now your prompt attention is sought for the critical review and merging of the MR into the main branch of Nettle. As encrypted client hello(ECH) also relies on HPKE, your swift action is highly appreciated. HPKE MR Link:https://git.lysator.liu.se/nettle/nettle/-/merge_requests/27 Thanks, Ajit

3 4

Relax blocking requirement of gcm_update?
by Niels Möller 10 Mar '24

10 Mar '24

While looking at extended tests of the aead update function (for the associated data), I stumbled on a restriction of gcm_update that is different from most (all?) other update functions in Nettle. According to the docs, -- Function: void gcm_update (struct gcm_ctx *CTX, const struct gcm_key *KEY, size_t LENGTH, const uint8_t *DATA) Provides associated data to be authenticated. If used, must be called before ‘gcm_encrypt’ or ‘gcm_decrypt’. All but the last call for each message _must_ use a length that is a multiple of the block size. Would it be worthwhile to drop the restriction of the last sentence, and allow all calls to gcm_update to use any size? This requirement may be particularly surprising when using nettle_aead; then gcm has different requirements for the update function than all other aead algorithms. I think that might be doable without any ABI break, by the following hack: reuse the ctr field of struct gcm_context as a block buffer, while processing the associated data. The ctr field is clearly needed also for encrypt/decrypt, but we could move initialization for that purpose from gcm_set_iv to the first call to encrypt/decrypt. Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

2 3

Add RSA-OAEP encryption/decryption to Nettle
by Nicolas Mora 09 Mar '24

09 Mar '24

Hello, I've made a new Merge Request in the nettle gitlab repo to provide RSA-OAEP encryption and decryption: https://git.lysator.liu.se/nettle/nettle/-/merge_requests/20 It adds 2 new functions: int pkcs1_oaep_encrypt (size_t key_size, void *random_ctx, nettle_random_func *random, size_t hlen, size_t label_length, const uint8_t *label, size_t message_length, const uint8_t *message, mpz_t m); int pkcs1_oaep_decrypt (size_t key_size, const mpz_t m, size_t hlen, size_t label_length, const uint8_t *label, size_t *length, uint8_t *message); The parameter hlen is the output length of the SHA function used for masking data: - SHA1_DIGEST_SIZE - SHA256_DIGEST_SIZE - SHA384_DIGEST_SIZE - SHA512_DIGEST_SIZE Is it possible to get feedback for this MR and eventually push it to the master branch? Thanks in advance /Nicolas

4 21

Support for ML-KEM (Kyber)
by Daiki Ueno 04 Mar '24

04 Mar '24

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

2 1

reply: reply: A new realization of ecc-sm2
by zhongxuan (A) 14 Feb '24

14 Feb '24

> "zhongxuan (A)" <zhongxuan2(a)huawei.com> writes: >> Where should I commit my patch? The access request to fork in Nettle / nettle * GitLab (liu.se)<https://git.lysator.liu.se/nettle/nettle> was denied. > Hi, I think you asked for "developer access" in the Nettle repo, which would allow you to push any changes you like to the repository. You can't have that, but unfortunately, I couldn't add any explanatory message when pushing the deny button in gitlab. > The usual way to contribute code in gitlab (as well as on github), is that you make your own "fork" of the repository, where you have full permissions. You commit your changes to a branch in that fork, and then create a merge request asking for changes to be merged into the original repo. Yes, I've tried to make a fork in https://git.lysator.liu.se/nettle/nettle/-/forks/new but failed, it just reports ' An error occurred while forking the project. Please try again. '. I replied a long email but tragically didn’t attach my patch. Here I attach my new patch of ecc-sm2. Besides, could you help me figure out what's wrong with my fork? I preferred to commit in fork mode, too. > See > https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html > on how to create a fork from the gitlab ui. > When you work with git locally, you can have both your own "fork" repo and the original repo as git "remotes". > And if gitlab doesn't work out for you, you could also send the updated patch to this list. > Best regards, > /Niels > -- > Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. > Internet email is subject to wholesale government surveillance.

2 1

Question on s390x AES acceleration
by Niels Möller 27 Jan '24

27 Jan '24

When I look at the logic in https://git.lysator.liu.se/nettle/nettle/-/blob/master/fat-s390x.c?ref_type…, automatic detection of hardware acceleration for aes128, aes192 and aes256 is done independently for each key size, based on corresponding bits in the "km status" words. While when configured manually, at configure time or using NETTLE_FAT_OVERRIDE, there are instead two flags, "msa_x1" enabling aes128 (and sha256), and "msa_x2" enabling aes192, aes256 (and sha512). I'm thinking that if we could enable all or none of the s390x aes assembly, then we could make things a bit simpler, only overriding the internal _nettle_aes_set_key and _nettle_aes_invert_key, instead of all 9 of aes{128,192,256}_{set_encrypt,set_decrypt,invert}_key. Are there s390x machines out there that have hardware support for just some of the aes key sizes but not all? Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

nettle-bugs