4 ms·
>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 t
by upofadown 4y ago
>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 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-matter-with-pgp/ https://blog.cryptographyengineering.com/2014/08/13/whats-ma...
- gnull 4y ago> 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.)
- upofadown 4y agoYou 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.
- gnull 4y ago1. What did you try exactly? 2. How is this “regular integrity protection” defined formally?
- upofadown 4y agoI 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 https://articles.59.ca/doku.php?id=pgpfan:mdc
- gnull 4y agoIt'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.
- upofadown 4y agoIn 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.