| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
| |
Use PowerPC unaligned loads and stores with Power8. Formerly we were using Power7 as the floor because the IBM POWER Architecture manuals said unaligned loads and stores were available. However, some compilers generate bad code for unaligned loads and stores using `-march=power7`, so bump to a known good.
|
| |
|
| |
|
|
|
|
| |
We don't know what we are supposed to do at the moment. We need the CFRG or IETF to say what is supposed to happen.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Unfortunately the block counter wrap problem is still present.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Rounds are alwys 20 in the IETF implementation.
|
| |
|
|
|
|
| |
We tweaked ChaCha to arrive at the IETF's implementation specified by RFC 7539. We are not sure how to handle block counter wrap. At the moment the caller is responsible for managing it. We were not able to find a reference implementation so we disable SIMD implementations like SSE, AVX, NEON and Power4. We need the wide block tests for corner cases to ensure our implementation is correct.
|
| |
|
|
|
|
|
| |
The CORE function provides the implementation for ChaCha_OperateKeystream_ALTIVEC, ChaCha_OperateKeystream_POWER7, BLAKE2_Compress32_ALTIVEC and BLAKE2_Compress32_POWER7. Depending on the options used to compile the source files, either POWER7 or ALTIVEC will be used.
This is needed to support the "new toolchain, ancient hardware" use case.
|
|
|
|
|
| |
This is kind of tricky. We automatically drop from POWER7 to POWER4 if 7 is notavailable. However, if POWER7 is available the runtime test checks for HasAltivec(), and not HasPower7(), if the drop does not occur.
All of this goodness is happening on an old Apple G4 laptop with Gentoo. It is a "new toolchain on old hardware".
|
|
|
|
| |
The way the existing ppc_simd.h is written makes it hard to to switch between the old Altivec loads and stores and the new POWER7 loads and stores. This checkin rewrites the wrappers to use _ALTIVEC_, _ARCH_PWR7 and _ARCH_PWR8. The wrappers in this file now honor -maltivec, -mcpu-power7 and -mcpu=power8. It allows users to compile a source file, like chacha_simd.cpp, with a lower ISA and things just work for them.
|
|
|
|
| |
This costs about 0.6 cpb (700 MB/s on GCC112), but it makes the faster algorithm available to more machines. In the future we may want to provide both POWER7 and POWER8
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
This is only a work-around for the moment. The issue only affects SIMD code. The problem is, the algorithm we use performs a 32-bit add as an intermediate result, but we really need a 64-bit add. We are running 4 transforms in parallel, and we can't add and carry the way we need to.
The workaround is, whenever we could cross the 32-bit counter boundary we use the C version of the transform. We determine the cross-over point by 'bool safe = 0xffffffff - state.low > 4'. When not safe we skip the SIMD version of the algorithm and use the C version. Once we are safe again we use the SIMD version again.
The work-around costs us about 0.1 to 0.2 cpb. At 1.10 or 1.15 cpb that equates to about 200 MB/s on a Skylake. We'd like to get it back eventually.
|
| |
|
|
|
|
| |
We can use the input pointer directly after checking KeystreamOperation
|
| |
|
| |
|
| |
|
|
|
|
| |
This change obtains the remaining 0.1 to 0.15 cpb. It should be engaged with -march=native
|
|
|
|
| |
This picks up about 0.2 cpb in ChaCha::OperateKeystream. It may not sound like much but it puts SSE2 intrinsics version on par with the ASM version of Salsa20. Salsa20 leads ChaCha by 0.1 to 0.15 cpb, which equates to about 50 MB/s.
|
| |
|
| |
|
|
|
|
| |
This should have been done at 916c4484a270
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
This broke at https://github.com/weidai11/cryptopp/commit/e2be0cdecce7
|
| |
|
|
|
|
| |
These changes made it in by accident at Commit b74a6f444568. We were going to try to let them ride but they broke versioning. They may be added later but we should avoid the change at this time.
|
| |
|
|
|
|
| |
This will help Clang and its need for a constexpr
|
|
|
|
| |
Currently the CRYPTOPP_BOOL_XXX macros set the macro value to 0 or 1. If we remove setting the 0 value (the #else part of the expression), then the self tests speed up by about 0.3 seconds. I can't explain it, but I have observed it repeatedly.
This check-in prepares for the removal in Upstream master
|
|
|
|
| |
Similar text may be added in the future
|
|
|
|
| |
Also see https://github.com/weidai11/cryptopp/commit/399a1546de71f41598c15edada28e7f0d616f541#commitcomment-19448453
|
|
|
|
| |
behavior pivots on CRYPTOPP_DEBUG, and not NDEBUG (Issue 277, CVE-2016-7420)
|
|
|
|
| |
trap.h and CRYPTOPP_ASSERT has existed for over a year in Master. We deferred on the cut-over waiting for a minor version bump (5.7). We have to use it now due to CVE-2016-7420
|
| |
|