Distributing the server

[mitar]

In 10.11 Password Salt and Storage Implications it says:

OPAQUE enables defense against such offline dictionary attacks by distributing the server so that an offline attack is only possible if all - or a minimal number of - servers are compromised [JKX18].

My understanding is that the OPAQUE in the paper describes how one could distribute the server, but this spec itself does not mention this anywhere? (Or have I missed it.) Probably using a threshold OPRF? I think it would be beneficial to the spec if this would be more fleshed out somewhere. Or made into one of showcased features of OPAQUE. I think this is a cool feature but currently one finds hidden inside one set of parenthesis.

[stef]

afaik, there is no cfrg/irtf specification for t-oprf, and much less implementations, the only one i am aware of is mine at https://github.com/stef/liboprf/ . anyway the paper and the spec here deviate in a couple of points, so t-opaque is one of those really. on the other hand it is possible to implement t-oprf in a way, that a proxy hides the threshold setup from the client, and thus could enable a threshold opaque without any changes to the spec itself.

[mitar]

My main issue here is that the paragraph is confusing because OPAQUE here is about the one from the paper. Maybe the solution could be to write something like:

OPAQUE [JKX18] enables defense against such offline dictionary attacks by distributing the server so that an offline attack is only possible if all - or a minimal number of - servers are compromised. This is out of the scope of this spec.

[bytemare]

This suggestion sounds reasonable to me. @chris-wood @kevinlewi what do you think?

[kevinlewi]

Good point, I think it would be a good idea to clarify that threshold OPAQUE is out of scope for this spec, since as @mitar mentioned, it is described in the paper. Thanks for bringing this up!

[stef]

i think it is very much possible to implement a threshold opaque without violating the spec.

[hugokraw]

I suggest to keep this "informational-only" remark. Note that the remark touches on an implementation of the server, not a change to OPAQUE. Namely, this mention the possibility of implementing the server's OPRF in a distributed manner. This is a strong defense against essentially the only inherent remaining weakness of a "strong aPAKE", namely, offline dictionary attacks upon server compromise. By distributing the OPRF, you need t+1 parties to be compromised and only then you can start running the offline attack. Actually, with the 2HashDH implementation you get that even if you break into all n servers, you still need an full offline dictionary attack against the password. In short: I propose to keep the remark on a distributed implementation, possibly mentioning a distributed OPRF rather than just "distributing the server", and definitely adding the sentence that this is out-of-scope for this specification.

[chris-wood]

By distributing the OPRF, you need t+1 parties to be compromised and only then you can start running the offline attack.

I don't agree with this assessment. With a server-side threshold OPRF, it's true that the OPRF computation is split across n different servers, but there is still one entity which combines t of them to compute the OPRF value. The threat model doesn't change here: just compromise the entity that combines these values together.

Fundamentally, if the motivation to use a threshold OPRF is to distribute trust in the server away from a single entity, then a server-only threshold OPRF implementation doesn't solve that problem.

EDIT: Ah, wait! You said offline attack, which, yes, I would agree with. I don't think this helps with the online attack though.

[stef]

since the value is blinded, the combining/proxy oprf evaluate function does not learn anything about either the secret of the client, nor of the distributed oprf key. and the combining/proxy oprf evaluate function needs to query the distributed oprf shares for every bruteforce attempt, thus eliminating server offline bruteforce attacks, and thus making them online.

[chris-wood]

Right, I misunderstood the original comment and agree that a server-only threshold implementation forces attacks to either be online or for an attacker to compromise t different key shares.

[stef]

glad that this has been cleared up! <3

[bytemare]

Hello @hugokraw, I took some of your words in your comment to brew a paragraph mentioning TOPPSS, here: https://github.com/cfrg/draft-irtf-cfrg-opaque/pull/397

May I ask you to take a look and tell me what you think?