Unlike glibc and musl, MinGW provides no libssp symbols leading to
countless compile errors if FORTIFY_SOURCE is defined.
Add a (incomplete) implementation of libssp written in Zig so that
linking succeeds.
Closes#6492
* remove GetModuleHandleA from kernel32.zig. use of A functions
considered harmful.
* make it a compile error to expose WinMain instead of wWinMain. same
thing.
* start code declares wWinMainCRTStartup instead of WinMainCRTStartup
when it has the choice.
`DefaultCsprng` is documented as a cryptographically secure RNG.
While `ISAAC` is a CSPRNG, the variant we have, `ISAAC64` is not.
A 64 bit seed is a bit small to satisfy that claim.
We also saw it being used with the current date as a seed, that
also defeats the point of a CSPRNG.
Set `DefaultCsprng` to `Gimli` instead of `ISAAC64`, rename
the parameter from `init_s` to `secret_seed` + add a comment to
clarify what kind of seed is expected here.
Instead of directly touching the internals of the Gimli implementation
(which can change/be architecture-specific), add an `init()` function
to the state.
Our Gimli-based CSPRNG was also not backtracking resistant. Gimli
is a permutation; it can be reverted. So, if the state was ever leaked,
future secrets, but also all the previously generated ones could be
recovered. Clear the rate after a squeeze in order to prevent this.
Finally, a dumb test was added just to exercise `DefaultCsprng` since
we don't use it anywhere.
HMAC is a generic construction, so we allow it to be instantiated
with any hash function.
In practice, HMAC is almost exclusively used with MD5, SHA1 and SHA2,
so it makes sense to define some shortcuts for them.
However, defining `HmacBlake2s256` is a bit weird (and why
specifically that one, and not other hash functions we also support?).
There would be nothing wrong with that construction, but it's not
used in any standard protocol and would be a curious choice.
BLAKE2 being a keyed hash function, it doesn't need HMAC to be used as
a MAC, so that also doesn't make it a good example of a possible hash
function for HMAC.
This commit doesn't remove the ability to use a Hmac(Blake2s256) type
if, for some reason, applications really need this, but it removes
HmacBlake2s256 as a constant.
* std.Target.standardDynamicLinkerPath: macOS has a dynamic linker
* no need to override the default dynamic linker in the macos
CrossTarget initialization in the tests
* in getExternalExecutor, when validating the dynamic linker path, take
into account the standard dynamic linker path.
This commit enables stage2 end-to-end tests to run natively on macOS
(where and when applicable). Since QEMU on macOS doesn't support
the same type of architecture emulation as it does on linux (i.e.,
there is no `qemu-x86_64` for instance), this commit ensures that we
specify a path to dynamic linker on macOS (`/usr/lib/dyld`) which
is then checked for existence in `std.CrossTarget.getExternalExecutor()`
function, and if exists, we can run the test natively.
Signed-off-by: Jakub Konka <kubkon@jakubkonka.com>
This is slightly slower but makes our verification function compatible
with batch signatures. Which, in turn, makes blockchain people happy.
And we want to make our users happy.
Add convenience functions to substract edwards25519 points and to
clear the cofactor.
Brings a 30% speed boost on x86_64 even though we still process only
one block at a time for now.
Only enabled on x86_64 since the non-vectorized implementation seems
to currently perform better on some architectures (at least on aarch64).
But the non-vectorized implementation still gets a little speed boost
as well (~17%) with these changes.
* Add an optimized squaring routine under the `sqr` name.
Algorithms for squaring bigger numbers efficiently will come in a
PR later.
* Fix a bug where a multiplication was done twice if the threshold for
the use of Karatsuba algorithm was crossed. Add a test to make sure
this won't happen again.
* Streamline `pow` method, take a `Const` parameter.
* Minor tweaks to `pow`, avoid bit-reversing the exponent.
* std.fs.Dir.readFile: add doc comments to explain what it means when
the returned slice has the same length as the supplied buffer.
* introduce readSmallFile / writeSmallFile to abstract over the
decision to use symlink or file contents to store data.
