You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jan 31, 2025. It is now read-only.
Repository navigation
This repository was archived by the owner on Jan 31, 2025. It is now read-only.
How does OPAQUE relates to DE-PAKE and Sphinx? #15
I am trying to understand this project. So for some time it included OPAQUE implementation but it was then removed. But DE-PAKE seems to be a predecessor to OPAQUE? Isn't OPAQUE (as defined in latest RFC) already supporting an easy extension for being a password manager? It includes "export key" which can be used to store additional encrypted data for clients: https://cfrg.github.io/draft-irtf-cfrg-opaque/draft-irtf-cfrg-opaque.html#name-export-key-usage
So is Sphinx then a parallel alternative development of similar ideas?
the relation between opaque and sphinx is that both are using an oprf underneath, actually sphinx is just an oprf, while opaque is an AKE which is a whole lot of stuff more that is not needed for sphinx. and also opaque itself cannot be used as a replacement for sphinx, as the naive usage of opaque for password storage would elminate the offline-bruteforce resistance, that is one of the great security guarantees that is setting it apart from almost all other password managers.
the opaque implementation that was previously part of libsphinx is now in its own library with a whole lot of bindings and other stuff here: https://github.com/stef/libopaque/
there was actually an experimental variant of sphinx which used opaque, or rather the other way around, it was opaque, but if not needed it didn't do the ake, and thus was merely sphinx. but it was suffering from what i alluded above, the lack of offline-bruteforce resistance, and thus was decommissioned. however with the advent of a threshold-oprf as implemented in https://github.com/stef/liboprf/ we will be able to implement a sphinx variant that can resurrect the opaque around it, and indeed that is the plan for v2 of sphinx, in the near future.
Thanks for fast and elaborate replies! I will read more about this, at the moment it all goes way over my head. But my understanding with OPAQUE was that it allows offline backups (like what is used at WhatsApp) and that those backups are protected against offline attacks? It seems not. :-(
But my understanding with OPAQUE was that it allows offline backups (like what is used at WhatsApp) and that those backups are protected against offline attacks? It seems not. :-(
i don't quite understand this question. and i think it is a misunderstanding. opaque does not protect against offline dictionary attacks, it merely makes it more difficult. whereas sphinx does. but the two things are used for very different uses. with sphinx, if a sphinx server "database" leaks, an attacker cannot run a search for passwords offline. since there is nothing that can confirm to the attacker if a guess is correct. with opaque, there is ample data available that allows an attacker to use leaked opaque server database to guess passwords while being offline.
so the best thing you can do is have whatever server you wanna run, have that use opaque. and use a completely separate sphinx server to handle your passwords that you use against your opaque-using server.
with sphinx, if a sphinx server "database" leaks, an attacker cannot run a search for passwords offline.
So then I could simply store my password "database" in GitHub's public git repository. :-)
so the best thing you can do is have whatever server you wanna run, have that use opaque. and use a completely separate sphinx server to handle your passwords that you use against your opaque-using server.
Hm, but it would have to be two different passwords. Otherwise one could do attack against opaque server to recover the password and then use it to get to your other passwords.
Repository owner locked and limited conversation to collaborators on Feb 25, 2023
Activity
stef commentedon Feb 25, 2023
the relation between opaque and sphinx is that both are using an oprf underneath, actually sphinx is just an oprf, while opaque is an AKE which is a whole lot of stuff more that is not needed for sphinx. and also opaque itself cannot be used as a replacement for sphinx, as the naive usage of opaque for password storage would elminate the offline-bruteforce resistance, that is one of the great security guarantees that is setting it apart from almost all other password managers.
stef commentedon Feb 25, 2023
the opaque implementation that was previously part of libsphinx is now in its own library with a whole lot of bindings and other stuff here: https://github.com/stef/libopaque/
stef commentedon Feb 25, 2023
there was actually an experimental variant of sphinx which used opaque, or rather the other way around, it was opaque, but if not needed it didn't do the ake, and thus was merely sphinx. but it was suffering from what i alluded above, the lack of offline-bruteforce resistance, and thus was decommissioned. however with the advent of a threshold-oprf as implemented in https://github.com/stef/liboprf/ we will be able to implement a sphinx variant that can resurrect the opaque around it, and indeed that is the plan for v2 of sphinx, in the near future.
stef commentedon Feb 25, 2023
more about oprfs in layman terms: https://ctrlc.hu/~stef/blog/posts/oprf.html
stef commentedon Feb 25, 2023
not to mention with threshold-oprf we will also be able to do a threshold-opaque! super exciting stuff!
stef commentedon Feb 25, 2023
furthermore the next version of sphinx will replace libsphinx with liboprf entirely.
mitar commentedon Feb 25, 2023
Thanks for fast and elaborate replies! I will read more about this, at the moment it all goes way over my head. But my understanding with OPAQUE was that it allows offline backups (like what is used at WhatsApp) and that those backups are protected against offline attacks? It seems not. :-(
stef commentedon Feb 25, 2023
i don't quite understand this question. and i think it is a misunderstanding. opaque does not protect against offline dictionary attacks, it merely makes it more difficult. whereas sphinx does. but the two things are used for very different uses. with sphinx, if a sphinx server "database" leaks, an attacker cannot run a search for passwords offline. since there is nothing that can confirm to the attacker if a guess is correct. with opaque, there is ample data available that allows an attacker to use leaked opaque server database to guess passwords while being offline.
mitar commentedon Feb 25, 2023
Oh, you should link to this and https://ctrlc.hu/~stef/blog/posts/sphinx.html from README. Also I just now found PDFs in the
docdirectory.stef commentedon Feb 25, 2023
so the best thing you can do is have whatever server you wanna run, have that use opaque. and use a completely separate sphinx server to handle your passwords that you use against your opaque-using server.
stef commentedon Feb 25, 2023
may i ask how did you find this repo?
mitar commentedon Feb 25, 2023
I was searching for Go OPAQUE implementations and it was listed here:
https://github.com/cretz/gopaque
mitar commentedon Feb 25, 2023
So then I could simply store my password "database" in GitHub's public git repository. :-)
Hm, but it would have to be two different passwords. Otherwise one could do attack against opaque server to recover the password and then use it to get to your other passwords.