mirage-crypto-ec.Dsa raise Message_too_long in sign, verify checks di…#108
Merged
Conversation
…gest length Previously, only the x leftmost bits were used with x being the bit size of the group order. This could lead to two inputs X and Y with the same signature, especially bad for verify.
kit-ty-kate
pushed a commit
to ocaml/opam-repository
that referenced
this pull request
Mar 31, 2021
…ge-crypto-rng, mirage-crypto-rng-mirage and mirage-crypto-rng-async (0.9.0) CHANGES: - Elliptic curve support in the new package mirage-crypto-ec The arithmetic code is generated by [fiat-crypto](https://github.com/mit-plv/fiat-crypto), a development in Coq which includes proofs of constant time behaviour. The generation can be reproduced (see ec/native/GNUmakefile). The group operation implementations are taken from BoringSSL. The high-level mechanisms (signature DSA and key exchange ECDH) are implemented in OCaml. The ECDSA implementation (as our DSA one) uses a deterministic k (RFC 6979). The NIST curves P224 (SECP224R1), P256 (SECP256R1), P384 (SECP384R1), and P521 (SECP521R1) are supported (ECDH and ECDSA), in addition to Curve25519 (X25519 and Ed25519). Performance of X25519 has been measured and is roughly the same as the hacl_x25519 and also the hacl opam package (see mirage/mirage-crypto#107 for numbers). Tests vectors are from RFCs and wycheproof. Import mirage/fiat repository (@pascutto @emillon @NathanReb @hannesm mirage/mirage-crypto#101) Check bounds of message (reported by @greg42, fixed by @hannesm mirage/mirage-crypto#108) Remove blinding, since constant time arithmetics is used (@hannesm mirage/mirage-crypto#106) Curve 25519 (X25519 & Ed25519) support (@hannesm mirage/mirage-crypto#107 imported from BoringSSL) Partially reviewed by @JasonGross @avsm @dinosaure Partially sponsored by Nitrokey GmbH
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
…gest length
Previously, only the x leftmost bits were used with x being the bit size of the
group order. This could lead to two inputs X and Y with the same signature,
especially bad for verify.