Round numbers that were not a multiple of 3 caused an OOB.
Nothing in the standard library uses a number of round that is
not 12 or 24, and these are the only values used in current
specifications.
But we should be future proof and we already provide an API
that's expected to work with any number of rounds, so honor that.
Zig was the first programming language to ship with field arithmetic
generated by fiat-crypto.
This is great! But since then, two things happened:
- We manually modified the generated code to deal with changes in Zig
- Fiat-crypto evolved, including its Zig backend
- Barriers turned out to be necessary to avoid memory loads depending
on a secret selector. What we ship in Zig didn't had them.
So, reconciliate everything and update the code we ship with what
fiat now produces.
As a bonus, point multiplication on NIST curves gets ~10% faster.
An all-zero r or s component would try to encode an empty slice,
and panic. Not great.
When decoding, we accept integers shorter than the encoding
and pad them with zeros. Problem it that to check the sign,
we were always looking at the first byte, which in that case
was padding instead of the actual sign byte. This is now fixed.
And also reject integers with unnecessary leading zeros.
For example 02 02 00 01 was accepted, but the canonical
representation is 02 01 01. We should be strict and only accept
the canonical representation.
In Ascon-AEAD128, we forgot a padding-only block after the AD.
And for the hash/XOF moes, we should keep track of the offset
between update() and squeeze() calls to make them equivalent to
a single-shot call, as in other hash functions/XOFs.
Otherwise the construction is not insecure, but the output
doesn't match the specification either.
Packed coefficients have a limited valid range:
- With `eta = 2` (ML-DSA-44 and ML-DSA-87), 3-bit values must be
0...4. Values `5` through `7` are reserved.
- With `eta = 4` (ML-DSA-65), 4-bit must be values 0...8. Values
9 through 15 are reserved.
We were previously accepting reserved values, allowing malformed
secret key encodings.
This is not a security issue (secret keys are trusted anyway),
and the specification doesn't require these coefficients to be
checked. In fact, most implementations including the reference
implementations currently don't do it.
But:
1) the Zig crypto implementations generally try to be strict for
validation
2) the checks are very cheap
3) this makes sure the invariants are enforced
4) SecretKey.fromBytes() already allows returning an error, so
this is not really an API change
5) OpenSSL, BoringSSL and Go reject these encodings.
Previously this always caused a compilation failure because it would
correctly substitute multiple packages with the provided forked package,
however, this ends up constructing a zig build-exe command line for the
configurer that included multiple differnt modules that used the same
files.
Closes#31677
Any time the same package (based on fingerprint) appears in the
dependency tree, if the semantic version compares equal, the hash must
be identical, otherwise one of three things has gone wrong and the
maintainer must address it.
--fetch is changed to mean:
> Fetch all dependencies including lazy ones; exit without configuration
--configure is introduced (replaces old `--fetch` semantics):
> Exit after the configuration phase
Contiki-NG is really more like a freestanding library for driving MCUs and
peripherals; it's not an OS with an ABI as such. So a dedicated OS tag isn't
really doing anything useful over `freestanding`.
Hermit is a unikernel with no stable syscall ABI; you must link its syscall
library statically to perform syscalls. Due to the way the project's build
system works, that means using Rust/Cargo. As such, it makes essentially zero
sense for Zig to support this target.
When the modulus takes its full limb capacity, we can take
advantage of the fact that this is a comptime value to get
specialized code with better vectorization.
Also avoid expensive copies.
This is all internal; no changes to the public APIs.
Modular addition uses the same code in plain and Montgomery
representations, so factor it.
Computation of m0inv can also be in a dedicated function.
This improves clarity, but this is also something that we'll need
for working with a secret modulus, so that will avoid code
duplication as well.
* We need to add current_dtv_offset in __tls_get_addr() because we aren't
reading the actual DTV entry (where that value would be baked in).
* In both __tls_get_addr() and __tls_get_offset(), we need to subtract
area_info.abi_tcb.offset rather than area_info.block.size because we apply
align_factor to the block size when computing the area layout.
netReadWindows and netWriteWindows returned error.Unexpected when AFD
reported STATUS_LOCAL_DISCONNECT. I was able to produce this error in
both the read and write paths locally.
Partial fix of #31956
An `Io.Mutex` is bound to the Io implementation used to lock and unlock it: having it cross Io implementations could already be an abuse of the API. C code is even further removed, since it has no `Io` at all and could never meaningfully interact with an `Io.Mutex`, so making it `extern` doesn't buy us anything. The only thing we actually gain is less boilerplate when the user needs to protect a struct that is also used from C, where the C side doesn't need the synchronization. I would argue that's not a strong enough reason to keep it `extern`, since the same behavior can be achieved with composition.
Being `extern` also conflicts with adding safety features to the implementation: their size would change with the compilation configuration, which defeats the purpose of `extern`.
Reviewed-on: https://codeberg.org/ziglang/zig/pulls/37081
Reviewed-by: Andrew Kelley <andrew@ziglang.org>
Andrew Kelley