P-256 vs 3DES: Why the Next Card Network Won't Use Visa's Crypto

Visa's payment cards still use 3DES (Triple Data Encryption Standard) for transaction authentication. It's a symmetric-key algorithm from the 1990s.

We built a card network using P-256 ECDSA instead. Here's why it matters.

What Visa Uses: 3DES

3DES applies the DES cipher three times to each data block. It was adopted by payment networks in the late 1990s as an upgrade from single DES.

Key characteristics:

• Symmetric key: Same key encrypts and decrypts
• 112-bit effective security (with 168-bit key)
• Block cipher: 64-bit blocks
• NIST deprecated: Officially deprecated in 2023, disallowed after 2023 for new applications

The problem: symmetric keys mean the card and the terminal/issuer share a secret. Key management becomes the weak point. And 112-bit security is below modern recommendations.

What We Use: P-256 ECDSA

P-256 (also known as secp256r1 or prime256v1) is an elliptic curve used in:

• TLS 1.3 (securing the web)
• Apple's Secure Enclave
• FIDO2/WebAuthn (passkeys)
• Modern EMV chip cards
• Our payment card

Key characteristics:

• Asymmetric key: Private key signs, public key verifies
• 128-bit equivalent security (with 256-bit key)
• No shared secrets: The card holds the private key; only signatures leave the chip
• On-chain verifiable: Via RIP-7212 precompile on EVM chains

Why Asymmetric Wins for Payments

With 3DES, if an acquirer or processor is compromised, the symmetric keys can be extracted and used to create fraudulent transactions.

With P-256 ECDSA, the private key never leaves the card's secure element. You can verify a transaction's authenticity without ever knowing the signing key.

This is why we can verify payment signatures on a public blockchain. The card signs, the chain verifies. No trusted third party needed.

The RIP-7212 Precompile

Verifying P-256 signatures in a smart contract used to be prohibitively expensive (~300K gas). The RIP-7212 precompile reduces this to ~3,450 gas.

This is what makes on-chain card payment verification economically viable on L2s like Base.

Our flow:

1. Card taps terminal, signs payment data with P-256
2. Transaction submitted to Base L2
3. RIP-7212 precompile verifies the signature (~3,450 gas, sub-cent)
4. ClearingVault releases AUD stablecoins to merchant's CREATE2 receiver

Java Card Implementation

Our card runs a custom applet on a JCOP4 (Java Card Open Platform) chip. The applet:

1. Generates and stores a P-256 key pair in the card's secure element
2. Implements the EMV contactless protocol (so terminals recognize it)
3. Signs transaction data on tap
4. Returns the signature and payment metadata via NFC

The same applet supports three form factors: physical card, mobile NFC (HCE), and can generate QR codes for wallet-based payments.

The Result

Stronger cryptography, no shared secrets, on-chain verifiability, and a payment experience identical to tapping a Visa card.

3,200+ users, 20+ Sydney cafes, settling in seconds instead of days.

---

Built by OpenPasskey. Follow @OpenPasskey.