nettle-bugs September 2021

nettle-bugs@lists.lysator.liu.se

3 participants
8 discussions

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

Feature request: OCB mode
by Justus Winter 16 Feb '22

16 Feb '22

Hello, we (Sequoia PGP) would love to see OCB being implemented in Nettle. The OpenPGP working group is working on a revision of RFC4880, which will mostly be a cryptographic refresh, and will bring AEAD to OpenPGP. The previous -now abandoned- draft called for EAX being mandatory, and OCB being optional [0]. This was motivated by OCB being encumbered by patents. However, said patents were waived by the holder [1]. 0: https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-rfc4880bis-10#sect… 1: https://mailarchive.ietf.org/arch/msg/cfrg/qLTveWOdTJcLn4HP3ev-vrj05Vg/ With OCB being no longer patent-encumbered, it seems preferable over the two-pass EAX construction. Therefore, it seems plausible that the WG makes OCB mandatory to implement. To support that in Sequoia, we'd need support for that in Nettle (Nettle is our main cryptographic backend). Unfortunately, we don't have the expertise in our team to contribute a patch, and we currently aren't in a position to offer funding for the implementation. Thanks, Justus

2 5

Re: Build problem on ppc64be + musl
by Maamoun TK 04 Jan '22

04 Jan '22

On Wed, Aug 18, 2021 at 11:38 PM Stijn Tintel <stijn(a)linux-ipv6.be> wrote: > On 18/08/2021 22:29, Maamoun TK wrote: > > On Tue, Aug 17, 2021 at 9:40 AM Niels Möller <nisse(a)lysator.liu.se > > <mailto:nisse@lysator.liu.se>> wrote: > > > > The configuration where it didn't work was > > powerpc64-openwrt-linux-musl. I'd like Nettle to work on embedded > > systems whenever practical. But support depends on assistance from > > users > > of those systems. > > > > As I understood it, this system needs to use the v2 ABI. I would hope > > it's easy to detect the abi used by the configured C compiler, and > > then > > select the same prologue sequence as is currently used for > > little-endian. I.e., one more configure test, and changing the > > "ifelse(WORDS_BIGENDIAN,no," condition in powerpc64/machine.m4 to > > check > > a different configure variable. > > > > > > I skipped processing the assembly files with a different approach, I > > made the configuration check for musl and endianness variant to > > trigger assembly processing. You can check the fix in this branch > > https://git.lysator.liu.se/mamonet/nettle/-/tree/ppc64_musl_fix > > <https://git.lysator.liu.se/mamonet/nettle/-/tree/ppc64_musl_fix> > > Apparently, the bug reporter uses a cross-compiler for powerpc arch. > > It would be great to run this fix at the same bug environment since I > > tested the patch in different circumstances. > > Your patch has no effect in my environment (OpenWrt build system), as > host_os is linux-gnu, according to config.log, so it doesn't match > *musl. See [1] for config.log and [2] for full compile log. > > The output of powerpc64-openwrt-linux-musl-gcc -E -dM - </dev/null | > sort, which was requested earlier in this thread can be seen at [3]. > > Thanks, > Stijn > > [1] https://gist.github.com/9e0ecb025033dda1d0d58094da84c308 > [2] https://gist.github.com/stintel/0e7046df511cf4d1ca20edb56df50b1b > [3] https://gist.github.com/stintel/b3651a7db87edea9e8bd0aef242bcdae config.guess detects the C standard library based on a result from the compiler defined in "CC_FOR_BUILD" variable, for some reason OpenWrt build system failed to set that variable properly, from your config.log I can see CC_FOR_BUILD='gcc -O -g' but when I use bare musl tools I get CC_FOR_BUILD='musl-gcc' There is nothing specific in the output of powerpc64-openwrt-linux-musl-gcc -E -dM log as I can see. In musl libc FAQ, they stated that there is no __MUSL__ in the preprocessor macros https://wiki.musl-libc.org/faq.html regards, Mamone

2 9

Curve point decompression
by Wim Lewis 10 Nov '21

10 Nov '21

I'm looking at implementing elliptic curve point compression a la SEC1 (admittedly, mostly to reduce the number of "feature not supported" code paths in a library, but it seems like a somewhat useful ability). Nettle/Hogweed already implements it internally for curve25519, but I want to implement it for the "secp" curves as well. Point compression is easy enough, but point decompression requires some curve math, potentially dependent on the specific curve, and some of it is redundant with what's already done in ecc_point_set(). So I was thinking about moving this functionality into Hogweed as a function along the lines of ecc_point_set_compressed(), which would take, instead of a y-coordinate, an int containing the sign/parity of the y-coordinate. So my question for the list and for the maintainers is, is this a reasonable API to add to Hogweed? Is there interest in including it in Hogweed if I were to take the time to turn it into a tidy patch?

3 10

Structural fixes to the manual
by nisse＠lysator.liu.se 22 Sep '21

22 Sep '21

I've spent some time to improve structure (mostly non-text changes) of the manual. 1. Deleted all explicit node pointers in nettle.texinfo, instead letting makeinfo infer the node structure. This is the recommended way these days, according to texinfo documentation. 2. Changed the make rules producing nettle.pdf to use texi2pdf, instead of the chain texi2dvi + dvips + pstopdf. Most obvious result is that hyperlinks work better, and output file is slightly smaller. It's done in whatever way is default in texi2pdf, I haven't tried to check the details (e.g., what kind of fonts are used, and if they're all embedded in the file). 3. Split the huge Cipher functions node into one node per cipher. 4. Fixed a few places where urls or example code was too wide for the page. According to the docs (https://www.gnu.org/software/texinfo/manual/texinfo/html_node/URL-Line-Brea…), line breaks should be automatically added in urls when needed (and that's true also according to the docs for texinfo-6.7, which is what I have installed), but that didn't work at all when I tried it, so I've added a few explicit hints on how to break long urls. Also the @urefbreakstyle command wasn't recognized at all. Anyone here more familiar with texinfo that can explain? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.

1 0

[S390x] Optimize SHA1 with fat build support
by Maamoun TK 20 Sep '21

20 Sep '21

I made a merge request in the main repository that optimizes SHA1 for s390x architecture with fat build support !33 <https://git.lysator.liu.se/nettle/nettle/-/merge_requests/33>. regards, Mamone

2 10

[S390x] Optimize AES modes
by Maamoun TK 19 Sep '21

19 Sep '21

I made a merge request for optimizing AES modes on s390x architecture, the patch implements the optimized cores using cipher instructions that have been added to s390x arch in message security assist extensions. The patch uses the following functions: KM-AES-128 (ECB-AES128) KM-AES-192 (ECB-AES192) KM-AES-256 (ECB-AES256) KMC-AES-128 (CBC-AES128) KMC-AES-192 (CBC-AES192) KMC-AES-256 (CBC-AES256) KMAC-AES-128 (CCM-AES128, CMAC-AES128) KMAC-AES-192 (CCM-AES192) KMAC-AES-256 (CCM-AES256, CMAC-AES256) KMF-AES-128 (CFB-AES128, CFB8-AES128) KMF-AES-192 (CFB-AES192, CFB8-AES192) KMF-AES-256 (CFB-AES256, CFB8-AES256) KM-XTS-AES-128 (XTS-AES128) KM-XTS-AES-256 (XTS-AES256) KIMD-GHASH (GHASH) KMCTR-AES-128, KMA-GCM-AES-128 (CTR-AES128) KMCTR-AES-192, KMA-GCM-AES-192 (CTR-AES192) KMCTR-AES-256, KMA-GCM-AES-256 (CTR-AES256) KMA-GCM-AES-128 (GCM-AES128) KMA-GCM-AES-192 (GCM-AES192) KMA-GCM-AES-256 (GCM-AES256) The merge request has also a benchmark that measures the speed of optimized cores on s390x arch. I can't set up gitlab CI for automatic testing on s390x arch because qemu hasn't implemented cipher functions for this arch. However, there is an easy way to test the patch manually by requesting a free account on the LinuxONE Community Cloud, both short-term and long-term access are available. https://linuxone.cloud.marist.edu/#/register?flag=VM regards, Mamone

4 39

Reorganization of x86_64 aesni code
by nisse＠lysator.liu.se 04 Sep '21

04 Sep '21

I've merged a reorganization of the x86_64 aesni code to the master-updates branch for testing. This replaces the x86_64/aesni/aes-*crypt-internal.asm files with separate files for the different key sizes, as has been discussed earlier. And I've implemented 2-way interleaving, i.e., doing 2 blocks at a time, which gave a nice speedup on the order of 15% in my tests. I may be worthwhile to go to 3-way or 4-way, but I don't plan to try that soon. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. 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 September 2021