Patch implementation benchmark for GCM_AES (Tested on POWER8):
little-endian:
- Encrypt x~17.5 of nettle C implementation
- Decrypt x~17.5 of nettle C implementation
- Update x~30 of nettle C implementation
big-endian:
- Encrypt x~18.5 of nettle C implementation
- Decrypt x~18.5 of nettle C impleme
Maamoun TK writes:
> Is nettle-dev:ppe64el installed in the image?
> If not installed, there is no point in removing it.
There was a loop over all archs. But I guess I should just remove ppc64
from that list. I was a bit in a hurry to get something working.
> I have no experience modifying buil
On Tue, Jun 30, 2020 at 5:14 AM Maamoun TK wrote:
>
> Patch implementation benchmark for GCM_AES (Tested on POWER8):
> little-endian:
> - Encrypt x~17.5 of nettle C implementation
> - Decrypt x~17.5 of nettle C implementation
> - Update x~30 of nettle C implementation
> big-endian:
> - Encrypt x~1
On Tue, Jun 30, 2020 at 5:29 AM Jeffrey Walton wrote:
>
> On Tue, Jun 30, 2020 at 5:14 AM Maamoun TK wrote:
> >
> > Patch implementation benchmark for GCM_AES (Tested on POWER8):
> > little-endian:
> > - Encrypt x~17.5 of nettle C implementation
> > - Decrypt x~17.5 of nettle C implementation
> >
Dmitry Baryshkov writes:
> I wouldn't call it legacy (since it is an actual standard). What about
> adding the "Other hash functions" section? It can further receive
> algorithms such as SM3 (if somebody submits it)?
I've now committed your docs, in a "Miscellaneous hash functions"
section.
Tha
Hello,
вт, 30 июн. 2020 г. в 14:04, Niels Möller :
>
> Dmitry Baryshkov writes:
>
> > I wouldn't call it legacy (since it is an actual standard). What about
> > adding the "Other hash functions" section? It can further receive
> > algorithms such as SM3 (if somebody submits it)?
>
> I've now comm
On Tue, Jun 30, 2020 at 12:29 PM Jeffrey Walton wrote:
One small comment for aes_encrypt and aes_decrypt... src and dst are
> usually user supplied buffers. Using lxvd2x to load a vector may
> produce incorrect results if the user is feeding a stream to an
> encryptor or decryptor that is not nat
I tested something similar, I tried to load data at address 0xXXX1
using lxvd2x and it loaded it properly.
On Tue, Jun 30, 2020 at 12:35 PM Jeffrey Walton wrote:
> On Tue, Jun 30, 2020 at 5:29 AM Jeffrey Walton wrote:
> >
> > On Tue, Jun 30, 2020 at 5:14 AM Maamoun TK
> wrote:
> > >
> > >
On Tue, Jun 30, 2020 at 12:26 PM Niels Möller wrote:
> Does that mean that explicitly
> setting QEMU_LD_PREFIX is needed only for ppc64 (big-endian), but not
> for ppc64el?
>
It's needed for both, I just give ppc64 as an example.
___
nettle-bugs maili
Maamoun TK writes:
> It's needed for both, I just give ppc64 as an example.
I see.
And I just pushed the change to enable big-endian too.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
__
"Stephen R. van den Berg" writes:
> Fix examples in the docs relative to v4.2.
Thanks.
I've now merged this (squashed together with part 2/3) to the bcrypt
branch in the repository. Before merging to master, I'd need some basic
tests for the testsuite, preferably based on authoritative test vec
Maamoun TK writes:
> --- a/asm.m4
> +++ b/asm.m4
> @@ -30,13 +30,26 @@ COFF_STYLE, yes,
> define(,<>)dnl
>
> define(,
> + <.globl C_NAME($1)
> DECLARE_FUNC(C_NAME($1))
> -C_NAME($1): ASM_X86_ENDBR>)
> +C_NAME($1): ASM_X86_ENDBR>,
> +<.globl C_NAME($1)
> +DECLARE_FUNC(C_NAME($1))
> +.section "
On Tue, Jun 30, 2020 at 7:55 AM Maamoun TK wrote:
>
> I tested something similar, I tried to load data at address 0xXXX1
> using lxvd2x and it loaded it properly.
I think you should reconsider.
Consider, even Andy Polyakov uses lvx/lvsl when loading [potentially]
unaligned buffers on POWER8:
From POWER ISA 2.07 B:
- Load Vector Indexed X-form
lvx VRT,RA,RB
.
.
VRT ← MEM(EA & 0x___FFF0, 16)
- Load VSX Vector Doubleword*2 Indexed XX1-form
lxvd2x XT,RA,RB
.
.
VSR[XT]{0:63} ← MEM(EA,8)
VSR[XT]{64:127} ← MEM(EA+8,8)
lxvd2x doesn't set the least significant 4-bit of effective a
On Tue, Jun 30, 2020 at 11:06 PM Niels Möller wrote:
Can you explain a bit more what's special with the powerpc64 prologue
> and epilogue? What are the .C_NAME($1) symbols?
This is ELFv1 ABI stuff that is still required to get the function working
for PowerPC64 big-endian systems. PowerPC64 litt
15 matches
Mail list logo