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.
Note this airdrop was implemented on the Handshake blockchain and just went live today. If you had over 15 followers on GitHub in Aug 2018 you were included and get 4662 HNS (worth $2000+ at current market price). If you’re eligible, we created these instructions on how to claim here https://namebase.io/airdrop.
1) Requires a private SSH/GPG key that was associated with your GitHub account at some arbitrary date in the near past. It would be trivial to design a cryptographic scheme to prove ownership of a GitHub account without compromising private keys. So why do it the way they have?
2) Requires that you provide government issued identification (and possibly more) to be able to withdraw or sell the airdropped tokens for USD or bitcoin.
Call me paranoid, but this feels like a honeypot. It feels like an attempt to compile a database of programmers/developers (and their real identities) - with a bit of a bias towards those with knowledge in the areas of cryptography and/or cryptocurrencies.
Even if that is not the intent. Would you trust this company to safely store such information about you?
1) Nowhere is a private key exposed in the process. I do not know how you came to this conclusion after reading the paper and the code.
2) Namebase definitely makes things easier, but you can absolutely claim your airdropped coins locally on your own computer.
As a final note, if you think this is targeting those with knowledge in the areas of cryptography, I assure you, any cryptographer who reviews the code and paper would not have the same conclusion as you.
The main goal of the Handshake airdrop was to get developers interested in using Handshake, but one of the sub-goals was to help incentivize good security practices. The airdrop process involves running a script on your private key, so you should naturally rotate your key after claiming your coins.
I believe you can have the airdrop tool  output the raw bytes that you need to sign with your private key. Still not fool proof but makes it more transparent what you're actually doing with the key.
Well if you get that part running I'm interested because when I run the tool on an air-gapped machine without access to SSH private key, then this bare mode is not functional and keeps saying "Address is not a faucet or sponsor address".
The next step on the Namebase website is that they ask you for your passport and utility bills, and since they issued the address of your wallet, they perfectly know who received the reward.
(as a note I really don't see the point of the crypto-privacy protocol, if it's supposed to hide who received rewards if you need to give your passport to transfer the coins out or exchange against other currency).
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.
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 , 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.,  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  supports both RSA groups and class groups. Please let me know if the above isn't clear!
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
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 right solution: Give me a random block of text, I'll sign it using my private RSA/DSA key and you can verify that I am the owner of the public key, send me the money, and everybody is happy.
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)
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.
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
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.