STARK Curve Primitives

All Track 1 cryptography in Obelysk operates on the STARK elliptic curve — the same curve native to Starknet. This page documents the curve parameters, Schnorr proofs, Pedersen commitments, and other primitives used across the protocol.

Curve Parameters

The STARK curve is a short Weierstrass curve over the Stark prime field:

Equation:  y² ≡ x³ + x + β  (mod p)       where α = 1

Field prime (p):
  0x800000000000011000000000000000000000000000000000000000000000001
  = 2²⁵¹ + 17 · 2¹⁹² + 1

Curve order (n):
  0x800000000000010ffffffffffffffffb781126dcae7b2321e66a241adc64d2f

Cofactor: 1 (prime-order group)

Generator Points

Generator G (base point):
  x = 0x1ef15c18599971b7beced415a40f0c7deacfd9b0d1819e03d723d8bc943cfca
  y = 0x5668060aa49730b7be4801df46ec62de53ecd11abe43a32873000c36e8dc1f

Pedersen Generator H (nothing-up-my-sleeve):
  x = 0x73bd2c9434c955f80b06d2847f8384a226d6cc2557a5735fd9f84d632f576be
  y = 0x1bd58ea52858154de69bf90e446ff200f173d49da444c4f462652ce6b93457e

Core Operations

Scalar Multiplication

ec_mul(scalar, point) → point

Computes scalar · point using double-and-add. All scalars are reduced mod n (curve order), not mod p (field prime).

Point Addition

ec_add(P₁, P₂) → P₃

Standard Weierstrass point addition with slope computation.

Modular Arithmetic

mul_mod_n(a, b) → a · b  (mod curve_order)
add_mod_n(a, b) → a + b  (mod curve_order)

Schnorr Proofs

Non-interactive Schnorr proofs (via Fiat-Shamir) are used throughout the protocol for ownership verification.

Protocol

Prover (knows secret sk, public key pk = sk·G):
  1. k ← random scalar
  2. A = k · G                           (commitment)
  3. c = Poseidon(A || pk || domain)     (Fiat-Shamir challenge)
  4. s = k + c · sk  (mod n)            (response)

Verifier:
  1. Recompute c = Poseidon(A || pk || domain)
  2. Check: s · G == A + c · pk

Domain Separators

Pedersen Commitments

Pedersen commitments hide a value while binding the committer to it:

Commit(v, r) = v · G + r · H

Properties:
  - Perfectly hiding: infinitely many (v, r) pairs produce the same commitment
  - Computationally binding: can't find two openings without solving DLP
  - Additively homomorphic: Commit(a, r₁) + Commit(b, r₂) = Commit(a+b, r₁+r₂)

Usage in Obelysk

Chaum-Pedersen Proof

Proves that an ElGamal ciphertext (L, R) correctly encrypts a value under a given public key. This is a dual discrete log equality proof:

Statement:
  L = m·G + r·pk     (encryption)
  R = r·G            (randomness commitment)

Proves: The same r is used in both, and the message m is well-formed.

Same-Encryption Proof

The most complex proof in the protocol. Proves that multiple ciphertexts encrypt the same value under different public keys.

2-Party (Sender + Receiver)

Shared response: sb = kb + c·b     ← SAME b in both checks!
Per-key responses: sr₁, sr₂        ← different randomness per key

Verifier checks both equations with the SAME sb → proves same message.

3-Party (Sender + Receiver + Auditor)

Extends to three parties for compliance. Used by PrivacyRouter when auditor keys are enabled.

Where Each Primitive Is Used

Next Steps

• ElGamal Encryption — full encryption scheme details
• Poseidon2-M31 Primitives — Track 2 hash function
• M31 Field Analysis — why M31 is 250-800x faster
• Whitepaper — formal specifications