handshake-org/goosig

Anonymous RSA signatures

goosig's Issues

Pass around hC1 instead of C1 (minor API change)

Very minor API change. This would essentially bake p2pkh into the API itself. C1 would be provided in the signature struct while a hash of C1 would be passed around on a higher level. The verification step ensures hash(sig.C1) == hC1.

This just seems nicer as it's less data to pass around. This seems useful for more generalized usages of this protocol. For example, someone could easily publish a tweet with hC1 in it. They couldn't do the same if they're required to deal only with C1.

`challenger.create_challenge()` doesn't need the full key, just the public key

First, thanks for inviting me to collaborate! I look forward to meeting y'all in person, too :)

One quick comment: in libGooPy I played it a bit fast and loose with RSAKey as it pertains to the challenger. The challenger (as you'd expect) only needs the public key, while the signer needs both the public and the private key.

I'll push an update now to libGooPy that makes this clearer. Specifically, I'll add a get_public_key() method to the RSAKey class, and pass the result of that to GooSigTokGen object.

Does this make sense?

Limit Lucas iterations for choosing P

Our Lucas primality test was ported from golang. This initial loop is limited at 10,000. Makes more sense to limit it at maybe 100. If a signer runs over the limit, they will just have to start over.

Possibly increase ell to 136 bits

Grind random primes instead of counting

@kwantam mentioned that counting may bias the prime depending on the distribution of primes, i.e. counting does not result in a uniform distribution of chosen primes. An attacker gains some information about what the prime is likely to be through this method.

This goes hand-in-hand with #3. The verification can be optimized to one primality test as long as the signer includes their current PRNG state in the signature.

question about use-case of ct/pt from sample code

Hi,

Hiding the each party's real pubkey is a very important feature for a decentralized platform. I took a glance at the sample code. In the scenario of the multi-party are using handshake-based RSA, each party will generate their own pub/priv key pair and generate an random number s_prime based on pubkey. Then generate C1 based on s_prime. IIRC, C1 is the only info being published which related w/ the pubkey and everyone can access to. There's one thing I still don't figure:

// Encrypt s_prime to user's pubkey.
const ct = goo.encrypt(s_prime, pub);

// User decrypts the encrypted payload.
const pt = goo.decrypt(ct, priv);

If A only can access B's C1, how does A get B's pubkey and use it to encrypt s_prime? Or what use-case would that be?

Switch to AES-CTR or ChaCha20 for the PRNG

Faster and less stateful (since it does not depend on a hash chain). This allows us to seek to an arbitrary state, which may be valuable for the verification step.

Leaning towards ChaCha, given the simpler implementation.