Privacy and encryption
The short version
Participant results are stored on the server in encrypted form. Encryption is arranged so that a person with full access to the machine — including the site administrator — still cannot read those results.
When you deploy a test you choose a password. That password never leaves your computer as plaintext, is not stored on the server in any recoverable form, and is the only thing that can later unlock the results. If you lose it, the data is gone. That is the cost of keeping it private.
What the server can see
The hosted service needs enough information to run the test and to hand results back to you. It does not need to read the answers.
- It stores the test configuration you uploaded so the administration pages can be served.
- It stores each completed administration as ciphertext, plus the public half of a key pair that can lock a result but cannot unlock it.
- It stores an encrypted copy of the matching private key. That blob is useless without the password you chose at deploy time.
- It cannot reconstruct that password. It cannot decrypt a result set. A database dump is not a results file.
What you do
You set the password on the machine that deploys the test. IAT Design keeps a local copy so the same computer can retrieve results without asking again. Any other computer must be given the password at retrieval time.
Treat the password the way you would treat a key to a filing cabinet of identifiable records. Do not email it. Do not reuse a password you use elsewhere. Write it down somewhere that is not the server.
There is no password-reset path for results. Resetting would mean the server could, at some later date, grant itself the ability to read the data. That is the opposite of the design.
What this does not claim
Encryption of stored results is not the same thing as participant anonymity.
- If a survey item asks for a name, an email address, a student ID, or anything else that identifies a person, that answer is inside the encrypted payload. The server cannot read it. You can, once you retrieve the file.
- Product activation uses a verified email address so that image uploads can be tied to a responsible author. That address is an account contact. It is not the results password, and it cannot unlock a result set.
- The connection that carries the test to a participant is ordinary HTTPS. That protects the session in transit. It is a different problem from making the stored file unreadable at rest.
- If you embed the test on another site, that site’s own logging, analytics, and consent language are yours to handle. IAT Design encrypts what it stores. It does not run your IRB protocol.
If something goes wrong
Lost password: the encrypted results cannot be recovered. Not by you, not by support, not by restoring a backup. Delete the test when you are done with it if you no longer need the file.
Compromised deploy machine: anyone who can use IAT Design on that computer with the saved password can retrieve results. Protect the machine the same way you would protect any research workstation that holds identifiable data.
Server breach: an attacker who copies the database has ciphertext, public keys, and an encrypted private-key blob. Without the deploy password they cannot read participant answers. That is the point of the design. It is not a substitute for patching the host.
How the lock is built
Two standard algorithms are used together because they are good at different jobs.
AES-GCM encrypts the result set itself. It is a modern symmetric cipher: the same secret both locks and unlocks the data, and it also produces an authentication tag so a tampered file fails to decrypt rather than decrypting into garbage that looks plausible.
RSA is used only to wrap that AES key. RSA is public-key encryption. The public half can lock a small secret. The private half can unlock it. The private half never sits on the server in usable form.
RSA is not used to encrypt the results directly. It is slow, and a single RSA operation can only protect a few hundred bytes. Wrapping a 256-bit AES key is exactly the job it is sized for. AES then handles the payload.
At deploy
- You enter a password on the deploy machine.
- IAT Design derives a symmetric key from that password. The derivation is deterministic: the same password later produces the same key. The password itself is not sent.
- The client generates an RSA key pair for this test.
- The private RSA material is encrypted under the password-derived key and sent to the server as a decryptor blob.
- The public RSA key is stored in the clear. It can encrypt. It cannot decrypt.
When a participant finishes
The server builds a plaintext result document — survey answers plus IAT trial data. It then:
- Generates a fresh AES-256 key and a fresh nonce.
- Encrypts the result document with AES-GCM. The ciphertext, the authentication tag, and the nonce are stored.
- Encrypts the AES key with the test’s RSA public key and stores that wrapped key next to the ciphertext. The AES key in the clear is discarded.
Each administration gets its own AES key. Compromising one wrapped key, were that possible, would not unlock the others.
When you retrieve results
- You enter the deploy password, or the client uses the copy stored on that machine.
- The same derivation produces the key that unlocks the decryptor blob.
- The private RSA key is now available on your computer only.
- For each result row, the private key unwraps that row’s AES key.
- AES-GCM decrypts the payload. A bad password, a truncated file, or a flipped bit fails the tag check and is rejected.
What “unreadable on the server” means, precisely
The server holds: ciphertext, GCM tag, nonce, RSA-wrapped AES keys, the RSA public key, and the password-encrypted private-key blob. None of those objects is the password. None of them is a usable private key. Reading the database is not reading the study.
On strength, without theater
AES-256 is the current standard for data at rest. A correct implementation is not broken by “having a fragment of ciphertext and the matching plaintext,” which is a claim the old page made and which is not how modern authenticated encryption fails. The practical risks are a weak password, a copied deploy workstation, and implementation error — not an amateur factoring the AES key by hand.
RSA’s public modulus is the product of two large primes. Recovering those primes from the modulus would yield the private key. For a 2048-bit modulus that remains infeasible with publicly known classical methods; sites still rotate TLS certificates on a schedule measured in months and years, not hours. The construction here does not invent a new public-key scheme. It uses RSA the way TLS and package signing use it: to protect a small symmetric secret.
This page is not a cryptography paper and does not walk through Miller–Rabin primality testing or modular exponentiation. Those details belong in a textbook. What belongs on a product site is the threat model: who can read a result, who cannot, and what you lose if you lose the password.