saltpack encryption for keybase users, how?

[stefanclaas]

Hi all,

i wonder how saltpack (python code) users (not using keybase) can use an encryption key from keybase? When i use saltpack for encryption it gives no erros but when decrypting with keybase decrypt -i file.txt i get the following error:

Decryption failed; it was encrypted for 1 hidden receivers, which may or may not you ▶ ERROR decrypt error: no suitable device key found

my second question about saltpack signatures: when signing with saltpack keybase shows verified and the key id, but saltpack python code does not. Would it be possible that saltpack python code could show this info too, in an update?

Best regards Stefan

[stefanclaas]

O.k. i used the public paper key and not the public device key... Problem solved. :-)

[oconnor663]

Sounds like you figured it out, which is great, but since this is pretty tricky I'll comment anyway. Unlike PGP fingerprints, we don't usually expose your device public keys through the UI. The fastest way to get the public key for one of your devices is to use the devices page on the website. Here's an example using mine at https://keybase.io/oconnor663/devices

What I've highlighted there is the NaCl public encryption key for my laptop, encoded in hex. Note that I've omitted four hex digits from the front and two hex digits from the back. Those digits are Keybase metadata describing the key type, and you'll notice that they're the same for every device encryption key.

Note that unfortunately this approach is requiring you to trust Keybase not to lie to you about the encryption key. In an ideal world you could use the keybase command line to get the encryption key, and it could verify the user's whole sigchain before it printed anything. We have the dump-keyfamily command to do this for your own keys, but it doesn't currently take a user argument. I've filed a task for us.

Once you've got the encryption key, the saltpack Python implementation can encrypt to it like this:

saltpack encrypt -m "stuff woo" 0000000000000000000000000000000000000000000000000000000000000000 bb260a2d6e849813b1a7f2a9cd757e11c9d7726d43725622c062d9603a2c0717

That first string of zeroes is the sender private key. For just testing, that can be any random 64-character hex string. Unfortunately, if you forget that argument, the encrypt command will assume that your recipient public key is in fact the sender private key, and it will just encrypt to itself. But in this case "to itself" is garbage, because it's treating a public key as a private key. This probably caused the no suitable device key found you saw.

That "oops I assumed that was a private key" gotcha is a terrible design mistake on my part, and it tripped me up too when I first started looking into your question. Any suggestions for a better way to accept both private and public keys on the command line? My current thought is to just always generate a random private key by default, and assume all positional arguments are recipients, and have a new flag for the cases where you want to supply a specific private key.

To your second question, yes we probably should print the sender when we verify (or decrypt) a message. I'll make a note to fix that when I fix the positional arguments issue above.

[stefanclaas]

Thank you very much for your detailed reply, much appreciated! What i did was i generated a key pair with tweetnacl-tools (from github) and used the private key from their and the paper key from my account , like you described, resulting in the error message. Once i used, with the same procedure, the device key no error occured. I would like to use, if possible, the paper key in the future, because that way i could use them also in a signature for email or Usenet.

Since i'm very new to saltpack and keybase's implementation i wonder a bit how users in the future can exchange messages (i.e. keybase users to saltpack users).

For command line arguments with saltpack, well it works good for me when copying my secret key string and the recipients pub key string, but i can imagine with multiple recipients it's a bit more work. According to the documents of tweetnacl-tools for example, the command line takes a seckey file and a pubkey file as arguments. Maybe this could be useful when dealing with multiple recipients, so that a list of pubkey strings (one per line) in file could be helpful.

Regards Stefan