Live data from Hacker News

An airdrop that preserves recipient privacy [pdf]

fc20.ifca.ai

41–50 of 51 posts

Re: An airdrop that preserves recipient privacy [pdf]

#41
post #36

Hi HN, I'm one of the authors of this paper. Very cool to see it being discussed here! I'm happy to answer questions about private airdrops, with two caveats: first, I'm not associated with Handshake, so I probably don't know the answer to Handshake-specific questions. Second, I'm juggling some other things today, so apologies in advance if my answers are delayed.

I see (on your own repo) an intriguing mention:

"The design of GooSig requires a public RSA modulus whose prime factorization is unknown."

I see one of the key is http://certificate.fyicenter.com/356_Root_CA_America_Online_...

Did you choose this key because you consider it to have been lost ?

Re: An airdrop that preserves recipient privacy [pdf]

#42
post #16

As I understand it developers have to submit a government ID to withdraw their tokens. https://help.namebase.io/article/usgrydy7da-kyc-restrictions This is a bit concerning, and it practically negates the privacy claims of the airdrop, unless people only use the tokens to bid on Handshake names. Could you share more details about the documents you're requesting? Which company handles the personal data?

You're correct. Unfortunately due to regulatory restrictions in the US, we're required to verify accounts before enabling withdrawals and selling HNS for BTC (we're not happy about it either). We work with Cognito and Jumio, which are the vendors that Coinbase, Brex, Airbnb, and many other companies use — so if you've used any of those products you've already used Cognito and Jumio before.

Thanks for the details, I think that sounds reasonable. Do you have access to the documents during the verification process, or are users redirected to the KYC provider to upload them? If you don't have access to the documents, what personal data does the KYC provider return to your company upon successful verification?

I'm curious because I haven't gone through an online KYC process before, and I'd like to understand the risks before claiming the airdrop.

Re: An airdrop that preserves recipient privacy [pdf]

#43
post #42

Earlier quoted context omitted.

You're correct. Unfortunately due to regulatory restrictions in the US, we're required to verify accounts before enabling withdrawals and selling HNS for BTC (we're not happy about it either). We work with Cognito and Jumio, which are the vendors that Coinbase, Brex, Airbnb, and many other companies use — so if you've used any of those products you've already used Cognito and Jumio before.

Thanks for the details, I think that sounds reasonable. Do you have access to the documents during the verification process, or are users redirected to the KYC provider to upload them? If you don't have access to the documents, what personal data does the KYC provider return to your company upon successful verification? I'm curious because I haven't gone through an online KYC process before, and I'd like to understan…

You can see a concrete example of API for KYC here: https://developers.veriff.com/#sessions-sessionid

or specific to Jumio:

https://github.com/Jumio/implementation-guides/blob/master/n...

Essentially all personal data. Generally for these, the name is also sent to other processors, to check against OFAC's Specially Designated Nationals (to see if you are under sanctions in the US).

So if you are in North Korea for example, you may not have access to your funds in practice with the current situation.

It's a rather normal process though. At the end is no point about the GitHub anonymity thing because all users (even European or people from Zimbabwe) have to do the KYC anyway.

Re: An airdrop that preserves recipient privacy [pdf]

#44
post #41
post #36

Hi HN, I'm one of the authors of this paper. Very cool to see it being discussed here! I'm happy to answer questions about private airdrops, with two caveats: first, I'm not associated with Handshake, so I probably don't know the answer to Handshake-specific questions. Second, I'm juggling some other things today, so apologies in advance if my answers are delayed.

I see (on your own repo) an intriguing mention: "The design of GooSig requires a public RSA modulus whose prime factorization is unknown." I see one of the key is http://certificate.fyicenter.com/356_Root_CA_America_Online_... Did you choose this key because you consider it to have been lost ?

Great question! The very short answer is "yes." In slightly more detail:

We wanted to be able to test with a 4096-bit RSA modulus whose factorization was plausibly unknown, but this is a tough thing to find! (We certainly didn't want to include a modulus that we generated in the codebase, because from the outside there would be no way to know that we hadn't kept a trapdoor.) There are the famous RSA challenge numbers [1], but those only go up to 2048 bits; we include both of the 2048-bit challenge numbers in the repo.

Root certificate moduli are almost what we want, since their factorization is a very closely guarded secret. (In fact, in all cases we're aware of, root cert secrets are kept only in hardware security modules, which by design do not allow anyone to extract the factorization---though of course HSMs can be buggy, so this is no silver bullet.) The problem is, the owner of the cert might in principle know the factorization, so we didn't want to pick an active root cert. We settled on the AOL root cert because it's the oldest 4096-bit root cert we could find that (1) that saw widespread use, (2) was plausibly uncompromised, but (3) is no longer actively used. To us, this was the best candidate for a 4096-bit modulus for which the factorization is lost---exactly as you say.

This is only a heuristic---someone might know the factorization, in which case they could generate false proofs. We think it's exceedingly unlikely, but each person must assess that risk for themselves. This is related to other issues with trusted setup, "toxic waste," etc. (see, e.g., [2] for a discussion of this in the ZCash context).

Another way to generate an RSA modulus whose factorization is plausibly unknown is to use a multi-party computation ceremony. In cases like this, you can believe that the factorization is unknown if you trust some fraction of the parties in the computation (details vary). I've heard that Ethereum is planning to do this at some point in the future, but I do not know any other details.

As a final point, if one does not want to trust an RSA modulus, an alternative is to work in an imaginary quadratic class group. It's widely believed that there is no efficient way of computing the order of such a (which is what we require for security), and unlike an RSA group there's no trusted setup---you just pick a random prime and that defines your group. The downside is that group operations are about 10x slower.

We discuss this a bit more in the paper, and our Python implementation [3] supports both RSA groups and class groups. Please let me know if the above isn't clear!

[1] https://en.wikipedia.org/wiki/RSA_Factoring_Challenge

[2] https://blog.ethereum.org/2016/12/05/zksnarks-in-a-nutshell/

[3] https://github.com/kwantam/GooSig

Re: An airdrop that preserves recipient privacy [pdf]

#45

> As a final addition, Hacker News accounts which are linked with Keybase accounts are included in the tree [1] How do I claim the airdrop with keybase? If I have a HN/keybase account and a github account, can I claim the airdrop twice? [1] https://github.com/handshake-org/hs-airdrop

Duplicate accounts were deduped, but you can try both options to see which method was used for your airdrop. https://namebase.io/airdrop has instructions for GitHub. For keybase, follow the instructions from the page but instead of using your ssh key log in to keybase.io, go to your profile and 1) click on your GPG key 2) click to show private key 3) add your keybase passphrase 4) copy the private key into a file called `secret.asc` 4) executed `./bin/hs-airdrop secret.asc GPG_ID ADDRESS` where `GPG_ID` was the id/name of the key

Re: An airdrop that preserves recipient privacy [pdf]

#46
post #44
post #41

Earlier quoted context omitted.

I see (on your own repo) an intriguing mention: "The design of GooSig requires a public RSA modulus whose prime factorization is unknown." I see one of the key is http://certificate.fyicenter.com/356_Root_CA_America_Online_... Did you choose this key because you consider it to have been lost ?

Great question! The very short answer is "yes." In slightly more detail: We wanted to be able to test with a 4096-bit RSA modulus whose factorization was plausibly unknown, but this is a tough thing to find! (We certainly didn't want to include a modulus that we generated in the codebase, because from the outside there would be no way to know that we hadn't kept a trapdoor.) There are the famous RSA challenge numbers…

Very interesting feedback. I appreciate your time detailing the answer.

I really like what you have done, it's a beautiful project from a mathematical perspective and the crypto code your team has wrote with GooSig is impressive.

I enjoyed reading what you wrote and this made me think a lot about integer factorization, prime numbers discovery, etc, and even found cute comments in the past commits (that one made me smile: https://github.com/kwantam/GooSig/blob/dc9a197c3574127aa37e8... fortunately it's not there anymore).

Thanks for sharing zkSNARKs too!

Re: An airdrop that preserves recipient privacy [pdf]

#47
post #40
post #35

Earlier quoted context omitted.

Try it please :) I've spent several hours around this option.

I've explained above why it cannot work, but I'm still digging on alternative that wouldn't consist on revealing the private key.

More feedback, if I understood it right: if you extract the findNonces function, dump the 1500 files of 512 bytes, transfer them to a machine that has the ssh private key, then you should be able to sign without risking anything (encryption is RSA-OAEP), because your private key wouldn't touch the software.

Re: An airdrop that preserves recipient privacy [pdf]

#48
post #23

How has github _not_ shut this down? I'm not giving away any credentials for anything.

we do not allow standard PGP signatures on the consensus layer. This is done for simplicity and safety. This means that a regular call to $ gpg --sign will not work for handshake airdrop proofs. As far as SSH keys go, people typically do not sign arbitrary messages with them. Because of this, we require a special tool to do both the signing and merkle proof creation. I like how they say, simplicity and safety. The ri…

An update on this after 6 hours of code reading: I'm quite sure the code doesn't leak components of the private key when using --base parameter. So this may be safe.

The part of the code running without --base is very complex and it would be difficult to share an opinion and I'm not sure that I understand all the sorcery (for sure the crypto people behind are very very smart)

Re: An airdrop that preserves recipient privacy [pdf]

#49

> As a final addition, Hacker News accounts which are linked with Keybase accounts are included in the tree [1] How do I claim the airdrop with keybase? If I have a HN/keybase account and a github account, can I claim the airdrop twice? [1] https://github.com/handshake-org/hs-airdrop

Duplicate accounts were deduped, but you can try both options to see which method was used for your airdrop. https://namebase.io/airdrop has instructions for GitHub. For keybase, follow the instructions from the page but instead of using your ssh key log in to keybase.io, go to your profile and 1) click on your GPG key 2) click to show private key 3) add your keybase passphrase 4) copy the private key into a file cal…

I'd really rather use keybase as it's a lot easier to rotate that key and it doesn't secure anything important. But you picked one of my keys at random and I have to try them all to see which one you picked? And you did all this rigamarole to make it private even though a scan of my passport is required to actually use the proceeds? I feel like the effort put into this was misdirected.

Re: An airdrop that preserves recipient privacy [pdf]

#50

Earlier quoted context omitted.

Duplicate accounts were deduped, but you can try both options to see which method was used for your airdrop. https://namebase.io/airdrop has instructions for GitHub. For keybase, follow the instructions from the page but instead of using your ssh key log in to keybase.io, go to your profile and 1) click on your GPG key 2) click to show private key 3) add your keybase passphrase 4) copy the private key into a file cal…

I'd really rather use keybase as it's a lot easier to rotate that key and it doesn't secure anything important. But you picked one of my keys at random and I have to try them all to see which one you picked? And you did all this rigamarole to make it private even though a scan of my passport is required to actually use the proceeds? I feel like the effort put into this was misdirected.

To be clear, Namebase didn’t create Handshake or the airdrop. We’re building on top of it but we’re a separate team. You can also claim your coins outside of Namebase if you want. The cli wallet is actually pretty easy to use.
Post reply on HN