aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
| * crypto-factory: Add enumerator method to support individual transform testingMartin Willi2015-04-152-0/+127
| |
| * unit-tests: Invoke all registered thread cleanup handlers on test failureMartin Willi2015-04-151-0/+3
| | | | | | | | | | | | | | | | | | | | | | If a test fails in a timeout or a test failure, longjmp() is used to restore the thread context and handle test failure. However, there might be unreleased resources, namely locks, which prevent the library to clean up properly after finishing the test. By using thread cleanup handlers, we can release any test subject internal or test specific external resources on test failure. We do so by calling all registered cleanup handlers.
| * thread: Add a function to pop and call all registered cleanup handlersMartin Willi2015-04-154-0/+78
| |
| * thread: Don't acquire lock for thread_cleanup_push/popMartin Willi2015-04-151-5/+0
| | | | | | | | | | This is called only by the thread for its own thread_t, and does not need synchronization.
| * travis: Run a gcrypt test with leak-detectiveMartin Willi2015-04-152-5/+1
| | | | | | | | And also enable gcrypt in the all tests with leak-detective enabled.
| * gcrypt: Explicitly initialize RNG backend to allocate static dataMartin Willi2015-04-151-0/+3
| | | | | | | | | | | | The libgcrypt RNG implementation uses static buffer allocation which it does not free. There is no symbol we can catch in leak-detective, hence we explicitly initialize the RNG during the whitelisted gcrypt_plugin_create() function.
| * leak-detective: Whitelist gcrypt_plugin_create()Martin Willi2015-04-151-0/+1
| | | | | | | | | | | | gcry_check_version() does not free statically allocated resources. However, we can't whitelist it in some versions, as it is not a resolvable symbol name. Instead, whitelist our own plugin constructor function.
| * unit-tests: Add a TESTS_PLUGINS environment variableMartin Willi2015-04-152-1/+6
| | | | | | | | This is often more convenient than specifying plugins in a configuration file.
| * unit-tests: Use a larger timeout for test vector testingMartin Willi2015-04-151-0/+1
| | | | | | | | | | As we test DH calculations this now takes more time. If multiple DH backends are enabled, we likely hit the default test timeout.
| * gcrypt: Support setting private value and testing of DH backendMartin Willi2015-04-151-0/+19
| |
| * openssl: Support setting ECDH private valuesMartin Willi2015-04-151-0/+44
| |
| * openssl: Support setting private Diffie-Hellman valuesMartin Willi2015-04-151-0/+13
| |
| * gmp: Support setting Diffie-Hellman private valuesMartin Willi2015-04-151-0/+10
| |
| * test-vectors: Add DH vectors for Brainpool groupsMartin Willi2015-04-153-0/+118
| |
| * test-vectors: Add DH vectors for ECDH groupsMartin Willi2015-04-153-0/+140
| |
| * test-vectors: Add DH vectors for subgroup MODP groupsMartin Willi2015-04-153-0/+168
| |
| * test-vectors: Add DH vectors for normal MODP groupsMartin Willi2015-04-153-0/+741
| |
| * test-vectors: Support testing DH groupsMartin Willi2015-04-151-1/+16
| |
| * crypto-tester: Support testing DH groups using DH test vectorsMartin Willi2015-04-153-2/+224
| |
| * diffie-hellman: Introduce an optional setter for the private valueMartin Willi2015-04-151-0/+12
|/ | | | This allows us to work with deterministic values for testing purposes.
* Merge branch 'aesni'Martin Willi2015-04-1532-104/+5891
|\ | | | | | | | | Add an aesni plugin providing CBC, CTR, XCBC, CMAC, CCM and GCM modes for for AES-128/192/256 based on AES-NI/PCLMULQDQ intrinsics.
| * NEWS: Add aesni plugin newsMartin Willi2015-04-151-0/+6
| |
| * aesni: Avoid loading AES/GHASH round keys into local variablesMartin Willi2015-04-156-1568/+1244
| | | | | | | | | | | | | | | | | | | | The performance impact is not measurable, as the compiler loads these variables in xmm registers in unrolled loops anyway. However, we avoid loading these sensitive keys onto the stack. This happens for larger key schedules, where the register count is insufficient. If that key material is not on the stack, we can avoid to wipe it explicitly after crypto operations.
| * aesni: Align all class instances to 16 byte boundariesMartin Willi2015-04-157-14/+14
| | | | | | | | | | | | While the required members are aligned in the struct as required, on 32-bit platforms the allocator aligns the structures itself to 8 bytes only. This results in non-aligned struct members, and invalid memory accesses.
| * utils: Provide aligning variants of INIT/INIT_EXTRA macrosMartin Willi2015-04-151-0/+29
| |
| * unit-tests: Pass stringyfied assertion statement as non-format string argumentMartin Willi2015-04-151-3/+3
| | | | | | | | | | | | If the assertion contains a modulo (%) operation, test_fail_msg() handles this as printf() format specifier. Pass the assertion string as argument for an explicit "%s" in the format string, instead.
| * utils: Add malloc/free wrappers returning aligned dataMartin Willi2015-04-153-0/+101
| | | | | | | | | | | | | | | | | | | | | | | | | | While we could use posix_memalign(3), that is not fully portable. Further, it might be difficult on some platforms to properly catch it in leak-detective, which results in invalid free()s when releasing such memory. We instead use a simple wrapper, which allocates larger data, and saves the padding size in the allocated header. This requires that memory is released using a dedicated function. To reduce the risk of invalid free() when working on corrupted data, we fill up all the padding with the padding length, and verify it during free_align().
| * aesni: Calculate GHASH for 4 blocks of associated data in parallelMartin Willi2015-04-151-2/+18
| | | | | | | | | | While associated data is usually not that large, in some specific cases this can bring a significant performance boost.
| * aesni: Calculate GHASH for 4 blocks of encryption data in parallelMartin Willi2015-04-151-40/+180
| | | | | | | | Increases performance by another ~30%.
| * aesni: Use 4-way parallel en/decryption in GCMMartin Willi2015-04-151-132/+635
| | | | | | | | Increases overall performance by ~25%.
| * aesni: Use dedicated key size specific en-/decryption functions in GCMMartin Willi2015-04-151-24/+353
| | | | | | | | | | This gives not much more than ~5% increase in performance, but allows us to improve further.
| * aesni: Add a GCM AEAD based on the AES-NI key scheduleMartin Willi2015-04-154-1/+627
| |
| * aesni: Implement CMAC mode to provide a signer/prfMartin Willi2015-04-154-0/+441
| | | | | | | | | | Compared to the cmac plugin using AESNI-CBC as backend, this improves performance of AES-CMAC by ~45%.
| * aesni: Implement XCBC mode to provide a signer/prfMartin Willi2015-04-154-0/+436
| | | | | | | | | | Compared to the xcbc plugin using AESNI-CBC as backend, this improves performance of AES-XCBC by ~45%.
| * aesni: Partially use separate code paths for different key sizes in CCMMartin Willi2015-04-151-33/+438
| | | | | | | | Due to the serial nature of the CBC mac, this brings only a marginal speedup.
| * aesni: Add a CCM AEAD reusing the key scheduleMartin Willi2015-04-154-0/+645
| |
| * aesni: Use 4-way parallel AES-NI instructions for CTR en/decryptionMartin Willi2015-04-151-115/+354
| | | | | | | | | | | | | | CTR can be parallelized, and we do so by queueing instructions to the processor pipeline. While we have enough registers for 128-bit decryption, the register count is insufficient to hold all variables with larger key sizes. Nonetheless is 4-way parallelism faster, depending on key size between ~10% and ~25%.
| * aesni: Use dedicated round count specific encryption functions in CTR modeMartin Willi2015-04-151-23/+243
| | | | | | | | | | This allows us to unroll loops and hold the key schedule in local (register) variables. This brings an impressive speedup of ~45%.
| * aesni: Implement a AES-NI based CTR crypter using the key scheduleMartin Willi2015-04-154-0/+278
| |
| * aesni: Use 4-way parallel AES-NI instructions for CBC decryptionMartin Willi2015-04-151-66/+314
| | | | | | | | | | | | | | CBC decryption can be parallelized, and we do so by queueing instructions to the processor pipeline. While we have enough registers for 128-bit decryption, the register count is insufficient to hold all variables with larger key sizes. Nonetheless is 4-way parallelism faster, roughly by ~8%.
| * aesni: Use separate en-/decryption CBC code paths for different key sizesMartin Willi2015-04-151-22/+290
| | | | | | | | | | | | This allows us to unroll loops, and use local (register) variables for the key schedule. This improves performance slightly for encryption, but a lot for reorderable decryption (>30%).
| * aesni: Implement a AES-NI based CBC crypter using the key scheduleMartin Willi2015-04-154-0/+293
| |
| * aesni: Implement 256-bit key scheduleMartin Willi2015-04-151-0/+77
| |
| * aesni: Implement 192-bit key scheduleMartin Willi2015-04-151-0/+81
| |
| * aesni: Implement 128-bit key scheduleMartin Willi2015-04-151-0/+45
| |
| * aesni: Add a common key schedule class for AESMartin Willi2015-04-153-0/+165
| |
| * aesni: Provide a plugin stub for AES-NI instruction based crypto primitivesMartin Willi2015-04-155-0/+152
| |
| * utils: Provide an INIT_EXTRA() macro, that allocates extra data to INIT()Martin Willi2015-04-151-0/+15
| |
| * test-vectors: Add some self-made additional AES-GCM test vectorsMartin Willi2015-04-152-0/+157
| | | | | | | | | | We missed test vectors for 192/256-bit key vectors for ICV8/12, and should also have some for larger associated data chunk.
| * test-vectors: Define some additional CCM test vectorsMartin Willi2015-04-152-1/+84
| | | | | | | | | | | | We don't have any where plain or associated data is not a multiple of the block size, but it is likely to find bugs here. Also, we miss some ICV12 test vectors using 128- and 192-bit key sizes.
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-11 16:56:05 +0000