SIGNATURE GATE / CHAPTER 01

Who gets to verify?

Ordinary P-256 ECDSA · WebCrypto · SHA-256

Try the problem first: Alice signs a fictional agreement. Bob checks it. Then he forwards the same evidence to Dave, who can check it too. Change the agreement and see both reject it.

Chapter 01 is working. The full confirmer protocol is still being built. This exercise uses real ECDSA to show why anyone can verify an ordinary signature. The separate protocol where Carol proves a signature valid or invalid is not yet implemented; Chapters 02–04 remain unavailable. Use fictional information only.
New research exercise: Carol can answer Bob's mathematical challenge. Try the interactive 2013 OR-confirmation workbench: Alice or Carol responds to Bob's challenge, then Eve tries to fake a proof by choosing the challenge before her commitment. You can predict, forge, and inspect the rejection yourself. It is not secure DCS confirmation. Its symbolic group exposes secrets; genuine disavowal, full non-transferability and the final 2016 construction remain unfinished.
Now available: real BLS12-381 signature and pairing experiments. Open the Real Pairing Research Workbench. Alice and Carol can answer real elliptic-curve OR-proof challenges; Bob independently checks the equations. Alter the alleged message to examine an explicitly research-candidate invalidity proof, then see how Eve can simulate a convincing transcript by choosing her own challenge. This is genuine group arithmetic but not a security-proven, audited designated-confirmer protocol. Its Type-3 adaptation, corrected proof candidate and non-transferability remain under independent review.

ONE / THE PUBLIC SIGNATURE

An agreement anyone can check

Start by generating Alice's temporary signing key. Bob and Dave will import copies of her public key and perform their own cryptographic verification.

01 / SIGNERA

Alice

Holds a private signing key, never exported.

Public key SHA-256 fingerprintNot generatedSignature (P1363 r ∥ s)Not signed
02 / RECIPIENTB

Bob

Only gets Alice's public key, the message and signature.

NOT TESTED

No special confirmer is needed for an ordinary digital signature.

03 / OUTSIDERD

Dave

Bob forwards exactly the same public evidence to Dave.

NOT TESTED

Dave imports the public key for himself. He does not need Alice's private key or Bob's permission.

Now try to cheat.

After signing, change the statement. A genuine verifier must reject those different bytes. You can also change the text manually.

READY TO START

Generate Alice's temporary key pair to begin the real cryptographic experiment.

THE LESSON

What did the signature actually establish?

Signature verified means the message bytes match what was signed under Alice's public key. It does not prove that a package was delivered or that anyone has independently checked Alice's real-world identity.

Dave can verify an ordinary signature even if Alice never speaks to him. But a valid signature on “Package delivered” still does not prove that a package was actually delivered.

In this fictional example, a separate dispatch note reads: “Status: not delivered.” The note is not cryptographic evidence and could itself be wrong; it illustrates that signatures do not adjudicate external facts.

Inspect the actual algorithm, evidence and limits

Alice uses browser-native ECDSA over NIST P-256 and SHA-256. The private CryptoKey is non-extractable. Her public key is exported in SPKI format, copied and re-imported independently by Bob and Dave. The ECDSA signature is a 64-byte IEEE P1363 r∥s value. Signing uses a fixed, domain-separated prefix bound to the experiment.

When you change the message, the signature remains the original—verifiers recompute SHA-256 over the *changed* message and should reject it. The signature is not encrypted. The experiment uses synthetic statements only and performs no uploads, account creation or local storage.

The unfinished goal: Carol should be able to help Bob check whether Alice signed this particular agreement—or prove that an alleged signature is invalid—by running the published mathematical protocol. Bob should not automatically receive an ordinary signature he can show to everyone. Those real confirmation, disavowal and non-transferability requirements are not implemented by this exercise.

P-256 published verification vector (RFC 6979 Appendix A.2.5) · Research gate · Product vision