1. 14

Lobte.rs discussion of the article referenced: https://lobste.rs/s/7rkfsu/pgp_problem


  2. 5

    That is because a long term standard must be extensible. Thus the fields can not be fixed and it must be possible to add new types.

    The new wisdom is “have one joint and keep it well oiled”. Last I heard, PGP was still having problems with the message authentication hash upgrade.

    All you have to do is directly transcribe these cases into a case statement and you are done. There is no real thinking required.

    This is only correct if out of bounds reads are not something you need to worry about, which is not correct in PGP’s favorite implementation language.

    Since this is from the public key section of the PGP published standard it might be interesting to compare with the same sort of thing from the Signal Protocol

    Wait, we were talking about packet parsing and you criticize Signal for not providing “identity information outside the program”? Massive non sequitur, and I can hardly call GPG’s “human only output” policy as proper access (see e.g. GDPR’s opinion on “machine readable” data exports). Additionally, from what I can tell this was an intentional design decision, so it’s misleading to describe it as “missing” from the standard.

    RSA with 2048 bit keys is a perfectly reasonable and conservative default.

    Uh, what year is it? 1024 bit RSA is considered too short now. 2048 is a perfectly reasonable minimum, not conservative at all.

    Most people prefer to keep their identity indefinitely.

    This statement demonstrates a blatant misunderstanding of the complaint.

    But apparently the author does not understand why authenticated encryption is not used or even required for the things that PGP is normally used for.

    I briefly read the author’s citation; the argument can be paraphrased as “attacks (such as oracle attacks) on the lack of authenticated encryption are impossible, because you can’t automate PGP processing.” This is a bold claim for a piece of software, frankly.

    PGP’s signatures are cryptographically strong and are indeed intended to both prove that a particular entity sent a message and that message was delivered as sent. They work very well in practice and are normally used. […] and that is the third time the fact that MDCs can be stripped is mentioned […] Quite excessive when talking about a feature that is not normally used in PGP.

    Again, this is a staggering indictment of the author’s lack of understanding of the criticisms. This could only be an acceptable response if we pretend that signature forgery via ciphertext malleability isn’t a thing that exists.

    Of course, if you allege that your software is impossible to automate, then you can try to pretend that IND-CCA2 doesn’t matter.

    16 whole bits of security.

    this statement is quite misleading […] guessing with only a one in 2^16 (65536) chance

    More reading comprehension problems. The rebuttal is reiterating the complaint in a different tone of voice. But of course, our software is impossible to automate, so 16 bits of security is plenty.

    There is no such “reference PGP implementation”.

    This is simply being obtuse. OpenPGP and GPG are practically indistinguishable.

    If they were distinguishable, the community would be forced to recognize that the spec is insecure as soon as you automate usage, which brings in decryption oracles and enabling all the attacks that Walzer has dismissed as irrelevant.

    it forces the user to comprehend the existence of a key in a way where it is intuitively obvious

    Let me just slide this one against this earlier paragraph…

    They are usability studies. They are deliberately designed to be as difficult as possible (you hide all the documentation) in order to get results.

    Sure would be nice if you had documented evidence of that intuitiveness, but it seems the author has a grudge against usability studies.

    EFAIL turned out to be a kind of a media hoax against PGP

    EFAIL was a vulnerability in a program attempting to automate usage of PGP. This failed for predictable reasons, because you can’t automate usage of PGP, therefore any vulnerability from any such attempted automation is not the fault of PGP.

    1. 2

      Yes, I have a grudge in general against software that makes it impossible for the user to automate it.

      1. 2

        EFAIL was just programs trying to decrypt everything stupidly without parsing or considering message limits. It wasn’t because you can’t usage of PGP (you totally can), but because the program that doing it was written in incredibly stupid ways, dare I say without any security considerations.

        1. 2

          It’s not just the implementation that was erroneous. The Efail work identified various protocol bugs in gpg too.