Introducing Noon: Anonymous but Verified Form Submissions

In an era of ubiquitous digital surveillance, "anonymous" forms often aren't as private as they claim. Most platforms rely on "trust us" policies while collecting IP addresses, browser fingerprints, and session metadata. Noon takes a different approach by employing Blind Signature Cryptography to provide mathematical guarantees of anonymity.

How Blind Signatures Work

Blind signatures, first proposed by David Chaum in 1983, allow a person to get a message signed by another party without the signer ever seeing the content of the message. The resulting signature can be publicly verified against the original, unblinded message.

The RSA-based Process

Noon uses an RSA-based blind signature scheme. Here is the step-by-step mathematical flow:

1. Preparation: The server generates an RSA key pair (n, e, d). The public key (n, e) is shared with the client.
2. Blinding: The client prepares a message m (which should be a cryptographic hash of the form submission). The client then chooses a random blinding factor r such that gcd(r, n) = 1 and computes the blinded message:
   m' = (m · re) mod n
3. Signing: The client sends m' to the server. The server signs it using its private key d:
   s' = (m')d mod n

   Because of the homomorphic property:

   (m · re)d = md · red ≡ md · r (mod n)

   The blinded signature s' is effectively (m^d · r) mod n.

4. Unblinding: The server returns s' to the client. The client removes the blinding factor by multiplying by the modular inverse of r:
   s = s' · r-1 mod n

   The resulting s = m^d mod n is a valid RSA signature for the message m, where m = SHA256(Submission || Nonce).

5. Verification: The client submits the submission data, the nonce, and the signature s. The server recomputes m = SHA256(Submission || Nonce) and verifies it:
   m ≡ se (mod n)

By signing the hash of the actual submission content combined with a unique nonce, Noon ensures that the signature is cryptographically bound to the specific answers provided. This prevents "signature poaching" where a valid signature could be detached from one submission and reattached to another.

Authentication in Noon

Anonymity doesn't mean "anyone can submit." To prevent spam and ensure only authorized participants respond, Noon uses a two-stage process:

1. Identity Verification: Users authenticate via an Email OTP (One-Time Password). Upon success, they receive a short-lived JWT (JSON Web Token).
2. Token Exchange: The user uses this JWT to request a blind signature from the server. The server records that this specific user has used their "right to sign" for a particular form, preventing double-voting.
3. Submission: The user unblinds the signature and submits their response along with the signature. This request is unauthenticated (sent without a JWT or session cookies).

Current Downsides & Vulnerabilities

While cryptographically sound, the current web-based implementation has several weaknesses:

• Network-Level Linkability: If the signing request and the submission request originate from the same IP address within a short timeframe, the server can correlate them regardless of the cryptography.
• Browser Fingerprinting: Browsers reveal a vast amount of metadata (User-Agent, screen resolution, installed fonts, canvas fingerprints). A malicious server can use this to link the "anonymous" submitter to the previously "authenticated" signer.
• Metadata Leaks: HTTP headers, TLS handshakes, and even packet sizes can be used for side-channel analysis to deanonymize users.

Making it Better: The Path to True Anonymity

To achieve the level of privacy required for whistleblowing or sensitive voting, we must move beyond the browser:

1. Proxying via Tor / Onion Routing

The most effective way to break network-level linkability is to ensure that the signing and submission requests follow entirely different network paths.

• Sign request: Authenticated, via standard internet.
• Submit request: Unauthenticated, via Tor or a series of rotating high-quality proxies.

2. A Dedicated Desktop/Mobile App

Web browsers are designed to be identified. A dedicated application can:

• Standardize all outgoing headers to eliminate fingerprinting.
• Enforce "wait times" between signing and submitting to defeat timing attacks.
• Directly integrate with the Tor daemon.
• Zero out memory and local storage more aggressively than a browser environment.

3. Advanced Zero-Knowledge Proofs

While hashing binds the signature to the content, we can further improve the protocol using Zero-Knowledge Proofs (ZKPs) to prove properties about the submission (e.g., "this response is from an authorized domain") without revealing even the blind signature metadata.

4. Temporal Decoupling

Even with network anonymity, a server can use timing analysis to correlate requests. If a signature is issued and a submission follows within seconds, they are likely linked. Implementing mandatory or randomized delays—where a client signs the payload now but waits several minutes or hours before submitting—breaks this temporal link and significantly increases the difficulty of de-anonymization via correlation.

By combining blind signatures with multi-channel network routing, Noon can evolve from a "private-by-policy" system to a "private-by-design" infrastructure.

---

Try out Noon at noon.lupyd.com and check out the open-source code at github.com/lupyd/noon.