Tag Archives: GPG

Pass – A perfect shell based password manager

Pass 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
business
commerce
financial
$ ls -1 $HOME/.password-store/business/
linkedin.com.gpg
example.com.gpg
important.com.gpg

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
|   |-- linkedin.com
|   |-- example.com
|   `-- important.com
|-- commerce
|   `-- amazon
|-- financial
|   |-- badbank.com
|   `-- mybank.com

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/example.com
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/example.com
[master 4c09c76] Added password for business/example.com using /usr/bin/vim.
 1 file changed, 0 insertions(+), 0 deletions(-)
 create  ...read more 
Source: FULL ARTICLE at Planet KDE

Philipp Kern: git-annex: encrypted remotes

Due to the data loss I blogged about, I had to reverse engineer the encryption used by git-annex for its encrypted special remotes. The file system on which the content lived has a bullet hole of 8 GB in it, which was helpfully discarded by pvmove. It’s pretty unhappy about that fact, parts of the git repository are unusable and directories cannot be accessed anymore. git-annex cannot possibly run anymore.

However, I was still able to access the git-annex branch within said git repository (using porcelain). This branch contains a file called remote.log which contains the keys of the special remotes. There’s one per remote, encrypted to a GPG key of your choice and all files within that remote are encrypted with the same symmetric key.

One small detail stopped me from getting the decryption right the first time, though. It seems that git-annex uses randomness generated by GPG and armored into base64. In my naïveté I spotted the base64 and decoded it. Instead it’s used verbatim: the first 256 bytes as HMAC key (which reduces randomness to 192 bytes) and the remaining bytes for the symmetric key used by GPG (which will do another key derivation for CAST5 with it). A bug about that just hit the git-annex wiki.

With that knowledge in mind I wrote a little tool that’s able to generate encrypted content keys from the plain ones used in the symlinks. That helps you to locate the file in the encrypted remote. Fetch it and then use the tool to decrypt the file in question with the right key.

The lesson: Really backup the git repository used with git-annex and especially remote.log. I’m now missing most of the metadata but for some more important files it’s luckily still present. Recovery of the file content does not depend on it if you can deduce the filename from the content. If you have many little files it might be a bit futile without it, though. …read more
Source: FULL ARTICLE at Planet Ubuntu

Wildman Kickstarter Will Remain Active

Last week Gas Powered Games’s Chris Taylor announced significant layoffs at his studio only days after revealing a Kickstarter for an action-RPG called Wildman.

After posting a video update on Wildman’s Kickstarter page stating that the futures of GPG and Wildman were tied up in how much demand there was for the game, Taylor revealed in a Reddit AMA that the Kickstarter will continue for now.

Continue reading…

Source: FULL ARTICLE at IGN Video Games