mirror of
https://github.com/saymrwulf/curve25519-dalek-source.git
synced 2026-09-03 20:13:48 +00:00
Patched source for Aeneas/Charon formal verification transpilation
594808680c
* [WIP] ed25519-dalek: bump `ed25519` crate dependency to v3.0.0
This has two test failures:
serialisation::serialize_deserialize_signature_json
serialisation::serialize_signature_size
These are due to a last minute change to use `serdect` for implementing
`serde` support: RustCrypto/signatures#1324.
The signature size regression from `64` to `72` is a deliberate tradeoff
we've accepted in `serdect`. First note that this test is for now the
unmaintained `bincode` crate.
The core problem is that `serde` does not actually provide fixed-size
arrays as a type within its data model (serde-rs/serde#1937) and you're
instead left faking it using `SerializeTuple` and serializing it a
byte-at-a-time as a tuple. While this gives optimal-sized results on
`bincode`, it gives less-than-optimal results on e.g. `rmp-serde` where
the bytes each end up tagged with a type prefix.
`serde` does provide portable APIs for using optimal format-specific
byte encodings, but they carry an additional length prefix, which is
unnecessary and suboptimal for something fixed-width like an Ed25519
signature, but alas as noted earlier `serde` does not actually have
fixed-width arrays in its data model.
The second test failure occurs specifically because `serdect`
introspects the format and uses `base16ct` to perform hex serialization
for human readable formats. While this is a readability improvement for
these formats (and also makes them easier to implement in constant-time,
though it's not relevant here), the drawback is it currently requires
the `alloc` feature for such formats, which is a regression:
Error("serializer is human readable, which requires the `alloc` crate feature", line: 0, column: 0)
Note that regardless these are both breaking changes to how `serde`
serialization is handled.
See also:
- RustCrypto/formats#1111
- RustCrypto/formats#1112
- dalek-cryptography/ed25519-dalek#140
* Migrate bincode -> postcard
* Bump `serdect` to v0.4.3
Includes `no_alloc` hex serialization support
---------
Co-authored-by: Michael Rosenberg <mrosenberg@cloudflare.com>
|
||
|---|---|---|
| .github/workflows | ||
| curve25519-dalek | ||
| curve25519-dalek-derive | ||
| docs/assets | ||
| ed25519-dalek | ||
| x25519-dalek | ||
| .gitignore | ||
| .typos.toml | ||
| Cargo.lock | ||
| Cargo.toml | ||
| CONTRIBUTING.md | ||
| README.md | ||
Dalek elliptic curve cryptography
This repo contains pure-Rust crates for elliptic curve cryptography:
| Crate | Description | Crates.io | Docs | CI |
|---|---|---|---|---|
curve25519‑dalek |
A library for arithmetic over the Curve25519 and Ristretto elliptic curves and their associated scalars. |  |
 |
 |
ed25519‑dalek |
An implementation of the EdDSA digital signature scheme over Curve25519. |  |
 |
 |
x25519‑dalek |
An implementation of elliptic curve Diffie-Hellman key exchange over Curve25519. |  |
 |
 |
There is also the curve25519-dalek-derive crate, which is just a helper crate with some macros that make curve25519-dalek easier to write.
Contributing
Please see CONTRIBUTING.md.
Code of Conduct
We follow the Rust Code of Conduct, with the following additional clauses:
- We respect the rights to privacy and anonymity for contributors and people in the community. If someone wishes to contribute under a pseudonym different to their primary identity, that wish is to be respected by all contributors.