Add pbkdf2_hmac_sha384 and pbkdf2_hmac_sha512 to Nettle
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 OpenPGP_signature Description: OpenPGP digital signature ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [AArch64] Optimize GHASH
Hello Niels, > I think this would be more user-friendle without the "a", > --enable-armv8-crypto, or --enable-arm64-crypto. Or do you foresee any > collision with an incompatible ARMv8-M crypto extension or the like? FWIW, I like --enable-arm64-crypto because it would nicely match with a directory arm64/crypto for the source and the idea of enabling the crypto extension for the arm64 target of nettle and be in line with --enable-arm-neon and arm/neon as well. > > +aarch64*) > > + if test "$enable_armv8_a_crypto" = yes ; then > > +if test "$ABI" = 64 ; then > > + CFLAGS="$CFLAGS -Wa,-march=armv8-a+crypto" > (This looks slightly different after merging all the changes). > I think it's unfortunate to have to modify CFLAGS, and in particular > using compiler-specific options. Is there any way to use a pseudoop in > the .asm file instead, similar to the .fpu neon used in the arm/neon/ > files? With binutils gas, both .arch and .arch_extension seem to do what you describe. Based on when they appeared in the manual, both are supported in gas since 2.26[4]. I've done a quick test with 2.35.1. I have successfully tried both .arch armv8-a+crypto (the -a is required here, otherwise errors are still thrown for uses of pmull with just armv8 or armv8-r) and .arch_extension crypto The testsuite still runs with both on LE and BE cross-compiled and run under qemu-user. binutils 2.26 also know the crypto extension name and were released January 2016. aarch64 support seems to have been introduced in 2.23 (October 2012) and with 2.25 (July 2015) the crypto flag to the -march command line option was added. (All based on when it appeared in the documentation.) So we'd likely have a dependency on 2.25 by using the -march option already and 2.26 wouldn't be a big step. [4] https://sourceware.org/binutils/docs-2.26/as/AArch64-Directives.html All this is gas-specific though, I would assume. Some discussion of compatible extensions to llvm-as seems to have happened in 2018 but I have not researched what came out of it[5]. The recent date and that it's the first search hit and no others link to documentation or such doesn't bode well IMO. It might as well be that llvm-as just knows the pmull instruction and assembles it fine but can't check if the target CPU will be able to run it. [5] https://lists.llvm.org/pipermail/llvm-dev/2018-September/126346.html What other assemblers for aarch64 do you have in mind? -- Thanks, Michael ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [AArch64] Optimize GHASH
Michael Weiser writes: > Subject: [PATCH 1/4] Mamone's unmodified patch Hi, I've merged this, but I have a couple of comments and questions. > --- a/Makefile.in > +++ b/Makefile.in > @@ -616,6 +616,7 @@ distdir: $(DISTFILES) > set -e; for d in sparc32 sparc64 x86 \ > x86_64 x86_64/aesni x86_64/sha_ni x86_64/fat \ > arm arm/neon arm/v6 arm/fat \ > + arm64 arm64/v8 \ Why the name "v8" for the directory, aren't arm64 and v8 more or less synonyms? I think it would make more sense with a name connected to the extension needed for the pmull instructions. > --- /dev/null > +++ b/arm64/v8/gcm-hash.asm > @@ -0,0 +1,343 @@ > +C common macros: > +.macro PMUL in, param1, param2 > +pmull F.1q,\param2\().1d,\in\().1d > +pmull2 F1.1q,\param2\().2d,\in\().2d > +pmull R.1q,\param1\().1d,\in\().1d > +pmull2 R1.1q,\param1\().2d,\in\().2d > +eorF.16b,F.16b,F1.16b > +eorR.16b,R.16b,R1.16b > +.endm For consistency, I'd prefer defining all needed macros using m4. > --- a/configure.ac > +++ b/configure.ac > @@ -81,6 +81,10 @@ AC_ARG_ENABLE(arm-neon, >AC_HELP_STRING([--enable-arm-neon], [Enable ARM Neon assembly. > (default=auto)]),, >[enable_arm_neon=auto]) > > +AC_ARG_ENABLE(armv8-a-crypto, > + AC_HELP_STRING([--enable-armv8-a-crypto], [Enable Armv8-A Crypto > extension. (default=no)]),, > + [enable_armv8_a_crypto=no]) I think this would be more user-friendle without the "a", --enable-armv8-crypto, or --enable-arm64-crypto. Or do you foresee any collision with an incompatible ARMv8-M crypto extension or the like? > +aarch64*) > + if test "$enable_armv8_a_crypto" = yes ; then > +if test "$ABI" = 64 ; then > + CFLAGS="$CFLAGS -Wa,-march=armv8-a+crypto" (This looks slightly different after merging all the changes). I think it's unfortunate to have to modify CFLAGS, and in particular using compiler-specific options. Is there any way to use a pseudoop in the .asm file instead, similar to the .fpu neon used in the arm/neon/ files? One could also consider introducing a separate ASMFLAGS make variable (suggested earlier by Jeffrey Walton, for other reasons). Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [AArch64] Optimize GHASH
Maamoun TK writes: > This is a new patch to fix the clang build if "armv8-a-crypto" is enabled > and should be applied on top of the previous patches. Thanks, merged all the changes to the arm64 branch. Let me know if there's anything I missed. I have a few comments on the main patch, I'll write that in a separate mail. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
