Gives a ~40% speedup on x86_64.
However, the generic code remains faster on aarch64.
This is still processing only one block at a time for now.
I'm pretty confident that processing more blocks per round
will eventually give a substantial performance improvement on
all platforms with vector units.
The bcrypt function intentionally requires quite a lot of CPU cycles
to complete.
In addition to that, not having its full state constantly in the
CPU L1 cache causes a massive performance drop.
These properties slow down brute-force attacks against low-entropy
inputs (typically passwords), and GPU-based attacks get little
to no advantages over CPUs.
The NaCl constructions are available in pretty much all programming
languages, making them a solid choice for applications that require
interoperability.
Go includes them in the standard library, JavaScript has the popular
tweetnacl.js module, and reimplementations and ports of TweetNaCl
have been made everywhere.
Zig has almost everything that NaCl has at this point, the main
missing component being the Salsa20 cipher, on top on which NaCl's
secretboxes, boxes, and sealedboxes can be implemented.
So, here they are!
And clean the X25519 API up a little bit by the way.
of https://github.com/BarabasGitHub/zig into
BarabasGitHub-improve-windows-networking
Conflicts:
lib/std/os.zig
This commit resolves conflicts with the changes to std.os which removed
the EAGAIN error handling interactions with the event loop. The solution
to the conflict was to apply EAGAIN => return error.WouldBlock into the
improved windows networking branch.
The fix for #6715 introduced a new compiler error when attempting to use
wWinMain as the application entry-point.
The Windows API often relies on implicit casts between signed and
unsigned variables. In this case, wWinMain returns an INT despite the
fact this value is intended to feed into ExitProcess, which expects a
UINT, so I've restored the bitcast from #5613.
Calling @panic made the executable ~30x times bigger, use a simple
`abort()` and let the user figure out what went wrong.
Supporting ARMv6 (and earlier?) platforms is not a priority.
Closes#6676
* Smaller startup sequence for ppc64
* Terminate the frame-pointer chain when executing _start
* Make the stack traces work on ppc64
* Make the stack traces coloured on ppc64, some ioctls numbers are
different and the whole set of constants should be audited.
mimics the duplication of strings in `Builder` for `Pkg`. This
ensures the lifetime of the memory backing strings in a `Pkg`
struct and the `Pkg.dependencies` slice is not shorter than the
`Builder` that the data is associated with.
The new defaults that came in with
644400054c are nice, however, it is still
possible that someone knows their inputs are always small and wants to
use the simpler implementations. We keep the default to make the choice
at runtime, but expose the linear functions in the public interface of
std.mem.
Also improved the doc comments.
- use `PascalCase` for all types. So, AES256GCM is now Aes256Gcm.
- consistently use `_length` instead of mixing `_size` and `_length` for the
constants we expose
- Use `minimum_key_length` when it represents an actual minimum length.
Otherwise, use `key_length`.
- Require output buffers (for ciphertexts, macs, hashes) to be of the right
size, not at least of that size in some functions, and the exact size elsewhere.
- Use a `_bits` suffix instead of `_length` when a size is represented as a
number of bits to avoid confusion.
- Functions returning a constant-sized slice are now defined as a slice instead
of a pointer + a runtime assertion. This is the case for most hash functions.
- Use `camelCase` for all functions instead of `snake_case`.
No functional changes, but these are breaking API changes.
Žiga Željko