nettle-bugs

nettle-bugs@lists.lysator.liu.se

2191 discussions

ANNOUNCE: Nettle-3.7.2
by nisse＠lysator.liu.se 21 Mar '21

21 Mar '21

I've prepared a new bug-fix release of Nettle, a low-level cryptographics library, to fix a serious bug in the function to verify ECDSA signatures. Implications include an assertion failure, which could be used for denial-of-service, when verifying signatures on the secp_224r1 and secp521_r1 curves. More details in NEWS file below. Upgrading is strongly recomended. The Nettle home page can be found at https://www.lysator.liu.se/~nisse/nettle/, and the manual at https://www.lysator.liu.se/~nisse/nettle/nettle.html. The release can be downloaded from https://ftp.gnu.org/gnu/nettle/nettle-3.7.2.tar.gz ftp://ftp.gnu.org/gnu/nettle/nettle-3.7.2.tar.gz https://www.lysator.liu.se/~nisse/archive/nettle-3.7.2.tar.gz Regards, /Niels NEWS for the Nettle 3.7.2 release This is a bugfix release, fixing a bug in ECDSA signature verification that could lead to a denial of service attack (via an assertion failure) or possibly incorrect results. It also fixes a few related problems where scalars are required to be canonically reduced modulo the ECC group order, but in fact may be slightly larger. Upgrading to the new version is strongly recommended. Even when no assert is triggered in ecdsa_verify, ECC point multiplication may get invalid intermediate values as input, and produce incorrect results. It's trivial to construct alleged signatures that result in invalid intermediate values. It appears difficult to construct an alleged signature that makes the function misbehave in such a way that an invalid signature is accepted as valid, but such attacks can't be ruled out without further analysis. Thanks to Guido Vranken for setting up the fuzzer tests that uncovered this problem. The new version is intended to be fully source and binary compatible with Nettle-3.6. The shared library names are libnettle.so.8.3 and libhogweed.so.6.3, with sonames libnettle.so.8 and libhogweed.so.6. Bug fixes: * Fixed bug in ecdsa_verify, and added a corresponding test case. * Similar fixes to ecc_gostdsa_verify and gostdsa_vko. * Similar fixes to eddsa signatures. The problem is less severe for these curves, because (i) the potentially out or range value is derived from output of a hash function, making it harder for the attacker to to hit the narrow range of problematic values, and (ii) the ecc operations are inherently more robust, and my current understanding is that unless the corresponding assert is hit, the verify operation should complete with a correct result. * Fix to ecdsa_sign, which with a very low probability could return out of range signature values, which would be rejected immediately by a verifier. -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.

1 0

ANNOUNCE: Serious bug in Nettle's ecdsa_verify
by nisse＠lysator.liu.se 16 Mar '21

16 Mar '21

I've been made aware of a bug in Nettle's code to verify ECDSA signatures. Certain signatures result in the ecc point multiply function being called with out-of-range scalars, which may give incorrect results, or crash in an assertion failure. It's an old bug, probably since Nettle's initial implementation of ECDSA. I've just pushed fixes for ecdsa_verify, as well as a few other cases of potentially out-of-range scalars, to the master-updates branch. I haven't fully analysed the implications, but I'll describe my current understanding. I think an assertion failure, useful for a denial-of-service attack, is easy on the curves where the bitsize of q, the group order, is not an integral number of words. That's secp224r1, on 64-bit platforms, and secp521r1. Even when it's not possible to trigger an assertion failure, it's easy to produce valid-looking input "signatures" that hit out-of range intermediate scalar values where point multiplication may misbehave. This applies to all the NIST secp* curves as well as the GOST curves. To me, it looks very difficult to make it misbehave in such a way that ecdsa_verify will think an invalid signature is valid, but it might be possible; further analysis is needed. I will not be able to analyze it properly now, if anyone else would like to look into it, I can provide a bit more background. ed25519 and ed448 may be affected too, but it appears a bit harder to find inputs that hit out of range values. And since point operations are inherently more robust on these curves, I think they will produce correct results as long as they don't hit the assert. Advise on how to deal best with this? My current plan is to prepare a 3.7.2 bugfix release (from a new bugfix-only branch, without the new arm64 code). Maybe as soon as tomorrow (Wednesday, european time), or in the weekend. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.

1 0

Status update
by nisse＠lysator.liu.se 07 Mar '21

07 Mar '21

I've haven't had much hacking time since the 3.7.1 bug fix rel1ease. I'm aware of the following recent issues that need review/work: 1. New Arm64 code (don't recall current status off the top of my head). 2. s390x testing. I'd prefer to not run a git checkout on the s390x test machine, but have the ci job make a tarball, ssh it over to the test machine, unpack in a fresh directory for build and test. This needs to be in place before adding s390x specific code. When done, could likely be reused for remote testing on any other platforms of interest, which aren't directly available in the ci system. 3. AES-keywrap merge request, https://git.lysator.liu.se/nettle/nettle/-/merge_requests/19 4. RSA-OAEP merge request. I intend to attend to (3) first, and will not pay much attention to this one at the moment. If anyone else would like to help out with review, maybe have alook at this one? https://git.lysator.liu.se/nettle/nettle/-/merge_requests/20 Anything else? There are other projects that's been on hold for a while, e.g., support for compact representation (aka "point compression") on the NIST curves, that I don't give high priority at the moment. I often get some hacking time on Wednesdays and weekends, but not every week. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.

3 6

ANNOUNCE: Nettle-3.7.1
by nisse＠lysator.liu.se 17 Feb '21

17 Feb '21

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I'd like to announce a new release of GNU Nettle, a low-level cryptographics library. This release fixes a few problem in Nettle-3.7, in particular, a bug affecting GnuTLS on powerpc64 platforms. See NEWS entries below. The Nettle home page can be found at https://www.lysator.liu.se/~nisse/nettle/, and the manual at https://www.lysator.liu.se/~nisse/nettle/nettle.html. The release can be downloaded from https://ftp.gnu.org/gnu/nettle/nettle-3.7.1.tar.gz ftp://ftp.gnu.org/gnu/nettle/nettle-3.7.1.tar.gz https://www.lysator.liu.se/~nisse/archive/nettle-3.7.1.tar.gz Happy hacking, /Niels Möller NEWS for the Nettle 3.7.1 release This is primarily a bug fix release, fixing a couple of problems found in Nettle-3.7. The new version is intended to be fully source and binary compatible with Nettle-3.6. The shared library names are libnettle.so.8.2 and libhogweed.so.6.2, with sonames libnettle.so.8 and libhogweed.so.6. Bug fixes: * Fix bug in chacha counter update logic. The problem affected ppc64 and ppc64el, with the new altivec assembly code enabled. Reported by Andreas Metzler, after breakage in GnuTLS tests on ppc64. * Support for big-endian ARM platforms has been restored. Fixes contributed by Michael Weiser. * Fix build problem on OpenBSD/powerpc64, reported by Jasper Lievisse Adriaanse. * Fix corner case bug in ECDSA verify, it would produce incorrect result in the unlikely case of an all-zero message hash. Reported by Guido Vranken. New features: * Support for pbkdf2_hmac_sha384 and pbkdf2_hmac_sha512, contributed by Nicolas Mora. Miscellaneous: * Poorly performing ARM Neon code for doing single-block Salsa20 and Chacha has been deleted. The code to do two or three blocks in parallel, introduced in Nettle-3.7, is unchanged. - -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEy0li0HDXfX/Li6Nicdjx/zaMZncFAmAtgJMACgkQcdjx/zaM ZnfTEQf+KdzEoCkSHZfOFQ9qreKfY4ZVzxO3Nbh8wBiQYbueUw2X9kNxh+ErL4M7 FL2ovRbE3vLsWft5Y+rWg7wmDPUCwOdVsovURwENB6l+kbynksG+DWhIfg6hcjQ4 qqlhSArW/2UtIlswMj1hfh/g//aUDl0gigZX0C1LmCIlr4IzZvmMk5+9ZsR+9cXT +R/gdh2Hxw/DzMT8yB/J5wP5/5IzA5xkV2LhBKqS538bFEVsE7t+DInEjoUYhmtv st5VuyUxstKxqtp6RB+RfVcWDwpyyMi6/wn8fKfv5UkdVVgOHsXwY2Ls2YG6oKvs XswtEhTV17sYMTlVNtLKm8vOLnLYPA== =E0qp -----END PGP SIGNATURE-----

1 0

Arcfour status
by nisse＠lysator.liu.se 14 Feb '21

14 Feb '21

I've had a report (from Matthew Kempe) about another problem with the openssl benchmarking code. It fails on FreeBSD, because there (and possible in other environments too) openssl has been configured without RC4 (aka arcfour) support. I'm considering just deleting code to benchmark openssl arcfour; I don't plan any improvements of Nettle's arcfour performance, and I would be surprised if the openssl people do. I do intend to keep arcfour support in Nettle for the foreseeable future, to support old protocols and applications. But I'm thinking that maybe the arcfour assembly code could be deleted? Nettle currently includes arcfour assembly implementations for x86 (32-bit) and sparc (both 32-bit and 64-bit), which as far as I remember gave a modest speedup when added. But the code hasn't been tuned or benchmarked recently. And we have nothing for more relevant platforms. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.

2 1

GnuTLS testsuite error on ppc64 after nettle upgrade
by Andreas Metzler 10 Feb '21

10 Feb '21

Hello, Upgrading nettle from 3.6 to 3.7 triggers a GnuTLS 3.7.0 testsuite error on both ppc64 and ppc64el: (sid_ppc64el-dchroot)ametzler@plummer:~/GNUTLS/gnutls28-3.7.0/b4deb/tests$ ./min i-record-2 testing aes-cbc testing aes-cbc-sha256 testing aes-gcm testing aes-ccm testing aes-ccm-8 testing null-sha1 testing arcfour-sha1 testing arcfour-md5 testing chacha20-poly1305 testing tls13-chacha20-poly1305 server:330: client: Error: An unexpected TLS packet was received. Running the same binary dynamically (with LD_LIBRARY_PATH setting) linked against nettle 3.6 succeeds. --verbose logs are huge (5-7 MB xz-compressed), I have uploaded them to https://people.debian.org/~ametzler/tmp/ cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'

4 10

Bug fix release Nettle-3.7.1 ?
by nisse＠lysator.liu.se 10 Feb '21

10 Feb '21

Hi, I think the chacha bug is a severe enough regression to warrant a bugfix release pretty soon. I'll aim to get it out in a week from now. I think it should be fine to do a 3.7.1 release from the master branch, rather than cherry-picking selected bugfixes. I've looked through git history and ChangeLog since the release one and a half month ago, and I think this is a accurate summary for the NEWS file: Bug fixes: * Fix bug in chacha counter update logic. The problem affected ppc64 and ppc64el, with the new altivec assembly code enabled. Reported by Andreas Metzler, after breakage in GnuTLS tests on ppc64. * Support for big-endian ARM platforms has been restored. Fixes contributed by Michael Weiser. * Fix build problem on OpenBSD/powerpc64, reported by Jasper Lievisse Adriaanse. * Fix corner case bug in ECDSA verify, it would produce incorrect result in the unlikely case of an all-zero message hash. Reported by Guido Vranken. New features: * Support for pbkdf2_hmac_sha384 and pbkdf2_hmac_sha512, contributed by Nicolas Mora. Miscellaneous: * Poorly performing ARM Neon code for doing single-block Salsa20 and Chacha has been deleted. The code to do two or three blocks in parallel, introduced in Nettle-3.7, is unchanged. Sonames will be unchanged. libnettle.so should get an incremented minor number, for the addition of the new pbkdf2 function. I don't think libhogweed.so strictly needs an incremented minor number, but maybe it's less confusing to increment it anyway. Anything I'm missing? Any easy in-progress changes that should also get into the release? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.

1 0

Re: Release of Nettle-3.7?
by nisse＠lysator.liu.se 06 Feb '21

06 Feb '21

Michael Weiser <michael(a)weiser.dinsnail.net> writes: > Porting over the basic > IF_[LB]E mechanism from chacha-core-internal was easy and fixed up the > first of the three interleaved blocks right away. For the other two I am > still in the process of wrapping my head around how the interleaving > works and how it would need some adjustment for BE. The 3-way functions don't do anything fancy, just each of the three blocks represented in separate registers, and same instruction sequence as for the 1-way version, duplicated threee times and interleaved. The 2-way version (for ARM, that's salsa only) tries to be a bit more clever, with registers representing either odd or even words from both blocks. Not sure how endianness affects the code to move words around. Byte swapping should go close to the final stores, but after the addition of the initial state. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.

3 16

[AArch64] Optimize GHASH
by Maamoun TK 06 Feb '21

06 Feb '21

I made a merge request in the main repo that enables optimized GHASH on AArch64 architecture. The implementation is based on Niels Möller's enhanced algorithm which yields more speedup on AArch64 arch in comparison with intel algorithm. Using the Karatsuba algorithm with Intel algorithm yielded an overhead so I dropped its benchmark result. I'll attach the file of Intel algorithm implementation here since it's not include in the MR. Here is the benchmark result on AArch64: *---------------------------------------------------------------------------------------------* | C version | Intel algorithm | Niels Möller's enhanced algorithm | | 208 Mbyte/s | 2781 Mbyte/s | 3255 Mbyte/s | *---------------------------------------------------------------------------------------------* This is +17% performance boost of the enhanced algorithm over the Intel algorithm, it's not as impressive as PowerPC benchmark result but it did a great job on AArch64 considering PMULL instruction doesn't have the assistance that vpmsumd offers by multiply four polynomials then summing. I tried to avoid using the stack in this implementation so I wrote a procedure to handle leftovers by just using the registers, let me know if there's a room for improvement here. regards, Mamone C arm/v8/gcm-hash.asm ifelse(` Copyright (C) 2020 Niels Möller and Mamone Tarsha This file is part of GNU Nettle. GNU Nettle is free software: you can redistribute it and/or modify it under the terms of either: * the GNU Lesser General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version. or * the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. or both in parallel, as here. GNU Nettle is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received copies of the GNU General Public License and the GNU Lesser General Public License along with this program. If not, see http://www.gnu.org/licenses/. ') C gcm_set_key() assigns H value in the middle element of the table define(`H_Idx', `128') .file "gcm-hash.asm" .text C void gcm_init_key (union gcm_block *table) C This function populates the gcm table as the following layout C ******************************************************************************* C | H1M = (H1 div x⁶⁴)||((H1 mod x⁶⁴) × (x⁶⁴+x⁶³+x⁶²+x⁵⁷)) div x⁶⁴ | C | H1L = (H1 mod x⁶⁴)||(((H1 mod x⁶⁴) × (x⁶³+x⁶²+x⁵⁷)) mod x⁶⁴) + (H1 div x⁶⁴) | C | | C | H2M = (H2 div x⁶⁴)||((H2 mod x⁶⁴) × (x⁶⁴+x⁶³+x⁶²+x⁵⁷)) div x⁶⁴ | C | H2L = (H2 mod x⁶⁴)||(((H2 mod x⁶⁴) × (x⁶³+x⁶²+x⁵⁷)) mod x⁶⁴) + (H2 div x⁶⁴) | C | | C | H3M = (H3 div x⁶⁴)||((H3 mod x⁶⁴) × (x⁶⁴+x⁶³+x⁶²+x⁵⁷)) div x⁶⁴ | C | H3L = (H3 mod x⁶⁴)||(((H3 mod x⁶⁴) × (x⁶³+x⁶²+x⁵⁷)) mod x⁶⁴) + (H3 div x⁶⁴) | C | | C | H4M = (H3 div x⁶⁴)||((H4 mod x⁶⁴) × (x⁶⁴+x⁶³+x⁶²+x⁵⁷)) div x⁶⁴ | C | H4L = (H3 mod x⁶⁴)||(((H4 mod x⁶⁴) × (x⁶³+x⁶²+x⁵⁷)) mod x⁶⁴) + (H4 div x⁶⁴) | C ******************************************************************************* define(`TABLE', `x0') define(`ZERO', `v0') define(`EMSB', `v1') define(`POLY', `v2') define(`B', `v3') define(`H', `v4') define(`HQ', `q4') define(`H_t', `v5') define(`H2', `v6') define(`H2_t', `v7') define(`H3', `v16') define(`H3_t', `v17') define(`H4', `v18') define(`H4_t', `v19') define(`H_m', `v20') define(`H_m1', `v21') define(`H_h', `v22') define(`H_l', `v23') define(`RP', `v24') define(`Ml', `v25') define(`Mh', `v26') PROLOGUE(_nettle_gcm_init_key) ldr HQ,[TABLE,#16*H_Idx] dup EMSB.16b,H.b[0] rev64 H.16b,H.16b mov x9,#0xC200000000000000 mov x10,#1 mov POLY.d[0],x9 mov POLY.d[1],x10 sshr EMSB.16b,EMSB.16b,#7 and EMSB.16b,EMSB.16b,POLY.16b ushr B.2d,H.2d,#63 and B.16b,B.16b,POLY.16b ext B.16b,B.16b,B.16b,#8 shl H.2d,H.2d,#1 orr H.16b,H.16b,B.16b eor H.16b,H.16b,EMSB.16b eor ZERO.16b,ZERO.16b,ZERO.16b dup POLY.2d,POLY.d[0] ext H_t.16b,H.16b,H.16b,#8 pmull H_m.1q,H.1d,H_t.1d pmull2 H_m1.1q,H.2d,H_t.2d pmull H_h.1q,H.1d,H.1d pmull2 H_l.1q,H.2d,H.2d eor H_m.16b,H_m.16b,H_m1.16b pmull RP.1q,H_l.1d,POLY.1d ext Ml.16b,ZERO.16b,H_m.16b,#8 ext Mh.16b,H_m.16b,ZERO.16b,#8 ext RP.16b,RP.16b,RP.16b,#8 eor H_l.16b,H_l.16b,Ml.16b eor H_h.16b,H_h.16b,Mh.16b eor H_l.16b,H_l.16b,RP.16b pmull2 RP.1q,H_l.2d,POLY.2d eor H_h.16b,H_h.16b,H_l.16b eor H2_t.16b,H_h.16b,RP.16b ext H2.16b,H2_t.16b,H2_t.16b,#8 st1 {H.16b,H_t.16b,H2.16b,H2_t.16b},[TABLE],#64 pmull H_m.1q,H.1d,H2_t.1d pmull2 H_m1.1q,H.2d,H2_t.2d pmull H_h.1q,H.1d,H2.1d pmull2 H_l.1q,H.2d,H2.2d eor H_m.16b,H_m.16b,H_m1.16b pmull RP.1q,H_l.1d,POLY.1d ext Ml.16b,ZERO.16b,H_m.16b,#8 ext Mh.16b,H_m.16b,ZERO.16b,#8 ext RP.16b,RP.16b,RP.16b,#8 eor H_l.16b,H_l.16b,Ml.16b eor H_h.16b,H_h.16b,Mh.16b eor H_l.16b,H_l.16b,RP.16b pmull2 RP.1q,H_l.2d,POLY.2d eor H_h.16b,H_h.16b,H_l.16b eor H3_t.16b,H_h.16b,RP.16b ext H3.16b,H3_t.16b,H3_t.16b,#8 pmull H_m.1q,H2.1d,H2_t.1d pmull2 H_m1.1q,H2.2d,H2_t.2d pmull H_h.1q,H2.1d,H2.1d pmull2 H_l.1q,H2.2d,H2.2d eor H_m.16b,H_m.16b,H_m1.16b pmull RP.1q,H_l.1d,POLY.1d ext Ml.16b,ZERO.16b,H_m.16b,#8 ext Mh.16b,H_m.16b,ZERO.16b,#8 ext RP.16b,RP.16b,RP.16b,#8 eor H_l.16b,H_l.16b,Ml.16b eor H_h.16b,H_h.16b,Mh.16b eor H_l.16b,H_l.16b,RP.16b pmull2 RP.1q,H_l.2d,POLY.2d eor H_h.16b,H_h.16b,H_l.16b eor H4_t.16b,H_h.16b,RP.16b ext H4.16b,H4_t.16b,H4_t.16b,#8 st1 {H3.16b,H3_t.16b,H4.16b,H4_t.16b},[TABLE] ret EPILOGUE(_nettle_gcm_init_key) define(`TABLE', `x0') define(`X', `x1') define(`LENGTH', `x2') define(`DATA', `x3') define(`POLY', `v0') define(`ZERO', `v1') define(`D', `v2') define(`C0', `v3') define(`C0D', `d3') define(`C1', `v4') define(`C2', `v5') define(`C3', `v6') define(`RP', `v7') define(`H', `v16') define(`H_t', `v17') define(`H2', `v18') define(`H2_t', `v19') define(`H3', `v20') define(`H3_t', `v21') define(`H4', `v22') define(`H4_t', `v23') define(`H_m', `v24') define(`H_m1', `v25') define(`H_h', `v26') define(`H_l', `v27') define(`H_m2', `v28') define(`H_m3', `v29') define(`H_h2', `v30') define(`H_l2', `v31') define(`Ml', `v4') define(`Mh', `v5') C void gcm_hash (const struct gcm_key *key, union gcm_block *x, C size_t length, const uint8_t *data) PROLOGUE(_nettle_gcm_hash) mov x10,#0xC200000000000000 mov POLY.d[0],x10 dup POLY.2d,POLY.d[0] eor ZERO.16b,ZERO.16b,ZERO.16b ld1 {D.16b},[X] rev64 D.16b,D.16b ands x10,LENGTH,#-64 b.eq L2x add x9,TABLE,64 ld1 {H.16b,H_t.16b,H2.16b,H2_t.16b},[TABLE] ld1 {H3.16b,H3_t.16b,H4.16b,H4_t.16b},[x9] L4x_loop: ld1 {C0.16b,C1.16b,C2.16b,C3.16b},[DATA],#64 rev64 C0.16b,C0.16b rev64 C1.16b,C1.16b rev64 C2.16b,C2.16b rev64 C3.16b,C3.16b eor C0.16b,C0.16b,D.16b pmull H_m.1q,C1.1d,H3_t.1d pmull2 H_m1.1q,C1.2d,H3_t.2d pmull H_h.1q,C1.1d,H3.1d pmull2 H_l.1q,C1.2d,H3.2d pmull H_m2.1q,C2.1d,H2_t.1d pmull2 H_m3.1q,C2.2d,H2_t.2d pmull H_h2.1q,C2.1d,H2.1d pmull2 H_l2.1q,C2.2d,H2.2d eor H_m.16b,H_m.16b,H_m2.16b eor H_m1.16b,H_m1.16b,H_m3.16b eor H_h.16b,H_h.16b,H_h2.16b eor H_l.16b,H_l.16b,H_l2.16b pmull H_m2.1q,C3.1d,H_t.1d pmull2 H_m3.1q,C3.2d,H_t.2d pmull H_h2.1q,C3.1d,H.1d pmull2 H_l2.1q,C3.2d,H.2d eor H_m.16b,H_m.16b,H_m2.16b eor H_m1.16b,H_m1.16b,H_m3.16b eor H_h.16b,H_h.16b,H_h2.16b eor H_l.16b,H_l.16b,H_l2.16b pmull H_m2.1q,C0.1d,H4_t.1d pmull2 H_m3.1q,C0.2d,H4_t.2d pmull H_h2.1q,C0.1d,H4.1d pmull2 H_l2.1q,C0.2d,H4.2d eor H_m.16b,H_m.16b,H_m2.16b eor H_m1.16b,H_m1.16b,H_m3.16b eor H_h.16b,H_h.16b,H_h2.16b eor H_l.16b,H_l.16b,H_l2.16b eor H_m.16b,H_m.16b,H_m1.16b pmull RP.1q,H_l.1d,POLY.1d ext Ml.16b,ZERO.16b,H_m.16b,#8 ext Mh.16b,H_m.16b,ZERO.16b,#8 ext RP.16b,RP.16b,RP.16b,#8 eor H_l.16b,H_l.16b,Ml.16b eor H_h.16b,H_h.16b,Mh.16b eor H_l.16b,H_l.16b,RP.16b pmull2 RP.1q,H_l.2d,POLY.2d eor H_h.16b,H_h.16b,H_l.16b eor D.16b,H_h.16b,RP.16b ext D.16b,D.16b,D.16b,#8 subs x10,x10,64 b.ne L4x_loop and LENGTH,LENGTH,#63 L2x: tst LENGTH,#-32 b.eq L1x ld1 {H.16b,H_t.16b,H2.16b,H2_t.16b},[TABLE] ld1 {C0.16b,C1.16b},[DATA],#32 rev64 C0.16b,C0.16b rev64 C1.16b,C1.16b eor C0.16b,C0.16b,D.16b pmull H_m.1q,C1.1d,H_t.1d pmull2 H_m1.1q,C1.2d,H_t.2d pmull H_h.1q,C1.1d,H.1d pmull2 H_l.1q,C1.2d,H.2d pmull H_m2.1q,C0.1d,H2_t.1d pmull2 H_m3.1q,C0.2d,H2_t.2d pmull H_h2.1q,C0.1d,H2.1d pmull2 H_l2.1q,C0.2d,H2.2d eor H_m.16b,H_m.16b,H_m2.16b eor H_m1.16b,H_m1.16b,H_m3.16b eor H_h.16b,H_h.16b,H_h2.16b eor H_l.16b,H_l.16b,H_l2.16b eor H_m.16b,H_m.16b,H_m1.16b pmull RP.1q,H_l.1d,POLY.1d ext Ml.16b,ZERO.16b,H_m.16b,#8 ext Mh.16b,H_m.16b,ZERO.16b,#8 ext RP.16b,RP.16b,RP.16b,#8 eor H_l.16b,H_l.16b,Ml.16b eor H_h.16b,H_h.16b,Mh.16b eor H_l.16b,H_l.16b,RP.16b pmull2 RP.1q,H_l.2d,POLY.2d eor H_h.16b,H_h.16b,H_l.16b eor D.16b,H_h.16b,RP.16b ext D.16b,D.16b,D.16b,#8 and LENGTH,LENGTH,#31 L1x: tst LENGTH,#-16 b.eq Lmod ld1 {H.16b,H_t.16b},[TABLE] ld1 {C0.16b},[DATA],#16 rev64 C0.16b,C0.16b eor C0.16b,C0.16b,D.16b pmull H_m.1q,C0.1d,H_t.1d pmull2 H_m1.1q,C0.2d,H_t.2d pmull H_h.1q,C0.1d,H.1d pmull2 H_l.1q,C0.2d,H.2d eor H_m.16b,H_m.16b,H_m1.16b pmull RP.1q,H_l.1d,POLY.1d ext Ml.16b,ZERO.16b,H_m.16b,#8 ext Mh.16b,H_m.16b,ZERO.16b,#8 ext RP.16b,RP.16b,RP.16b,#8 eor H_l.16b,H_l.16b,Ml.16b eor H_h.16b,H_h.16b,Mh.16b eor H_l.16b,H_l.16b,RP.16b pmull2 RP.1q,H_l.2d,POLY.2d eor H_h.16b,H_h.16b,H_l.16b eor D.16b,H_h.16b,RP.16b ext D.16b,D.16b,D.16b,#8 Lmod: tst LENGTH,#15 b.eq Ldone ld1 {H.16b,H_t.16b},[TABLE] tbz LENGTH,3,Lmod_8 ldr C0D,[DATA],#8 rev64 C0.16b,C0.16b mov x10,#0 mov C0.d[1],x10 Lmod_8: tst LENGTH,#7 b.eq Lmod_8_done mov x9,#0 mov x8,#64 and x7,LENGTH,#7 Lmod_8_loop: mov x10,#0 ldrb w10,[DATA],#1 sub x8,x8,#8 lsl x10,x10,x8 orr x9,x9,x10 subs x7,x7,#1 b.ne Lmod_8_loop tbz LENGTH,3,Lmod_8_load mov C0.d[1],x9 b Lmod_8_done Lmod_8_load: mov x10,#0 mov C0.d[0],x9 mov C0.d[1],x10 Lmod_8_done: eor C0.16b,C0.16b,D.16b pmull H_m.1q,C0.1d,H_t.1d pmull2 H_m1.1q,C0.2d,H_t.2d pmull H_h.1q,C0.1d,H.1d pmull2 H_l.1q,C0.2d,H.2d eor H_m.16b,H_m.16b,H_m1.16b pmull RP.1q,H_l.1d,POLY.1d ext Ml.16b,ZERO.16b,H_m.16b,#8 ext Mh.16b,H_m.16b,ZERO.16b,#8 ext RP.16b,RP.16b,RP.16b,#8 eor H_l.16b,H_l.16b,Ml.16b eor H_h.16b,H_h.16b,Mh.16b eor H_l.16b,H_l.16b,RP.16b pmull2 RP.1q,H_l.2d,POLY.2d eor H_h.16b,H_h.16b,H_l.16b eor D.16b,H_h.16b,RP.16b ext D.16b,D.16b,D.16b,#8 Ldone: rev64 D.16b,D.16b st1 {D.16b},[X] ret EPILOGUE(_nettle_gcm_hash)

6 62

Add pbkdf2_hmac_sha384 and pbkdf2_hmac_sha512 to Nettle
by Nicolas Mora 01 Feb '21

01 Feb '21

Hello, I just opened a merge request [1] to add pbkdf2_hmac_sha384 and pbkdf2_hmac_sha512 to the Nettle library. These pbkdf2 functions are required to implement pbes2-* key management algorithms defined in the JSON Web Encryption (JWE) and JSON Web Algorithms (JWA) specifications [2], [3]. I added the new pbkdf2 functions, one test case per function, based on the same key derivation as the pbkdf2_hmac_sha256 test case. I also updated the documentation. Is it possible to get a code review for this patch? Thanks in advance /Nicolas [1] https://git.lysator.liu.se/nettle/nettle/-/merge_requests/18 [2] https://tools.ietf.org/html/rfc7516 [3] https://tools.ietf.org/html/rfc7518

2 1

← Newer
1
...
7
8
9
10
11
12
13
...
220
Older →

Jump to page:

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