Xoroshiro128+ is the current default non-cryptographic random
number generator.
This algorithm was designed to generate floating-point numbers, by
only using the top 53 bits. Lower bits have a significant bias, that
contradicts the documented properties for `rand.DefaultPrng`. This
also has implications on everything using `Random.fill()`, including
the way we generate random floating-point numbers.
In addition, Xoroshiro128+ has known issues. See for example:
- https://lemire.me/blog/2017/08/22/cracking-random-number-generators-xoroshiro128/
- https://www.pcg-random.org/posts/xoroshiro-fails-truncated.html
Xoshiro256++ addresses these issues, while remaining very fast.
Conflicts:
* doc/langref.html.in
* lib/std/enums.zig
* lib/std/fmt.zig
* lib/std/hash/auto_hash.zig
* lib/std/math.zig
* lib/std/mem.zig
* lib/std/meta.zig
* test/behavior/alignof.zig
* test/behavior/bitcast.zig
* test/behavior/bugs/1421.zig
* test/behavior/cast.zig
* test/behavior/ptrcast.zig
* test/behavior/type_info.zig
* test/behavior/vector.zig
Master branch added `try` to a bunch of testing function calls, and some
lines also had changed how to refer to the native architecture and other
`@import("builtin")` stuff.
std.crypto.random
* cross platform, even freestanding
* can't fail. on initialization for some systems requires calling
os.getrandom(), in which case there are rare but theoretically
possible errors. The code panics in these cases, however the
application may choose to override the default seed function and then
handle the failure another way.
* thread-safe
* supports the full Random interface
* cryptographically secure
* no syscall required to initialize on Linux (AT_RANDOM)
* calls arc4random on systems that support it
`std.crypto.randomBytes` is removed in favor of `std.crypto.random.bytes`.
I moved some of the Random implementations into their own files in the
interest of organization.
stage2 no longer requires passing a RNG; instead it uses this API.
Closes#6704
`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.
Instead of having all primitives and constructions share the same namespace,
they are now organized by category and function family.
Types within the same category are expected to share the exact same API.
* Implements #3768. This is a sweeping breaking change that requires
many (trivial) edits to Zig source code. Array values no longer
coerced to slices; however one may use `&` to obtain a reference to
an array value, which may then be coerced to a slice.
* Adds `IrInstruction::dump`, for debugging purposes. It's useful to
call to inspect the instruction when debugging Zig IR.
* Fixes bugs with result location semantics. See the new behavior test
cases, and compile error test cases.
* Fixes bugs with `@typeInfo` not properly resolving const values.
* Behavior tests are passing but std lib tests are not yet. There
is more work to do before merging this branch.
