secp256k1-zkp
secp256k1-zkp copied to clipboard
BlockstreamResearch
Expose Borromean ring signature and de-anonymization functionality
Nice :).
One design point though -- since we have to nail down the stream cipher to make the anonymity revocation work in the future, maybe we should switch to chacha rather than sha2_hmac? It'd be much much faster.
Also worth considering whether we should expose an encyption API for this too.
Nice :).
One design point though -- since we have to nail down the stream cipher to make the anonymity revocation work in the future, maybe we should switch to chacha rather than sha2_hmac? It'd be much much faster.
I haven't looked at the PR so far but we need to think about the properties we require from the function that maps a seed to the coefficients. The function still needs to be a PRG simply because we need random coefficients.
I think for security against "false claims" of not being the signer, we need only preimage resistance and AFAIU, the text quoted in #109 is essentially arguing that any function {0,1}^s -> {0,1}^n from a short seed of s bits to a much longer output of n bits is statistically preimage-resistant: Given a random element of {0,1}^n, it has a preimage with probability at most 2^(s-n).
Also worth considering whether we should expose an encyption API for this too.
Encryption API for what exactly?
I didn't realize that chacha was biased and could not be used as a PRG. Will need to address this in the Bulletproofs PR as well.
The encryption API lets you hide data inside the rangeproof by xoring it with the PRG output.
I didn't realize that chacha was biased and could not be used as a PRG. Will need to address this in the Bulletproofs PR as well.
Wait, who said that ChaCha is biased?
The encryption API lets you hide data inside the rangeproof by xoring it with the PRG output.
Ah yes, that will be neat.
Wait, who said that ChaCha is biased?
I am quoting https://tools.ietf.org/html/rfc8439#page-20 which says
Additionally, unlike HMAC, Poly1305 is biased, so using it for key derivation would reduce the security of the symmetric encryption.
Oh, I'm an idiot, it says in the next sentence that chacha20 would be fine but that is not what some particular use case needs, so they don't specifiy it in the RFC.
How could something be a stream cipher but not a PRG?
Sorry this was automaticaly closed. PR needs to be reopened against the master branch.
All good. I will reopen. Looks like github won't let me retarget the same PR so we'll lose the comments, but given that they're mostly me being confused about chacha, that's not a big loss.