Hi, [email protected]. I’m curious about zero-knowledge encryption, and I would like to use it in my CS50x final project. My goal is to authenticate users and store their encrypted data on the server so that only the users can decrypt it.
I understand the general concepts of public and private keys, as well as symmetric keys, and how to use them to protect data. However, I don’t understand how to authenticate users. I have searched online for information on implementing the zero proof knowledge authentication flow, but I found either vague high-level descriptions or research papers that require a strong background in mathematics and cryptography to understand and implement.
Could you maybe suggest some resources on this topic? When your search for “how to implement jwt authentication”, you can find many articles that describe the flow with code examples. I’m looking for something similar.
Or should I choose a simpler project?
It seems to me that you’re asking about two different things: zero-knowledge authentication, and public key authentication. I think you’d have a much easier time using public key auth. And tbh I don’t know anything about the zero-knowledge stuff. I don’t know what reading resources to point to, so I’ll try to provide a little clarifying background instead.
The simplest way to a authenticate a user if you have their public key is probably to require every request to be signed with that key. The server gets the request, verifies the signature, and that’s it, that’s an authenticated request. Although adding a nonce to the signed content would be a good idea if replay attacks might be a problem.
If you want to be properly standards-compliant you want a standard “envelope” for signed requests. Personally I would use the multipart/signed MIME type since that is a ready-made, standardized format that is about as simple as it gets.
You mentioned JSON Web Tokens (JWTs) which are a similar idea. That’s a format that you might think you could use for signing requests - it’s sort of another quasi-standardized envelope format for signed data. But the wrinkle is that JWTs aren’t used to sign arbitrary data. The data is expected to be a set of “claims”. A JWT is a JSON header, JSON claims, and a signature all of three which are serialized with base64 and concatenated. Usually you would put a JWT in the Authorization header of an HTTP request like this:
Then the server verifies the JWT signature, inspects the “claims”, and decides whether the request is authorized based on whether it has the right claims. JWTs make sense if you want an authentication token that is separate from the request body. They are more complicated than multipart/signed content since the purpose is to standardize a narrow use case, but to also support all of the features that the stakeholders wanted.
Another commenter suggested Diffie-Hellman key exchange which I think is not a bad idea as a third alternative if you want to establish sessions. Diffie-Hellman used in every https connection to establish a session key. In https the session key is used for symmetric encryption of all subsequent traffic over that connection. But the session key doesn’t have to be an encryption key - you could use the key exchange to establish a session password. You could use that temporary password to authenticate all requests in that session. I do know of an intro video for Diffie-Hellman: https://youtu.be/Ex_ObHVftDg
The first two options I suggested require the server to have user public keys for each account. The Diffie-Hellman option also requires users to have the server’s public key available. An advantage is that Diffie-Hellman authenticates both parties to each other so users know they can trust the server. But if your server uses https you’ll get server authentication anyway during the connection key exchange. And the Diffie-Hellman session password needs an encrypted connection to be secure. The JWT option would probably also need an encrypted connection.
Thanks for your reply. The idea of zero-knowledge authentication is that the password never touches the server. Instead, the user can prove that they know the password when logging in by solving a challenge. This enables the user to log in from any new device without the need to transfer keys between them. I’ll take a closer look at your suggestions though. Thanks again!
All you need in order to do this is for the client to encrypt their password before sending it to the server. Often services that advertise “zero knowledge” platforms that use end-to-end encryption will authenticate their users in this way. If this were a website for example, there could be a javascript/wasm library used within the client page that encrypts their password before a login request is sent to the server.