Exponentiation with short, public exponents doesn't use a
precomputation table. Building the table would take more time
that it would eventually save.
However without explicit parenthesis the test for that parsed as
"(public and e.len < 3) or (e.len == 3 and top_byte <= 0x0f)"
and not "public and (e.len < 3 or...)" as intended.
Not a practical issue since a secret exponent is never going to be
short, but we're still supposed to use the constant-time path for
non-public exponents.
AES-SIV supports "only" up to 126 AD fields.
Passing more than that never happens in any real-world protocol
(it's typically 1-3), but an assert() doesn't hurt.
Null optional struct fields were emitted as empty TLVs.
They should be omitted instead.
The outer field tag should also be restored after encoding struct
fields.
The encoder was writing 15 in the low five bits to mark a high tag
number insetad of 31.
Emit the correct marker and as many continuation bytes as the tag
number requires, and expose encodeToSlice so a Writer is not needed
any more.
And return proper errors.
Fixes#32069 and supersedes #32139
Drop the writer wrapper since ArrayListReverse no longer exposes one,
and use prependBytes consistently.
Also rewrite length encoding so the high-bit length-of-length byte is
placed last as expected by X.690.
And always derive the leading-zero pad from the sign bit of the
first encoded byte.
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.
Meghan Denny