nettle-bugs December 2020

nettle-bugs@lists.lysator.liu.se

8 participants
8 discussions

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

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

Release of Nettle-3.7?
by nisse＠lysator.liu.se 02 Jan '21

02 Jan '21

Hi, I wonder if it would make sense to try to cut a release pretty soon (and without any arm64 changes)? Previous release was made end of April, and there's been quite a few improvements since then. I wonder if it is possible to make a release in time for the upcoming debian release? https://lists.debian.org/debian-devel-announce/2020/11/msg00002.html Nettle-3.7 should be abi-compatible, and with unchanged soname, so I'm not sure if it would count as a "transition" in the debian world. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.

6 16

Failing gnutls tests
by nisse＠lysator.liu.se 28 Dec '20

28 Dec '20

Hi, recent gnutls tests on the gitlab ci system all fail the test "testpkcs11.sh". See e.g., https://gitlab.com/gnutls/nettle/-/jobs/932664781. First failure was an a merge commit with a minor ppc-related fix. And it looks like gnutls' own pipelines have been failing for a month or so too, see https://gitlab.com/gnutls/gnutls/-/pipelines. Any gnutls people on the list who could have a look? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.

3 3

Re: Release of Nettle-3.7?
by Maamoun TK 19 Dec '20

19 Dec '20

Hi Michael, On Fri, Dec 18, 2020 at 8:00 PM Michael Weiser <michael(a)weiser.dinsnail.net> wrote: > qemu-user works nicely for aarch64_be. I used it to semi-natively > compile a whole aarch64 userland. I could dust off pine64 board that is > running that userland now for real-world testing if you like. > Thank you, I will give qemu-user a shot for aarch64_be testing. Also, I will let you know if I reach a point where real-world testing is needed. regards, Mamone

1 0

PPC chacha
by nisse＠lysator.liu.se 02 Dec '20

02 Dec '20

I'm trying to learn a bit of ppc assembly. Below is an implementation of _chacha_core. Seems to work, when tested on gcc112.fsffrance.org (just put the file in the powerpc64 directory and reconfigure). This machine is little-endian, I haven't yet tested on big-endian. Unfortunately I don't get any accurate benchmark numbers on that machine, but I think speedup may be on the order of 50%. It could likely be speedup further by processing 2, 3 or 4 blocks in parallel, similar to recent improvements for arm and x86_64. I'd like to do that after the simpler single-block function is properly merged. I'm not sure where it fits under powerpc64. The code doesn't need any cryptographic extensions, but it depends on vector instructions as well as VSX registers (for the unaligned load and store instructions). So I'd need advice both on the directory hierarchy and compile time configuration, and appropriate runtime tests for fat builds. Comments on the code highly appreciated! It's the first ppc code I've written, and the reference manual isn't that easy to navigate. The vector instructions seem very nice to work with, and makes for a shorter QROUND than both x86_64 SSE and ARM Neon (these suffer a bit from missing vector rotate instruction). Help with additional benchmarking would also be useful. Regards, /Niels C powerpc64/chacha-core-internal.asm ifelse(` Copyright (C) 2020 Niels Möller and Torbjörn Granlund 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 Register usage: C Argments define(`DST', `r3') define(`SRC', `r4') define(`ROUNDS', `r5') C Working state define(`X0', `v0') define(`X1', `v1') define(`X2', `v2') define(`X3', `v3') define(`ROT16', `v4') define(`ROT12', `v5') define(`ROT8', `v6') define(`ROT7', `v7') C Original input state define(`S0', `v8') define(`S1', `v9') define(`S2', `v10') define(`S3', `v11') C QROUND(X0, X1, X2, X3) define(`QROUND', ` C x0 += x1, x3 ^= x0, x3 lrot 16 C x2 += x3, x1 ^= x2, x1 lrot 12 C x0 += x1, x3 ^= x0, x3 lrot 8 C x2 += x3, x1 ^= x2, x1 lrot 7 vadduwm $1, $1, $2 vxor $4, $4, $1 vrlw $4, $4, ROT16 vadduwm $3, $3, $4 vxor $2, $2, $3 vrlw $2, $2, ROT12 vadduwm $1, $1, $2 vxor $4, $4, $1 vrlw $4, $4, ROT8 vadduwm $3, $3, $4 vxor $2, $2, $3 vrlw $2, $2, ROT7 ') .text .align 4 C _chacha_core(uint32_t *dst, const uint32_t *src, unsigned rounds) PROLOGUE(_nettle_chacha_core) li r6, 0x10 C set up some... li r7, 0x20 C ...useful... li r8, 0x30 C ...offsets vspltisw ROT16, -16 C -16 instead of 16 actually works! vspltisw ROT12, 12 vspltisw ROT8, 8 vspltisw ROT7, 7 lxvw4x VSR(X0), 0, SRC lxvw4x VSR(X1), r6, SRC lxvw4x VSR(X2), r7, SRC lxvw4x VSR(X3), r8, SRC vor S0, X0, X0 vor S1, X1, X1 vor S2, X2, X2 vor S3, X3, X3 srdi ROUNDS, ROUNDS, 1 mtctr ROUNDS .Loop: QROUND(X0, X1, X2, X3) C Rotate rows, to get C 0 1 2 3 C 5 6 7 4 <<< 1 C 10 11 8 9 <<< 2 C 15 12 13 14 <<< 3 vsldoi X1, X1, X1, 4 vsldoi X2, X2, X2, 8 vsldoi X3, X3, X3, 12 QROUND(X0, X1, X2, X3) C Inverse rotation vsldoi X1, X1, X1, 12 vsldoi X2, X2, X2, 8 vsldoi X3, X3, X3, 4 bdnz .Loop vadduwm X0, X0, S0 vadduwm X1, X1, S1 vadduwm X2, X2, S2 vadduwm X3, X3, S3 stxvw4x VSR(X0), 0, DST stxvw4x VSR(X1), r6, DST stxvw4x VSR(X2), r7, DST stxvw4x VSR(X3), r8, DST blr EPILOGUE(_nettle_chacha_core) -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.

5 43

Fwd: [PowerPC] GCM optimization
by Maamoun TK 01 Dec '20

01 Dec '20

---------- Forwarded message --------- From: Maamoun TK <maamoun.tk(a)googlemail.com> Date: Thu, Nov 12, 2020 at 7:42 PM Subject: Re: [PowerPC] GCM optimization To: Niels Möller <nisse(a)lysator.liu.se> On Thu, Nov 12, 2020 at 6:40 PM Niels Möller <nisse(a)lysator.liu.se> wrote: > I gave it a test run on gcc112 in the gcc compile farm, and speedup of > gcm update seems to be 26 times(!) compared to the C version. > That's reasonable, I got similar speedup on more stable POWER instances than gcc compile farm. > Where would that documentation be published? In the Nettle manual, as > some IBM white paper, or as a more-or-less academic paper, e.g., on > arxiv? I will not be able to spend much time on writing, but I'd be > happy to review. > I'll start writing the papers once I got more details from IBM, similar to intel documents, the document will be academic and practical at the same time, I'll dive into finite field equations to demonstrate how we get there as well as I'll add a practical example to clarify the preference of this method in addition to the expected speedup of this method. My intention that other crypto libraries could take advantage of this document or maybe be a starting point for further improvements to the algorithm so I'm checking if IBM would publish or approve such a document the same as intel. > I have a sketch of ARM Neon code doing the equivalent of two vpmsumd, > with reasonable parallelism. Quite a lot of instructions needed. > If you don't have much time, you can send it here and I'll continue from that point. I'm planning to compare the new method with the usual method with and without the karatsuba algorithm. > +C Alignment of gcm_key table elements, which is declared in gcm.h > > +define(`TableElemAlign', `0x100') > > I still find this large constant puzzling. If I try > > struct gcm_key key; > printf("sizeof (key): %zd, sizeof(key.h[0]): %zd\n", sizeof(key), > sizeof(key.h[0])); > > (I added it to the start of test_main in gcm-test.c) and run on the > gcc112 machine, I get > > sizeof (key): 4096, sizeof(key.h[0]): 16 > > Which is what I'd expect, with elements of size 16 bytes, not 256 bytes. > > I haven't yet had the time to read the code carefully. > You see, the alignment of each element is 0x100 (256). The table has 16 elements and you got the size of the table 4096 which is reasonable because 16*256=4096 regards, Mamone

3 5

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 December 2020