UTCTime years in the range 50-99 must map to 1950-1999, but the
parser unconditionally added 2000, producing dates 100 years in the
future.
This caused verify() to accept certificates whose validity actually
expired decades ago.
Change that to match what OpenSSL, BoringSSL, etc. do
AsconXof128 and AsconCxof128 were applying the padding in update()
calls. That was totally fine for one-shot hashing, but not for
streaming (multiple update() calls before finalization).
After decryption, TLS 1.3 plaintext is trimmed of zero padding, then
the last byte is read as the content type.
But when the plaintext was entirely zero padding, we got a
"thread panic: integer overflow at msg.len - 1" error. That could be
triggered by any server to crash the client.
The first issue is that when len(Sn) >= 128,
we perform Sn xor D instead of the Sn xorend D
that is specified in RFC 5297.
The second issue is that we truncate the Sn
if it is larger than 4096 bytes, which could
lead to collisions between inputs. We solve
this by absoring the Sn into the CMAC state
perform the last 16 bytes, xoring those 16
bytes with D as described in the first issue,
and then updating and squeezing the CMAC.
In #31086, the `std.time.Timer` struct was removed, but this broke the last few programs that used it, those being the benchmarking programs for `std.Random`, `std.hash`, `std.crypto` and `std.unicode`. One more is `zig/perf_test.zig`, but as far as I can tell, that one is broken due to changes in file import rules too, unless I'm launching it wrong.
I also spotted some performance and benchmarking issues with the RNGs, detailed in #31554.
Reviewed-on: https://codeberg.org/ziglang/zig/pulls/31553
Reviewed-by: Andrew Kelley <andrew@ziglang.org>
Co-authored-by: UraniaZPM <uraniazpm@noreply.codeberg.org>
Co-committed-by: UraniaZPM <uraniazpm@noreply.codeberg.org>
This is the same as for Edwards25519 without the y coordinate,
since it returns Montgomery coordinates, but it can be confusing
to call the Edwards25519 function while working on the
Curve25519 representation.
New protocols such as CPACE requires the map over Curve25519.
Importantly, adds ability to get Clock resolution, which may be zero.
This allows error.Unexpected and error.ClockUnsupported to be removed
from timeout and clock reading error sets.
Finite field elements can be in regular or Montgomery form, and
chaining different operations use to require manual and error-prone
conversions.
Now:
- `add`, `sub` and `mul` convert the second operand to match the
first operand's form
- `sq` and `pow` preserve the input's Montgomery form
- `toPrimitive` and `toBytes` return `UnexpectedRepresentation` if
the element is in Montgomery form, preventing incorrect serialization
This is fully backwards compatible and allows seamless chaining of
operations regardless of their representation.
Previously these functions made the assumption that
when performing a on the input digits,
there could be no collisions between the less
significant digits being larger than '9', and the
upper digits being small enough to get past the
checks.
Now we perform a correct check across all of the
digits to ensure they're in between '0'-'9', at
a minimal cost, since all digits are checked in
parallel.
I believe these tests may have been flaky as a result of the bug fixed
in the previous commit. A big hint is that they were all crashing with
SIGSEGV with no stack trace. I suspect that some lingering SIGIOs from
cancelations were being delivered to a thread after its `munmap` call,
which was happening because the test runner called `Io.Threaded.deinit`
to cause all of the (detached) worker threads to exit.
If this passes, I'll re-run the x86_64-linux CI jobs on this commit a
few times before merge to try and be sure there are no lingering
failures.
Resolves: https://codeberg.org/ziglang/zig/issues/30096
Resolves: https://codeberg.org/ziglang/zig/issues/30592
Resolves: https://codeberg.org/ziglang/zig/issues/30682
Linus Groh