summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* wycheproof: run ML-KEM test vectors against libcryptoHEADmastertb9 days1-2/+139
|
* mlkem_public_to_private: fix overread/information leaktb9 days1-3/+3
| | | | | | | | | | | | After the guts of MLKEM_public_key were changed from a union to a struct, the aligner grew the struct, leaking as many bytes of private key data as the struct grew (on normal platforms that would be 2). Ideally this would all be a bit more robust. CID 621603 621604 ok jsing kenjiro
* wycheproof: zap stray empty linetb2025-09-091-2/+1
|
* Call aes_set_encrypt_key_generic() from aes_set_decrypt_key_generic().jsing2025-09-081-2/+2
| | | | | With the renaming, aes_set_decrypt_key_generic() should now call aes_set_encrypt_key_generic() directly.
* Allow generic AES implementation to be used as a fallback.jsing2025-09-083-19/+65
| | | | | | | | | Rename the C based AES implementation to *_generic() and provide *_internal() wrappers for these. This allows for architectures to provide accelerated versions without having to also provide a fallback implementation. ok tb@
* Zero the round keys on AES_set_{en,de}crypt_key() function entry.jsing2025-09-081-1/+5
| | | | | | | This avoids leaving previous round keys around on failure, or leaving parts of previous round keys behind if reused with a smaller key size. ok tb@
* Validate AES_set_{encrypt,decrypt}_key() inputs at API boundary.jsing2025-09-082-18/+28
| | | | | | | | | | | Every aes_set_{encrypt,decrypt}_key_internal() implementation is currently required to check the inputs and return appropriate error codes. Pull the input validation up to the API boundary, setting key->rounds at the same time. Additionally, call aes_set_encrypt_key_internal() directly from aes_set_decrypt_key_internal(), rather than going back through the public API. ok tb@
* wycheproof: rework test selectiontb2025-09-081-69/+82
| | | | | | | | | | Since this has grown organically, the test selection has become a weird mix of globs, regexes and test variants and it is hard to reason about what is run and why. Instead, load all the json files from testvectors_v1/ and look at algorithm (almost always available) and test schema to figure out if we support it in libcrypto and the test harness. This separates the logic of the test runner better from the test selection. Also make it a fatal error if we don't explicitly skip an unknown algorithm.
* wycheproof: skip tests using curve448/edwards448tb2025-09-081-7/+12
|
* wycheproof: skip tests using SHAKE-128 and SHAKE-256tb2025-09-081-1/+17
|
* wycheproof: rename skipSmallCurve() into skipCurve()tb2025-09-081-4/+6
| | | | | This prepares an upcoming change by not only skipping small curves but also binary curves that have test vectors.
* wycheproof: determine the test variant from the JSON schematb2025-09-081-30/+41
|
* wycheproof: retire the ECDSA webcrypto teststb2025-09-071-71/+2
| | | | | | | The webcrypto test files for P-256, P-384, and P-521 are identical to the P1363 test files for these curves with the hashes SHA-256, SHA-384, and SHA-512, respectively. The only real differences in the test paths is the Go glue code to translate to libcrypto, so they're pointless.
* Remove BN_DIV2W.jsing2025-09-073-28/+4
| | | | | | | The BN_DIV2W define provides a code path for double word division via the C compiler, which is only enabled on hppa. Simplify the code and mop this up. ok tb@
* Re-enable bn_sqr_words() assembly.jsing2025-09-073-8/+8
| | | | This is now only on amd64.
* Rename old assembly bn_sqr_words() to bn_sqr_word_wise().jsing2025-09-076-30/+27
| | | | | | | bn_sqr_words() does not actually compute the square of the words, it only computes the square of each individual word - rename it to reflect reality. Discussed with tb@
* wycheproof: go fmttb2025-09-061-4/+4
|
* wycheproof: use a cleaner way of dealing with P1363 signature lengthtb2025-09-061-4/+12
|
* Deduplicate the mlkem 768 and mlkem 1024 code.beck2025-09-056-1788/+527
| | | | | | | | | | | This moves everything not public to mlkem_internal.c removing the old files and doing some further cleanup on the way. With this landed mlkem is out of my stack and can be changed without breaking my subsequent changes ok tb@
* wycheproof: check for the v1 directory since v0 will go awaytb2025-09-051-2/+2
|
* wycheproof: port the MI primes check to v1tb2025-09-052-3/+24
|
* wycheproof: remove support for v0 test vectorstb2025-09-051-68/+38
|
* wycheproof: drop JOSE teststb2025-09-051-2/+1
| | | | These are no longer supported in v1 and we skipped them anyway.
* wycheproof: move AES key wrap tests to v1tb2025-09-051-4/+4
|
* wycheproof: add support for EcCurve teststb2025-09-051-1/+103
| | | | | | This checks for a collection of prime order groups (secp, Brainpool, FRP) the curve parameters are corrct. The collection is a superset of our built-in curves, so we get one more validation for exxentially free.
* wycheproof: add custom JSON unmarshaler big integerstb2025-09-051-9/+58
| | | | | | | | | | | Since the wycheproof tests were written in Java, they inherited some of that language's weirdnesses. For example, the hex representation may have odd length, is 2-complement and needs zero-padding if the top bit of a nibble is set, similar to ASN.1 integers. This is needed for correctly decoding the Primality test cases, which worked nicely in v0 but no longer for v1. Convert the Primality test to use this.
* wycheproof: make RSA tests worktb2025-09-051-43/+79
| | | | | | There's more work needed here since some of the tests are designed to test the signing side of things, where we only verify. To be dealt with later.
* wycheproof: move ECDSA tests to v1tb2025-09-051-14/+15
| | | | | | | | | | | | | This excludes the bitcoin tests since our ECDSA_verify() doesn't have the logic to enforce s < order / 2 to avoid the well-known malleability issue with secp256k1 that (r, s) is valid if and only if (r, order - s) is valid. Moreover, add a workaround for overly picky P1363 tests where only correctly padded P1363 signatures are accepted. As the test authors say "To our knowledge no standard (i.e., IEEE P1363 or RFC 7515) requires any explicit checks of the signature size during signature verification." In fact, the problem really is in the test code, not in libcrypto and is a bit annoying to fix in a non-silly way.
* wycheproof: move ECDH tests to v1 (skip PEM for now)tb2025-09-051-6/+5
|
* wycheproof: move AES to v1 and explicitly skip gmac testtb2025-09-051-3/+3
|
* wycheproof: go fmttb2025-09-041-6/+6
|
* wycheproof: move HKDF to v1tb2025-09-041-2/+2
|
* wycheproof: move EdDSA to v1tb2025-09-041-7/+7
| | | | | eddsa_test.json is now ed25519_test.json and again key* was renamed to PublicKey*.
* wycheproof: move DSA to v1tb2025-09-041-6/+6
| | | | key* are now called PublicKey*, so change teh json tags accordingly.
* wycheproof: move x25519 to v1tb2025-09-041-5/+5
|
* wycheproof: migrate {,X}ChaCha20-Poly1305 to v1tb2025-09-041-3/+3
|
* wycheproof: migrate HMAC to v1tb2025-09-041-3/+3
| | | | | This is straightforward since the schema did not change. This adds coverage for HMAC-SHA512/224 and HMAC-SHA512/256.
* wycheproof: add struct to support the testvector_v1 schematb2025-09-041-7/+26
|
* wycheproof: add version sum type and annotate all tests as v0tb2025-09-041-30/+41
| | | | | The version is passed to the test runner, so it can unmarshal the v0 and v1 JSON as appropriate later on.
* wycheproof: use local variables for testGroups and algorithmtb2025-09-041-7/+11
|
* wycheproof: start migrating to testvectors_v1tb2025-09-041-4/+5
| | | | | | | | | | | | In https://github.com/C2SP/wycheproof/pull/169, upstream removed the testvector/ path, thereby creating the need to migrate if we want to benefit from future changes and tests. While this has been around for a very long time and generally provided more and better coverage, there never was sufficient motivation to do so. As a first step, change use of the testVectorPath constant to use of a path variable so we can switch the tests one by one by appending _v1 when appropriate.
* Disable assembly bn_sqr_words() again for now.jsing2025-09-023-8/+8
| | | | | | | | The old assembly bn_sqr_words() does not actually square words in the bignum sense. These will have to be renamed (once I come up with a name for whatever it actually does) before we can roll forward again. Found the hard way by Janne Johansson.
* Add const here as well...jsing2025-09-011-2/+2
|
* Use bn_mul_words() from bn_mod_mul_words().jsing2025-09-011-5/+3
| | | | | | Use bn_mul_words() and bn_montgomery_reduce_words(), rather than using bn_montgomery_multiply_words(). This provides better performance on architectures that have assembly optimised bn_mul_words(), such as amd64.
* Constify bn_mul_words().jsing2025-09-013-6/+9
|
* Use bn_sqr_words() from bn_mod_sqr_words().jsing2025-09-011-5/+3
| | | | | | | | Use bn_sqr_words() and bn_montgomery_reduce_words(), rather than using bn_montgomery_multiply_words(). This provides better performance on architectures that have assembly optimised bn_sqr_words(), such as amd64. ok tb@
* Provide bn_mul_words() on amd64.jsing2025-09-012-2/+12
| | | | | This uses s2n-bignum's bignum_mul() and provides significant performance gains for a range of multiplication sizes.
* EC_GROUP_new_curve_GFp: add a sentence on what elliptic curves look liketb2025-08-311-2/+7
| | | | (for our purposes).
* Remove bn_dump.3tb2025-08-311-415/+0
| | | | | | Not installed for nearly a decade since it only "documents" internal functions and structs and the internal function doco gets more out of sync with reality with every (much needed) pass over bn/
* Reorder functions since they've been renamed.jsing2025-08-311-17/+17
|
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-09-23 15:49:32 +0000