I currently have this TOFU protocol:

First connection:

  1. Client generates salt and inputs a password
  2. Client saves salt
  3. Client hashes password with argon2 and salt
  4. Client generates Ed25519 keys
  5. Client sends to the server: Ed25519 public key, argon2 hashed password
  6. Server saves received Ed25519 public key and argon2 hashed password

After first connection:

  1. Server sends to client a newly generated nonce
  2. Client receives nonce inputs a password
  3. Client hashes the password with argon2 (salt is retrieved from file), then the nonce is appended to it, then the result of the append is hashed with SHA-2, then the final hash is signed with a Ed25519 private key
  4. Client sends signature to server
  5. Server verifies with the Ed25519 public key (Ed25519 public key is retrieved from file) and argon2 hashed password (argon2 hashed password is retrieved from file) which also goes through the SHA-2 with the nonce which was earlier generated and sent

So my question is, is this protocol secure to verify the user has both the Ed25519 private key and the correct password? If yes is there a way to keep the same level of security while making it simpler, also is the SHA-2 necessary in after connection step 2? If not what are the flaws and how do you recommend to fix them?

Also, does a protocol like this already exist?

  • $\begingroup$ What are you hoping to do with the proposition that someone knows the password and Ed25519 private key? Are you going to have a conversation with them, so that what you really want is an authenticated key agreement? $\endgroup$ – Squeamish Ossifrage May 15 '19 at 18:15
  • $\begingroup$ @SqueamishOssifrage my goal is to have an authenticated conversation, I am currently using Signal Protocol and reading about [authentication with nonce][signal.org/docs/specifications/sesame/… and I wanted to add a password into the mix. $\endgroup$ – OughtToPrevail May 15 '19 at 18:20
  • $\begingroup$ So it sounds like you want to sign the outcome of a PAKE with the Ed25519 key, since presumably you would want to ensure that even if an adversary compromised the Ed25519 key, a transcript of the network interaction of a MITM attack wouldn't help them to guess the password offline. $\endgroup$ – Squeamish Ossifrage May 17 '19 at 1:18
  • $\begingroup$ Well yes, but I also want to make sure, if a password was compromised an attacker still can't be authenticated since he also must have the Ed25519 private key from the registration. $\endgroup$ – OughtToPrevail May 17 '19 at 6:30
  • $\begingroup$ Hence ‘sign the outcome of a PAKE with the Ed25519 key’ so that you reject authentication attempts if they do not prove ownership of the Ed25519 key. $\endgroup$ – Squeamish Ossifrage May 17 '19 at 14:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.