aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
| * 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.
| * crypto-tester: Use the plugin feature key size to benchmark crypters/aeadsMartin Willi2015-04-154-21/+29
| | | | | | | | | | | | We previously didn't pass the key size during algorithm registration, but this resulted in benchmarking with the "default" key size the crypter uses when passing 0 as key size.
| * crypt-burn: Support burning signersMartin Willi2015-04-151-0/+53
| |
| * crypt-burn: Add a encryption buffer command line argumentMartin Willi2015-04-151-9/+14
| |
| * crypt-burn: Set a defined key, as some backends require thatMartin Willi2015-04-151-4/+10
| |
| * crypt-burn: Refactor to separate burn methodsMartin Willi2015-04-151-74/+116
| |
| * crypt-burn: Accept a PLUGINS env var to configure plugins to loadMartin Willi2015-04-151-3/+2
|/
* vici: Relicense libvici.h under MITMartin Willi2015-04-141-9/+20
| | | | | | libvici currently relies on libstrongswan, and therefore is bound to the GPLv2. But to allow alternatively licensed reimplementations without copyleft based on the same interface, we liberate the header.
* utils: Define MAX_(U)INT_TYPE to the maximum size integer type availableMartin Willi2015-04-141-0/+6
|
* utils: Typedef int128_t and u_int128_t types if supportedMartin Willi2015-04-141-0/+11
|
* configure: Check for __int128 type supportMartin Willi2015-04-141-0/+11
|
* Merge branch 'const-memeq'Martin Willi2015-04-1442-61/+580
|\ | | | | | | | | Introduce constant time memory comparing functions for cryptographic purposes, and a tool to test such functions or crypto transforms relying on them.
| * utils: Use chunk_equals_const() for all cryptographic purposesMartin Willi2015-04-1423-38/+33
| |
| * utils: Add a constant time chunk_equals() variant for cryptographic purposesMartin Willi2015-04-143-1/+87
| |
| * utils: Use memeq_const() for all cryptographic purposesMartin Willi2015-04-1412-22/+14
| |
| * utils: Add a constant time memeq() variant for cryptographic purposesMartin Willi2015-04-144-1/+79
| |
| * scripts: Add a tool that tries to guess MAC/ICV values using validation timesMartin Willi2015-04-143-1/+369
|/ | | | | | | | | | | | | | | | | | | This tool shows that it is trivial to re-construct the value memcmp() compares against by just measuring the time the non-time-constant memcmp() requires to fail. It also shows that even when running without any network latencies it gets very difficult to reconstruct MAC/ICV values, as the time variances due to the crypto routines are large enough that it gets difficult to measure the time that memcmp() actually requires after computing the MAC. However, the faster/time constant an algorithm is, the more likely is a successful attack. When using AES-NI, it is possible to reconstruct (parts of) a valid MAC with this tool, for example with AES-GCM. While this is all theoretical, and way more difficult to exploit with network jitter, it nonetheless shows that we should replace any use of memcmp/memeq() with a constant-time alternative in all sensitive places.
* Merge branch 'cpu-features'Martin Willi2015-04-136-134/+244
|\ | | | | | | | | Centralize all uses of CPUID to a cpu_feature class, which in theory can support optional features of non-x86/x64 as well using architecture specific code.
| * rdrand: Reuse CPU feature detection to check for RDRAND instructionsMartin Willi2015-04-131-51/+4
| |
| * padlock: Reuse common CPU feature detection to check for Padlock featuresMartin Willi2015-04-131-80/+17
| |
| * cpu-feature: Support Via Padlock security featuresMartin Willi2015-04-132-0/+56
| |
| * cpu-feature: Add a common class to query available CPU featuresMartin Willi2015-04-134-3/+167
|/ | | | Currently supported is x86/x64 via cpuid() for some common features.
* sqlite: Use our locking mechanism also when sqlite3_threadsafe() returns 0Martin Willi2015-04-131-7/+20
| | | | | | We previously checked for older library versions without locking support at all. But newer libraries can be built in single-threading mode as well, where we have to care about the locking.
* sqlite: Show SQLite library version and thread safety flag during startupMartin Willi2015-04-131-1/+8
|
* vici: Defer read/write error reporting after connection entry has been releasedMartin Willi2015-04-131-12/+34
| | | | | | | | | | | | | | | | If a vici client registered for (control-)log events, but a vici read/write operation fails, this may result in a deadlock. The attempt to write to the bus results in a vici log message, which in turn tries to acquire the lock for the entry currently held. While a recursive lock could help as well for a single thread, there is still a risk of inter-thread races if there is more than one thread listening for events and/or having read/write errors. We instead log to a local buffer, and write to the bus not before the connection entry has been released. Additionally, we mark the connection entry as unusable to avoid writing to the failed socket again, potentially triggering an error loop.
* aead: Create AEAD using traditional transforms with an explicit IV generatorMartin Willi2015-04-135-12/+34
| | | | | | Real AEADs directly provide a suitable IV generator, but traditional crypters do not. For some (stream) ciphers, we should use sequential IVs, for which we pass an appropriate generator to the AEAD wrapper.
* iv-gen: Add a generic constructor to create an IV gen from an algorithmMartin Willi2015-04-134-2/+71
|
* openssl: Don't pre-initialize OpenSSL HMAC with an empty keyMartin Willi2015-04-131-6/+16
| | | | | | | | | | With OpenSSL commit 929b0d70c19f60227f89fac63f22a21f21950823 setting an empty key fails if no previous key has been set on that HMAC. In 9138f49e we explicitly added the check we remove now, as HMAC_Update() might crash if HMAC_Init_ex() has not been called yet. To avoid that, we set and check a flag locally to let any get_mac() call fail if set_key() has not yet been called.
* thread: Remove unneeded thread startup synchronizationMartin Willi2015-04-131-13/+4
| | | | | | | | | | | sem_init() is deprecated on OS X, and it actually fails with ENOSYS. Using our wrapped semaphore object is not an option, as it relies on the thread cleanup that we can't rely on at this stage. It is unclear why startup synchronization is required, as we can allocate the thread ID just before creating the pthread. There is a chance that we allocate a thread ID for a thread that fails to create, but the risk and consequences are negligible.
* libsimaka: Link against Winsock2 on WindowsMartin Willi2015-04-131-0/+4
| | | | The library makes use of htons/ntohs().
* fips-prf: Remove superfluous <arpa/inet.h> includeMartin Willi2015-04-131-2/+0
| | | | | As we make no use of htonl() and friends, this is unneeded, but actually prevents a Windows build.
* kernel-netlink: Fix GCC error about uninitialized variable useMartin Willi2015-04-081-1/+1
| | | | | get_replay_state() always returns a replay_state_len when returning a replay state, but GCC doesn't know about that.
* asn1: Undefine TIME_UTC, which is used by C11Martin Willi2015-04-081-0/+4
| | | | | When building with C11 support, TIME_UTC is used for timespec_get() and defined in <time.h>. Undefine TIME_UTC for our own internal use in asn1.c.
* Wipe auxiliary key store5.3.0Andreas Steffen2015-03-281-1/+1
|
* crypto-tester: Explicitly exclude FIPS-PRF from append mode testsMartin Willi2015-03-281-8/+11
| | | | | This was implicitly done by the seed length check before 58dda5d6, but we now require an explicit check to avoid that unsupported use.
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-04 21:55:41 +0000