0

On new account creation in client-server "zero knowledge encryption" schemes

Client requests a nonce by sending new username
Server sends client a random nonce if username is available.
Client generates new RSA key pair.
Client signs nonce with private key.
Client sends singed nonce AND public key AND clear text username.
Server verifies nonce using public key.

Does this preclude man in the middle attacks?

On the face of it the sever must trust everything send by the 'client' but only the originating client could have signed the nonce with it's own private key. So therefor the public key sent by the client can also be trusted?

Is this true?

5
  • Are you assuming that the nonce is unknowable by everyone except the client?
    – crovers
    Nov 2, 2016 at 20:21
  • 2
    How can this prevent mitm?
    – Mr. E
    Nov 2, 2016 at 20:37
  • the nonce is public, the private key is...private.
    – dave.zap
    Nov 2, 2016 at 21:57
  • Only the true client can sign the nonce with the private key.. no one knows the private key.
    – dave.zap
    Nov 2, 2016 at 22:19
  • 1
    Yeah sleeping on that, mitm could simply generate their own key pairs and sign the nonce on the way to the server
    – dave.zap
    Nov 3, 2016 at 9:48

1 Answer 1

1

What do you want to accomplish with this system? First, Attacker can generate its own pair of key. But why would attacker want to do that? In new account creation process, attacker would want to get the username AND password. Interrupting Server-Client communication by replacing Client's Public key with his is of no point.

Second, even if attacker simply listens to the traffic, it'll get the Client's public key. Now, next time Client sends anything to the server (maybe password?) by encrypting it with private key, attacker will be able to decrypt it with the public key.

2
  • 2
    To your second point: with asymmetric cryptosystems, you don't encrypt secrets with your private key, but with the other party's public key. You only encrypt with your private key when you want to SIGN a document. Nov 3, 2016 at 15:50
  • @PascalSchuppli Yes, I know, but I didn't understand the significance of the proposed system. The only result of this system is that Server is getting Client's public key (and is able to verify it). It'll be of use only when Client is sending something encrypted by its Private key. I know things are normally other way round, Public key encrypts and Private key at server decrypts. Nov 4, 2016 at 7:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .