Feature #17073

Add Passphrase2pgp as additional software

Added by Kronos18 2019-09-19 18:39:51 . Updated 2019-09-20 17:50:32 .

Status:
Rejected
Priority:
Normal
Assignee:
Category:
Target version:
Start date:
Due date:
% Done:

0%

Feature Branch:
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

Tails is amnesia based distribution and works best in a non persistent state but to use GPG requests either using an external storage or installing Tails as persistent. The issue is in lots of countries just having possession of a GPG key can cause issues and in UK require you to divulge the password. Passphrase2pgp allows a user to never have to keep a copy of their GPG keys and can create them on as needed easily with a passphrase. This can minimize the chance of being caught with them while still allowing secure communications or signatures. This open source software can be easily audited and is in a memory safe language.

This is a simple and easy to use tool to prevent the users from ever having to worry about losing their GPG keys all while never having to use storage device. Please consider adding this additional software to Tails OS.

Here is a sample to show how it can be used:
First generate the key. I’ve used an empty passphrase so you can do the same to see exactly the same output.

$ passphrase2pgp —subkey —uid key@foo.com | gpg —import
passphrase:
passphrase (repeat):
gpg: /home/foo/.gnupg/trustdb.gpg: trustdb created
gpg: key BFB69BB42424AA60: public key “key@foo.com” imported
gpg: key BFB69BB42424AA60: secret key imported
gpg: Total number processed: 1
gpg: imported: 1
gpg: secret keys read: 1
gpg: secret keys unchanged: 1
Note, this doesn’t protect the key with a passphrase, so it will be stored unencrypted on the GnuPG keyring. Whether or not that matters depends on your computer’s configuration and how you use your computer. Use passphrase2pgp’s —protect (-e) option to add protection if needed. (I really wish GnuPG had an option to add protection to secret keys as they’re being imported. Sadly, it does not.)

So far everything looks good. We’ve got an a sign/certify/authenticate Ed25519 primary key and an encryption Curve25519 subkey:

$ gpg —list-keys
/home/foo/.gnupg/pubring.kbx
———————————————
pub ed25519 1970-01-01 [SCA]
32FE19AE744B5F668F299CBABFB69BB42424AA60
uid [ unknown] key@foo.com
sub cv25519 1970-01-01 [E]
If you have a notion of what your fingerprint should be, listing the keys like this will let you triple check that you’ve entered your passphrase correctly.

Now to encrypt a message, hello.txt. It will prompt me about trust since imported keys aren’t trusted by default. To disable this, use GnuPG’s —trusted-key, select a different —trust-model, or use —edit-key to change the trust on your key. (There’s nothing passphrase2pgp can do to force a key to be trusted.)

$ echo hello > hello.txt
$ gpg —encrypt —recipient key@foo.com hello.txt
gpg: 971FB333228465B2: There is no assurance this key belongs to the named user

sub cv25519/971FB333228465B2 1970-01-01 key@foo.com
Primary key fingerprint: 32FE 19AE 744B 5F66 8F29 9CBA BFB6 9BB4 2424 AA60
Subkey fingerprint: 526A C547 E142 64D6 7448 F9B1 971F B333 2284 65B2

It is NOT certain that the key belongs to the person named
in the user ID. If you really know what you are doing,
you may answer the next question with yes.

Use this key anyway? (y/N) y
That produces hello.txt.gpg. In another session, you can regenerate the key per the above instructions, and then decrypt like so:

$ gpg —decrypt hello.txt.gpg
gpg: encrypted with 256-bit ECDH key, ID 971FB333228465B2, created 1970-01-01
“key@foo.com”
hello

https://github.com/skeeto/passphrase2pgp


Subtasks


History

#1 Updated by sajolida 2019-09-20 17:50:32

  • Status changed from New to Rejected

I only have very rough data on how much of our users use OpenPGP:

  • The stats on the downloads of the OpenPGP signature of our downloads: 1 download of the signature per 12 direct downloads (8%).
  • The answers of our VeraCrypt survey: 28% of people mentioned OpenPGP.

So my very rough estimate is that at the very most a 1/3 of Tails users use OpenPGP, more likely less than 20%.

Passphrase2pgp would only be useful for a small fraction of these OpenPGP users: it’s mostly interesting for plausible deniability which is of very questionable interest (I’ll avoid diving in this debate here). But let’s be generous and say that 20% of OpenPGP users would be interested in Passphrase2pgp.

On top of that Passphrase2gpg only works from the command line.

It makes Passphrase2pgp only marginally relevant for the Tails user base at large, 5% at the very most.

We also have an Additional Software feature now. Someone concerned about plausible deniability but very interested in Passphrase2gpg could have a Persistence which only installs Passphrase2gpg. In front of a judge it wouldn’t change much to having Tails with Passphrase2gpg installed by default.

So yeah, I don’t think that we should include Passphrase2gpg in Tails. Instead, the developers of Passphrase2gpg should work on having it available in Debian so that the people who want it can install it in Tails.