Skip to content

[marco issue] solana-ed25519 auditing findings #40

@zz-sol

Description

@zz-sol

High Priority

  • Fix broken pkcs8 feature activation in curve25519/solana-ed25519/Cargo.toml.

  • Fix broken serde feature activation in curve25519/solana-ed25519/Cargo.toml.

  • Validate SPKI algorithm/OID when decoding public-key DER.

    • A DER/SPKI key labeled as another algorithm can currently be accepted if it contains usable 32-byte key material.
    • Replace unwrap() paths with proper error handling.
    • fix: [ed25519] Validate SPKI OID/bytes #43
  • Enforce or redesign the 128-bit scalar precondition for vartime_triple_base_mul_128_128_256.

Medium Priority

  • Make SwPoint::to_edwards reject off-curve affine inputs or clearly document the precondition.

  • Handle or document exceptional Edwards/SW conversion cases.

  • Fix or document the affine identity encoding asymmetry.

Low Priority

  • Update VerificationKeyBytes documentation.

    • It is a length-checked encoded-key container, not proof that the bytes are a valid Ed25519 verification key.
    • fix: [ed25519] improve docs #47
  • Fix verify_dalek documentation or implementation.

    • Docs claim exact ed25519-dalek behavior, but implementation adds legacy blacklist and all-zero public-key checks.
    • fix: [ed25519] improve docs #47
  • Fix stale HEEA docs/comments.

  • Return a more accurate batch-verification error for malformed verification keys.

    • Current batch verification maps verification-key decompression failure to InvalidSignature.
  • Align or document the serial/vector b_lo_naf window-size difference.

  • Consider requiring CryptoRng + RngCore for EdwardsPoint::random.

    • This would match Scalar::random and RistrettoPoint::random.
  • Consider implementing core::ops::Add for SwPoint.

    • SwPoint has an inherent add method but no + operator support.
  • Reduce duplicated lookup-table construction logic across serial/vector backends.

Not Tracked As A Bug

  • verify accepting more signatures than verify_dalek appears intentional because verify is documented as ZIP-215/Zebra-style verification.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions