Thoughts on crypted communication

network-63770_150Due to the recently published information about mass surveillance on a yet not known level right now the question remains how to encrypt communication. I had some thoughts regarding that topic involving a GPG like web of trust combined with user friendliness which I’d like to share here.

Given everything which was published so far, un-encrypted communication is not save at all. The same is unfortunately true for encryption methods which rely on encryption provided by the servers of some organization. If there is a centralized organization storing the keys for you, or just providing you with the encryption technology, you are screwed, because the intelligence agencies will force them to cooperate. For that reason, the encryption must take place on the end users system already (and the software must be Open Source).

However, if you have end-user encryption, you have the problem of the key exchange – if two people want to communicate securely, they need to exchange the keys or at least securely verify that a public key indeed belongs to their private key. That only works if they meet in person – or if there is a web of trust.

A common example of such a web of trust is the GPG web of trust: people who have properly verified that person A belongs to key M sign this key. If person B trusts person A, it can just use key M since it is already verified by person A. However, in case of GPG the web of trust never reached mainstream. It is mainly used by technical minded people. Most users never got used to it.

So, from what I can tell the only chance to establish a web of trust is to hide the technical details as much as possible from the users. The same is true for the actual key exchange – it needs to be as simple as possible so that each normal user can use it.

Given this background I would suggest the following solution at least for mobile phones. You download the app, and it asks the user for a password. In the background, a key pair is generated and secured with the password, and all data stored on the device are encrypted using the public key. If user A meets user B all they need to do is pressing a button in the app, and a QR code is shown. The other user scans that QR code, and its done. The user shows up in the contact list, and they can chat. In the background, the app extracts the key ID and fingerprint from the QR code, downloads the public key, signs it and uploads the signature automatically.

The biggest problem comes up when user C comes into play, wants to communicate with user A, but they both have no common connection in their web of trust. They would have to meet – or use some other way of exchanging the data securely. A simple way would still be to talk on the phone, but that never worked for GPG. So some kind of web service to host their QR code for a short time only would probably a solution, although it would be pretty risky.

To lower the danger of a man in the middle attack in the above given web example the key servers must only accept one key pair for each identity, which is different to the way GPG works. That would in fact mean that you can have each login only once – if you loose your key, your are screwed.

One question though remains: how many steps in the web of trust are still trustworthy? I guess that could be left as a configuration option if, and only if, a user wants to modify that.

To summarize: I guess that the current cryptography technologies we have could really help to establish secure communication. But to really bring that communication to the masses we need easy-to-use (read: your grandma!) applications doing everything in the background.

[Howto] Using sks key server pool for managing GPG signatures

920839987_135ba34fffGPG/PGP needs key servers to work properly. However, some of the servers announced on the web only react slowly – or not at all. The solution is to access a pool of servers which maintains itself.

GPG/PGP works within a web of trust: you trust people you know by signing their keys. If you meet someone you don’t know, you can check if someone you trusted signed the key of the unknown person.

To look up such signatures you however need the infrastructure of such a web of trust: key servers, which store and deliver keys and signatures.

However, many key servers are really slow or do not work properly although they are still listed in programs like KDE’s kgpg. The solution is to use a round robin based pool of servers like the sks key servers. The advantage of such a pool is that even if one server does not respond, next time you query the pool another server will respond most likely. Also, the pool checks itself if the servers are working and removes them from the pool if not. One new child of the family of pool servers is by the way a server provided by the Fedora Project.

The sks pool can be used just like any other key server, for example on the command line:

$ gpg --keyserver --recv-keys 449FA3AB
gpg: requesting key 449FA3AB from hkp server
gpg: key 449FA3AB: public key "Linus Torvalds <>" imported
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   2  signed:  12  trust: 0-, 0q, 0n, 0m, 0f, 2u
gpg: depth: 1  valid:  12  signed: 123  trust: 6-, 0q, 0n, 0m, 6f, 0u
gpg: depth: 2  valid: 122  signed: 177  trust: 119-, 0q, 0n, 0m, 3f, 0u
gpg: depth: 3  valid:  63  signed: 113  trust: 63-, 0q, 0n, 0m, 0f, 0u
gpg: next trustdb check due at 2014-05-10
gpg: Total number processed: 1
gpg:               imported: 1

You can also add the key server to GUI programs like kgpg, or add it as default server to your ~/.gnupg/gpg.conf:

$ grep keyserver .gnupg/gpg.conf
keyserver  hkp://

[Howto] Changing the expiry date of GPG keys

GnuPG keys can have an expiry date. When the key expires, it cannot be used to encrypt data anymore, and thus is a good way to enforce security measures. However, what most people does not seem to know is that this expiry date can be changed quite easily.

Setting an expiry date for a GPG key is usually a good thing: it makes sure that even if you forget the password and do not have a revocation certificate the key will not be valid at some point in the future. Additionally it might force users to replace keys ever so often to enforce specific security measures. Last but not least it forces the key owner to think about his or her own GPG infrastructure and if changes are needed.

Still, there might be times where it makes sense to change the expiry date – if only because you realized that your GPG keys are all fine.

First, you need to know the key ID, in this example ABCDEF12:

$ gpg --list-keys
pub   2048R/ABCDEF12 2012-09-10 [expires: 2032-09-10]
uid                  liquidat <>
sub   2048R/BCDEF123 2012-09-10 [expires: 2032-09-10]]

With that ID at hand you can now edit the key:

gpg --edit-key ABCDEF12
gpg (GnuPG) 1.4.12; Copyright (C) 2012 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

pub  2048R/ABCDEF12  created: 2012-09-10  expires: 2013-09-10  usage: SC  
                     trust: ultimate      validity: ultimate
sub  2048R/BCDEF123  created: 2012-09-10  expires: 2013-09-10  usage: E   
[ultimate] (1). liquidat <>


As you see this key is going to expire in fall 2013. The gpg> indicates a prompt, so you are basically at a gpg specific shell. So, let’s actually change the expiry date:

gpg> expire
Changing expiration time for the primary key.
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0) 3y
Key expires at Fri May  6 15:45:42 2016 CEST
Is this correct? (y/N) y

You need a passphrase to unlock the secret key for
user: "liquidat <>"
2048-bit RSA key, ID ABCDEF12, created 2012-09-10

The passphrase is usually queried by standard means, so on a desktop systems a pop up windows should come up asking you for the passphrase.

Afterwards, list the key again to check the new expiry date:

gpg> list
pub  2048R/ABCDEF12  created: 2012-09-10  expires: 2016-09-10  usage: SC  
                     trust: ultimate      validity: ultimate
sub  2048R/BCDEF123  created: 2012-09-10  expires: 2013-09-10  usage: E   
[ultimate] (1). liquidat <>


As you see, the expiry date has only changed for the first key, but not for the pub key. The edit procedure is always for one key only. Thus, change the focus from the first key, called “key 0”, to the sub key, “key 1”. A star sign * will indicate the focus on the subkey:

gpg> key 1
pub  2048R/ABCDEF12  created: 2012-09-10  expires: 2016-09-10  usage: SC  
                     trust: ultimate      validity: ultimate
sub*  2048R/BCDEF123  created: 2012-09-10  expires: 2013-09-10  usage: E   
[ultimate] (1). liquidat <>

gpg> expire

Changing expiration time for a subkey.
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0) 3y
Key expires at Fri May  6 15:45:42 2016 CEST
Is this correct? (y/N) y

You need a passphrase to unlock the secret key for
user: "liquidat <>"
2048-bit RSA key, ID BCDEF123, created 2012-09-10

gpg> list
pub  2048R/ABCDEF12  created: 2012-09-10  expires: 2016-09-10  usage: SC  
                     trust: ultimate      validity: ultimate
sub  2048R/BCDEF123  created: 2012-09-10  expires: 2016-09-10  usage: E   
[ultimate] (1). liquidat <>

As you see, you are done, both dates are changed now. The changes finally need to be saved:

gpg> save

And, last but not least, don’t forget to upload the updated public key to the key servers:

$ gpg --keyserver --send-keys ABCDEF12
gpg: sending key ABCDEF12 to hkp server

Pass – A perfect shell based password manager

920839987_135ba34fffPass is a tool to store and manage passwords and other data securely and on command line – even with built in support for Git and remote Git repositories. Thus it is a welcomed alternative for existing password managers which often require a GUI, or do not provide repository support.

What it is

Pass is a shell based password manager to store passwords and login data – or anything you want, actually. The name “the standard unix password manager” however is pretty misleading: the author wanted to stress that it only uses standard Unix tools, but failed to highlight that with a catchy name and instead just created confusion.

But the author is right with his main point: pass is in fact just gluing together already well known and tested Unix tools: the encryption of all information is ensured by GPG, passwords are queried using gpg-agent, the version control and remote repository support is done by Git, and the tool itself is written in shell code. Thus you have features you can rely on – in fact, if you want you can directly access the Git repository and the Gnupg files, you do not have to use Pass at all.

Pass stores information in simple files, which can be grouped in folders. While the main idea of Pass is to store one password in one file you can actually access each file with editors to store as many information in it as you want. Each file is encrypted with the gpg key which was defined during the initial setup of Pass. As a result the Pass database is nothing else but a folder full of other folders and gpg encrypted files:

$ ls -1 $HOME/.password-store
$ ls -1 $HOME/.password-store/business/

Pass is included in all major distributions like Fedora, Ubuntu, Debian, and so on, and thus can be installed with the usual package management tools.

How it works

If you call Pass without any further options, it just outputs the content of its password store:

$ pass
Password Store
|-- business
|   |--
|   |--
|   `--
|-- commerce
|   `-- amazon
|-- financial
|   |--
|   `--

The file type ending “gpg” is not shown here to not confuse users (I guess).

Showing the content of a file is straight forward:

$ pass business/
login:  example
pass:   password

Adding new entries can be done with the command pass insert $FOLDER/$FILENAME. But it might be more convenient to just use the default editor to edit a new file: pass edit $FOLDER/$FILENAME. That way multi line information can be added more easily.

However, the real strength of Pass is that after each change – like adding a new password – git-add and git-commit are called: the new file is automatically committed to a local git repository:

$ pass edit business/
[master 4c09c76] Added password for business/ using /usr/bin/vim.
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 business/

As a result all changes are automatically under version control and can be reverted. But it gets better: Pass forwards arbitrary options and commands to Git itself. Thus it is possible to access the full functionality of Git – and to push the files to an online repository:

$ pass git push
Counting objects: 6, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 823 bytes, done.
Total 4 (delta 1), reused 0 (delta 0)
   aa2aff7..2011296  master -> master

That way the password store can be shared with any remote Git repository – and thus can be re-used by other clients, given that they have the proper GPG key.

Missing pieces

As shown above Pass is almost perfect if you need a way to manage passwords (or any other data at all) on command line level, including repository and encryption support.

But while Pass replaced all my other password managers literally in a few minutes there is still one big feature I miss: the support for GUI tools! It would be nice if Pass support could be included in the major Desktop Environments and major GUI programs used in the Linux desktop world:

  • KDE’s Kwallet
  • Gnome’s Keyring
  • Android
  • Firefox
  • Chrome/Chromium

To summarize it: Pass is great, but would be even better if it could server as a backend for the usual GUI tools and desktop environments. There is already an experimental iOS client, so there is at least hope for an Android client…