aboutsummaryrefslogtreecommitdiffstats
path: root/src/libstrongswan/plugins
Commit message (Collapse)AuthorAgeFilesLines
* plugin-loader: Optionally use RTLD_NOW with dlopen()Tobias Brunner2015-11-091-6/+11
| | | | | | | | | This can be useful when writing custom plugins as typos or missing linker flags that result in unresolved symbols in the shared object could otherwise cause late crashes. In particular, if such a symbol is used in a code path that is rarely executed. During development and testing using RTLD_NOW instead of RTLD_LAZY will prevent the plugin from getting loaded and makes the error visible immediately.
* Explicitly mention SHA2 algorithm in BLISS OIDs and signature schemesAndreas Steffen2015-11-065-19/+31
|
* Use word-aligned XOR in sha3_absorb()Andreas Steffen2015-11-031-4/+47
|
* Support BLISS signatures with SHA-3 hashAndreas Steffen2015-11-032-0/+12
|
* Implemented SHA-3 hash algorithm including test vectorsAndreas Steffen2015-11-038-0/+1022
|
* random: Properly handle errors when reading from /dev/[u]randomTobias Brunner2015-10-291-0/+1
| | | | | | | | If -1 was returned on the first call to read() `done` got SIZE_MAX and the function returned TRUE even though no actual random data had been allocated. Fixes #1156.
* openssl: Explicitly include openssl/bn.hTobias Brunner2015-09-165-0/+5
| | | | | | | | If OpenSSL is compiled with OPENSSL_NO_DEPRECATED some of the headers we include don't include openssl/bn.h anymore. Therefore, we have to explicitly include it ourselves where we use BN_* functions. Fixes #1113.
* Fixed some typos, courtesy of codespellTobias Brunner2015-08-271-1/+1
|
* Fix some Doxygen issuesTobias Brunner2015-08-271-1/+1
|
* plugin-feature: Add vendor specific EAP method registration macrosTobias Brunner2015-08-172-8/+18
| | | | | | | | | | | Vendor specific EAP methods may be registered with: PLUGIN_CALLBACK(eap_method_register, <constructor>), PLUGIN_PROVIDE(EAP_SERVER_VENDOR, <type>, <vendor>), Same for client implementations via EAP_PEER_VENDOR. References #969.
* Initialize variables that some compilers seem to warn aboutTobias Brunner2015-08-131-1/+1
|
* pkcs11: Fix encoding of RSA keys if unnecessarily zero prefixedTobias Brunner2015-08-061-3/+8
| | | | | | | | | | | | | | Some tokens/libraries seem to prefix all numbers with zero bytes even if not necessary (e.g. the default exponent 0x010001). If we don't fix that, the fingerprints calculated based on the retrieved values will be incorrect. Even if the pkcs1 plugin can properly handle numbers that are not in two's complement since a81bd670b086 ("Added PUBKEY_RSA_MODULUS encoding type") we prefix them with zero if necessary as other encoders might expect them in two's complement. Fixes #1012.
* Use MGF1 with SHA-512 as BLISS random oracleAndreas Steffen2015-07-274-72/+58
|
* Generalize c_indices generation using SHA-512 random oracle.Markku-Juhani Olavi Saarinen2015-07-271-18/+24
| | | | | | This generalization allows the ring dimension n to be different from the current n = 512 and allows kappa to be > 56. Also the hash octets are consumed in a more consistent manner.
* Fixed several bugs in the BLISS signature generation/verification step.Markku-Juhani Olavi Saarinen2015-07-271-4/+8
| | | | | | | | | | | | | | | | The c_indices derived from the SHA-512 random oracle consist of nine bits (0..511). The leftmost 8 bits of each index are taken on an octet-by-octet basis from the 56 leftmost octets of the SHA-512 hash. The 9th bit needed for the LSB is taken from the extra_bits 64 bit unsigned integer which consists of the 8 rightmost octets of the SHA-512 hash (in network order). If more than 56 indices must be derived then additional rounds of the random oracle are executed until all kappa c_indices have been determined. The bug fix shifts the extra_bits value by one bit in each loop iteration so that the LSB of each index is random. Also iterate through the hash array using the loop variable j not the c_indices variable i.
* chapoly: Process two Poly1305 blocks in parallel in SSSE3 driverMartin Willi2015-07-121-85/+291
| | | | | | | | | | By using a derived key r^2 we can improve performance, as we can do loop unrolling and slightly better utilize SIMD instructions. Overall ChaCha20-Poly1305 performance increases by ~12%. Converting integers to/from our 5-word representation in SSE does not seem to pay off, so we work on individual words.
* chapoly: Process four ChaCha20 blocks in parallel in SSSE3 driverMartin Willi2015-07-121-16/+207
| | | | | As we don't have to shuffle the state in each ChaCha round, overall performance for ChaCha20-Poly1305 increases by ~40%.
* chapoly: Add an SSSE3 based driverMartin Willi2015-06-294-1/+514
| | | | | | | | | | | | | We always build the driver on x86/x64, but enable it only if SSSE3 support is detected during runtime. Poly1305 uses parallel 32-bit multiplication operands yielding a 64-bit result, for which two can be done in parallel in SSE. This is minimally faster than multiplication with 64-bit operands, and also works on 32-bit builds not having a __int128 result type. On a 32-bit architecture, this is more than twice as fast as the portable driver, and on 64-bit it is ~30% faster.
* chapoly: Add a ChaCha20/Poly1305 driver implemented in portable CMartin Willi2015-06-294-0/+488
|
* chapoly: Provide a generic ChaCha20/Poly1305 AEAD supporting driver backendsMartin Willi2015-06-297-0/+672
|
* test-vectors: Add some initial ChaCha20/Poly1305 AEAD test vectorMartin Willi2015-06-293-0/+112
|
* openssl: Don't refer to EVP_des_ecb() if OpenSSL is built without DES supportTobias Brunner2015-04-171-0/+2
| | | | | | While DES-ECB is not registered by the plugin in this case (so the function will never actually be called), the compiler still warns about the implicitly declared function.
* test-vectors: Define test vector symbols as externMartin Willi2015-04-161-7/+7
| | | | | | We don't actually define a vector, but only prototype the test vector implemented in a different file. GCC uses the correct symbol during testing, but clang correctly complains about duplicated symbols during linking.
* aesni: Fix doxygen groupsMartin Willi2015-04-151-2/+2
|
* 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.
* 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
|
* 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.
* 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%).
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-11 04:22:46 +0000