Bypass POC for #36: algorithm confusion in local pp verify

[akuraposo]

Algorithm confusion bypass against local pp verify (v0.1.0) — references #36

The local pp verify CLI accepts forged Authority Receipts that claim signatureAlg: "ed25519" but are actually signed with any asymmetric key (RSA, ECDSA, etc.). This is a classic algorithm-confusion vulnerability.

Reproduction:

cd permission-protocol/pp-cli
git checkout 0d282b9    # v0.1.0
npm install
node poc-bypass.mjs     # see attached

Output (vulnerable v0.1.0):

✓ Receipt rcpt_poc_bypass_001 verified
  Signer:        attacker@evil.com
  Action:        deploy:production
  ...

Output (with fix from PR #8):

✗ Receipt FAILED verification
  Reason: failed to read key file: unsupported signing key type: rsa (only Ed25519 is accepted)

Root cause: src/verify.ts calls verify(null, payloadBytes, key, sig). With null algorithm, Node's verify uses the algorithm embedded in the public key. The local resolver in src/keyResolver.ts doesn't assert asymmetricKeyType === 'ed25519'.

Scope of POC: I only have access to the local pp verify CLI. The deploy-gate GitHub Action calls the PP API endpoint, which may use a different verification code path. If the API has the same flaw, the server-side equivalent of this POC is also a bypass. If the API pins Ed25519 explicitly, then this is a CLI-only issue (still a security bug, but not a full bypass against the bounty target).

POC script and full write-up: see PR #8 in permission-protocol/pp-cli.

Payout: PayPal rubynich9@gmail.com (Venmo unavailable).

GitHub: @akuraposo

[akuraposo]

@rodchalski following up — would it be possible to clarify the scope of #36?

The local pp verify CLI in permission-protocol/pp-cli v0.1.0 accepts a forged receipt (algorithm confusion: RSA key, claim of ed25519). The receipt looks like a normal Authority Receipt and would pass any downstream consumer that trusts the CLI exit code.

I can only test against the local CLI (no PP_API_KEY). If the production pp verify endpoint at app.permissionprotocol.com uses the same verify(null, ...) + createPublicKey pattern, the same POC works against the API too — and that's clearly within #36's scope. If the API explicitly pins Ed25519, then this POC is a CLI-only issue (still a real security bug, but not the full bypass the bounty is asking for).

Two questions:

1. Can you share a sandbox / test API key so I can demonstrate the same POC against the live endpoint?
2. If not, would you accept the local CLI POC as a "flaw in the Ed25519 signing/verification flow" (one of the three explicit categories in Challenge: Bypass the Ed25519 signature verification ($200 bounty) #36)?

POC script: see poc-bypass.mjs (and the README in the issue body).
Fix: PR #8 in permission-protocol/pp-cli.

PayPal: rubynich9@gmail.com (Venmo unavailable).