[pass] pass and tomb together

Alexandre Pujol alexandre at pujol.io
Mon Feb 6 01:00:33 CET 2017


> Did you read my latest proposal yet?
> 
>   
> https://lists.zx2c4.com/pipermail/password-store/2017-February/002714.html
> 
> I think it should be secure, and would not completely transform pass.

In my opinion this is the perfect example of solution that would
transform pass.

>From the pass website: "each password lives inside of a gpg encrypted
file whose filename is the title of the website or resource that
requires the password." From this every solution that propose to "hide"
the path is not a sustainable solution.

Password management should be simple and follow Unix philosophy. With pass,

Moreover, in term of security, an hash based method is not secure
because a hash function is... a hash function, not an encryption
function. As you said a dictionary attack (not with password but with
possible path like facebook.com, google.com...) would retrieve you the
full tree in less than a minute.

For the you solution using a secret passphrase, it might work:
- If the master passphrase (MP) stays private,
- If The MP is random,
- If the MP is long enough,
- If you don't use an hash but a PBKDF.
- And even with all of these I'm not sure if the security level you can
provide will be comparable to the security level you have using a
cryptographic key.
If you continue in this direction you should definitely check the
literature in this domain.
Anyway with such a solution you are going to create more changes on pass.

Finally a more important concern: "Do not create you own crypto".
Playing with hash function to "encrypt" a path is creating your own crypto.

The interesting thing in tomb, it that it is (like pass) a very well
known program that uses the state of the art in term of cryptography
(GPG, Cryptsetup & LUKS...)

> 
> My proposal is less sophisticated, but would not introduce any
> significant new dependency.  (The only new thing it needs to do is
> generate SHA-256 digests.)

Because it is just an extension, the new dependency is not an issue
(people that do not want to use it just won't install it).

In my opinion, your proposal is more complex because it would need the
implementation on a new system, while my extension just create a link
between two well known software.

> 
> This sounds cool - thanks a lot for making it and sharing it!  My first
> question is: could this work on Android?  I see that LUKS has been ported:
>    https://github.com/guardianproject/luks/wiki
> 
> But I have no idea how easy it would be to integrate into
>    https://github.com/zeapo/Android-Password-Store
> 
> Unfortunately without Android support it's not really useful for me.

There is a (experimental) tomb port for android [1]. After I will need
to test how to integrate it with Android-Password-Store.


[1] https://github.com/dyne/Tomb/tree/master/extras/android


More information about the Password-Store mailing list