`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.
Conflicts:
src/clang.zig
Master branch renamed an enum; this branch gave it an explicit tag type
and explicitly initialized values. This commit combines the changes
together.
until https://github.com/ziglang/zig/issues/6168 is implemented,
partially revert 0bd53dd2033c60d3446abfb83209237c6eb6c9e2
in order to restore the ability to use std.math in comptime functions.
Conflicts:
cmake/Findllvm.cmake
The llvm11 branch changed 10's to 11's and master branch added the
"using LLVM_CONFIG_EXE" help message, so the resolution was to merge
these changes together.
I also added a check to make sure LLVM is built with AVR enabled, which
is no longer an experimental target.
* std.fs.File.copyRange and copyRangeAll return u64 instead of usize -
the returned value is how much of the `len` is transferred, so the
types should match. This removes the need for an `@intCast`.
* fix typo that removed a subtraction
* Fix the size of codegen.AnyMCValue which gave me a compile error when
I tried to build self-hosted for i386-linux.
* restore the coercion to u64 of syms_sect.sh_info. We want to make
sure the multiplication happens with 64 bits and not the smaller type
used by the ELF format.
* fix another offset parameter in link/Elf.zig to be u64 instead of usize
* add a nice little TODO note to help out Jakub
* FmtError already has FileTooBig in it; we just need to return it.
