encrypted file and directory names?

[Brian Candler]

On 05/02/2017 21:22, Adam Spiers wrote:
> The first thing to note is that if the mechanism for calculating 
> obfuscated filenames is a simple hash such as SHA-256, then in order 
> to implement
>    pass show google.com
> we simply perform SHA-256 on "google.com", and then look for a file 
> called
> ~/.password-store/d4c9d9027326271a89ce51fcaf328ed673f17be33469ff979e8ab8dd501e664f 
>
The trouble with this discussion is that no threat model has been 
proposed, so we can just argue round in circles.

You said you are worried about certain types of attack (e.g. an 
untrusted sysadmin on the same machine, who is able to read system 
memory) - IMO such an attack is meaningless to try to defend against. If 
the attacker has root on the system you're using, you are toast whatever 
you try to do.  There are a million ways they can intercept what you're 
doing.

I gather than you don't want people to learn which websites you have 
visited. Well, if they have root on your system they will learn this 
anyway. So if that's not it, perhaps the threat is from people who don't 
have access to your machine, but do have access to the git repo?

If they have access to the repo, even if the filenames are encrypted or 
salted and hashed, they'll be able to infer useful things from the 
number of subdirectories, the number of files in each subdirectory, and 
the commit history in each subdirectory.

(You could keep everything in one flat directory, but then you lose the 
ability to encrypted to different sets of keys, with a different .gpgid 
file in each subdirectory)

So if your paranoia level is high, then as others have said, it may make 
more sense to encrypt the whole directory tree rather than each file 
individually.

I like pass because it's simple, it's open, it does the job I care 
about, and its security model is abundantly clear. I worry that adding 
obfuscation will make it not really any more secure, but less practical 
to use.

Regards,

Brian.