An airdrop that preserves recipient privacy [pdf](fc20.ifca.ai)
fc20.ifca.ai
An airdrop that preserves recipient privacy [pdf]
https://fc20.ifca.ai/preproceedings/54.pdf#
50 コメント
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.
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.
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.
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.
Namebase didn’t create the airdrop. You can still claim your coins to a cli wallet if you want, and the cli wallet is pretty easy to use actually.
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?
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.
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.
With the tax implications of cryptocurrency in the US, it's rude to 'airdrop' or give it to people without their consent.
Making a mark in a private ledger does not count as a taxable event for anyone.
If I say in my diary "I give $100,000 to dublinben", or "dublinben can claim $100,000 from me for free by just asking", nothing has happened yet from the perspective of the IRS.
If I say in my diary "I give $100,000 to dublinben", or "dublinben can claim $100,000 from me for free by just asking", nothing has happened yet from the perspective of the IRS.
Here is more the equivalent of "Here is a coupon to redeem 100,000 USD from me", which is essentially currency / debt already
This is exactly the concern that the GooSig private airdrop addresses.
Nobody has any obligation to claim their coins, and even if they do, it will be private and nobody will know.
This is unlike Bitcoin forks or ERC-20 airdrops, because it’s 100pct opt-in.
Nobody has any obligation to claim their coins, and even if they do, it will be private and nobody will know.
This is unlike Bitcoin forks or ERC-20 airdrops, because it’s 100pct opt-in.
Only taxable if you claim it and convert to fiat. How is free money rude?
You have to pay taxes when claimed, and again when a transaction occurs.
The rule is you need to pay taxes on the value when you receive them, and then the profit / loss when you convert them to fiat, or another currency. Both are taxable events.
The rule is you need to pay taxes on the value when you receive them, and then the profit / loss when you convert them to fiat, or another currency. Both are taxable events.
This is incorrect, it's taxable even if you never convert it.
It’s not an ethereum airdrop which goes to an address you already own. You don’t have the coins until you deliberately claim them, so it’s opt-in.
If you claim this airdrop, best practice would be to save the key, and then first rotate your github keys before claiming. In this way any potential security risk is averted.
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[1], so you should naturally rotate your key after claiming your coins.
[1] https://namebase.io/airdrop
[1] https://namebase.io/airdrop
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'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 ?
"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
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
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!
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!
I find it a bit strange:
Pro-tip: Learn why the airdrop tool needs to use your private key.
So someone will give you 2000 USD if you feed your private SSH key into their software ?
Pro-tip: Learn why the airdrop tool needs to use your private key.
So someone will give you 2000 USD if you feed your private SSH key into their software ?
I believe you can have the airdrop tool [0] 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.
[0] https://github.com/handshake-org/hs-airdrop
[0] https://github.com/handshake-org/hs-airdrop
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).
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).
Yeah that's how the airdrop tool works and the instructions use that tool too (the first step in the instructions just shows how to install the tool).
Can you ask one of your developers to try using the bare mode only ? (a concrete case, only the public key and extracting the raw bytes).
Several hours, flipping the code in many ways, such option doesn't seem to exist (and for sure isn't documented)
Several hours, flipping the code in many ways, such option doesn't seem to exist (and for sure isn't documented)
Mhhh, your nonce discovery process cannot work without the private key.
while (br.left()) {
const ct = br.readBytes(br.readU16(), true);
qqq++;
try {
out.push(key.decrypt(ct, priv));
} catch (e) {
continue;
}
}
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.
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.
Alleged simplicity: Two hours I'm trying to redeem the airdrop without giving away the private key and the passphrase (hint, it's not implemented, despite the documentation somewhat references it here: https://github.com/handshake-org/hs-airdrop#fallback-for-hsm... ).
Alleged safety: after installing dozens of NPM packages and code from whoever who, and running an algorithm that we don't know (even the developers) if it's reversible or not.
I see horrible consequences: https://github.com/handshake-org/hs-airdrop/issues/31
User has key safely inside HSM, gets the key out to get free money that A16Z is supposedly giving.
Reminds me the "Elon Musk gives Bitcoin on Twitter, just send YOUR PASSWORD"
On the practices overall:
It's unclear what the private key derivation process does and if the developers themselves truly understand it.
If the developers would understand the full security implications, they would not say it's safe to do it on an air-gapped machine.
The process could just multiply by two or base64 encode the private key, it would be near invisible since the whole code and theory is a big soup.
All that, supposedly for privacy benefits, when at the end, you have to give your real identity and ID documents to actually withdraw/exchange the coins.
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)
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)
You don't have to, it works by signing a message with your PGP or SSH key. All GitHub users' public keys are already available from their API, that's how the airdrop works.
No. It's not like that at all. Otherwise there would be no controversy.
The airdrop tool takes your private key and your passphrase, does some overcomplicated (and unconventional) magic with it and asks you to post the resulting data to the public.
The airdrop tool takes your private key and your passphrase, does some overcomplicated (and unconventional) magic with it and asks you to post the resulting data to the public.
The Goosig (extra blinding crpyto) is also optional. With the --bare flag, its just a signature.
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.
[deleted]
> 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
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
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.
[deleted]
[deleted]
[deleted]
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?