* `comptime const` is redundant
* don't use `extern enum`; specify a tag type.
`extern enum` is only when you need tags to alias. But aliasing tags
is a smell. I will be making a proposal shortly to remove `extern enum`
from the language.
* there is no such thing as `packed enum`.
* instead of `catch |_|`, omit the capture entirely.
* unused function definition with missing parameter name
* using `try` outside of a function or test
std/crypto: use finer-grained error sets in function signatures
Returning the `crypto.Error` error set for all crypto operations
was very convenient to ensure that errors were used consistently,
and to avoid having multiple error names for the same thing.
The flipside is that callers were forced to always handle all
possible errors, even those that could never be returned by a
function.
This PR makes all functions return union sets of the actual errors
they can return.
The error sets themselves are all limited to a single error.
Larger sets are useful for platform-specific APIs, but we don't have
any of these in `std/crypto`, and I couldn't find any meaningful way
to build larger sets.
See https://eprint.iacr.org/2019/1492.pdf for justification.
8 rounds ChaCha20 provides a 2.5x speedup, and is still believed
to be safe.
Round-reduced versions are actually deployed (ex: Android filesystem
encryption), and thanks to the magic of comptime, it doesn't take much
to support them.
This also makes the ChaCha20 code more consistent with the Salsa20 code,
removing internal functions that were not part of the public API any more.
No breaking changes; the public API remains backwards compatible.
Let's follow the road paved by the removal of 'z'/'Z', the Formatter
pattern is nice enough to let us remove the remaining four special cases
and declare u8 slices free from any special casing!
OCB has been around for a long time.
It's simpler, faster and more secure than AES-GCM.
RFC 7253 was published in 2014. OCB also won the CAESAR competition
along with AEGIS.
It's been implemented in OpenSSL and other libraries for years.
So, why isn't everybody using it instead of GCM? And why don't we
have it in Zig already?
The sad reason for this was patents. GCM was invented only to work
around these patents, and for all this time, OCB was that nice
thing that everybody knew existed but that couldn't be freely used.
That just changed. The OCB patents are now abandoned, and OCB's
author just announced that OCB was officially public domain.
Don't use the instantiation argument types to build the function
parameter array.
f416535768fc30195cad6cd481f73fd1e80082aa worked around the problem, this
commit solves it.
Everybody gets what they want!
* AT_RANDOM is completely ignored.
* On Linux, MADV_WIPEONFORK is used to provide fork safety.
* On pthread systems, `pthread_atfork` is used to provide fork safety.
* For systems that do not have the capability to provide fork safety,
the implementation falls back to calling getrandom() every time.
* If madvise is unavailable or returns an error, or pthread_atfork
fails for whatever reason, it falls back to calling getrandom() every
time.
* Applications may choose to opt-out of fork safety.
* Applications may choose to opt-in to unconditionally calling
getrandom() for every call to std.crypto.random.fillFn.
* Added `std.meta.globalOption`.
* Added `std.os.madvise` and related bits.
* Bumped up the size of the main thread TLS buffer. See the comment
there for justification.
* Simpler hot path in TLS initialization.
* get rid of the pointless fences
* make seed_len 16 instead of 32, which is accurate since it was
already padding the rest anyway; now we do 1 pad instead of 2.
* secureZero to clear the AT_RANDOM auxval
* add a flag root source files can use to disable the start code. This
is in case people want to opt out of the initialization when they
don't depend on it.
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
Transforming scalars to non-adjacent form shrinks the number of
precomputations down to 8, while still processing 4 bits at a time.
However, real-world benchmarks show that the transform is only
really useful with large precomputation tables and for batch
signature verification. So, do it for batch verification only.
https://github.com/cfrg/draft-irtf-cfrg-hash-to-curve
This is quite an important feature to have since many other standards
being worked on depend on this operation.
Brings a couple useful arithmetic operations on field elements by the way.
This PR also adds comments to the functions we expose in 25519/field
so that they can appear in the generated documentation.
We currently have ciphers optimized for performance, for
compatibility, for size and for specific CPUs.
However we lack a class of ciphers that is becoming increasingly
important, as Zig is being used for embedded systems, but also as
hardware-level side channels keep being found on (Intel) CPUs.
Here is ISAPv2, a construction specifically designed for resilience
against leakage and fault attacks.
ISAPv2 is obviously not optimized for performance, but can be an
option for highly sensitive data, when the runtime environment cannot
be trusted.
This is a trivial implementation that just does a or[xor] loop.
However, this pattern is used by virtually all crypto libraries and
in practice, even without assembly barriers, LLVM never turns it into
code with conditional jumps, even if one of the parameters is constant.
This has been verified to still be the case with LLVM 11.0.0.
As documented in the comment right above the finalization function,
Gimli can be used as a XOF, i.e. the output doesn't have a fixed
length.
So, allow it to be used that way, just like BLAKE3.
With the simple rule that whenever we have or will have 2 similar
functions, they should be in their own namespace.
Some of these new namespaces currently contain a single function.
This is to prepare for reduced-round versions that are likely to
be added later.
We read and write bytes directly from the state, but in the init
function, we potentially endian-swap them.
Initialize bytes in native format since we will be reading them
in native format as well later.
Also use the public interface in the "permute" test rather than an
internal interface. The state itself is not meant to be accessed directly,
even in tests.
BLAKE2 includes the expected output length in the initial state.
This length is actually distinct from the actual output length
used at finalization.
BLAKE2b-256/128 is thus not the same as BLAKE2b-128.
This behavior can be a little bit surprising, and has been "fixed"
in BLAKE3.
In order to support this, we may want to provide an option to set the
length used for domain separation.
In Zig, there is another reason to allow this: we assume that the
output length is defined at comptime.
But BLAKE2 doesn't have a fixed output length. For an output length that
is not known at comptime, we can't take the full block size and
truncate it due to the reason above.
What we can do now is set that length as an option to get the correct
initial state, and truncate the output if necessary.
Leverage result location semantics for X25519 like we do everywhere
else in 25519/*
Also add the edwards25519->curve25519 map by the way since many
applications seem to use this to share the same key pair for encryption
and signature.
Intel keeps changing the latency & throughput of the aes* and clmul
instructions every time they release a new model.
Adjust `optimal_parallel_blocks` accordingly, keeping 8 as a safe
default for unknown data.
