1

I wrote an implementation of a non-interactive zero-knowledge proof system as outline in this research paper. As far as I can tell, it functions flawlessly as intended with text secrets such as authentication passwords.

# USER REGISTRATION:
  # CLIENT-SIDE
    client_zk = ZKProof.new(bits=256, curve_name="secp256k1")
    signature = client_zk.create_signature("Passw0rd")
    # send zk.params and signature to server for persistent storage


# USER AUTHENTICATION:
  # SERVER-SIDE
    server_zk = ZKProof(client_zk.params)
    token = ZKProof.random_token(bits=256)
    # send token to client

  # CLIENT-SIDE
    challenge = client_zk.create_challenge("Passw0rd", token)
    # send challenge to server

  # SERVER-SIDE
    if server_zk.prove_challenge(challenge, signature, token):
      # user is authenticated...

While this use case is great for something like user databases, it does nothing for data protection. I am designing an application which will store encrypted text on the server. If I use a symmetric encryption algorithm, I can create proofs to ensure that the user is in possession of a particular password (assuming it was honestly registered when the key was created), however I have no way of VERIFYING that the encrypted data received by the server was indeed encrypted using that password since the server does not have access to the plain text OR encryption key. How can I best approach this?

Note: I CAN actually verify that a password (or key) was used to generate a zero-knowledge PROOF, but not the actual integrity of the data itself.

Goodies
  • 135
  • 1
  • 8
  • The protocol is zero-knowledge, so the verifier can only learn if the prover knows the password, and nothing more. Therefore, you'll need to at least modify your protocol if not use a different one. We'd need to know more about what you security you're seeking to achieve through encrypting the data. For example, why can't the client just give whatever data, and if it's not encrypted properly then it's their own loss? It's also somewhat alarming that you're using the same secret in two cryptographic primitives (authentication and the data encryption). – theaspirer Jan 02 '20 at 05:53
  • Hello! The application in question is a password manager, so storing the password entries encrypted is simply a must. Also, the same password is not used into the two primitives. Each user will have their own user-specific passwords for authentication, but a single shared "password" that is used to encrypt/decrypt the data. I can prove that the user does indeed HAVE the password, but cannot prove that it was used in something like AES. – Goodies Jan 02 '20 at 06:09
  • How about you derive a key from the password, then encrypt/decrypt the data using the derived key? Only people how know the password can decrypt. – theaspirer Jan 02 '20 at 07:18
  • Well, that's essentially what I'm trying to do. That's all well and good if everyone was an honest prover and an honest verifier. But just because I prove that I have a password doesn't mean that I have to use it to encrypt the data unless the ciphertext has a signature that can be used to verify the key that was used. I don't think this is really possible, honestly. – Goodies Jan 02 '20 at 19:25

0 Answers0