News for hackers. Stuff that matters.
Re:An airdrop that preserves recipient privacy [pdf] by exabrial on Friday February 14, 2020 @04:08PM (#22330412)
How has github _not_ shut this down? I'm not giving away any credentials for anything.
Re:An airdrop that preserves recipient privacy [pdf] by rvnx on Friday February 14, 2020 @04:24PM (#22330543)

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

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.

Re:An airdrop that preserves recipient privacy [pdf] by rvnx on Friday February 14, 2020 @11:00PM (#22333143)
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] by pinhead26 on Friday February 14, 2020 @04:19PM (#22330498)
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.
Re:An airdrop that preserves recipient privacy [pdf] by rvnx on Friday February 14, 2020 @04:33PM (#22330620)
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.

Re:An airdrop that preserves recipient privacy [pdf] by pinhead26 on Friday February 14, 2020 @05:57PM (#22331282)
The Goosig (extra blinding crpyto) is also optional. With the --bare flag, its just a signature.
Re:An airdrop that preserves recipient privacy [pdf] by rvnx on Friday February 14, 2020 @06:25PM (#22331465)
Try it please :) I've spent several hours around this option.
Re:An airdrop that preserves recipient privacy [pdf] by rvnx on Friday February 14, 2020 @07:17PM (#22331835)
I've explained above why it cannot work, but I'm still digging on alternative that wouldn't consist on revealing the private key.
Re:An airdrop that preserves recipient privacy [pdf] by rvnx on Friday February 14, 2020 @10:47PM (#22333087)
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.