Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
code that might cause unaligned access errors on architectures that care (e.g. Android/ARM)
|
|
issue. Also update Salsa20 comments and clean up a bit.
|
|
If this works we should find a define that can be used to enable it there since it will slow things down on non-x86 other architectures.
|
|
much on newer chips.
|
|
intrinsics in Visual Studio
|
|
|
|
encrypt and decrypt. Profiling analysis found that Salsa20 encrypt was accounting for a nontrivial percentage of CPU time, so it makes sense to cut this load fundamentally. There are no published attacks against Salsa20/12, and DJB believes 20 rounds to be overkill. This should be more than enough for our needs. Obviously incorporating ASM Salsa20 is among the next steps for performance.
|
|
(1) Probable fix for issue #7 and major cleanup of EthernetTap code with consolidation for all unix-like systems and specialization for different flavors only when needed.
(2) Refactor of Buffer<> to make its members private, and Packet to use Buffer's methods exclusively to access them. This improves clarity and means we're no longer lying about Buffer's role in the code's security posture.
(3) Add -fstack-protect to Makefile to bounds check stack variables.
|
|
|