| Age | Commit message (Collapse) | Author |
|---|
|
The buffer descriptor is a local variable and no buffer data is changed, so
there is nothing to restore before returning
|
|
|
|
A random splay time of up to 5 minutes will ensure that simultaneous handshakes
with many peers are desynchronized as fast as possible.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This gives AES128 a slight boost on my system, but it is still slower than
XSalsa20... I should probably write userspace code that can make use of AES-NI
and CLMUL. Or directly jump to the kernel space with the whole forwarding code.
Nevertheless, this might run nicely on Geode CPUs and similar hardware with AES
acceleration, at least if the context switches aren't too expensive...
|
|
This doesn't really improve performance on my Intel CPU (I guess due to the
context switches), but more tests have to be made, in combination with
offloading the AES to the kernel as well, and on different hardware.
|
|
These changes improve the performance of the AES128-GCM method by ~10% on my
Intel CPU when compiled with -O2.
Furthermore, the AES and the GHASH parts are separated now, allowing to switch
to other implementations of the algorithms more easily.
|
|
There were several bugs in the code that were severely lowering the expected
security and completely breaking compatiblity with alternative implementations.
The fixed version is checked against the test vectors specified in [1], and
should thus be correct.
[1] http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/gcm/gcm-revised-spec.pdf
|
|
|
|
|
|
|
|
|
