I just published an RFC compliant Java implementation of OPAQUE/OPRF. OPAQUE provides authentication without the need to share the passwords... rendering server's authentication database useless for offline attacks. This implementation, with Typescript/Client support and Open API specs, can be found here: https://github.com/codeheadsystems/hofmann-elimination

I'd love to get a few eyes on it, looking for comments or security concerns. It's Apache 2 licensed and I'd love to get this (or something like it) everywhere to reduce the value of powning servers. I plan more ports to other languages, go, rust, c#.

#Java #Authentication #cryptography #infosec #opaque #oprf #rfc

GitHub - codeheadsystems/hofmann-elimination: OPF framework for shared keys built from sensitive data

OPF framework for shared keys built from sensitive data - codeheadsystems/hofmann-elimination

GitHub

in liboprf we have an updatable OPRF without using a pairing, and with klutschnik we have a project that does updatable public key encryption, for data at rest. why is their upstream academic research not even mentioned in this paper: https://eprint.iacr.org/2025/175

Hugo Krawczyk is even a colleague of some of these authors.

#upke #crypto #oprf

Updatable Public-Key Encryption, Revisited

We revisit Updatable Public-Key Encryption (UPKE), which was introduced as a practical mechanism for building forward-secure cryptographic protocols. We begin by observing that all UPKE notions to date are neither syntactically flexible nor secure enough for the most important multi-party protocols motivating UPKE. We provide an intuitive taxonomy of UPKE properties -- some partially or completely overlooked in the past -- along with an overview of known (explicit and implicit) UPKE constructions. We then introduce a formal UPKE definition capturing all intuitive properties needed for multi-party protocols. Next, we provide a practical pairing-based construction for which we provide concrete security bounds under a standard assumption in the random oracle and the algebraic group model. The efficiency profile of the scheme compares very favorably with existing UPKE constructions (despite the added flexibility and stronger security). For example, when used to improve the forward security of the Messaging Layer Security protocol [RFC9420], our new UPKE construction requires $\approx 1\%$ of the bandwidth of the next-most efficient UPKE construction satisfying the strongest UPKE notion previously considered.

IACR Cryptology ePrint Archive

evolution of generative password "storage" over the last decades:

1. "password"
2. hash("password")
3. hmac("password", site)
4. oprf("password"+site, sphinx-oracle)
5. t-oprf(password+site, [sphinx-oracle1, sphinx-oracle2, ... sphinx-oracleN])

#crypto #oprf #passwordmanager

check out https://sphinx.pm, v2 with threshold oprf coming soon...

SPHINX password storage

with the help of @vegetables i finally got it working. i had two off-by-ones, and i was messing up the generation of the commitments. \o/ robust updatable threshold oprfs here i come! expect some code hitting the liboprf repo soon.

#ngi0 #crypto #oprf #multipartyComputation #liboprf

for liboprf i try to implement the robust multiparty multiplication from Genarro,Rabin,Rabin '98. I struggle with implementing a check (the paper calls VSPS property). I asked the original authors 2 months ago, but they don't reply - i guess they're busy. I wrote up the relevant part of the paper, and my confusion and questions in this simple text (best viewed with a fixed with font!): https://ctrlc.hu/~stef/vsps_check.mail.txt - any help would be appreciated.
#crypto #multiparty #mpc #oprf

just prototyped this 3hashtdh from https://eprint.iacr.org/2024/1455 in python using pyoprf, and it is surprisingly simple and elegant. really looking forward to add it properly to liboprf. adding the t-opaque from the paper is a childs play, for each "target server" one additional hkdf call is all that is necessary besides using 3hashtdh...
https://github.com/stef/liboprf/blob/master/python/3hashtdh.py#L16-L21

#threshold #oprf #crypto #liboprf

Threshold PAKE with Security against Compromise of all Servers

We revisit the notion of threshold Password-Authenticated Key Exchange (tPAKE), and we extend it to augmented tPAKE (atPAKE), which protects password information even in the case all servers are compromised, except for allowing an (inevitable) offline dictionary attack. Compared to prior notions of tPAKE this is analogous to replacing symmetric PAKE, where the server stores the user's password, with an augmented (or asymmetric) PAKE, like OPAQUE [JKX18], where the server stores a password hash, which can be used only as a target in an offline dictionary search for the password. An atPAKE scheme also strictly improves on the security of an aPAKE, by secret-sharing the password hash among a set of servers. Indeed, our atPAKE protocol is a natural realization of threshold OPAQUE. We formalize atPAKE in the framework of Universal Composability (UC), and show practical ways to realize it. All our schemes are generic compositions which interface to any aPAKE used as a sub-protocol, making them easier to adopt. Our main scheme relies on threshold Oblivious Pseudorandom Function (tOPRF), and our independent contribution fixes a flaw in the UC tOPRF notion of [JKKX17] and upgrades the tOPRF scheme therein to achieve the fixed definition while preserving its minimal cost and round complexity. The technique we use enforces implicit agreement on arbitrary context information within threshold computation, and it is of general interest.

IACR Cryptology ePrint Archive
hah! a paper on #threshold #oprf and threshold #opaque by jarecki et al, although krawczyk is missing from the team, it still will be interesting to see how far their paper is from my toprf and topaque implementations. https://eprint.iacr.org/2024/1455
Threshold PAKE with Security against Compromise of all Servers

We revisit the notion of threshold Password-Authenticated Key Exchange (tPAKE), and we extend it to augmented tPAKE (atPAKE), which protects password information even in the case all servers are compromised, except for allowing an (inevitable) offline dictionary attack. Compared to prior notions of tPAKE this is analogous to replacing symmetric PAKE, where the server stores the user's password, with an augmented (or asymmetric) PAKE, like OPAQUE [JKX18], where the server stores a password hash, which can be used only as a target in an offline dictionary search for the password. An atPAKE scheme also strictly improves on the security of an aPAKE, by secret-sharing the password hash among a set of servers. Indeed, our atPAKE protocol is a natural realization of threshold OPAQUE. We formalize atPAKE in the framework of Universal Composability (UC), and show practical ways to realize it. All our schemes are generic compositions which interface to any aPAKE used as a sub-protocol, making them easier to adopt. Our main scheme relies on threshold Oblivious Pseudorandom Function (tOPRF), and our independent contribution fixes a flaw in the UC tOPRF notion of [JKKX17] and upgrades the tOPRF scheme therein to achieve the fixed definition while preserving its minimal cost and round complexity. The technique we use enforces implicit agreement on arbitrary context information within threshold computation, and it is of general interest.

IACR Cryptology ePrint Archive

@eprint what they fail to say in the title, they claim to be post-quantum, and can do this in less than a second on consumer-grade hw...

(re: https://ia.cr/2024/1032)

#postquantum #oprf #threshold

Threshold OPRF from Threshold Additive HE

An oblivious pseudorandom function (OPRF) is a two-party protocol in which a party holds an input and the other party holds the PRF key, such that the party having the input only learns the PRF output and the party having the key would not learn the input. Now, in a threshold oblivious pseudorandom function (TOPRF) protocol, a PRF key K is initially shared among T servers. A client can obtain a PRF value by interacting with t(≤ T) servers but is unable to compute the same with up to (t − 1) servers. In this paper, we present a practically efficient homomorphic encryption (HE)-based post-quantum secure TOPRF protocol. Our proposed approach, which is based on a novel use of threshold HE, is agnostic of the underlying PRF and outperforms existing fully homomorphic encryption (FHE)-based approaches for TOPRF computation by several orders of magnitude in terms of running time. The FHE-based approaches require bootstrapping, a computationally extensive operation, and the primary bottleneck for evaluating large-depth circuits. Whereas, our proposed approach is based on a multi-party computation (MPC) protocol that uses a threshold additive HE scheme based on Regev’s cryptosystem (J’ACM 2009) alternative to FHE-based approaches. Concretely, we show a novel replacement of bootstrapping required in traditional FHE schemes by a threshold additive HE-based interactive protocol that performs masked decryption followed by table look-ups, jointly performed by a group of servers holding secret shares of the HE decryption key. Finally, We present a practical validation of our approach by realizing an AES-based TOPRF with an evaluation time of less than 1 second on consumer-grade server(s).

IACR Cryptology ePrint Archive

addendum to my #blogpost about a nifty attack against #sphinx and other #oprf-based protocols, i published a simple PoC of the #attack: https://github.com/stef/liboprf/blob/master/misc/attack.c

#crypto #passwordmanager #poc #exploit

liboprf/misc/attack.c at master · stef/liboprf

library providing OPRF and Threshold OPRF based on libsodium - stef/liboprf

GitHub

i wrote a blog post about a nifty attack on #SPHINX and (possibly other OPRF-based protocols):

https://ctrlc.hu/~stef/blog/posts/A_nifty_attack_on_SPHINX_and_other_OPRF-based_systems.html

#passwordmanager #oprf #attack #crypto

~stef/blog/ - A nifty attack on SPHINX and other OPRF-based systems

personal ramblings, noone cares about