dot-asm / cryptogams

CRYPTOGAMS distribution repository

CRYPTOGAMS distribution repository. As for issues. It's unclear line between which issues are considered common, common with OpenSSL that is, and which are specific to this distribition repository. Thing is that common issues should rather be handled as OpenSSL ones. For this reason I reserve the right to close problem reports with resolution "to be taken through OpenSSL channels." Feature requests can be reported as issues. Pull requests will be [currently] ignored.

Common usage pattern is to invoke script and pass "flavour" and output file name as command line arguments. "Flavour" refers to ABI family or specfic OS. E.g. x86_64 scripts recognize 'elf', 'elf32', 'macosx', 'mingw64', 'nasm'. PPC scripts recognize 'linux32', 'linux64', 'linux64le', 'aix32', 'aix64', 'osx32', 'osx64'. And so on... Some x86_64 scripts even examine CC environment variable in order to determine if AVX code path should be generated. ["AVX" refers to all AVX versions.]

See https://www.openssl.org/~appro/cryptogams/ for background information.

cryptogams's Issues

add cpu detection code

it looks like you wrote the cpu detection code in openssl. It would be nice if that stuff (which is important for using these routines) was here, so the license was clearer.

Questions about powerpc implementation of Poly1305

Hi Andy (@dot-asm),

I have been looking at your implementation of Poly1305 for PowerPC [0] and have a few questions.

1. How does your general purpose facility implementation of Poly1305 add the secret key to the accumulator as suggested by the pseudocode “a += s” in the IETF protocols [1]?
2. Is the s1 register variable used to perform the modulo operation as suggested by the pseudocode “(r * a) % p” in the IETF protocols [1]?
3. What is the purpose of the poly1305_emit label?
   a) The name suggests that it is to produce the output of the poly1305 algorithm. However, it is unclear to me the purpose of the base2_26 notations in the poly1305_emit label.
4. How do the operations performed by the __poly1305_mul label that is used by the __poly1305_blocks_vsx label differ from the operations performed by the Loop label that is used by the Lpoly1305_blocks label?
   a) It seems to me that the operations are very similar and that there is little use of the vector facilities.
5. Can Poly1305 algorithm be accelerated by using the vector facility?
   a) The loop part of the algorithm is dependent on the accumulator value of the previous loop, so I am not sure if Poly1305 can be accelerated by using the vector facility. This would suggest why the operations for the Loop label and the __poly1305_mul label are similar.

References:
0: https://github.com/openssl/openssl/blob/master/crypto/poly1305/asm/poly1305-ppc.pl
1: https://datatracker.ietf.org/doc/html/rfc8439#section-2.5.1

Could I retake the license of aesv8-armx.pl as GPL license

I want to port aesv8-armx.pl into linux kernel. Could I retake the license to GPL v2 license or dual license?

I failed to contact Andy from openssl community. So I come to here.

Add some benchmark programs.

It would nice to be able to do this without openssl.

Add chacha20 to the repository

Hello, I'm using openssl chacha20 code as the base for my contribution to the Go Lang project. Since it's licensed as Cryptogams, can you please add it to the repository?

[1] https://go-review.googlesource.com/c/crypto/+/108999

Missing bug fix in aesp8-ppc

openssl/openssl@f643dea

MinGW cross-compilation fails due to .size/.type directives

Building for Win64, I get:

$ CC="x86_64-w64-mingw32-gcc" /usr/bin/perl ../aesni/aesni-x86_64.pl | sed s/OPENSSL_ia32/OPENCONNECT_ia32/g > aesni-x86_64.s
$ x86_64-w64-mingw32-gcc  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -c -o aesni-x86_64.o aesni-x86_64.s
aesni-x86_64.s: Assembler messages:
aesni-x86_64.s:4: Warning: .type pseudo-op used outside of .def/.endef: ignored.
aesni-x86_64.s:4: Error: junk at end of line, first unrecognized character is `a'
aesni-x86_64.s:27: Warning: .size pseudo-op used outside of .def/.endef: ignored.
aesni-x86_64.s:27: Error: junk at end of line, first unrecognized character is `a'
…

ppc8 does not build on powerpc64 big-endian while openssl version works fine

built with perl aesp8.pl ppc64

hmm.S: Assembler messages:
hmm.S:471: Error: invalid conditional option
hmm.S:1206: Error: invalid conditional option
hmm.S:1835: Error: invalid conditional option
hmm.S:2046: Error: invalid conditional option

Performance regression in SHA1

I updated to the latest Cryptogams code, from whatever I'd lifted from OpenSSL last time I was playing with this:
https://gitlab.com/openconnect/openconnect/-/commit/4abf01865dea0feb43c328c3a5311533fca8640f

The update reduces the performance of the stitched AES+SHA1 encryption code by about 10%, and decryption by even more.

Ryzen 5

• Before:

$ tests/esptest ; tests/esptest  ; tests/esptest  ; tests/esptest
CPU capabilities: 078bffff 7ed8320b 209c01a9 00000000
Encrypted 4580535 packets in 5s (5130 Mb/s)
Encrypted+decrypted 2446172 packets in 5s (2739 Mb/s)
CPU capabilities: 078bffff 7ed8320b 209c01a9 00000000
Encrypted 4553131 packets in 5s (5099 Mb/s)
Encrypted+decrypted 2500763 packets in 5s (2800 Mb/s)
CPU capabilities: 078bffff 7ed8320b 209c01a9 00000000
Encrypted 4537943 packets in 5s (5082 Mb/s)
Encrypted+decrypted 2460366 packets in 5s (2755 Mb/s)
CPU capabilities: 078bffff 7ed8320b 209c01a9 00000000
Encrypted 4530504 packets in 5s (5074 Mb/s)
Encrypted+decrypted 2500993 packets in 5s (2801 Mb/s)

• After:

CPU capabilities: 078bffff 7ed8320b 209c01a9 00000000
Encrypted 3920203 packets in 5s (4390 Mb/s)
Encrypted+decrypted 1384902 packets in 5s (1551 Mb/s)
CPU capabilities: 078bffff 7ed8320b 209c01a9 00000000
Encrypted 3833687 packets in 5s (4293 Mb/s)
Encrypted+decrypted 1404777 packets in 5s (1573 Mb/s)
CPU capabilities: 078bffff 7ed8320b 209c01a9 00000000
Encrypted 3922032 packets in 5s (4392 Mb/s)
Encrypted+decrypted 1415149 packets in 5s (1584 Mb/s)
CPU capabilities: 078bffff 7ed8320b 209c01a9 00000000
Encrypted 3889960 packets in 5s (4356 Mb/s)
Encrypted+decrypted 1414968 packets in 5s (1584 Mb/s)

Haswell Xeon

• Before:

$ tests/esptest ; tests/esptest  ; tests/esptest  ; tests/esptest 
CPU capabilities: ffebffff 7ffef3ff 000037ab 00000000
Encrypted 2346782 packets in 5s (2628 Mb/s)
Encrypted+decrypted 1265742 packets in 5s (1417 Mb/s)
CPU capabilities: ffebffff 7ffef3ff 000037ab 00000000
Encrypted 2377519 packets in 5s (2662 Mb/s)
Encrypted+decrypted 1265845 packets in 5s (1417 Mb/s)
CPU capabilities: ffebffff 7ffef3ff 000037ab 00000000
Encrypted 2371691 packets in 5s (2656 Mb/s)
Encrypted+decrypted 1265596 packets in 5s (1417 Mb/s)
CPU capabilities: ffebffff 7ffef3ff 000037ab 00000000
Encrypted 2406201 packets in 5s (2694 Mb/s)
Encrypted+decrypted 1263781 packets in 5s (1415 Mb/s)

• After:

$ tests/esptest ; tests/esptest  ; tests/esptest  ; tests/esptest 
CPU capabilities: ffebffff 7ffef3ff 000037ab 00000000
Encrypted 2193897 packets in 5s (2457 Mb/s)
Encrypted+decrypted 952022 packets in 5s (1066 Mb/s)
CPU capabilities: ffebffff 7ffef3ff 000037ab 00000000
Encrypted 2269787 packets in 5s (2542 Mb/s)
Encrypted+decrypted 951414 packets in 5s (1065 Mb/s)
CPU capabilities: ffebffff 7ffef3ff 000037ab 00000000
Encrypted 2243736 packets in 5s (2512 Mb/s)
Encrypted+decrypted 951446 packets in 5s (1065 Mb/s)
CPU capabilities: ffebffff 7ffef3ff 000037ab 00000000
Encrypted 2238346 packets in 5s (2506 Mb/s)
Encrypted+decrypted 949672 packets in 5s (1063 Mb/s)

The test case is part of the OpenConnect test suite in my 'hacks2' branch which (currently) contains the commit linked above.

GPL license is ambiguous

To date, there are three versions of GNU GPL license, each differing from the other. It would be great to see GPL version number in the license of the code to unambiguously know what are the permissions for (re)use.

Missing files and patches present in OpenSSL

I want to enable Intel CET in GnuTLS, which uses the CRYPTOGAMS implementation. Comparing the code in this repository with the code available in OpenSSL, there are missing patches (specially those from @hjl-tools enabling Intel CET) and missing files.

The CRYPTOGAMS code present in OpenSSL states that it is double licensed under CRYPTOGAMS and OpenSSL, but the license that applies depends on where the code is obtained from.

GnuTLS uses the CRYPTOGAMS implementation and claims to use the code under BSD 3-clause license, but obtains it from the OpenSSL repository.

Trying to fix this by obtaining the code directly from this repository, I found the following missing files which are present in OpenSSL repository, but not in this repository:

• openssl/crypto/modes/asm/aesni-gcm-x86_64.pl
• openssl/engines/asm/e_padlock-x86_64.pl
• openssl/engines/asm/e_padlock-x86.pl
• openssl/crypto/modes/asm/ghashv8-armx.pl
• openssl/crypto/modes/asm/ghash-x86_64.pl
• openssl/crypto/modes/asm/ghash-x86.pl
• openssl/crypto/sha/asm/sha512-armv8.pl
• openssl/crypto/sha/asm/sha256-586.pl
• openssl/crypto/sha/asm/sha512-armv8.pl
• openssl/crypto/sha/asm/sha512-586.pl

GnuTLS also uses the following file which is not double licensed:

• openssl/crypto/sha/asm/sha512-x86_64.pl

Would it be possible to add the missing code and patches to this repository?