nettle-bugs February 2024

nettle-bugs@lists.lysator.liu.se

4 participants
6 discussions

ppc64 micro optimization
by Niels Möller 14 Apr '24

14 Apr '24

In preparing for merging the gcm-aes "stitched" implementation, I'm reviewing the existing ghash code. WIP branch "ppc-ghash-macros. I've introduced a macro GHASH_REDUCE, for the reduction logic. Besides that, I've been able to improve scheduling of the reduction instructions (adding in the result of vpmsumd last seems to improve parallelism, some 3% speedup of gcm_update on power10, benchmarked on cfarm120). I've also streamlined the way load offsets are used, and trimmed the number of needed vector registers slightly. For the AES code, I've merged the new macros (I settled on the names OPN_XXY and OPN_XXXY), no change in speed expected from that change. I've also tried to understand the differenct between AES encrypt and decrypt, where decrypt is much slower, and uses an extra xor instruction in the round loop. I think the reason for that is that other AES implementations (including x86_64 and arm64 instructions, and Nettle's C implementation) expect the decryption subkeys to be transformed via the AES "MIX_COLUMN" operation, see https://gitlab.com/gnutls/nettle/-/blob/master/aes-invert-internal.c?ref_ty… While the powerpc64 vncipher instruction really wants the original subkeys, not transformed. So on power, it would be better to have a _nettle_aes_invert that is essentially a memcpy, and then the aes decrypt assembly code could be reworked without the xors, and run at exactly the same speed as encryption. Current _nettle_aes_invert also changes the order of the subkeys, with a FIXME comment suggesting that it would be better to update the order keys are accessed in the aes decryption functions. Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

2 17

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

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

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

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