>PGP: A 90ties horror show.

The linked attacks are literally not applicable to the "pass" pass use case. Even if they were there is no authentication done in the pass case. An attacker could replace the whole file so they don't have to mess around with trying to modify the encrypted material. An attacker could just delete the whole file as well for the same effect. So that doesn't really matter for the password storage case. This suggests that the author has not yet entirely thought through the password storage case.

>For a more in-depth post on the maladies of PGP see What’s the matter with PGP?[1].

It is unclear why the link to this blog post was posted. It seems to have nothing to do with what "pass" does. Anyway, here is my standard critique of that article:

* https://articles.59.ca/doku.php?id=pgpfan:wtmwp

>No Post-Quantum security

Really reaching here...

[1] https://blog.cryptographyengineering.com/2014/08/13/whats-ma...

> An attacker could replace the whole file so they don't have to mess around with trying to modify the encrypted material.

Replacing is one way of modifying. If the passwords storage is authenticated, it can't be replaced.

(An attacker could probably replace the storage with its older version. Unless there's an extra mechanism in place to counter that — this highly depends on the concrete setting.)

You still get the regular PGP integrity protection even in a case where there is no authentication. I just tried it and pass just sent along the GPG error:

    gpg: WARNING: encrypted message has been manipulated!

... instead of the password file I modified.

1. What did you try exactly?

2. How is this “regular integrity protection” defined formally?

I modified a byte in the encrypted data. It then failed the modification detection code (MDC) as defined by RFC-4880. My article:

* https://articles.59.ca/doku.php?id=pgpfan:mdc

It's still very unclear (having spent a few minutes on the RFC) what it does exactly. It sounds like a mechanism to detect accidental errors (say, user copy-pasting encrypted data incorrectly or passing some garbage in place of ciphertext) and not maliciously crafted modifications. More like error correcting code than authentication.

The fact that it detects one byte being modified means nothing.

In the case of pass, no authentication is normally done, so what remains has to be an integrity check. Pass can sign git commits, but OpenPGP signs the content directly, so the MDC is not used.

The encryption mode normally used in OpenPGP is an improved version of cipher feedback (OCFB) for the block mode and something called the modification detection code (MDC) to detect modification. The two (OCFB-MDC) work together to produce an authenticated encryption mode based on shared knowledge of the symmetrical encryption key. In practice few seem to bother with the MDC but it is there and is cryptographically strong should an implementer want to use it for preventing, say, EFAIL.

I give this article a chance, but some assumptions are outright false. For example:

> No Post-Quantum security

Yeah, no. The beauty of PGP is being able to select your encryption algorithm. Somehow, arguing that AES-256 is more resistant to for example Ed25519 is just factually incorrect and people that use KeePass are not memorizing 40 character passwords to unlock their password manager.

> No Service Privacy / Leaks Changes

Pass doesn't make assumptions. If you want to encrypt filenames then wrap it with gocryptfs or cryfs or pass-tomb. The nice thing about syncing with pass is having auditable changes that doesn't require a complete database resync. Imagine someone modifying your password store with KeePass. You are not going to have diff to tell what has been changed. With Password Store, you can see exactly what has been changed between syncs.

> No authentication of values

Again, something that you can change in your PGP settings. I'm not going through the full article, but in all honesty it just sounds like this person doesn't like GnuPG and doesn't understand it. Lest not forget that pass is by the same individual that created wireguard and a slew of other security-focused tools and I think their reputation speaks for itself.

There is also "passage": https://github.com/FiloSottile/passage

It's pass with age-encryption instead of pgp.

Discussed here: https://news.ycombinator.com/item?id=29597729

The use of age doesn't seem to address any of the stuff in the linked article. At least the use of age would not make things worse in this particular application because pass does not authenticate the saved password files. Age famously can't do authorization for the asymmetrical encryption case.

> people that use KeePass are not memorizing 40 character passwords to unlock their password manager.

I use a pass phrase that is substantially longer then 40 characters. It doesn’t take too long to sink in.

I find it easier to remember a short sentence than a short password with a bunch of weird characters in it for sure

Fair, but I think that is more of an exception than the norm. For people that may want to more frequently lock their password database, having a 40 character password would quickly become a PITA.

> […] having a 40 character password would quickly become a PITA.

Do you have a a favourite song/poem/nursery rhyme?

"Hey diddle diddle, the cat and the fiddle,"

* https://en.wikipedia.org/wiki/Hey_Diddle_Diddle

And you only have to unlock it perhaps once at the beginning of the work day (set auto-lock/forget to 8 hours), or twice a day (morning, after lunch; auto-lock to 4 hours). Once unlocked maybe only ask for confirmation for use.

Using a phrase in a book or a poem is not much stronger than using a single word as a passphrase. Attackers include such phrases in their cracking dictionaries, including variations on spelling and punctuation. After the initial hashing of the candidate passphrase, a five-letter word takes exactly as long as a 100-character lyric from a song.

There are lots of sad stories of people losing funds in the early days of Bitcoin when "brain wallets" were briefly popular. Victims used quote-based passphrases that seemed unguessable.

The threat model is a little different when it includes getting access to your encrypted password-manager database or OpenPGP smart card. But the point stands that a well-known phrase might as well be a dictionary word.

To me it makes more sense to use a longer password for FDE, and maybe have it have it cached into the TPM but with a shorter unlock code for resuming, locking, etc. It might make sense to have a two tier password for password managers though. Like a hot/cold.

Using a dictionary, I was able to roll a funny and easy to remember Passphrase that fulfills the 40 character limit. I'm using it ever since for my KeePass file.

Correct horse battery staple

I use that.. so not exactly that ;)

I mean, if the attacker has writable access to your vault, he likely can observe you handling the unencrypted password or steal all your gpg key material after you unlocked it. This makes the "No binding between keys/values", "No authentication of values" and "My passwords are emails?" sections moot.

>I mean, if the attacker has writable access to your vault, he likely can observe you handling the unencrypted password or steal all your gpg key material after you unlocked it.

To be clear here, only if that implies access to the memory you control, otherwise, no. GPG is pretty good about local file access by an attacker and pass maintains that on platforms where that is possible.

I would not assume the memory separation on x86 to be reliable.

Access to the vault ≠ access to unlocked vault. This is the whole point of storing anything encrypted on your disk.

The password managers don't protect against a malware running on your laptop with root privileges and attaching to your processes. They protect against someone taking the disk out of your computer and trying to extract the passwords.

But if they have the disk and modify is, its still them who have the disk. So the "No binding between keys/values" and "No authentication of values" still dont work out, either. And they are able to modify the contents on my disk, they'd be easier off installing a rootkit, pass cant protect against that.

> No Post-Quantum security

I am sure that in 100 years or so when this becomes a reality, if it ever actually happens, then I'll be sure to change my password manager.

It is kinda hard to take a security guy seriously when he thinks that a as yet mystical force is something that can be usefully defended again.

> then I'll be sure to change my password manager.

And change all your passwords as well? I don't think you can import your passwords into a new manager if the old one gets broken.

This reads like it was written by a junior auditor trying to make a name for themselves, while not minding looking like a total fool in the process.