| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
| |
This commit adds dynamic dispatch to LSH. The implementation pivots on AVX2 and SSSE3.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Calls to `MASM_RDSEED_GenerateBlock` would hang for an unknown reasons on Windows 10 and VS2017/VS2019 toolchains. Similar calls to `MASM_RDRAND_GenerateBlock` worked as expected. They were effectively the same code. The only differences were the function names and the opcodes (they were literally copy/paste).
Splitting `rdrand.asm` (with both `RDRAND` and `RDSEED`) into `rdrand.asm` (with `RDRAND`) and `rdseed.asm` (with `RDSEED`) resolved the issue. We don't know why.
|
|
|
|
| |
This broke SunCC to the point of no repair. SunCC is using AVX2 instructions for C++ and SSE2. Man this compiler sucks...
|
|
|
|
| |
We did some refactoring and added sse_simd.h. Over time more SSE functions will likely move into sse_simd.h
|
| |
|
| |
|
| |
|
|
|
| |
Use carryless multiplies for NIST b233 and k233 curves.
|
|
|
| |
Add ed25519
|
| |
|
|
|
|
| |
Moon's code is very fast. In fact it is so fast it broke our benchmarks. Moon's code registers 0.00 milliseconds and 0.00 megacycles/operation.
|
| |
|
|
|
|
| |
This adds the missing changes to the Windows source files
|
| |
|
|
|
|
| |
Also see https://groups.google.com/forum/#!topic/cryptopp-users/HBz-6gZZFOA on the mailing list
|
| |
|
|
|
|
|
|
| |
GH #731)
The split was required for Blake2b and Power8; Blake2s only requires Power7
|
|
|
|
|
|
|
|
| |
Thanks to Jack Lloyd and Botan for allowing us to use the implementation.
The numbers for SSE2 are very good. When compared with Salsa20 ASM the results are:
* Salsa20 2.55 cpb; ChaCha/20 2.90 cpb
* Salsa20/12 1.61 cpb; ChaCha/12 1.90 cpb
* Salsa20/8 1.34 cpb; ChaCha/8 1.5 cpb
|
| |
|
|
|
| |
Also see https://groups.google.com/forum/#!topic/cryptopp-users/5btwLoxXXD4.
|
|
|
|
| |
SIMON-64 and SIMON-128 have different ISA requirements. The same applies to SPECK-64 and SPECK-128. GCC generated code that resulted in a SIGILL due to the ISA differences on a down level machine. The instructions was a mtfprwz from POWER8. It was prsent in a function prologue on a POWER7 machine.
|
|
|
|
| |
Thanks to Markku-Juhani Olavi Saarinen for the code. Also see https://github.com/mjosaarinen/sm4ni
|
| |
|
| |
|
| |
|
| |
|
|
|
| |
Add Simeck lightweight block cipher (GH #675)
|
| |
|
|
|
|
| |
LEA-128(128) from 6.73 cpb to 2.84 cpb on modern Core-i5 6400. LEA-128 from 10.12 cpb to 7.84 cpb antique Core2 Duo.
|
|
|
|
| |
CHAM-128(128) from 10.5 cpb to 4.1 cpb. CHAM-128(256) from 12.5 cpb to 4.7 cpb.
|
|
|
| |
Add CHAM lightweight block cipher
|
| |
|
| |
|
| |
|
|
|
|
| |
This commit re-adds Simon and Speck. The commit includes C++, SSSE3 and SSE4. NEON, Aarch32 and Aarch64 are disabled at the moment.
|
|
|
|
|
|
| |
We recently learned our Simon and Speck implementation was wrong. The removal will stop harm until we can loop back and fix the issue.
The issue is, the paper, the test vectors and the ref-impl do not align. Each produces slightly different result. We followed the test vectors but they turned out to be wrong for the ciphers.
We have one kernel test vector but we don't have a working implementation to observe it to fix our implementation. Ugh...
|
|
|
|
| |
This should avoid confusion with header files from the reference implementation and libsodium
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TweetNaCl is a compact reimplementation of the NaCl library by Daniel J. Bernstein, Bernard van Gastel, Wesley Janssen, Tanja Lange, Peter Schwabe and Sjaak Smetsers. The library is less than 20 KB in size and provides 25 of the NaCl library functions.
The compact library uses curve25519, XSalsa20, Poly1305 and SHA-512 as default primitives, and includes both x25519 key exchange and ed25519 signatures. The complete list of functions can be found in TweetNaCl: A crypto library in 100 tweets (20140917), Table 1, page 5.
Crypto++ retained the function names and signatures but switched to data types provided by <stdint.h> to promote interoperability with Crypto++ and avoid size problems on platforms like Cygwin. For example, NaCl typdef'd u64 as an unsigned long long, but Cygwin, MinGW and MSYS are LP64 systems (not LLP64 systems). In addition, Crypto++ was missing NaCl's signed 64-bit integer i64.
Crypto++ enforces the 0-key restriction due to small points. The TweetNaCl library allowed the 0-keys to small points. Also see RFC 7748, Elliptic Curves for Security, Section 6.
TweetNaCl is well written but not well optimized. It runs 2x to 3x slower than optimized routines from libsodium. However, the library is still 2x to 4x faster than the algorithms NaCl was designed to replace.
The Crypto++ wrapper for TweetNaCl requires OS features. That is, NO_OS_DEPENDENCE cannot be defined. It is due to TweetNaCl's internal function randombytes. Crypto++ used DefaultAutoSeededRNG within randombytes, so OS integration must be enabled. You can use another generator like RDRAND to avoid the restriction.
|
|
|
|
| |
This also fixes the SPECK64 bug where CTR mode self tests fail. It was an odd failure because it only affected 64-bit SPECK. SIMON was fine and it used nearly the same code. We tracked it down through trial and error to the table based rotates.
|
| |
|
|
|
|
| |
Performance increased by about 200% on a 980 MHz BananaPi dev-board. Throughput went from about 176.6 cpb to about 60.3 cpb.
|
| |
|
| |
|
|
|
|
| |
Cleaned up whitespace
|