# P256 guest uses invalid parameters

OpenVM's P256 guest hardcoded GENERATOR/NEG_GENERATOR constants in wrong byte order, producing invalid curve points and breaking P256 group operations.

- Payout: Contest reward
- Severity: high
- Program: OpenVM
- Credited: zigtur
- Disclosed: 2025-03-24
- Write-up quality: 6/10
- Original: https://cdn.cantina.xyz/reports/cantina_competition_openvm_january2025.pdf#3.1.18
- Library page: https://bugbountylibrary.com/r/cantina%3Aopenvm_january2025%3A3.1.18
- Tags: domain:web3 impact:integrity kind:contest platform:cantina sev:high tech:rust technique:source-review vuln:crypto

**Target:** P256 elliptic curve implementation in zkVM guest (p256.rs)
**Root cause:** GENERATOR and NEG_GENERATOR constants for P256 were encoded big-endian while the from_const_bytes/hex! path expected little-endian (as used for secp256k1), yielding points not on the curve; double_impl also ignored curve_a.
**Steps:**
1. Read p256.rs GENERATOR constant `6b17d1f2...d898c296` (big-endian secp256r1 generator).
2. Compare with Secp256k1Point GENERATOR `9817F816...7E66BE79` encoded little-endian via same from_const_bytes/hex! helpers.
3. Note the encoding discrepancy: P256 bytes are reversed relative to expected order.
4. Conclude P256Point GENERATOR/NEG_GENERATOR are invalid points not on the curve, breaking CyclicGroup ops.
**How found:** Cross-comparing two curve implementations using identical helper functions (from_const_bytes/hex!) and noticing the byte order differed between P256 and secp256k1 constants, then checking against the neuromancer.sk secp256r1 reference.
**Insight:** When two implementations share a byte-decoding helper, diff their hardcoded constants' endianness against an external reference; a reversed generator silently yields off-curve points that pass compilation.