Tjaden Hess
@tjade273.bsky.social
Would the fact that this tag is an TOPRF output prevent the attack? The fake realm would need to have the OPRF private key from the original realm in order for the “phase 2” to complete, assuming it’s not possible to swap in the malicious realm in between phases (would need to look at code)
June 5, 2025 at 8:51 PM
Would the fact that this tag is an TOPRF output prevent the attack? The fake realm would need to have the OPRF private key from the original realm in order for the “phase 2” to complete, assuming it’s not possible to swap in the malicious realm in between phases (would need to look at code)
Looks like the cost is dominated by a size-3 elliptic curve MSM per guess. The work should be ~the same order of magnitude as edDSA signing operations. So on the order of 100k guesses per second on consumer hardware.
February 21, 2024 at 1:25 PM
Looks like the cost is dominated by a size-3 elliptic curve MSM per guess. The work should be ~the same order of magnitude as edDSA signing operations. So on the order of 100k guesses per second on consumer hardware.
I don’t see how a hash existence oracle could be more useful than a username existence oracle, which already exists.
The pedersen proof thing was implemented so it may just come down to “proof of knowledge of the actual username+discrimination” is easier to reason about/ harder to fuck up
The pedersen proof thing was implemented so it may just come down to “proof of knowledge of the actual username+discrimination” is easier to reason about/ harder to fuck up
February 20, 2024 at 11:57 PM
I don’t see how a hash existence oracle could be more useful than a username existence oracle, which already exists.
The pedersen proof thing was implemented so it may just come down to “proof of knowledge of the actual username+discrimination” is easier to reason about/ harder to fuck up
The pedersen proof thing was implemented so it may just come down to “proof of knowledge of the actual username+discrimination” is easier to reason about/ harder to fuck up
The current implementation code limits the discriminators to a 64-bit representable value
February 20, 2024 at 11:51 PM
The current implementation code limits the discriminators to a 64-bit representable value
I guess the question is: What kind of adversary knows H(username, discriminator) but not username and discriminator?
February 20, 2024 at 11:46 PM
I guess the question is: What kind of adversary knows H(username, discriminator) but not username and discriminator?
I had considered that it also forces Alice to prove that the hash was constructed properly, but
* I don’t know why that would be important
* It doesn’t actually prove the discriminator is in the correct range, nickname is valid, etc
* I don’t know why that would be important
* It doesn’t actually prove the discriminator is in the correct range, nickname is valid, etc
February 20, 2024 at 11:43 PM
I had considered that it also forces Alice to prove that the hash was constructed properly, but
* I don’t know why that would be important
* It doesn’t actually prove the discriminator is in the correct range, nickname is valid, etc
* I don’t know why that would be important
* It doesn’t actually prove the discriminator is in the correct range, nickname is valid, etc
Yeah, I get that this system ensures Bob knows the hash input, but don’t see why that lends any security over knowing the hash output. Maybe they intend to use the hash for something else, and might leak it? But that could just be solved with domain separation.
February 20, 2024 at 11:42 PM
Yeah, I get that this system ensures Bob knows the hash input, but don’t see why that lends any security over knowing the hash output. Maybe they intend to use the hash for something else, and might leak it? But that could just be solved with domain separation.
Right, but I guess the question is “why do we want a Pedersen commitment to the nickname”
Maybe some fun future feature that needs it for more zk proofs?
Given the desire for a pedersen commitment, the design makes sense (hash prevents brute-forcing the nickname and discriminator independently)
Maybe some fun future feature that needs it for more zk proofs?
Given the desire for a pedersen commitment, the design makes sense (hash prevents brute-forcing the nickname and discriminator independently)
February 20, 2024 at 11:37 PM
Right, but I guess the question is “why do we want a Pedersen commitment to the nickname”
Maybe some fun future feature that needs it for more zk proofs?
Given the desire for a pedersen commitment, the design makes sense (hash prevents brute-forcing the nickname and discriminator independently)
Maybe some fun future feature that needs it for more zk proofs?
Given the desire for a pedersen commitment, the design makes sense (hash prevents brute-forcing the nickname and discriminator independently)
Any idea why they use this pedersen hash
nickname*G1 + discriminator*G2 + H(nickname, discriminator)*G3
rather than just
H(nickname, discriminator)*G
along with a simple Schnorr proof?
I can’t think of any properties the former gives over the latter
nickname*G1 + discriminator*G2 + H(nickname, discriminator)*G3
rather than just
H(nickname, discriminator)*G
along with a simple Schnorr proof?
I can’t think of any properties the former gives over the latter
February 20, 2024 at 11:18 PM
Any idea why they use this pedersen hash
nickname*G1 + discriminator*G2 + H(nickname, discriminator)*G3
rather than just
H(nickname, discriminator)*G
along with a simple Schnorr proof?
I can’t think of any properties the former gives over the latter
nickname*G1 + discriminator*G2 + H(nickname, discriminator)*G3
rather than just
H(nickname, discriminator)*G
along with a simple Schnorr proof?
I can’t think of any properties the former gives over the latter