| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |
|
| |
| |
| |
| |
| | |
This allows us to do changes to the kernel configuration using menuconfig
and friends, and update the kernel with make-testing.
|
| |
| |
| |
| |
| |
| | |
This allows us to do modifications to the kernel tree and rebuild that kernel
using make-testing. We can even have a git kernel tree in a directory to
do kernel development.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
It uses the ChaCha20Poly1305 test vectors from
draft-ietf-ipsecme-chacha20-poly1305-06.
|
| | |
|
| |
| |
| |
| |
| | |
For some plugin features, such as crypters or AEADs, we have some additional
feature arguments, such as the key size.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| | |
As we don't have to shuffle the state in each ChaCha round, overall performance
for ChaCha20-Poly1305 increases by ~40%.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| | |
This allows us to include compiler flags specific for them, such as MMX/SSE.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As it turns out, getpwnam_r, getgrnam_r, and friends will return
ERANGE if _any_ user or group on the system is larger than will fit
into the scratch buffer you pass to them.
This reworks the resolve_uid and resolve_gid methods plus
init_supplementary_groups to use a variable-size buffer that is grown
until the results fit.
Based on a patch by Evan Broder.
Closes strongswan/strongswan#12.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Was added in bc4748832395 ("Add a return value to prf_t.get_bytes()").
|
|
|
|
|
| |
The header file was created in the source directory before, where it
wasn't found by the generated C files in the build directory.
|
|
|
|
|
|
| |
Fixes the build on FreeBSD.
Fixes #988.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
authentication
Previously the constraints in the authentication configuration of an
initiator were enforced only after all authentication rounds were
complete. This posed a problem if an initiator used EAP or PSK
authentication while the responder was authenticated with a certificate
and if a rogue server was able to authenticate itself with a valid
certificate issued by any CA the initiator trusted.
Because any constraints for the responder's identity (rightid) or other
aspects of the authentication (e.g. rightca) the initiator had were not
enforced until the initiator itself finished its authentication such a rogue
responder was able to acquire usernames and password hashes from the client.
And if a client supported EAP-GTC it was even possible to trick it into
sending plaintext passwords.
This patch enforces the configured constraints right after the responder's
authentication successfully finished for each round and before the initiator
starts with its own authentication.
Fixes CVE-2015-4171.
|
|
|
|
|
|
|
| |
Global reqid allocation (94eb09ac) broke fixed reqid allocation. Resupport them
by bypassing allocation in the kernel if a fixed reqid has been configured.
Fixes #976.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We use the message ID and fragment number as IV generator. As IKEv2 uses
distinct message ID counters for actively and passively initiated exchanges,
each IV would be used twice. As we explicitly reject such message IDs since
d0ed1079, original-responder initiated exchanges fail with counter mode ciphers.
This commit separates IV space in two halves for sequential IVs, and
automatically assigns once reused sequence numbers to the second half.
Fixes #980.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
This fixes a DoS and potential remote code execution vulnerability that was
caused because the original payload type that was returned previously was
used to cast such payload objects to payloads of the indicated type (e.g.
when logging notify payloads with a payload type for the wrong IKE version).
Fixes CVE-2015-3991.
|
|
|
|
|
|
| |
When using a cipher with sequential IVs, we never must pass an identical IV
to the IV generator. To avoid it when using IKEv2 fragmentation, use the lower
bits of the 64-bit message ID as the fragment number.
|
|
|
|
|
| |
While no algorithm actually uses such short IVs, we add a check here to ensure
we won't return just the lower bits of the counter.
|
|
|
|
| |
We allow gaps in IVs, but ensure that an IV is never used more than once.
|
| |
|
| |
|
| |
|