Re: OT: DKIM signatures on email messages from lists.gnupg.org
On Tue 13/Jun/2023 13:02:09 +0200 Alexander Leidinger via Gnupg-users wrote: Quoting Alessandro Vesely (from Tue, 13 Jun 2023 11:19:02 +0200): On Tue 13/Jun/2023 08:46:06 +0200 Alexander Leidinger via Gnupg-users wrote: Quoting Alessandro Vesely via Gnupg-users (from Mon, 12 Jun 2023 18:45:37 +0200): The From was re-written be the list and as such the header check fails. The body check fails as the list adds the following: ---snip--- ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users ---snip--- The message verifies after removing the footer. It can be done routinely, on some kind of signatures. DKIM doesn't specify an automatic removal of a signature. So I postulate there is no DKIM related tool which does this (only home-grown solutions which need to be specially tailored to the sender as you don't know in advance/automatically if a signature has to be stripped or not, and you can not rely on the way the signature is added, as even this list does not use the age old de-facto standard (which was ignored by big corporations like they did with some other de-facto standards) of "-- " on it's own line as a signature separator). http://www.tana.it/sw/zdkimfilter/zdkimfilter.html#mlmtrans for one. You may call it home grown, but it's not tailored to a specific sender. Of course it doesn't work on /every/ signature. Yours, for instance, didn't verify. Gmail's signatures, by contrast, verify across most mailing lists. "Yours ... didn't verify": via list or direct? I meant via list. Direct ones verify well. BTW your GPG signature doesn't verify. Any idea if it was because this lists signature was not stripped (even then, it would need to rewrite the from), or because my signature was stripped (which it shouldn't)? In the message I'm replying to, it was stripped (why?) In the one before that it didn't verify, probably because of the Reply-To:. (I can probably fix that, but not today.) Anyway, it proves my point. And it is not required by the DKIM standard, so yes, I would call it home-grown as you can not rely on its existence on the receiver side. Undoing transformations just mitigates the damage of From: munging by restoring the original From: when it succeeds. Perhaps it could also aid a receiver who trusts an ARC signer, if sometimes the ARC-Authentication-Results: can be verified that way. You may be able to do some un-munging in some situations, but this is not specified anywhere in any validation rule of the standard. As such you can not rely on anything on the receiver side. As such you need to remove the DKIM-Signature header as the list owner, if you want to have the message with a mangled from header not fail the dkim validation. No, to pass DKIM validation a list just needs to add its DKIM signature. The old one doesn't disturb. Lazy DMARC verifiers may even skip signatures where d= is not aligned. Really, you gain nothing by removing DKIM-Signature:'s, except saving a few bytes. (and maybe sign itself, but there are drawbacks), What drawback can there be to signing? CPU resource consumption? If the list signs the message itself due to the rewritten From:-header, it would sign spam-messages which slip through the anti-spam setup of this list. So it would defeat what it is supposed to do, prevent SPAM from arriving in your inbox . It would also either discredit the reputation of the list, or increase the reputation (for a while) of the SPAM message in some big anti-spam setups which use sender-reputation and message-hashes to rate the SPAMiness of messages. Camouflage is not a good anti-spam technique, IMHO. A sane list's subscribers want list messages, and their mailbox provider must be an inept if it degrades the list reputation because of occasional uncaught spam. I agree, but it doesn't mean it can not happen. As such I wouldn't want to mangle the from and sign myself. Not signing might result in worse treatment. Relying on SPF only is weak. See also this: https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail You can not expect all subscribers of the list to change their DKIM settings to a more relaxed way or other sending side related stuff. This may not be in the influence of the person (try to get google to change their dkim settings for gmail). As such it is up to the list owner to be a nice netticen. If the list owner(s) insists on message-munging, that's fine, but in this case the list owner(s) has to remove DKIM signatures if they want to have the message delivered correctly for the DKIM-policy=discard case. Any other action which needs involvement of the receiver or the sender will not work in the generic case (and I consider this list to fall into the
Re: OT: DKIM signatures on email messages from lists.gnupg.org
On Tue 13/Jun/2023 11:40:39 +0200 Werner Koch via Gnupg-users wrote: BTW, the whole DKIM thing does not protect the body of a mail because for example the Content-type is not commonly included in the hash and thus you can change the boundary in this header and then tweak the body. That hack only works when a signature contains the l= tag, which limits the part of the body covered by the signature to the given length. That tag was indeed designed so that mailing lists could append a footer to plain text messages. It should never be set. Best Ale -- ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OT: DKIM signatures on email messages from lists.gnupg.org
On Tue 13/Jun/2023 08:46:06 +0200 Alexander Leidinger via Gnupg-users wrote: Quoting Alessandro Vesely via Gnupg-users (from Mon, 12 Jun 2023 18:45:37 +0200): The From was re-written be the list and as such the header check fails. The body check fails as the list adds the following: ---snip--- ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users ---snip--- The message verifies after removing the footer. It can be done routinely, on some kind of signatures. DKIM doesn't specify an automatic removal of a signature. So I postulate there is no DKIM related tool which does this (only home-grown solutions which need to be specially tailored to the sender as you don't know in advance/automatically if a signature has to be stripped or not, and you can not rely on the way the signature is added, as even this list does not use the age old de-facto standard (which was ignored by big corporations like they did with some other de-facto standards) of "-- " on it's own line as a signature separator). http://www.tana.it/sw/zdkimfilter/zdkimfilter.html#mlmtrans for one. You may call it home grown, but it's not tailored to a specific sender. Of course it doesn't work on /every/ signature. Yours, for instance, didn't verify. Gmail's signatures, by contrast, verify across most mailing lists. What the list-software would need to do is to strip the original DKIM signature Why? Original signatures can often be recovered. They shouldn't be removed anyway. Already answered by Alessandro, but to add to that: any munging with the message (no matter if header or body) invalidates the DKIM signature. If the munging is done on purpose, the DKIM message has to be removed to prevent DKIM-policy=discard setups to lose the message (some people may say this would be on purpose / as designed, and I can agree to that, but the intend of this list here is surely not to discard such messages). I assume you mean the DKIM signature has to be removed, not the DKIM message. As I said, it's not true. (and maybe sign itself, but there are drawbacks), What drawback can there be to signing? CPU resource consumption? If the list signs the message itself due to the rewritten From:-header, it would sign spam-messages which slip through the anti-spam setup of this list. So it would defeat what it is supposed to do, prevent SPAM from arriving in your inbox . It would also either discredit the reputation of the list, or increase the reputation (for a while) of the SPAM message in some big anti-spam setups which use sender-reputation and message-hashes to rate the SPAMiness of messages. Camouflage is not a good anti-spam technique, IMHO. A sane list's subscribers want list messages, and their mailbox provider must be an inept if it degrades the list reputation because of occasional uncaught spam. However, as ARC's specifications, unlike DKIM's, mention no responsibility, some mailers use this instead of DKIM —more on forwarding than on mailing lists, IME. Mailing lists are enjoying an incredibly low rate of fraud. It is enough to impersonate a subscriber to have your message pass, failing authentications notwithstanding. Yet it doesn't happen any often. Sooner or later they'll have to enforce authentication checks on entry themselves. or to not modify the message (at least not the designated header lines, and the body). More info here: https://begriffs.com/posts/2018-09-18-dmarc-mailing-list.html Omitting subject tag and footer seems to me to be worse than From: munging. My filter setup doesn't depend on a footer or subject tag. The world has advanced way past a subject tag or a footer to be able to identify a mailinglist. Any search engine is quite good at finding a webpage related to the list (last line of the signature in this list) and I don't need the email address of the list itself in the footer (it's in the header anyway as the TO or CC). The first content-line of the signature I don't need either. All the info there is either redundant or useless to me when I'm already subscribed. This list also has no subject tag. Seems we can live without it. As we are talking about the DKIM issues this list has, I only talk about this list, and I don't care how other lists handle this. Some admins derive the need to put a footer from legal requirements. Subject tags are just handy for the eye. I too sort mailing list messages in various folders, but I don't have a folder for each list. Munged From:s can sometimes be restored. See also this: https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail You can not expect all subscribers of the list to change their DKIM settings to a more relaxed way or other sending side related
Re: OT: DKIM signatures on email messages from lists.gnupg.org
On Tue 13/Jun/2023 09:26:06 +0200 Alexander Leidinger via Gnupg-users wrote: Quoting Werner Koch via Gnupg-users (from Tue, 13 Jun 2023 09:02:31 +0200): lists.gnupg.org does not do DKIM. I know stripped the obvious wrong DKIM-Signature headers before they are processed by Mailman. Let's see whether this solves the problem. Those of you in C should see my DKIM header but the lists should not. I can confirm: no DKIM signature via the list. Setting up a DKIM signing filter in between Mailman and sendmail shouldn't take more than half an hour, Thanks for replying Ale -- ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OT: DKIM signatures on email messages from lists.gnupg.org
On Mon 12/Jun/2023 21:24:54 +0200 Konstantin Ryabitsev via Gnupg-users wrote: On Mon, Jun 12, 2023 at 06:45:37PM +0200, Alessandro Vesely via Gnupg-users wrote: What the list-software would need to do is to strip the original DKIM signature Why? Original signatures can often be recovered. They shouldn't be removed anyway. If list-software is doing something to make the DKIM signature no longer verify, it must remove the DKIM signature or rewrite the From: header to change alignment. An invalid signature is never a reason to reject a message. The spec states to treat invalid signatures as if they weren't there. Forensic analysis and advanced software can use the signature even if it was invalidated. Best Ale -- ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OT: DKIM signatures on email messages from lists.gnupg.org
On Mon 12/Jun/2023 13:05:51 +0200 Alexander Leidinger via Gnupg-users wrote: Quoting Alessandro Vesely via Gnupg-users (from Mon, 12 Jun 2023 10:57:32 +0200): Hi, would someone please explain DKIM settings of lists.gnupg.org? I'm not involved in gnupg.org administration, but it looks like there are none. Sometimes there is a signature. The Announce message of April 28 had two: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Sender:Content-Type:List-Subscribe:List-Help:List-Archive: List-Unsubscribe:List-Id:Subject:MIME-Version:Message-ID:Date:Cc:To:From: Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Post:List-Owner; bh=AaifcSnTnefRUURuPlCYtVlF0on0neCAn9vyAWrccMA=; b=GZor1crbzgMYZ0XztsHrHN0w3P d4QT2yOyZRUI1iA/Ys5St2fi/3ZIKghj/man3fY3c8bmN1N0fwEGCadSTzKO5YpM29kATZ8tDDLcf hX/49Mlk+X0sw5ecu3Z/Bm+2RJlpk8TPHWNM1wUy7yIlI4txDDSCsIlAawikJ4I4HTJY=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:Date:Subject:Cc:To:From: Sender:Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=waITwZnkLncVwES3fe/pbC3rS8gp+dpge17NQpRHvMU=; b=U9warAJAiKlE0f9mSRe61yIzqa TNpdihkg9KDQBb8px1ESE5/6/qPzsg2KOMt82hpGMJukxzKAoDMwOGvpN/TGO9ADjrjWz9Dk5Ry+p QIwg+x3PKxYoOGVU9cmpVmeGsu6yOemyfN3mz0fGdqEC7SBGWjbe4LusOc/Kb65Opd0k=; There were a number of Received: by/from kerckhoffs.g10code.com in between, as if the message was sent back and forth to a signer. Most likely some header fields are changed during the transaction. Looking at recent posts, I counted 44 with a failed signature by d=gnupg.org, 22 with no DKIM signature at all and none with a good signature. Can it be that those 44 are from real people which have a from-address @gnupg.org? I only counted d=gnupg.org. I'm asking because there was a proposal to eliminate SPF from DMARC authentication methods[*]. Opposers to such move note that in a number of cases SPF succeeds where DKIM fails. The discussion concluded that it must be because of misconfiguration, since most in-transit alterations were eliminated. As people on this list is certainly acknowledgeable, I though I'd dare asking where does such misconfiguration stem from. Your mail to the list had a DKIM signature from tana.it (your DKIM signature). It specifies that in the header the date, to, from and subject lines are subject to validation. Those lines are enough to uniquely identify a message. Signing more fields only makes the signature more fragile. It is not enough to prevent crackerjack re-playing in any case. The From was re-written be the list and as such the header check fails. The body check fails as the list adds the following: ---snip--- ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users ---snip--- The message verifies after removing the footer. It can be done routinely, on some kind of signatures. What the list-software would need to do is to strip the original DKIM signature Why? Original signatures can often be recovered. They shouldn't be removed anyway. (and maybe sign itself, but there are drawbacks), What drawback can there be to signing? CPU resource consumption? or to not modify the message (at least not the designated header lines, and the body). More info here: https://begriffs.com/posts/2018-09-18-dmarc-mailing-list.html Omitting subject tag and footer seems to me to be worse than From: munging. See also this: https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail For mailman there is some info here what could/should be done: https://wiki.list.org/DEV/DKIM https://wiki.list.org/DEV/DMARC For listserv there is some info here what could/should be done: https://www.lsoft.com/manuals/17.0/advancedtopics/Section12UsingDomainKeysIdentifi.html https://www.lsoft.com/manuals/17.0/advancedtopics/Section13DMARCandLISTSERV.html There is also ARC (which you should see in the headers of my mail): https://en.wikipedia.org/wiki/Authenticated_Received_Chain I'd definitely recommend ARC, not the conceptual Mailman 3 version. However, most receivers are not yet prepared to accept it. Best Ale -- ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
OT: DKIM signatures on email messages from lists.gnupg.org
Hi, would someone please explain DKIM settings of lists.gnupg.org? Looking at recent posts, I counted 44 with a failed signature by d=gnupg.org, 22 with no DKIM signature at all and none with a good signature. I'm asking because there was a proposal to eliminate SPF from DMARC authentication methods[*]. Opposers to such move note that in a number of cases SPF succeeds where DKIM fails. The discussion concluded that it must be because of misconfiguration, since most in-transit alterations were eliminated. As people on this list is certainly acknowledgeable, I though I'd dare asking where does such misconfiguration stem from. Best Ale -- [*] https://mailarchive.ietf.org/arch/msg/dmarc/2CcO17K8QcOmTORHl3_isQBm_RE ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [Announce] [CVE-2022-3515] GnuPG / Libksba Security Advisory
On Mon 17/Oct/2022 09:43:56 +0200 Werner Koch via Gnupg-users wrote: How to check whether GnuPG has been fixed ~ GnuPG is the most prominent user of Libksba and it is not immediately visible whether a fixed version of Libksba is used. To check this run: , | gpgconf --show-versions ` and watch out for a line like , | * KSBA 1.6.2 (x) ` If you see a version number of 1.6.2 or newer, you got the fix. Debian fix kept the old version number 1.5.0-3, though: Forwarded Message Subject: [SECURITY] [DSA 5255-1] libksba security update Resent-Date: Mon, 17 Oct 2022 20:13:43 + (UTC) Resent-From: debian-security-annou...@lists.debian.org Date: Mon, 17 Oct 2022 20:13:16 + From: Salvatore Bonaccorso Reply-To: debian-security-announce-requ...@lists.debian.org To: debian-security-annou...@lists.debian.org - Debian Security Advisory DSA-5255-1 secur...@debian.org https://www.debian.org/security/ Salvatore Bonaccorso October 17, 2022 https://www.debian.org/security/faq - Package: libksba CVE ID : CVE-2022-3515 Debian Bug : 1021928 An integer overflow flaw was discovered in the CRL parser in libksba, an X.509 and CMS support library, which could result in denial of service or the execution of arbitrary code. Details can be found in the upstream advisory at https://gnupg.org/blog/20221017-pepe-left-the-ksba.html For the stable distribution (bullseye), this problem has been fixed in version 1.5.0-3+deb11u1. We recommend that you upgrade your libksba packages. For the detailed security status of libksba please refer to its security tracker page at: https://security-tracker.debian.org/tracker/libksba Further information about Debian Security Advisories, how to apply these updates to your system and frequently asked questions can be found at: https://www.debian.org/security/ Mailing list: debian-security-annou...@lists.debian.org ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD docs on the wiki, restructuring. Feedback on forUsers page
On Tue 28/Sep/2021 17:39:29 +0200 Bernhard Reiter wrote: Feedback (and help) is always appreciated.:) I'm not sure if WKD/forHosts would be a better location than WKDHosting. Anyway, I'd publish the test suggested by Alissa on this list on 8 July 2019: gpg --homedir "$(mktemp -d)" --locate-keys h...@alyssa.is The address https://www.ietf.org/id/draft-koch-openpgp-webkey-service.txt, near the bottom of the page yields 404. Please use: https://datatracker.ietf.org/doc/html/draft-koch-openpgp-webkey-service Keep up the good work! Ale -- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Certified OpenPGP-encryption after release of Thunderbird 78
On Fri 29/May/2020 12:29:48 +0200 Stefan Claas wrote: > Binarus wrote: >> On 28.05.2020 23:21, Stefan Claas wrote: >>> >>> while it is not my business, I do not understand why you have to >>> take care about the Thunderbird issue, as a users and not the >>> Aufsichtsbehörde ... If for example you have a job at the >>> Aufsichtsbehörde then ok, like I said, I would contact gnupg.com and >>> ask them if GnuPG Desktop (A Windows app) fits for your working >>> environment and in case not what they would suggest, because the >>> Aufsichtsbehörde should have IMHO funds to issue a professional >>> licensed working solution for their employees. >>> >>> In case you only have to deal as a gpg4win user with the >>> Aufsichtsbehörde via email, then I don't understand how would they >>> detect if you would not comply by using later the new Thunderbird, >>> without BSI approval. >> >> This is not my field, but I believe that (besides authorities) there >> are companies or other institutions which *must* use certified >> encryption solutions. Some ideas: > > [...] > > Yes, understand. But then if those institutions have no funds or > are not willing to invested in their IT security infrastructure > then they may ask the BSI how to proceed. Maybe the BSI has funds > to let gnupg.com develope a custom Windows solution for them. > > The other option would be that the OP and others continue using > their current Thunderbird/Enigmail/gpg4win setup. Any chance that the BSI will approve the RNP library that Thunderbird is going to use? Best Ale -- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Comparison of RSA vs elliptical keys
On Wed 13/May/2020 11:54:12 +0200 Damien Goutte-Gattat via Gnupg-users wrote: > On Wed, May 13, 2020 at 10:02:14AM +0200, Sylvain Besençon via Gnupg-users > wrote: > >> I guess that Curve 25519 is mentioned in the IETF standard, isn't it? > > Not yet. Officially, only the NIST P-256, P-384, and P-521 curves are part of > the standard (since RFC 6637). The first mention of Curve 25519 for OpenPGP > was > in a draft by Werner in 2014 [2]. The draft never made it to a RFC but the > 25519 curve is now part of the draft for RFC4880bis, the next revision of the > OpenPGP standard [3]. However, its signing flavor, Ed25519, is described in RFC 8032: This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. https://tools.ietf.org/html/rfc8032 Its use is standardized for DKIM signatures by RFC 8463. Best Ale -- > > [2] https://tools.ietf.org/html/draft-koch-eddsa-for-openpgp-00 > > [3] https://gitlab.com/openpgp-wg/rfc4880bis signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to improve our GUIs
On Mon 07/Oct/2019 12:04:33 +0200 Werner Koch via Gnupg-users wrote: > On Sat, 5 Oct 2019 21:21, vedaal said: > >> and then a separate option of >> "Export Secret Keys" > > The OP explictly suggested to make the exporting of the secret key not > too easy so that users don't accidently send out their secret keys. On the other hand, if the user received a malicious mail explicitly asking to click so and so to export secret keys, does the GUI have to issue several warnings before eventually letting the user do it? What about users who are so gullible to not actually discern true from false? Trying to support _all computer users_[*] may turn out to displease more than expected. Best Ale -- [*] https://www.gnu.org/gnu/manifesto.html#benefit signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Difficulty of fixing reconciliation
On Tue 13/Aug/2019 13:07:07 +0200 Peter Lebbing wrote: > On 13/08/2019 09:54, Alessandro Vesely via Gnupg-users wrote: >> More than a reasonable number of signatures makes no sense in >> practice, so I agree lists should somehow be "fixed" so as not to >> accept an unreasonable number of signatures (reasonable == 2??) > > [...] > > Furthermore, this is from memory, but when I read basic information > about the SKS reconciliation algorithm, I see the terms "monotonicity > requirement for progress" or something alike. Absolute monotonicity is wrong. It must be possible to delete errors. > [...skip algorithm for their PhD thesis...] > > Let's do this with your max 2. > > Somebody uses SKS keyserver network host A to add two signatures, call > them A1 and A2 to the key in question, which did not have any signatures > yet. Host A accepts them, they fall within the limits. > > Either this same person or someone else adds two signatures on SKS > server B on the same key, call them B1 and B2. Hosts A and B haven't > reconciled yet, so B sees no signatures on the key and accepts. > > Now they reconcile. > > They compare their datasets. They are not the same: we still need to > have progress to get to completion. Let's reconcile signature A1. Server > A offers server B signature A1. Wait a minute, the key already has > signatures B1 and B2. Server B cannot accept signature A1, it would > break the contract that there are ever only 2 signatures on the key. > > Now we have a deadlock. There is no following step that would fulfill > the monotonicity requirement as well as make any progress. The only way > to fulfill the monotonicity requirement is when server A keeps the > signatures A1 and A2, and server B keeps B1 and B2. But the progression > has halted and the process never finishes. The illegal sig shall be deleted from both servers. (2 is a bit Procrustean, a reasonable number would be enforceable.) > Besides, any limit on the number of signatures is a Denial-of-Service. > In your case, if Alice, Bob and Carol all sign eachother's keys, there's > no more room for other signatures. And if Mallory creates two bogus keys > and signs all the keys of Alice, Bob and Carol, the three can't add any > real signatures anymore. I'm no expert, but it seems to me that 3rd party signatures should not be allowed. All signing party recipes provide for /exchanging/ sigs, but then rely on the fact that Alice can sign Bob's sig before Bob has signed Alice's and without Bob's authorization. That is, the semantics is good, but it's not algorithmically enforced. > The algorithm is designed to withstand very well funded actors, > oppressive regimes were what the designers were thinking of. Obviously, > the algorithm does this regardless of who is trying to do something > otherwise, no matter whether it is a repressive regime or the legitimate > operators and designers of the system. Hm... if your sig is signed by a suspect, you become suspect too? In fact, SKS servers with lots of countersigned sigs is manna from heaven for police. I recall someone in the sixties recommending "Comrades, no phone-books! Burn them, learn numbers by memory and burn them." So, would that be a reason to allow 3rd party signatures? I sign your sig, but then I also sign a few dozens other random sigs so as to conceal the link between you and me. Sounds like a poor trick to me. >> The bug, however, is in the program that chokes on poisoned keys! > > [...skip very unfavourable runtime <-> data size ratio...] > > So GnuPG gets a key with a lot of third-party signatures. It can keep > wading through all the crap looking for the real signatures the user > does want between all the crap added by attackers, and this takes a lot > of runtime. > > Or it can decide: this is taking to long, I bail out. Exactly! That signature is poisoned, delete it. There might be utilities that attempt to recover it —much like AV utilities to recover infected files. >> Was that fixed, yet? > > How? You keep looking through the piles of crap, or you stop looking. In > either case, you don't find what you are looking for in a desirable > length of time. The defense would try and avoid poisoning. When a signature is poisoned, the defense has failed. > I think the solution needs to be sought in a direction where GnuPG > doesn't have to look for valid data amidst a lot of invalid crap. > Because evaluating the invalid crap can always be made expensive, so > there should be other means to say "I'm not going to parse this, find > another way to get me the proper data where it's not buried in crap". Agreed. Best Ale -- signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: PGP Key Poisoner
On Tue 13/Aug/2019 12:08:31 +0200 Werner Koch Via Gnupg-users wrote: > On Tue, 13 Aug 2019 09:54, gnupg-users@gnupg.org said: > >> The bug, however, is in the program that chokes on poisoned keys! > > Nope. This is a long standing DoS protection by limiting the total > length of a keyblock. The diagnostics were a bit misleading, though. > > The time it took to process all these signatures during importing is due > to a fix and out of order keyblock functions which has been enabled by > default in 2.1. It should be obvious that checking several thousands of > signatures and finding the matching user-id takes its time. > > Anyway, given that these keys are real the approach with 2.2.17 is to > auto-retry an import with import-clean etc. if the keyblock size hits > the size limit. For keyserver imports import-clean is also the default. Why wasn't that check in place from version 0.0.0? Perhaps GnuPG was coded at times when DoS was an operating system? Of course, anonymous key poisoning is a kind of gratuitous vandalism. Yet, crypto is supposed to work in a hostile environment. Best Ale -- signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: PGP Key Poisoner
On Mon 12/Aug/2019 19:27:49 +0200 Peter Lebbing wrote: > On 12/08/2019 18:39, Stefan Claas via Gnupg-users wrote: >> Why was is then not fixed a decade ago, like it was done with 2.2.17? > > There is no fix for the SKS keyserver network, which explains why it > wasn't fixed in 2.2.17 either. In fact, fixes have been deployed over > the last several years. DANE, WKD, Autocrypt, work on > keys.openpgp.org... This and John Z mentioning OCaml seem to point a finger in the wrong direction. The key poisoner shows that 20 signatures can be handled in a few seconds (I didn't try, I trust the author). More than a reasonable number of signatures makes no sense in practice, so I agree lists should somehow be "fixed" so as not to accept an unreasonable number of signatures (reasonable == 2??) The bug, however, is in the program that chokes on poisoned keys! Was that fixed, yet? Best Ale signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
