aboutsummaryrefslogtreecommitdiff
path: root/lib/std/crypto/errors.zig
AgeCommit message (Collapse)Author
2024-06-04crypto.edwards25519: add the ability to check for group membership (#20175)Frank Denis
Most of the functions related to points on the Edwards25519 curve check that input points are not in a small-order subgroup. They don't check that points are on the prime-order subgroup, because this is expensive, and not always necessary. However, applications may require such a check in order to ensure that a public key is valid, and that a secret key counterpart exists. Many functions in the public API of libsodium related to arithmetic over Edwards25519 also do that check unconditionally. This is expensive, but a good way to catch bugs in protocols and implementations. So, add a `rejectUnexpectedSubgroup()` function to achieve this. The documentation on the edwards25519->curve25519 conversion function was also updated, in order to explain how to match libsodium's behavior if necessary. We use an addition chain to multiply the point by the order of the prime group. An alternative we may implement later is Pornin's point halving technique: https://eprint.iacr.org/2022/1164.pdf
2023-04-30std: fix a bunch of typosLinus Groh
The majority of these are in comments, some in doc comments which might affect the generated documentation, and a few in parameter names - nothing that should be breaking, however.
2021-04-20std/crypto: use finer-grained error sets in function signatures (#8558)Frank Denis
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.