RATING

The student feedback dilemma

Universities need candid student evaluations to maintain course quality. Traditional survey systems face a trilemma: - Anonymity: Students need total confidence that teaching staff cannot trace critical comments back to their student registration number or login account. - Sybil resistance: The university must guarantee that only enrolled students can vote, and that each enrolled student submits at most one rating per course. - Integrity: Students and auditors need proof that submitted ratings were actually counted in the final summary, without relying on blind trust in database administrators.

Centralized web forms fail this trilemma. Even when a checkbox says "anonymous", the web server records login sessions, IP addresses, and timestamps. If student IDs are removed entirely, anyone with the link can spam fake reviews.

We solve all three requirements with elliptic-curve cryptography, without a central authority holding the power to deanonymize students.

LSAG ring signatures

We use Linkable Spontaneous Anonymous Group (LSAG) ring signatures over the SECP256k1 elliptic curve (y^2 = x^3 + 7 mod p).

When a student enrolls in a course through Moodle, their browser generates a private scalar x and registers the public point P = x · G. When submitting feedback, the student fetches the public keys of all classmates enrolled in that module: R = [P_1, P_2, ..., P_k].

How the signature is formed

The student computes a ring signature sigma = (I, c_0, [s_1, s_2, ..., s_k]). The signature forms a cryptographic ring: each step hashes the previous point and scalar multiplier. The signer closes the ring using their private scalar x at their own secret position, while generating random decoy scalars for all classmates.

A verifier checks that the ring closes correctly using public points only. The verifier confirms that an enrolled student signed, but learns zero information about which classmate created it.

Key image nullifiers

To prevent duplicate submissions without identifying students, each LSAG signature includes a key image (nullifier): I = x · H(R), where H(R) maps the public key ring to a valid point on SECP256k1, and x is the student's private scalar for that module.

Why duplicate voting fails

Because elliptic curve point multiplication is deterministic, the same student signing for the same module key ring will always produce the exact same key image I. The Feedback Server stores used key images in an indexed set. When a second submission arrives with an existing key image, the server rejects it as a double-vote.

Cross-module unlinkability

Students generate a distinct, independent SECP256k1 keypair for every enrolled module. Because the private scalar x and the ring R differ between modules, the key image I in CS402 shares no mathematical correlation with the key image in CS403. Even if a student submits reviews for five different courses, no entity can link those submissions together.

Hybrid ECIES encryption

Submissions use hybrid authenticated encryption: 1. The student browser generates an ephemeral 256-bit symmetric key K_sym. 2. The review payload (numeric rating and text comment) is sealed using AES-128-GCM under K_sym with a unique 96-bit nonce, producing the ciphertext and 16-byte authentication tag. 3. The symmetric key K_sym is encrypted under the module's public key K_pub = d · G using ECIES (Elliptic Curve Integrated Encryption Scheme).

Decoupled service architecture & key ownership

The system decouples identity, storage, and verification across three isolated services: - Moodle Server (:8001): Manages student enrollments and stores the module's private key d. Because Moodle generates and holds d, it has the cryptographic authority to decrypt course feedback for the teaching staff. - Feedback Server (:8002): Receives anonymous submissions, verifies LSAG ring signatures, checks key image nullifiers, and stores ciphertexts in the Merkle log. It never holds the private key d and cannot decrypt any review. - Verifier Server (:8003): Public audit engine that validates cryptographic proofs. Like the Feedback Server, it only ever sees ciphertext.

When the lecturer logs into Moodle to inspect feedback, Moodle fetches the ciphertexts from the Feedback Server over an authenticated machine-to-machine (M2M) API, decrypts them locally using the module private key d, and displays the reviews. Because submissions carry only ring signatures and zero student identifiers, neither Moodle nor the lecturer can tell which student wrote which review.

RFC 9162 binary Merkle tree

Each module maintains an append-only binary Merkle tree following RFC 9162 (Certificate Transparency):

• Leaf hash: SHA-256(module_id ‖ encrypted_feedback ‖ sig_hash) where sig_hash = SHA-256(canonical_json(sigma)).
• Interior node: SHA-256(0x01 ‖ left_child ‖ right_child).

Inclusion receipts

Upon successful submission, the student receives a permanent receipt: { receipt_token, module_id, leaf_hash, leaf_index }.

Any student can independently verify that their review was incorporated into the published evaluation summary. The verifier requires only ceil(log2 N) sibling hashes to prove inclusion against the published merkle_root. For a class of 256 students, only 8 hashes prove complete integrity.

Independent verifier engine

Our Verifier Server (:8003) is completely decoupled from both Moodle and the Feedback database: - It maintains its own isolated database (verifier_db.sqlite3). - It has zero direct database connections to Moodle or the Feedback Server. - It interacts strictly over public HTTP REST endpoints. - It operates solely on ciphertexts and cryptographic proofs, never seeing decrypted feedback.

# Audit a student receipt token against the live Merkle root:
curl -X POST https://erating-moodle.onrender.com/api/verify/audit/ \
  -H "Content-Type: application/json" \
  -d '{"receipt_token": "rcpt_7f3a9c..."}'

The audit verifies that: 1. The leaf hash correctly binds the ciphertext to the signature hash. 2. The Merkle sibling path hashes up to the active published root. 3. The LSAG signature satisfies the ring equation over SECP256k1. If any check fails, the verifier returns an explicit error code naming the exact point of failure.