Consider alternative implementation of authentication that does not expose the entry decryption key to the server

[boompig]

Not sure if this is actually OK in security circles, wondering how security people deal with this problem. The basic problem:

• The password is used as the encryption key for the entries, and should never be sent to the server. Obviously it's encrypted in transit by TLS, but the server, if malicious, can then read the password and decrypt the entries.
• How to authenticate a user if their password cannot be sent to the server?

[boompig]

Sketch of this idea

Registration

The user's master key K_m is used as the seed to generate a public-private key pair K_pub and K_priv. The server sends a message m and the client returns (K_pub, sign(m, K_priv)). The server then verifies that the message m was signed by the owner of the pair to K_pub and stores K_pub.

Authentication

The server sends an "authentication entry" (AKA a message) m. The client again generates the same key pairs (K_pub, K_priv) using the master key. The client then signs m and returns sign(m, K_priv). The server verifies that the owner of K_priv indeed signed m.

Probably key-pair generation is expensive?

[boompig]

Note that in the above case, for authentication it's equivalent for the client to simply send the public key.

[boompig]

An interesting read is Implementing Zero-Knowledge Authentication with Zero Knowledge. However, our threat model is different from the one that the author presents.

Author's threat model: adversary listening on the wire. Dangers are replay attacks, since information is stored unencrypted on the server and will be yielded to the adversary if they authenticate successfully.

Our threat model: the channel between the client and server is assumed secure. The server was good at account and entry creation time T1, but has now become malicious at time T2. The user would like to read their entries without having them exposed to the malicious server at time T2.

We're not worried about authentication replay attacks, since the server already has all the user's information. The most important information however, (entries) is encrypted. The malicious server's goal is to decrypt those entries.

[boompig]

In the implementation section of the paper "NARWHAL An Implementation of Zero Knowledge Authentication" (2014), they mention various ways of implementing the above authentication scheme, and the issues inherent in these approaches.

Realistically, only the javascript implementation would work here (at least for the website). The authors of the paper talk about how buggy the js crypto libraries are, and that bigint support is needed, and how buggy those libraries are.

From a security perspective, implementing the solution in javascript provides no security benefit, as the website, if malicious, can alter the javascript. However this approach makes a lot of sense for:

(a) a mobile app
(b) browser extension
(c) third-party script

I am just reticent to commit effort in this direction until I am sure that the libraries have stabilized, or until browsers provide native crypto and big int support.

[boompig]

In general this is called Zero-knowledge password proof. One possible implementation is a password-authenticated key exchange (PAKE).

Research:

• Early paper (1992)