
An airdrop that preserves recipient privacy [pdf] - bitxbitxbitcoin
https://fc20.ifca.ai/preproceedings/54.pdf#
======
dessant
As I understand it developers have to submit a government ID to withdraw their
tokens.

[https://help.namebase.io/article/usgrydy7da-kyc-
restrictions](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?

~~~
troquerre
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.

~~~
dessant
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.

~~~
rvnx
You can see a concrete example of API for KYC here:
[https://developers.veriff.com/#sessions-
sessionid](https://developers.veriff.com/#sessions-sessionid)

or specific to Jumio:

[https://github.com/Jumio/implementation-
guides/blob/master/n...](https://github.com/Jumio/implementation-
guides/blob/master/netverify/callback.md)

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.

~~~
troquerre
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.

------
troquerre
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](https://namebase.io/airdrop).

~~~
dublinben
With the tax implications of cryptocurrency in the US, it's rude to 'airdrop'
or give it to people without their consent.

~~~
stevewodil
Only taxable if you claim it and convert to fiat. How is free money rude?

~~~
verdverm
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.

------
emeltzz
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.

~~~
rvnx
Yeah but if you use the same key for server management, then you may be in a
bad situation :(

~~~
emeltzz
I mean rotating keys periodically is always good practice.

------
rvnx
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 ?

~~~
agrinman
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](https://github.com/handshake-org/hs-airdrop)

~~~
troquerre
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).

~~~
rvnx
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)

~~~
rvnx
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;
        }
      }
    

What you do is that you bruteforce 1500 items with the private key of the user
to find the nonce. So obviously, the --bare mode cannot work the way you
describe.

------
kwantam
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.

~~~
rvnx
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_...](http://certificate.fyicenter.com/356_Root_CA_America_Online_Root_Certification_Authority_1_Ameri.html)

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

~~~
kwantam
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](https://en.wikipedia.org/wiki/RSA_Factoring_Challenge)

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

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

~~~
rvnx
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...](https://github.com/kwantam/GooSig/blob/dc9a197c3574127aa37e8a58afdb570a6fb219f7/libGooPy/rsa.py#L31)
fortunately it's not there anymore).

Thanks for sharing zkSNARKs too!

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

~~~
rvnx

        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 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...](https://github.com/handshake-org/hs-airdrop#fallback-for-hsms) ).

 _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](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.

~~~
rvnx
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)

------
modeless
> 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](https://github.com/handshake-org/hs-airdrop)

~~~
troquerre
Duplicate accounts were deduped, but you can try both options to see which
method was used for your airdrop.
[https://namebase.io/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

~~~
modeless
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.

~~~
troquerre
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.

