build(deps): bump curve25519-dalek from 4.1.3 to 5.0.0

[dependabot]

Bumps curve25519-dalek from 4.1.3 to 5.0.0.

Commits

• 07bef73 Prep v5.0 major release (#916)
• 0cd94ea ed: Implement KeySizeUser, TryKeyInit, and Generate for SigningKey. A...
• eeaf902 perf(lizard): skip negative preimages in lizard_decode (#882)
• 78abeae Fix running doc tests (#914)
• 4cf8db2 Support AVX512 on stable Rust (#913)
• d995caf Prep v5.0-rc.1 (#911)
• 1c14d54 curve: Bring back ff and group (#909)
• 58b331c curve,x,ed: re-export rand_core (#908)
• 70e82aa Prep v5.0-rc.0 (#906)
• 13ac5e6 curve: Remove ff/group features for now (#907)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[senseix21]

Review: hold — green CI is hiding a duplicated curve implementation inside the TCB

All 66 checks pass, including dark-features-compile (crypto-curve25519). It compiles. That is exactly why this one needs a human: the lockfile shows the cost, and the cost is not acceptable as-is.

What the lockfile actually does

curve25519-dalek does not get upgraded — it gets duplicated. Three consumer entries were rewritten, and they do not agree:

microkernel      -> curve25519-dalek 5.0.0   (direct, this PR)
ed25519-dalek    -> curve25519-dalek 4.1.3   (pins ^4)
x25519-dalek     -> curve25519-dalek 4.1.3   (pins ^4)

So after this merge the graph carries both majors simultaneously, and the dependency split propagates downward:

+ fiat-crypto 0.3.0   alongside   fiat-crypto 0.2.9
+ cpufeatures 0.3.0   alongside   cpufeatures 0.2.17

fiat-crypto is newly duplicated by this change. That is two independent copies of formally-generated Curve25519 field arithmetic linked into the same image.

Why that is a blocker here specifically, not a nitpick

• Two curve implementations in a TCB is a security property regression, not just bloat. We would be shipping two distinct field-arithmetic backends, audited and constant-time-reviewed separately, reachable from the same attestation and key-exchange paths. "Which implementation verified this signature" stops having a single answer.
• The type systems don't interoperate. A Scalar/MontgomeryPoint from 4.1.3 is a different type from the 5.0.0 one. Today that is latent because crypto-curve25519 and crypto-ed25519-dalek are separate optional features. The moment any code path wants to hand a scalar or a point between our direct curve25519-dalek usage and x25519-dalek, it will not compile — and the tempting fix at that point is a byte-level to_bytes/from_bytes round-trip across two different implementations, which is precisely the kind of reinterpretation we should never add to a key path.
• It bypasses the point of the feature flag. crypto-curve25519 = ["curve25519-dalek", "x25519-dalek"] bundles the two together, so enabling that single feature is what materialises the 4.x/5.x split. The flag that was supposed to isolate this dependency is the flag that guarantees the duplication.
• These are dark features, so CI green is weak evidence. default = ["microkernel-core"] does not include crypto-curve25519; the comment in Cargo.toml is explicit that external crypto is optional and "in-tree implementations are the default." dark-features-compile proves it type-checks. It does not prove constant-time behaviour, does not exercise the curve at runtime, and does not measure the TCB growth from a second field-arithmetic backend.

Recommendation

Block until the dalek ecosystem catches up. The correct trigger to revisit is ed25519-dalek and x25519-dalek publishing releases that depend on curve25519-dalek 5.x — then all three move together in one coherent bump and the duplication never exists.

Concretely, I'd like to see one of:

1. Preferred: close/park this, and re-open it as a single PR that bumps curve25519-dalek → 5, ed25519-dalek and x25519-dalek in lockstep once upstream supports it, with cargo tree -d showing no duplicate curve or fiat-crypto.
2. If there is a concrete reason we need 5.0.0 now (a security advisory against 4.1.3 would qualify — I did not find one), then say so on this PR and we take the duplication knowingly, with a cargo deny [bans] exception documenting why, plus a TCB-size delta recorded.

Either way, please add a cargo tree -d check to the gate so a duplicated crypto crate fails CI instead of passing it. That is the systemic fix — this PR is green today precisely because nothing asserts single-version crypto, and the next dalek bump will reproduce this silently.

Not merging on a green checkmark here.