I'll summarize our discussion from the ta...@gnu.org list.
There are shades of a "bug door" in their no certificates arguments : - "The only thing edge to manage is a private scalar. No certificates." - The edge's public key xG is "posted publicly [similar] to a Certificate Transparency Log [and] "verifiable by all users and so the deanonymization attack above would not be possible." In other words, there is no plan for the Tor Project to control any certificate authorizing the edge's public keys, ala an auditor key in Taler. Afaik, there are no promises being made about any particular certificate transparency scheme to keep edges from employing unique keys. I think their client software could track the public keys they see themselves easily enough, but if different edge servers use different keys then this becomes mostly useless. In fact, if the transparency log posts 256 keys supposedly used concurrently by 256 different edge servers, but secretly all edge servers used all keys, then your edge server plus your edge public key gives CF 8 bits of identifying information, but nothing looks suspicious in the transparency log. On Sat, 2017-11-11 at 12:05 -0500, z...@manian.org wrote: > If anyone is inventing a protocol that calls for blinded RSA, I think > they would be far happier using a curve based OPRF. If you're actually doing money, like we do in Taler, then no you actually do want RSA blind signatures, not OPRFs plus DLEQ proofs. These batched DLEQ proofs provide roughly a Schnoor signature for the withdrawal, so they suffice for many purposes, but.. You loose the blinding when using the DLEQ proof because their hash incorporates the blinded T. As a result, users must deanonymize themselves for many activities, like to expose fraud by a merchant, or show a receipt with fair exchange properties, so all these activities become privacy minefields with stupidly complex user interfaces. Worse, you cannot batch the DLEQ proofs like they do lest you deanonymize multiple transactions, which triples the computational and bandwidth overhead for OPRFs plus DLEQ proofs. You loose offline transactions too. We do not require true offline transaction from a payment system today, and Taler intentionally does not support them, but.. First, merchants with delayed delivery could benefit from batching their deposits, so OPRFs make their deposits more fragile. Second, completely centralized verification for OPRFs turns merchants into a DoS vector. In principle, the OPRF described here has extremely secure blinding because an adversary must compromise both the scalar multiplication and the hash function that produces the blinding scalar. Against a quantum adversary, there is likely a slight security regression vs RSA blinding because the blinding scalar is unlikely to be full domain anymore. In curve25519, the group order would produce a negligible risk, but against a quantum adversary the clamping is catastrophic, not sure about P256. Also, these Schnorr signatures are extremely sensitive to nonce reuse issues, so you require a good PRNG or else you might reveal your denomination key through the DLEQ proof. It's fine if you're CF who can throw serious security at just protecting blogs from SPAM, but it sounds kinda risky if you want to roll out a payment system in a country disliked by the NSA or even a refugee camp. Best, Jeff
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Curves mailing list Curves@moderncrypto.org https://moderncrypto.org/mailman/listinfo/curves