From donottellmetonottellyou at gmail.com Tue Dec 3 17:41:41 2024 From: donottellmetonottellyou at gmail.com (Jade Masker) Date: Tue, 3 Dec 2024 11:41:41 -0500 Subject: Pinentry password manager regression Message-ID: Hi, not sure if this is the right place, but here goes. My distribution has recently updated from pinentry 1.2.1 to 1.3.1 in nixos 24.11. I was using the gtk2 version of pinentry, which allowed integration with a password manager (the other ones didn't). This allowed me to skip the pinentry prompt and instead get a prompt from keepassxc, which stores the private key password. 1.3.1 has a regression: https://github.com/NixOS/nixpkgs/issues/361151 To summarize, the checkbox that allowed opening the password manager on prompt is gone, and I now have to manually copy the password in the clipboard, which is less convenient and potentially less secure. My request is that this checkbox and related functionality is added back if possible. Potentially it could also be useful for the other pinentry's to have this so people on a default KDE or Gnome distribution could use this feature. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernhard at intevation.de Thu Dec 5 11:37:44 2024 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 5 Dec 2024 11:37:44 +0100 Subject: phasing out SHA1 for digest creation Message-ID: <202412051137.51831.bernhard@intevation.de> Hi Werner, last year in March 2023 you wrote in https://dev.gnupg.org/T6433 to the question > > Is there some plan to disable SHA-1 signatures by including this in the weak algorithms list in close future? > No, it would break the verification of too many signatures. Just rereading https://www.gnupg.org/faq/weak-digest-algos.html > Although the SHA-1 algorithm shows signs of weaknesses as well, > it is still very hard and time consuming to create collisions. > Mounting a pre-image attack is still far out of reach. Wikipedia has > As of 2020, chosen-prefix attacks against SHA-1 are practical.[6][8] [6] https://www.ntu.edu.sg/news/detail/critical-flaw-demonstrated-in-common-digital-security-algorithm | [?chosen-prefix collision attack] | using a cluster of 900 GPUs running for two months, | the pair have successfully demonstrated their way to break the SHA-1 | algorithm using this attack [8] is the same research result, adding costs | using 900 Nvidia GTX 1060 GPUs (we paid US$ 75k and machines got faster. Is the statement of https://www.gnupg.org/faq/weak-digest-algos.html for 2025 still current? It feels outdated. This page is not linked from https://www.gnupg.org/faq/gnupg-faq.html so maybe it should have been deleted already. I suggest to delete it. I also suggest to change the default to not create SHA1 message digest by default anymore, unless and option is given. (And update https://dev.gnupg.org/T6433) As for verification, how many signatures would be affected, do we have any ideas since when no new signatures with SHA1 digests are created? Maybe adding a depreciation warning is another path? It has been more than 18th months since March 2023. :) NIST aims to phase out SHA1 until 2030 (if Wikipedia is right), I think this means old signatures. In short, there should be a plan. Best Regards, Bernhard -- https://intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From bwalzer at 59.ca Thu Dec 5 13:36:20 2024 From: bwalzer at 59.ca (Bruce Walzer) Date: Thu, 5 Dec 2024 06:36:20 -0600 Subject: phasing out SHA1 for digest creation In-Reply-To: <202412051137.51831.bernhard@intevation.de> References: <202412051137.51831.bernhard@intevation.de> Message-ID: On Thu, Dec 05, 2024 at 11:37:44AM +0100, Bernhard Reiter via Gnupg-devel wrote: > Hi Werner, > > last year in March 2023 you wrote in > https://dev.gnupg.org/T6433 There was no discussion of the potential vulnerabilities in T6433 that might be caused by leaving things as they are. When discussing long used methods we really need to concentrate on the actual potential harm to users. What are those potential harms here? My understanding is that since SHA-1 is secure for everything but collisions that the user is quite safe even in the face of easy to create collisions. What am I missing? An attacker can't create a collision with an existing SHA-1 digest and the new digests are made with SHA-256. An attacker can create matching keys using SHA-1 digests and submit one of them to some sort of trusted third party for certification but that is the sort of thing that only works once. What is the actual issue here? Bruce From rainer.perske at uni-muenster.de Thu Dec 5 18:13:44 2024 From: rainer.perske at uni-muenster.de (Rainer Perske) Date: Thu, 05 Dec 2024 18:13:44 +0100 (CET) Subject: phasing out SHA1 for digest creation In-Reply-To: Message-ID: Bruce Walzer schrieb am 2024-12-05: > What is the actual issue here? Extremely simplified: Attacker makes many good documents and many bad documents until he finds a collision. See https://shattered.io Attacker takes the good document and the bad document with the same hash. Attacker asks victim to sign the good document. Victim does so. Attacker combines the signature with the bad document. So the attacker can "prove" that the victim has signed the bad document. Conclusion: Do never use SHA-1 for new signatures. Emit a warning for existing SHA-1 signatures. Kind regards -- Rainer Perske Systemdienste + Leiter der Zertifizierungsstelle (UCAM) -- Universit?t M?nster CIT - Center for Information Technology Rainer Perske, Systemdienste R?ntgenstra?e 7-13, Raum 006 48149 M?nster Tel.: +49 251 83-31582 E-Mail: rainer.perske at uni-muenster.de Website: www.uni-muenster.de/IT Universit?tszertifizierungsstelle M?nster (UCAM): Tel.: +49 251 83-31590 E-Mail: ca at uni-muenster.de WWW: www.uni-muenster.de/CA YouTube: youtube.com/@uni_muenster Instagram: instagram.com/uni_muenster LinkedIn: linkedin.com/school/university-of-muenster Facebook: facebook.com/unimuenster -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6319 bytes Desc: S/MIME cryptographic signature URL: From bwalzer at 59.ca Thu Dec 5 23:59:00 2024 From: bwalzer at 59.ca (Bruce Walzer) Date: Thu, 5 Dec 2024 16:59:00 -0600 Subject: phasing out SHA1 for digest creation In-Reply-To: References: Message-ID: On Thu, Dec 05, 2024 at 06:13:44PM +0100, Rainer Perske wrote: [...] > See https://shattered.io I was referring to something like Shattered in my previous comment. I thought Shattered was about signing keys not documents. > Attacker takes the good document and the bad document with the same hash. > Attacker asks victim to sign the good document. Then the victim signs the document with SHA-256. Why would the victim use SHA-1? It might be reasonable to prevent the use of SHA-1 for new signatures, but isn't that already the case in practice? Here is the preference list of digest hashes I got by default on a 4 year old key: Digest: SHA512, SHA384, SHA256, SHA224, SHA1 Does the problem somehow exist for very old keys? At any rate, if an attacker actually ever did something like this, presumably the victim would know they did not actually sign the document. If it turned out that SHA-1 was used then we could look at the document to see where the SHA-1 collision prefix was hidden. If there was a fraud then legal action could be initiated based on strong proof of a forgery. Appropriate countermeasures could be discussed to prevent the signing of new documents Using SHA-1. For now, this is a non-issue. Bruce From heiko.schaefer at posteo.de Fri Dec 6 01:34:10 2024 From: heiko.schaefer at posteo.de (=?UTF-8?Q?Heiko_Sch=C3=A4fer?=) Date: Fri, 6 Dec 2024 00:34:10 +0000 Subject: gpg --export produces invalid EdDSA output - regression In-Reply-To: References: Message-ID: <5a22dff9-6903-4241-99a8-8733bc47320e@posteo.de> Just to add a note to this thread: I believe the issue Marek described has been fixed in GnuPG 2.4.7 (via https://dev.gnupg.org/T7426) From jcb62281 at gmail.com Fri Dec 6 01:54:14 2024 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Thu, 5 Dec 2024 18:54:14 -0600 Subject: phasing out SHA1 for digest creation In-Reply-To: References: Message-ID: <45cd1c91-956e-4f04-9035-f2543d2ea4e5@gmail.com> On 12/5/24 11:13, Rainer Perske wrote: > Bruce Walzer schrieb am 2024-12-05: >> What is the actual issue here? > Extremely simplified: > > Attacker makes many good documents and many bad documents until he finds a collision. > Seehttps://shattered.io > Attacker takes the good document and the bad document with the same hash. > Attacker asks victim to sign the good document. > Victim does so. > Attacker combines the signature with the bad document. > So the attacker can "prove" that the victim has signed the bad document. Better solution:? never sign a document exactly as presented to you; always make a small change first.? This could be as simple as including a nonce in the signature.? This is from Schneier's /Applied Cryptography/ from many years ago:? this problem (and its solution) is old. -- Jacob -------------- next part -------------- An HTML attachment was scrubbed... URL: From wiktor at metacode.biz Fri Dec 6 09:11:48 2024 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Fri, 6 Dec 2024 09:11:48 +0100 Subject: phasing out SHA1 for digest creation In-Reply-To: <45cd1c91-956e-4f04-9035-f2543d2ea4e5@gmail.com> References: <45cd1c91-956e-4f04-9035-f2543d2ea4e5@gmail.com> Message-ID: <2904999a-34ed-4aa3-af9d-f2c9a1e5efa3@metacode.biz> On 6.12.2024 01:54, Jacob Bachmeyer via Gnupg-devel wrote: > This could be as simple as including a nonce in the signature. Just for the record, due to the way of how OpenPGP hashes files, there's plenty of other metadata influencing the final hash e.g. signature creation time (I guess it's rather improbable that the attacker would control that up to a second precision; it's not a high entropy data though; also: some implementations embed nonce data in notations). Kind regards, Wiktor From rainer.perske at uni-muenster.de Fri Dec 6 10:56:06 2024 From: rainer.perske at uni-muenster.de (Rainer Perske) Date: Fri, 06 Dec 2024 10:56:06 +0100 (CET) Subject: phasing out SHA1 for digest creation In-Reply-To: <45cd1c91-956e-4f04-9035-f2543d2ea4e5@gmail.com> Message-ID: Hello Jacob Bachmeyer schrieb am 2024-12-06: > Better solution:? never sign a document exactly as presented to you; always make a small change first. This could be as simple as including a nonce in the signature.? Correct ? if the change or nonce is big and random enough (at least about 80 bit of randomness to compensate for the lost 80 bits of security due to the birthday attack, even if that is not a real compensation for multiple reasons), i.e. make many small or few big changes to the content. But the normal user does not know. > This is from Schneier's /Applied Cryptography/ from many years ago:? this problem (and its solution) is old. Absolutely correct. It is a great book. But most people do not even see the problem. Best regards -- Rainer Perske Systemdienste + Leiter der Zertifizierungsstelle (UCAM) -- Universit?t M?nster CIT - Center for Information Technology Rainer Perske, Systemdienste R?ntgenstra?e 7-13, Raum 006 48149 M?nster Tel.: +49 251 83-31582 E-Mail: rainer.perske at uni-muenster.de Website: www.uni-muenster.de/IT Universit?tszertifizierungsstelle M?nster (UCAM): Tel.: +49 251 83-31590 E-Mail: ca at uni-muenster.de WWW: www.uni-muenster.de/CA YouTube: youtube.com/@uni_muenster Instagram: instagram.com/uni_muenster LinkedIn: linkedin.com/school/university-of-muenster Facebook: facebook.com/unimuenster -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6319 bytes Desc: S/MIME cryptographic signature URL: From wk at gnupg.org Fri Dec 6 11:02:08 2024 From: wk at gnupg.org (Werner Koch) Date: Fri, 06 Dec 2024 11:02:08 +0100 Subject: [Announce] GnuPG 2.5.2 released Message-ID: <87v7vxyvrz.fsf@jacob.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG release: version 2.5.2. This release is the third of a series of public testing releases eventually leading to a new stable version 2.6. We also release a first Beta version of the forthcoming Gpg4win 5.0. The main features in the 2.6 series are improvements for 64 bit Windows and the introduction of a PQC encryption algorithm. Other than PQC support the 2.6 series will not differ a lot from 2.4 because the majority of changes are internal to make use of newer features from the supporting libraries. What is GnuPG ============= The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation of the OpenPGP and S/MIME standards. GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. The separate library GPGME provides a uniform API to use the GnuPG engine by software written in common programming languages. A wealth of frontend applications and libraries making use of GnuPG are available. As an universal crypto engine GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Noteworthy changes in version 2.5.2 (2024-12-05) ================================================ [compared to version 2.5.1] * gpg: Add option 16 to --full-gen-key to create ECC+Kyber. [T6638] * gpg: For composite algos add the algo string to the colons listings. [T6638] * gpg: Validate the trustdb after the import of a trusted key. [T7200] * gpg: Exclude expired trusted keys from the key validation process. [T7200] * gpg: Fix a wrong decryption failed status for signed and OCB encrypted messages without a signature verification key. [T7042] * gpg: Retain binary representation for import->export with Ed25519 key signatures. [T7426] * gpg: Fix comparing ed448 to ed25519 with --assert-pubkey-algo. [T7425] * gpg: Avoid a failure exit code for expired ultimately trusted keys. [T7351] * gpg: Emit status error for an invalid ADSK. [T7322] * gpg: Allow the use of an ADSK subkey as ADSK subkey. [T6882] * gpg: Fix --quick-set-expire for V5 subkey fingerprints. [T7298] * gpg: Robust error handling for SCD READKEY. [T7309] * gpg: Fix cv25519 v5 export regression. [T7316] * gpgsm: Nearly fourfold speedup of validated certificate listings. [T7308] * gpgsm: Improvement for some rare P12 files. [rGf50dde6269] * gpgsm: Terminate key listing on output write error. [T6185] * agent: Add option --status to the LISTRUSTED command. [rG4275d5fa7a] * agent: Fix detection of the yet unused trustflag de-vs. [T5079] * agent: Allow ssh to sign data larger than the Assuan line length. [T7436] * keyboxd: Fix a race condition on the database handle. [T7294] * dirmngr: A list of used URLs for loaded CRLs is printed first in the output of the LISTCRL command. [T7337] * scd: More mitigations against lock ups with multiple cards or apps. [T7323, T7402] * gpgtar: Use log-file from common.conf only in --batch mode. [rGb389e04ef5] * gpgtar: Fix directory creation during extraction. [T7380] * gpg-mail-tube: Minor fixes. * gpgconf: Add list flag to trusted-key et al. [T7313] * Implement GNUPG_ASSUME_COMPLIANCE envvar and registry key for testing de-vs compliance mode. [rGb287fb5775,rG7b0be541a9] * Enable additional runtime protections in speedo builds for Windows. [rG39aa206dc5] * Fix a race condition in creating the socket directory. [T7332] * Fix a build problem on macOS (missing unistd.h). [T7193] Release-info: https://dev.gnupg.org/T7289 Getting the Software ==================== Please follow the instructions found at or read on: GnuPG may be downloaded from one of the GnuPG mirror sites or direct from its primary file server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. The GnuPG source code compressed using BZIP2 and its OpenPGP signature are available here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.2.tar.bz2 (7959k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.2.tar.bz2.sig An installer for Windows without any graphical frontend except for a very minimal Pinentry tool is available here: https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.2_20241205.exe (5497k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.2_20241205.exe.sig The source used to build this 32 bit Windows installer is available at https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.2_20241205.tar.xz (16M) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.2_20241205.tar.xz.sig This Windows source tarball may also be used to download all required libraries at once to build a Unix version on any modern system. See the included README but replace the make target "native" by "this-native". For Windows a *Beta* version of Gpg4win, our full featured Gpg4win installer including this version of GnuPG as well as Kleopatra GUI and a PDF editor can be retrieved from here: https://files.gpg4win.org/gpg4win-5.0.0-beta32.exe (43M) https://files.gpg4win.org/gpg4win-5.0.0-beta32.exe.sig with the source code at: https://files.gpg4win.org/gpg4win-5.0.0-beta32.tar.xz (260M) https://files.gpg4win.org/gpg4win-5.0.0-beta32.tar.xz.sig Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.5.2.tar.bz2 you would use this command: gpg --verify gnupg-2.5.2.tar.bz2.sig gnupg-2.5.2.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See the end of this mail for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.5.2.tar.bz2, you run the command like this: sha1sum gnupg-2.5.2.tar.bz2 and check that the output matches the next line: 25697dd115703c4ba7b9d6a1a00ede65a5cbc7cc gnupg-2.5.2.tar.bz2 f85f5ad0c6db370f3497fc2cc1e1da9207cfa21a gnupg-w32-2.5.2_20241205.tar.xz 324a2fa030f1cef1e49d12944b6c3cf34aeef0fd gnupg-w32-2.5.2_20241205.exe 18125b4e12356ba36a99a6c3656a3482fe4218bd gpg4win-5.0.0-beta32.tar.xz 6a62cec9deb77751fd8e0e040a87f35d81e813b6 gpg4win-5.0.0-beta32.exe Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese (traditional and simplified), Czech, French, German, Italian, Japanese, Norwegian, Polish, Portuguese, Russian, Turkish, and Ukrainian being almost completely translated. Documentation and Support ========================= The file gnupg.info has the complete reference manual of the system. Separate man pages are included as well but they miss some of the details available only in the manual. The manual is also available online at https://gnupg.org/documentation/manuals/gnupg/ or can be downloaded as PDF at https://gnupg.org/documentation/manuals/gnupg.pdf You may also want to search the GnuPG mailing list archives or ask on the gnupg-users mailing list for advise on how to solve problems. Most of the new features are around for several years and thus enough public experience is available. https://wiki.gnupg.org has user contributed information around GnuPG and relate software. In case of build problems specific to this release please first check https://dev.gnupg.org/T7289 for updated information. Please consult the archive of the gnupg-users mailing list before reporting a bug: https://gnupg.org/documentation/mailing-lists.html. We suggest to send bug reports for a new release to this list in favor of filing a bug at https://bugs.gnupg.org. If you need commercial support go to https://gnupg.com or https://gnupg.org/service.html. If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH and has mostly been financed by donations. Several full-time employed developers and contractors are working exclusively on GnuPG and closely related software like Libgcrypt, GPGME, Kleopatra and Gpg4win. Fortunately, and this is still not common with free software, we have established a way of financing the development while keeping all our software free and freely available for everyone. Our model is similar to the way RedHat manages RHEL and Fedora: Except for the actual binary of the MSI installer for Windows and client specific configuration files, all the software is available under the GNU GPL and other Open Source licenses. Thus customers may even build and distribute their own version of the software as long as they do not use our trademarks GnuPG Desktop? or GnuPG VS-Desktop?. We like to thank all the nice people who are helping the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, answering questions on the mailing lists, or helped with donations. *Thank you all* Your GnuPG hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users at gnupg.org mailing list. List of Release Signing Keys: To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: rsa3072 2017-03-17 [expires: 2027-03-15] 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) ed25519 2020-08-24 [expires: 2030-06-30] 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA Werner Koch (dist signing 2020) ed25519 2021-05-19 [expires: 2027-04-04] AC8E 115B F73E 2D8D 47FA 9908 E98E 9B2D 19C6 C8BD Niibe Yutaka (GnuPG Release Key) brainpoolP256r1 2021-10-15 [expires: 2029-12-31] 02F3 8DFF 731F F97C B039 A1DA 549E 695E 905B A208 GnuPG.com (Release Signing Key 2021) The keys are available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- Arguing that you don't care about the right to privacy because you have nothing to hide is no different from saying you don't care about free speech because you have nothing to say. - Edward Snowden -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From rainer.perske at uni-muenster.de Fri Dec 6 11:11:55 2024 From: rainer.perske at uni-muenster.de (Rainer Perske) Date: Fri, 06 Dec 2024 11:11:55 +0100 (CET) Subject: phasing out SHA1 for digest creation In-Reply-To: Message-ID: Hello > At any rate, if an attacker actually ever did something like this, > presumably the victim would know they did not actually sign the > document. No. Do not underestimate fraudsters, they can be very convincing. Kind regards -- Rainer Perske Systemdienste + Leiter der Zertifizierungsstelle (UCAM) -- Universit?t M?nster CIT - Center for Information Technology Rainer Perske, Systemdienste R?ntgenstra?e 7-13, Raum 006 48149 M?nster Tel.: +49 251 83-31582 E-Mail: rainer.perske at uni-muenster.de Website: www.uni-muenster.de/IT Universit?tszertifizierungsstelle M?nster (UCAM): Tel.: +49 251 83-31590 E-Mail: ca at uni-muenster.de WWW: www.uni-muenster.de/CA YouTube: youtube.com/@uni_muenster Instagram: instagram.com/uni_muenster LinkedIn: linkedin.com/school/university-of-muenster Facebook: facebook.com/unimuenster -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6319 bytes Desc: S/MIME cryptographic signature URL: From jcb62281 at gmail.com Sat Dec 7 02:40:48 2024 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Fri, 6 Dec 2024 19:40:48 -0600 Subject: phasing out SHA1 for digest creation In-Reply-To: References: Message-ID: On 12/6/24 03:56, Rainer Perske wrote: > Hello > > Jacob Bachmeyer schrieb am 2024-12-06: > >> Better solution:? never sign a document exactly as presented to you; always make a small change first. This could be as simple as including a nonce in the signature. > Correct ? if the change or nonce is big and random enough (at least about 80 bit of randomness to compensate for the lost 80 bits of security due to the birthday attack, even if that is not a real compensation for multiple reasons), i.e. make many small or few big changes to the content. But the normal user does not know. As I understand, one bit is enough to destroy a tediously prepared collision; and Wiktor noted that PGP includes a timestamp (to one second) in the signed data and the protocol allows implementations to add more data to the signature. -- Jacob From jcb62281 at gmail.com Sat Dec 7 02:42:08 2024 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Fri, 6 Dec 2024 19:42:08 -0600 Subject: phasing out SHA1 for digest creation In-Reply-To: <2904999a-34ed-4aa3-af9d-f2c9a1e5efa3@metacode.biz> References: <45cd1c91-956e-4f04-9035-f2543d2ea4e5@gmail.com> <2904999a-34ed-4aa3-af9d-f2c9a1e5efa3@metacode.biz> Message-ID: On 12/6/24 02:11, Wiktor Kwapisiewicz via Gnupg-devel wrote: > On 6.12.2024 01:54, Jacob Bachmeyer via Gnupg-devel wrote: >> This could be as simple as including a nonce in the signature. > > Just for the record, due to the way of how OpenPGP hashes files, > there's plenty of other metadata influencing the final hash e.g. > signature creation time (I guess it's rather improbable that the > attacker would control that up to a second precision; it's not a high > entropy data though; also: some implementations embed nonce data in > notations). So PGP is already resistant to such attacks and can be made entirely immune by simply adding a nonce to the signature, which the protocol already allows? Does GPG already do this?? If not, can this message count as a feature request for secure nonces in signatures?? Even 64 bits should be enough to guard against collision-based forgeries, but I would suggest a nonce length equal to one half of the digest length. (I initially wanted to propose making the nonce length equal to the digest length, but the pigeonhole principle suggests that a nonce that long *might* make signatures malleable with enough computation---an attacker *might* be able to use the nonce field to make a signature "fit" a different document hash.? I do not know if factoring a 4096-bit RSA key would be easier---I would expect such an attack to be computationally infeasible.) Alternately, for the next PGP protocol version, including a nonce N in the calculation of the digest H and also signing {N,H} instead of just H should allow longer nonces without risking the signature integrity.? (I wonder if the SSH developers were thinking along those lines...) -- Jacob From heiko.schaefer at posteo.de Sat Dec 7 10:50:43 2024 From: heiko.schaefer at posteo.de (=?UTF-8?Q?Heiko_Sch=C3=A4fer?=) Date: Sat, 7 Dec 2024 09:50:43 +0000 Subject: phasing out SHA1 for digest creation In-Reply-To: References: <45cd1c91-956e-4f04-9035-f2543d2ea4e5@gmail.com> <2904999a-34ed-4aa3-af9d-f2c9a1e5efa3@metacode.biz> Message-ID: On 12/7/24 2:42 AM, Jacob Bachmeyer via Gnupg-devel wrote: > Alternately, for the next PGP protocol version, including a nonce N in > the calculation of the digest H and also signing {N,H} instead of just > H should allow longer nonces without risking the signature integrity.? > (I wonder if the SSH developers were thinking along those lines...) FWIW, OpenPGP version 6 signatures, specified in RFC 9580, do contain a salt (https://www.rfc-editor.org/rfc/rfc9580.html#section-5.2.3-2.10.1). The signature hashing process starts with that salt (https://www.rfc-editor.org/rfc/rfc9580.html#section-5.2.4-2). From ametzler at bebt.de Sat Dec 7 11:56:48 2024 From: ametzler at bebt.de (Andreas Metzler) Date: Sat, 7 Dec 2024 11:56:48 +0100 Subject: gpa status Message-ID: Hello, gpa is due to be removed from Debian/testing since it uses gtk2. gpa git has gtk3 conversion, so we could switch to GIT head. However I am not happy with shipping unreleased code in a Debian stable release. My impression from browsing dev.gnupg.org [1] [2] is that gpa is currently not alive and should not be used. I would therefore block gpa from being released with Debian trixie and in the longer term would drop the package from Debian/unstable too. Any comments on that? TIA, cu Andreas [1] https://dev.gnupg.org/T4642 [2] https://dev.gnupg.org/T5432 "GPA development has been stopped ... switch to Kleopatra" -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From rainer.perske at uni-muenster.de Sat Dec 7 13:20:31 2024 From: rainer.perske at uni-muenster.de (Rainer Perske) Date: Sat, 07 Dec 2024 13:20:31 +0100 (CET) Subject: phasing out SHA1 for digest creation In-Reply-To: Message-ID: Hello. > As I understand, one bit is enough to destroy a tediously prepared collision If the attacker can prepare one collision, he can also prepare multiple sets collisions. It only adds some amount of complexity to the attack. > and Wiktor noted that PGP includes a timestamp (to one second) in the signed data Timestamps are not random bits. An attacker can set up a situation where the victim will create the signature in a very short time window, and prepare accordingly. If you need randomness, use real randomness. > and the protocol allows implementations to add more data to the signature. Of course there are countermeasures. But they cannot fully compensate weaknesses of the hash algorithm. (If they were, no cryptographic hash algorithm would be needed at all.) To guide this discussion back to the origin: B. W. thought that there is no way to launch a collision attack against signatures. J. B. thought that modifying one bit would be enough protection. J. B. also thought that including a timestamp would add to security in this situation. I only want to illustrate kindly with examples why these thoughts are wrong, so that you do not make unsafe decisions based on these ? very human ? mistakes. (Absolutely no offense intended: I myself make similar mistakes far too often ... :-) ) Kind regards -- Rainer Perske Systemdienste + Leiter der Zertifizierungsstelle (UCAM) -- Universit?t M?nster CIT - Center for Information Technology Rainer Perske, Systemdienste R?ntgenstra?e 7-13, Raum 006 48149 M?nster Tel.: +49 251 83-31582 E-Mail: rainer.perske at uni-muenster.de Website: www.uni-muenster.de/IT Universit?tszertifizierungsstelle M?nster (UCAM): Tel.: +49 251 83-31590 E-Mail: ca at uni-muenster.de WWW: www.uni-muenster.de/CA YouTube: youtube.com/@uni_muenster Instagram: instagram.com/uni_muenster LinkedIn: linkedin.com/school/university-of-muenster Facebook: facebook.com/unimuenster -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6319 bytes Desc: S/MIME cryptographic signature URL: From wk at gnupg.org Sat Dec 7 14:50:57 2024 From: wk at gnupg.org (Werner Koch) Date: Sat, 07 Dec 2024 14:50:57 +0100 Subject: phasing out SHA1 for digest creation In-Reply-To: (Jacob Bachmeyer via Gnupg-devel's message of "Fri, 6 Dec 2024 19:42:08 -0600") References: <45cd1c91-956e-4f04-9035-f2543d2ea4e5@gmail.com> <2904999a-34ed-4aa3-af9d-f2c9a1e5efa3@metacode.biz> Message-ID: <87msh7zjni.fsf@jacob.g10code.de> Hi! On Fri, 6 Dec 2024 19:42, Jacob Bachmeyer said: > Does GPG already do this?? If not, can this message count as a feature > request for secure nonces in signatures?? Even 64 bits should be The suggestion with hashing a nonce is to mitigate a specific way to create collisions. OTOH, an arbitrary random nonce allows to change the data in an undetectable way - maybe even to create such a collision. Even worse, a random nonce adds a covert channel to a signed message. This needs to be avoided in sensitive areas where encryption is not allowed for exactly that reason. In particular that new IETF OpenPGP specification introduced a mandatory random salt, despite the counter arguments that if this will be added the salt must not be random but be derive from other information. Some people obviously want to have this covert channel in signatures. A nonce, actually salt, can be introduced in a compatible way with signature subpackets and maybe extra rules to place that salt as the first subpacket. Of course the salt needs to be computed from other info. Anyway, there are no signs that SHA-256 can be attacked in a similar way as SHA-1. The SHA3 development process clearly showed that SHA256, SHA384, SHA512 are safe choices. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From wk at gnupg.org Sat Dec 7 15:02:24 2024 From: wk at gnupg.org (Werner Koch) Date: Sat, 07 Dec 2024 15:02:24 +0100 Subject: gpa status In-Reply-To: (Andreas Metzler's message of "Sat, 7 Dec 2024 11:56:48 +0100") References: Message-ID: <87ikrvzj4f.fsf@jacob.g10code.de> Hi! On Sat, 7 Dec 2024 11:56, Andreas Metzler said: > gpa is due to be removed from Debian/testing since it uses gtk2. gpa git > has gtk3 conversion, so we could switch to GIT head. However I am not Actually I still use GPA for testing things, in particular new GPGME features. That is because I find it much easier to hack on GPA than on Kleopatra/Libkleo. Compiles faster and the code is easier to understand. I have not done releases because my co-developers convinced me that it is better to concentrate on one GUI frontend and they want Kleopatra. Frankly we are putting a huge amount of work and money into Kleopatra and it won't be easily to get GPA to the same level of UX. That said, I don't known whether it makes sense to keep GPA in Debian. Building from source is easy enough and that is sufficient for having GPA as a testbench. If there are enough voices to keep GPA as binary package, I would spend some time on making a new release. But in the long run we need an upstream maintainer for GPA. I can't promise to do that; there are anyway too many things I have to care about. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From ametzler at bebt.de Sat Dec 7 16:14:13 2024 From: ametzler at bebt.de (Andreas Metzler) Date: Sat, 7 Dec 2024 16:14:13 +0100 Subject: gpa status In-Reply-To: <87ikrvzj4f.fsf@jacob.g10code.de> References: <87ikrvzj4f.fsf@jacob.g10code.de> Message-ID: On 2024-12-07 Werner Koch wrote: > On Sat, 7 Dec 2024 11:56, Andreas Metzler said: > > gpa is due to be removed from Debian/testing since it uses gtk2. gpa git > > has gtk3 conversion, so we could switch to GIT head. However I am not > Actually I still use GPA for testing things, in particular new GPGME > features. That is because I find it much easier to hack on GPA than on > Kleopatra/Libkleo. Compiles faster and the code is easier to > understand. > I have not done releases because my co-developers convinced me that it > is better to concentrate on one GUI frontend and they want Kleopatra. > Frankly we are putting a huge amount of work and money into Kleopatra > and it won't be easily to get GPA to the same level of UX. > That said, I don't known whether it makes sense to keep GPA in Debian. > Building from source is easy enough and that is sufficient for having > GPA as a testbench. > If there are enough voices to keep GPA as binary package, I would spend > some time on making a new release. But in the long run we need an > upstream maintainer for GPA. I can't promise to do that; there are > anyway too many things I have to care about. Hello Werner, thank you for your speedy reply. That is quite helpful. For the time being I going to vote for keeping gpa in Debian, using GIT head. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From andrewg at andrewg.com Sat Dec 7 15:35:09 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sat, 7 Dec 2024 14:35:09 +0000 Subject: phasing out SHA1 for digest creation In-Reply-To: <87msh7zjni.fsf@jacob.g10code.de> References: <87msh7zjni.fsf@jacob.g10code.de> Message-ID: <4C112657-2995-4CAD-B8E0-C96486FB132C@andrewg.com> On 7 Dec 2024, at 13:58, Werner Koch via Gnupg-devel wrote: > > Some people obviously want to have this > covert channel in signatures. Which people? Werner, this is a very serious allegation. If you?re not willing to name names and provide receipts, I would strongly advise you to withdraw it. As discussed previously on the openpgp mailing list, there are already countless places in the wire format that an adversary could use for a covert channel, and I?m not aware of any implementation (including gnupg) that attempts to close these channels, perhaps because doing so would be a rich source of interop failures. It would be counterproductive for an adversary to introduce salted signatures for this purpose, as doing so would only draw attention for little further benefit. Please let this be the end of it. Thanks, A From gusnan at librem.one Sat Dec 7 15:59:20 2024 From: gusnan at librem.one (Andreas Ronnquist) Date: Sat, 7 Dec 2024 15:59:20 +0100 Subject: gpa status In-Reply-To: <87ikrvzj4f.fsf@jacob.g10code.de> References: <87ikrvzj4f.fsf@jacob.g10code.de> Message-ID: <20241207155852.2be15a10@debian-i7> On Sat, 07 Dec 2024 15:02:24 +0100 Werner Koch via Gnupg-devel wrote: >Hi! > >On Sat, 7 Dec 2024 11:56, Andreas Metzler said: > >> gpa is due to be removed from Debian/testing since it uses gtk2. gpa git >> has gtk3 conversion, so we could switch to GIT head. However I am not > >Actually I still use GPA for testing things, in particular new GPGME >features. That is because I find it much easier to hack on GPA than on >Kleopatra/Libkleo. Compiles faster and the code is easier to >understand. > >I have not done releases because my co-developers convinced me that it >is better to concentrate on one GUI frontend and they want Kleopatra. >Frankly we are putting a huge amount of work and money into Kleopatra >and it won't be easily to get GPA to the same level of UX. > >That said, I don't known whether it makes sense to keep GPA in Debian. >Building from source is easy enough and that is sufficient for having >GPA as a testbench. > >If there are enough voices to keep GPA as binary package, I would spend >some time on making a new release. But in the long run we need an >upstream maintainer for GPA. I can't promise to do that; there are >anyway too many things I have to care about. > I have helped with gpa previously, and done the GTK3 conversion, but after this message I definitely feel that it's time to abandon it. (And my contributions going to waste, a shame, but not much one can do about that). If Kleopatra is where the resources (and money) go, then what's the point in wasting (unpaid) time on GPA? This message makes it very clear where the focus is. /Andreas R?nnquist gusnan at librem.one andreas at ronnquist.net From jcb62281 at gmail.com Sun Dec 8 05:48:14 2024 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Sat, 7 Dec 2024 22:48:14 -0600 Subject: phasing out SHA1 for digest creation In-Reply-To: <87msh7zjni.fsf@jacob.g10code.de> References: <45cd1c91-956e-4f04-9035-f2543d2ea4e5@gmail.com> <2904999a-34ed-4aa3-af9d-f2c9a1e5efa3@metacode.biz> <87msh7zjni.fsf@jacob.g10code.de> Message-ID: On 12/7/24 07:50, Werner Koch wrote: > Hi! > > On Fri, 6 Dec 2024 19:42, Jacob Bachmeyer said: > >> Does GPG already do this?? If not, can this message count as a feature >> request for secure nonces in signatures?? Even 64 bits should be > The suggestion with hashing a nonce is to mitigate a specific way to > create collisions. OTOH, an arbitrary random nonce allows to change the > data in an undetectable way - maybe even to create such a collision. Which I thought I was mentioning in the parenthetical about nonces as long as the digest used.? The first counterargument is motive:? why would a signer want to create a collision? Presumably, signing {nonce, hash(document, nonce, etc)} instead of only {hash(document, nonce, etc)} would prevent a third party from altering the nonce in order to create a collision.? Of course, changing the actual signed blob cannot be done compatibly. > Even worse, a random nonce adds a covert channel to a signed message. Oh bother... solving one problem creates *another* problem.? I guess I was not considering /that/ risk, on the reasoning that your cipher software should be trusted.(I consider nonfree cipher software categorically insecure.) > This needs to be avoided in sensitive areas where encryption is not > allowed for exactly that reason. In particular that new IETF OpenPGP > specification introduced a mandatory random salt, despite the counter > arguments that if this will be added the salt must not be random but be > derive from other information. Some people obviously want to have this > covert channel in signatures. Is it plausible that they had the same line of reasoning that I did, and simply did not consider covert channel risks? > A nonce, actually salt, can be introduced in a compatible way with > signature subpackets and maybe extra rules to place that salt as the > first subpacket. Of course the salt needs to be computed from other > info. > > Anyway, there are no signs that SHA-256 can be attacked in a similar > way as SHA-1. The SHA3 development process clearly showed that > SHA256, SHA384, SHA512 are safe choices. Nor were there signs that SHA-1 could be attacked until it was. (Although the attacks on SHA-1 are still very limited.) -- Jacob -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Sun Dec 8 20:34:40 2024 From: wk at gnupg.org (Werner Koch) Date: Sun, 08 Dec 2024 20:34:40 +0100 Subject: gpa status In-Reply-To: <20241207155852.2be15a10@debian-i7> (Andreas Ronnquist's message of "Sat, 7 Dec 2024 15:59:20 +0100") References: <87ikrvzj4f.fsf@jacob.g10code.de> <20241207155852.2be15a10@debian-i7> Message-ID: <87bjxmynn3.fsf@jacob.g10code.de> Hi Andreas, I just noticed all the work you did. It took me only a few minutes to also make make distcheck work again and thus I think we can do a realese with a short note in the NEWS that all changes can be found in the git commit log. After all building the whole stuff is far less troublesome than building Kleopatra. > after this message I definitely feel that it's time to abandon it. (And > my contributions going to waste, a shame, but not much one can do about That would be not fair. Given that I will keep on using GPA as a test bench anyway, I should also be abale to spend time doing a release form time to time. > If Kleopatra is where the resources (and money) go, then what's the > point in wasting (unpaid) time on GPA? This message makes it very clear > where the focus is. Yes, from a business point of view. But there is also the hacker's pleasure to keep software alive. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From bernhard at intevation.de Tue Dec 10 09:48:19 2024 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 10 Dec 2024 09:48:19 +0100 Subject: Adding a nounce before hashing as covert channel (Re: phasing out SHA1 for digest creation) In-Reply-To: <4C112657-2995-4CAD-B8E0-C96486FB132C@andrewg.com> References: <87msh7zjni.fsf@jacob.g10code.de> <4C112657-2995-4CAD-B8E0-C96486FB132C@andrewg.com> Message-ID: <202412100948.32538.bernhard@intevation.de> Am Samstag 07 Dezember 2024 15:35:09 schrieb Andrew Gallagher via Gnupg-devel: > there are already countless places in the wire format that an adversary > could use for a covert channel, It still may not be wise to add another place. There can be unwanted side effects of adding a nonce (is what I understand from the example). > and I?m not aware of any implementation > (including gnupg) that attempts to close these channels, perhaps because > doing so would be a rich source of interop failures. It would be > counterproductive for an adversary to introduce salted signatures for this > purpose, as doing so would only draw attention for little further benefit. Which we only know if we fully understand all side effects. Not saying that this is done deliberately. Regards, Bernhard -- https://intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Tue Dec 10 09:58:36 2024 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 10 Dec 2024 09:58:36 +0100 Subject: phasing out SHA1 for digest creation In-Reply-To: References: <202412051137.51831.bernhard@intevation.de> Message-ID: <202412100958.50450.bernhard@intevation.de> Am Donnerstag 05 Dezember 2024 13:36:20 schrieb Bruce Walzer: > On Thu, Dec 05, 2024 at 11:37:44AM +0100, Bernhard Reiter via Gnupg-devel wrote: > > last year in March 2023 you wrote in > > ? ?https://dev.gnupg.org/T6433 > > There was no discussion of the potential vulnerabilities in T6433 that > might be caused by leaving things as they are. When discussing long > used methods we really need to concentrate on the actual potential > harm to users. What are those potential harms here? Not being an expert here, that is why I am asking. It seems that with MD5 a bunch of attacks and clever ways to exploit the weakness came after first collisions where found. Now chosen-prefix attacks are feasable and a number of crypto researchers and standard bodies suggest to not create SHA1 based signatures anymore. > My understanding is that since SHA-1 is secure for everything but > collisions that the user is quite safe even in the face of easy to > create collisions. What am I missing? That has been discussed and it has been interesting. It seems some people believe that there is a possibility to present others with a document they sign, but you have many others prepared to somehow create a different one with the same SHA1 hash and thus signatures. (This may include many documents as with OpenPGP there is at least a timestamp that varies.) Other believe this is to hard. But to get more practical: Does gpg still create SHA1 based signatures over documents, when being presented with some pubkeys? Or by default? If it does not, since when? Would a warning help users understand better that a SHA1 based signature maybe created by an attacker in order to exploit weaknesses in the future. And then users could wonder in high security contexts? How many signatures would be affected by such a warning? Is something I'd guess we would need to estimate. Regards, Bernhard -- https://intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From andrewg at andrewg.com Tue Dec 10 17:06:41 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 10 Dec 2024 16:06:41 +0000 Subject: Adding a nounce before hashing as covert channel (Re: phasing out SHA1 for digest creation) In-Reply-To: <202412100948.32538.bernhard@intevation.de> References: <87msh7zjni.fsf@jacob.g10code.de> <4C112657-2995-4CAD-B8E0-C96486FB132C@andrewg.com> <202412100948.32538.bernhard@intevation.de> Message-ID: On 10 Dec 2024, at 08:48, Bernhard Reiter via Gnupg-devel wrote: > > Am Samstag 07 Dezember 2024 15:35:09 schrieb Andrew Gallagher via Gnupg-devel: >> there are already countless places in the wire format that an adversary >> could use for a covert channel, > > It still may not be wise to add another place. > There can be unwanted side effects of adding a nonce > (is what I understand from the example). There might be, however since the nonce is signed over as if it were the first N bits of the document, manipulating the nonce of a salted signature would be equivalent to manipulating the first N bits of a document signed by an unsalted signature. Collision attacks generally require manipulation of many more bits than is provided by a V6 signature salt, which is half the bit length of the digest algorithm. And remember that the nonce is not attacker-controlled, unlike the document. Even if there were an additional vulnerability introduced, the attacker would have a 1 in O(2^N) chance of successfully exploiting it. > Not saying that this is done deliberately. Of course you aren't. I do wish we could have a reasonable discussion without other people resorting to veiled allegations and FUD. A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From wk at gnupg.org Wed Dec 11 09:50:07 2024 From: wk at gnupg.org (Werner Koch) Date: Wed, 11 Dec 2024 09:50:07 +0100 Subject: gpa status In-Reply-To: (Andreas Metzler's message of "Sat, 7 Dec 2024 16:14:13 +0100") References: <87ikrvzj4f.fsf@jacob.g10code.de> Message-ID: <875xnqy56o.fsf@jacob.g10code.de> On Sat, 7 Dec 2024 16:14, Andreas Metzler said: > thank you for your speedy reply. That is quite helpful. For the time > being I going to vote for keeping gpa in Debian, using GIT head. You can now use 0.11.0. Take it from the usual place. BTW, this is the first release which allows to do bzcat tarball | git get-tar-commit-id to get the commit id of the released version in a pretty efficient way. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From fg.gnupg at shimps.de Wed Dec 11 11:39:19 2024 From: fg.gnupg at shimps.de (Frank Guthausen) Date: Wed, 11 Dec 2024 11:39:19 +0100 Subject: Adding a nounce before hashing as covert channel In-Reply-To: <202412100948.32538.bernhard@intevation.de> References: <87msh7zjni.fsf@jacob.g10code.de> <4C112657-2995-4CAD-B8E0-C96486FB132C@andrewg.com> <202412100948.32538.bernhard@intevation.de> Message-ID: <20241211113919.43cdce90@incubator.example.net> Some thoughts about signing a document, e.g. a contract: 1. Someone, either Alice or Bob, will make a last change to the document proposal. WLOG Alice. 2. This might offer an attack vector regarding two versions of the document with the same hash value. 3. Alice sends the final draft to Bob for signing. Bob wants mitigation of this attack vector. Can Bob modify the document in a defined way (i.e. a nonce inside the document rather an external salt while hashing and signing) which will solve the problem? Let's have Bob adding a line to the document: nonce1: f1d2d2f924e986ac86fdf7b36c94bcdf32beec15 This example is obtained from ``echo foo | sha1sum'', but might be completely random. 4. Bob sends the document back to Alice for purpose of signing. Since Alice does not want Bob to prepare an evil document with different nonce, she adds a line to the document: nonce2: e242ed3bffccdf271b7fbaf34ed72d089537b42f obtained by ``echo bar | sha1sum'' for this example. If she sends it back to Bob, the problems starts all over again (infinite regress). On Tue, 10 Dec 2024 09:48:19 +0100 Bernhard Reiter via Gnupg-devel wrote: > > There can be unwanted side effects of adding a nonce > (is what I understand from the example). As shown above, a trivial "solution" with a nonce does not really work. There are some implicit or explicit expectations which interfere here: - both sides sign the same document (symmetric) - nonces are inside the signed document - the time and place of signing are different (asymmetric), and - the time interval between signatures is big enough to create a good/evil hash collision - no third trust party involved The attack vector discussed refers to the asymmetric part which allows to modify both versions of the document (good and evil) to create a hash collision. A nonce inside the document mirrors the problem back. Are there any good solutions to the problem (workflow, best practice) besides hoping the hash algorithm will prevent such an attack in reasonable time? - external nonce/salt - signing two different documents The more I consider the problem, the more difficult it appears. kind regards Frank -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Wed Dec 11 15:26:54 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 11 Dec 2024 14:26:54 +0000 Subject: Adding a nounce before hashing as covert channel In-Reply-To: <20241211113919.43cdce90@incubator.example.net> References: <20241211113919.43cdce90@incubator.example.net> Message-ID: On 11 Dec 2024, at 11:33, Frank Guthausen wrote: > > Are there any good solutions to the problem (workflow, best practice) > besides hoping the hash algorithm will prevent such an attack in > reasonable time? Avoiding hash collisions is the entire point of a hash algorithm. An external salt doesn?t make it more difficult for an attacker to find a hash collision, but it prevents an attacker from finding a *useful* collision in advance. A From fg.gnupg at shimps.de Wed Dec 11 16:19:49 2024 From: fg.gnupg at shimps.de (Frank Guthausen) Date: Wed, 11 Dec 2024 16:19:49 +0100 Subject: Adding a nounce before hashing as covert channel In-Reply-To: References: <20241211113919.43cdce90@incubator.example.net> Message-ID: <20241211161949.7ab0eb37@incubator.example.net> On Wed, 11 Dec 2024 14:26:54 +0000 Andrew Gallagher via Gnupg-devel wrote: > On 11 Dec 2024, at 11:33, Frank Guthausen wrote: > > > > Are there any good solutions to the problem (workflow, best > > practice) besides hoping the hash algorithm will prevent such an > > attack in reasonable time? > > Avoiding hash collisions is the entire point of a hash algorithm. An > external salt doesn?t make it more difficult for an attacker to find > a hash collision, but it prevents an attacker from finding a *useful* > collision in advance. I understand this aspect of the problem. But assuming the document is a contract signed by Alice and Bob, how is the problem solved in a bidirectional manner? This extended problem remains open, because adding a nonce leads to an infinite regress. The problem is the double control of good and evil document, which makes it easier to generate hash collisions. This advantage for Alice moves to Bob when using a nonce from Bob. Usage of external salts would increase difficulty since the free choice is restricted to evil document. My understanding is that external salt is a better choice than nonce inside of the document. But I am not sure whether I am missing something in the chain of arguments. -- kind regards Frank -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From rainer.perske at uni-muenster.de Wed Dec 11 17:59:55 2024 From: rainer.perske at uni-muenster.de (Rainer Perske) Date: Wed, 11 Dec 2024 17:59:55 +0100 (CET) Subject: Adding a nounce before hashing as covert channel In-Reply-To: <20241211161949.7ab0eb37@incubator.example.net> Message-ID: Hey, you are discussing ways to circumvent the security risks of a weak hash algorithm. That is the wrong way and only wastes time and energy. Do NOT use a weak hash algorithm like SHA-1 at all any more. Simply choose a strong one like SHA-2 or SHA-3. This solution is so easy and helps much, much more than any use of salts or nonces. Because then the problem that you are trying to fix simply does not exist at all! Best regards -- Rainer Perske Systemdienste + Leiter der Zertifizierungsstelle (UCAM) -- Universit?t M?nster CIT - Center for Information Technology Rainer Perske, Systemdienste R?ntgenstra?e 7-13, Raum 006 48149 M?nster Tel.: +49 251 83-31582 E-Mail: rainer.perske at uni-muenster.de Website: www.uni-muenster.de/IT Universit?tszertifizierungsstelle M?nster (UCAM): Tel.: +49 251 83-31590 E-Mail: ca at uni-muenster.de WWW: www.uni-muenster.de/CA YouTube: youtube.com/@uni_muenster Instagram: instagram.com/uni_muenster LinkedIn: linkedin.com/school/university-of-muenster Facebook: facebook.com/unimuenster -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6319 bytes Desc: S/MIME cryptographic signature URL: From dirkx at webweaving.org Wed Dec 11 19:58:54 2024 From: dirkx at webweaving.org (Dirk-Willem van Gulik) Date: Wed, 11 Dec 2024 19:58:54 +0100 Subject: STDIN behaviour change ( 2.2.44/2.4.5) Message-ID: L.S. After an update to 2.4.5 - we?re seeing an odd behaviour change (not sure it is regression) - where GPG seems to wait for an EOF as opposed to the end of message. E.g. in 2.2.4 (libgcrypt 1.11.0) the following works # Setup test echo foo | gpg -a -e -r dirkx > test.asc # cmd 1 cat test.asc | gpg -d # cmd 2 (cat test.asc; sleep 100) | gpg -d With the latter command ?2? returning the decrypted value (foo) right away - not waiting for the ?sleep 100?. With version 2.45 (libgcrypt 1.8.) this does -not- happen; ?1? outputs it right away; but in ?2? ? gpg waits for sleep to time out; and the EOF to trigger decryption. Is this a known/intentional change ? Any flags to get the old behaviour ? Any suggestions for a worn around (short of processing the message). Dw Background: The use case for this is our use in pipelines ? for example for an ZFS encrypted remove volume we; have an .ssh/authorized_key file with command="cat /.key; /sbin/zfs load-key -L prompt XXXXX c && zfs mount XXXXX && echo OK? ssh-XXXX And from the remote end ; we then do mkfifo $FIFO cat $FIFO |\ ssh -F $PINPAD_CONFIG_SSH -i $SSHKEY -T $host |\ $GPG --quiet --default-key $PINPAD_KEYID >> $FIFO So we rely on GPG acting on end of message, not EOF. And we have a few more complex cases - were multiple GPG blocks are handled this way with a single GPG (which we like - as there is some hardware/physical pin-pad/chipcard magic in the loop). From jcb62281 at gmail.com Thu Dec 12 05:39:12 2024 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Wed, 11 Dec 2024 22:39:12 -0600 Subject: Adding a nounce before hashing as covert channel In-Reply-To: <20241211161949.7ab0eb37@incubator.example.net> References: <20241211113919.43cdce90@incubator.example.net> <20241211161949.7ab0eb37@incubator.example.net> Message-ID: <913f4364-a0d7-4855-b8cf-adcecfa48095@gmail.com> On 12/11/24 09:19, Frank Guthausen wrote: > On Wed, 11 Dec 2024 14:26:54 +0000 > Andrew Gallagher via Gnupg-devel wrote: > >> On 11 Dec 2024, at 11:33, Frank Guthausen wrote: >>> Are there any good solutions to the problem (workflow, best >>> practice) besides hoping the hash algorithm will prevent such an >>> attack in reasonable time? >> Avoiding hash collisions is the entire point of a hash algorithm. An >> external salt doesn?t make it more difficult for an attacker to find >> a hash collision, but it prevents an attacker from finding a *useful* >> collision in advance. > I understand this aspect of the problem. But assuming the document > is a contract signed by Alice and Bob, how is the problem solved in > a bidirectional manner? This extended problem remains open, because > adding a nonce leads to an infinite regress. > > The problem is the double control of good and evil document, which > makes it easier to generate hash collisions. This advantage for Alice > moves to Bob when using a nonce from Bob. > > Usage of external salts would increase difficulty since the free choice > is restricted to evil document. My understanding is that external salt > is a better choice than nonce inside of the document. But I am not sure > whether I am missing something in the chain of arguments. You note a good, simple, technical solution:? a salt associated with each signature, such that Alice and Bob each sign their own nonce and the shared document. For contracts, there are legal solutions.? I believe the term is "executed in parts" for one such arrangement, in which Alice signs her copy (with her nonce added) and Bob signs his copy (with his nonce added). An extended form of that process continues with each then sending their signed copy to the other, counter-signing the signed copy received, and returning it as well.? This produces four slightly different versions of the same contract, due to the various nonces, but the substantive text should be identical. If either party attempts to cheat by producing colliding contracts, it will be possible to determine which version the parties actually agreed on because that will be only version with all of the signatures and countersignatures. Alice and Bob wish to agree on contract C: 1. ? Alice chooses N_A_1, signs {N_A_1,C} producing S_A_1, and sends {S_A_1,N_A_1,C} to Bob, while Bob chooses N_B_1, signs {N_B_1,C} producing S_B_1, and sends {S_B_1,N_B_1,C} to Alice. 2. ? Alice verifies S_B_1, chooses N_A_2, signs {N_A_2,S_B_1,N_B_1,C} producing S_A_2, and sends {S_A_2,N_A_2} to Bob, while Bob verifies S_A_1, chooses N_B_2, signs {N_B_2,S_A_1,N_A_1,C} producing S_B_2, and sends {S_B_2,N_B_2} to Alice. 3. ? Alice verifies S_B_2 while Bob verifies S_A_2. 4. The pair of tuples {S_A_2,N_A_2,S_B_1,N_B_1,C} and {S_B_2,N_B_2,S_A_1,N_A_1,C} are the signed contract.? Both of the signatures in each tuple must validate. This is a bit more complex than standard PGP signatures because of the need to include both the other party's signature and the contract in the signed data in step 2. On a first analysis, I believe this Byzantine process works even if *both* parties try to cheat and can use their nonce fields to produce collisions on demand. -- Jacob -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcb62281 at gmail.com Thu Dec 12 05:39:28 2024 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Wed, 11 Dec 2024 22:39:28 -0600 Subject: Adding a nounce before hashing as covert channel In-Reply-To: References: Message-ID: <582422b1-91ad-4a1b-baba-b3b5c53da63d@gmail.com> On 12/11/24 10:59, Rainer Perske wrote: > Hey, you are discussing ways to circumvent the security risks of a weak hash algorithm. > > That is the wrong way and only wastes time and energy. > > Do NOT use a weak hash algorithm like SHA-1 at all any more. > > Simply choose a strong one like SHA-2 or SHA-3. > > This solution is so easy and helps much, much more than any use of salts or nonces. > > Because then the problem that you are trying to fix simply does not exist at all! Some years ago, you could have given almost exactly the above advice, except with MD5 in place of SHA-1 and SHA-1 (!) in place of SHA-2 or SHA-3. The problem is that strong algorithms *become* weak without advance warning.? Therefore, it is necessary to take measures to reduce the fragility of the overall system. -- Jacob From rainer.perske at uni-muenster.de Thu Dec 12 10:39:35 2024 From: rainer.perske at uni-muenster.de (Rainer Perske) Date: Thu, 12 Dec 2024 10:39:35 +0100 (CET) Subject: Adding a nounce before hashing as covert channel In-Reply-To: <582422b1-91ad-4a1b-baba-b3b5c53da63d@gmail.com> Message-ID: Hello > The problem is that strong algorithms *become* weak without advance warning.? Therefore, it is necessary to take measures to reduce the fragility of the overall system. Due to the thermodynamic barrier, minor weaknesses in SHA-2 and SHA-3 do not matter due to the sheer length of the hash. And you are not protecting at all against major weaknesses in the hash algorithm and you are not even considering possible weaknesses in other protocol elements. The solution to protect against any weakness in one hash algorithm is much simpler and much less susceptible to undetected security problems than your proposal: In place of using one hash algorithm, simply use the concatenation of different hash algorithms based on different mathematical problems. Use as many as you like: The result is proven to be at least as strong as the strongest of the algorithms involved. Kind regards -- Rainer Perske Systemdienste + Leiter der Zertifizierungsstelle (UCAM) -- Universit?t M?nster CIT - Center for Information Technology Rainer Perske, Systemdienste R?ntgenstra?e 7-13, Raum 006 48149 M?nster Tel.: +49 251 83-31582 E-Mail: rainer.perske at uni-muenster.de Website: www.uni-muenster.de/IT Universit?tszertifizierungsstelle M?nster (UCAM): Tel.: +49 251 83-31590 E-Mail: ca at uni-muenster.de WWW: www.uni-muenster.de/CA YouTube: youtube.com/@uni_muenster Instagram: instagram.com/uni_muenster LinkedIn: linkedin.com/school/university-of-muenster Facebook: facebook.com/unimuenster -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6319 bytes Desc: S/MIME cryptographic signature URL: From andrewg at andrewg.com Thu Dec 12 11:43:50 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 12 Dec 2024 10:43:50 +0000 Subject: Adding a nounce before hashing as covert channel In-Reply-To: References: Message-ID: <86CC5BFF-6B28-4F73-B787-1E9E1C0C9596@andrewg.com> On 12 Dec 2024, at 09:39, Rainer Perske wrote: > > Due to the thermodynamic barrier, minor weaknesses in SHA-2 and SHA-3 do not matter due to the sheer length of the hash. > > And you are not protecting at all against major weaknesses in the hash algorithm and you are not even considering possible weaknesses in other protocol elements. It should be noted that the salt in v6 signatures also helps to protect against fault-based attacks. See https://eprint.iacr.org/2017/1014 A -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From wk at gnupg.org Thu Dec 12 12:08:42 2024 From: wk at gnupg.org (Werner Koch) Date: Thu, 12 Dec 2024 12:08:42 +0100 Subject: STDIN behaviour change ( 2.2.44/2.4.5) In-Reply-To: (Dirk-Willem van Gulik via Gnupg-devel's message of "Wed, 11 Dec 2024 19:58:54 +0100") References: Message-ID: <87r06dw43p.fsf@jacob.g10code.de> Hi! On Wed, 11 Dec 2024 19:58, Dirk-Willem van Gulik said: > After an update to 2.4.5 - we?re seeing an odd behaviour change (not sure it is regression) - where GPG seems to wait for an EOF as opposed to the end of message. I am not sure what you mean by EOF vs. end of message. How should gpg distinguish your two use cases - it reads the input and acts upon it. There might have been changes in the input buffering but that can't be the problem. On Unix we use read(2) until it returns 0 to indicate EOF or until we see an error and the errno is EPIPE. All other errors will print an error message. For reference the code in 2.2 is: do { n = read (f, buf, size); } while (n == -1 && errno == EINTR); if (n == -1) { /* error */ if (errno != EPIPE) { rc = gpg_error_from_syserror (); log_error ("%s: read error: %s\n", a->fname, strerror (errno)); } } else if (!n) { /* eof */ a->eof_seen = 1; rc = -1; } else { nbytes = n; } and in 2.4: read_more: do { n = read (f, buf + nbytes, size - nbytes); } while (n == -1 && errno == EINTR); if (n > 0) { nbytes += n; if (nbytes < size) goto read_more; } else if (!n) /* eof */ { if (nbytes) a->delayed_rc = -1; else { a->eof_seen = 1; rc = -1; } } else /* error */ { rc = gpg_error_from_syserror (); if (gpg_err_code (rc) != GPG_ERR_EPIPE) log_error ("%s: read error: %s\n", a->fname, gpg_strerror (rc)); if (nbytes) { a->delayed_rc = rc; rc = 0; } } The change in 2.4 (from 2018) is due to https://dev.gnupg.org/rGbfc11816444512b4ebcc6617d3c3b5988e753de3 which tries to utilize larger buffers. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From wk at gnupg.org Thu Dec 12 12:15:03 2024 From: wk at gnupg.org (Werner Koch) Date: Thu, 12 Dec 2024 12:15:03 +0100 Subject: Adding a nounce before hashing as covert channel In-Reply-To: <582422b1-91ad-4a1b-baba-b3b5c53da63d@gmail.com> (Jacob Bachmeyer via Gnupg-devel's message of "Wed, 11 Dec 2024 22:39:28 -0600") References: <582422b1-91ad-4a1b-baba-b3b5c53da63d@gmail.com> Message-ID: <87msh1w3t4.fsf@jacob.g10code.de> On Wed, 11 Dec 2024 22:39, Jacob Bachmeyer said: > The problem is that strong algorithms *become* weak without advance > warning.? Therefore, it is necessary to take measures to reduce the But we don't know in which way they become weak. You can't exclude that a new weakness is leveraged by the extra random salt [1]. Salam-Shalom, Werner [1] We are talking about a salt and not a nonce (number-used-once). -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From wiktor at metacode.biz Thu Dec 12 12:58:26 2024 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Thu, 12 Dec 2024 12:58:26 +0100 Subject: Adding a nounce before hashing as covert channel In-Reply-To: <86CC5BFF-6B28-4F73-B787-1E9E1C0C9596@andrewg.com> References: <86CC5BFF-6B28-4F73-B787-1E9E1C0C9596@andrewg.com> Message-ID: Hi Andrew, On 12.12.2024 11:43, Andrew Gallagher via Gnupg-devel wrote: > It should be noted that the salt in v6 signatures also helps to protect > against fault-based attacks. See?https://eprint.iacr.org/2017/1014 I'm not entirely sure that the v6 salt helps in this case - it influences the final digest but the fault attack then operates on that new digest. I've read section 9. Countermeasures and couldn't find any mention of salt being effective. Of course, the obligatory disclaimer: I'm not a cryptographer and it'd be nice to hear one voice their opinion and arguments. Kind regards, Wiktor From jcb62281 at gmail.com Fri Dec 13 02:16:22 2024 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Thu, 12 Dec 2024 19:16:22 -0600 Subject: Adding a nounce before hashing as covert channel In-Reply-To: <87msh1w3t4.fsf@jacob.g10code.de> References: <582422b1-91ad-4a1b-baba-b3b5c53da63d@gmail.com> <87msh1w3t4.fsf@jacob.g10code.de> Message-ID: <28517af5-92c5-4dca-8a8f-2555261fb2ce@gmail.com> On 12/12/24 05:15, Werner Koch wrote: > On Wed, 11 Dec 2024 22:39, Jacob Bachmeyer said: > >> The problem is that strong algorithms *become* weak without advance >> warning.? Therefore, it is necessary to take measures to reduce the > But we don't know in which way they become weak. You can't exclude that > a new weakness is leveraged by the extra random salt [1] So that would make adding salted signatures neutral:? they protect against one class of unknown attacks but could also enable another class of unknown attacks. > [...] > > [1] We are talking about a salt and not a nonce (number-used-once). Now I have to ask:? how is a salt different from a nonce? -- Jacob -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrewg at andrewg.com Fri Dec 13 13:43:53 2024 From: andrewg at andrewg.com (andrewg) Date: Fri, 13 Dec 2024 12:43:53 +0000 Subject: Adding a nounce before hashing as covert channel In-Reply-To: <28517af5-92c5-4dca-8a8f-2555261fb2ce@gmail.com> References: <582422b1-91ad-4a1b-baba-b3b5c53da63d@gmail.com> <87msh1w3t4.fsf@jacob.g10code.de> <28517af5-92c5-4dca-8a8f-2555261fb2ce@gmail.com> Message-ID: <152425d887215d2904fec454fb87c2c8@andrewg.com> On 2024-12-13 01:16, Jacob Bachmeyer via Gnupg-devel wrote: > On 12/12/24 05:15, Werner Koch wrote: >> >> But we don't know in which way they become weak. You can't exclude >> that >> a new weakness is leveraged by the extra random salt [1] > > So that would make adding salted signatures neutral:? they protect > against one class of unknown attacks but could also enable another > class of unknown attacks. I don't see how adding a salt enables a new class of attacks. The salt is hashed as if it were part of the message; if it was possible to create a collision in a salted signature by manipulating the salt, it would equally be possible to create a collision in an unsalted signature by manipulating the first N bits of the message. But while the message may be attacker-controlled, the salt is not. So even if an attacker could generate a collision more easily using the salt, they would still need to make O(2^N) attempts before the victim happened by chance to generate a matching signature. A From andrewg at andrewg.com Fri Dec 13 13:59:15 2024 From: andrewg at andrewg.com (andrewg) Date: Fri, 13 Dec 2024 12:59:15 +0000 Subject: Adding a nounce before hashing as covert channel In-Reply-To: References: <86CC5BFF-6B28-4F73-B787-1E9E1C0C9596@andrewg.com> Message-ID: <1db95a3e847f5a43860a76bc0af016a3@andrewg.com> On 2024-12-12 11:58, Wiktor Kwapisiewicz wrote: > > On 12.12.2024 11:43, Andrew Gallagher via Gnupg-devel wrote: >> It should be noted that the salt in v6 signatures also helps to >> protect against fault-based attacks. >> See?https://eprint.iacr.org/2017/1014 > > I'm not entirely sure that the v6 salt helps in this case - it > influences the final digest but the fault attack then operates on that > new digest. I've read section 9. Countermeasures and couldn't find any > mention of salt being effective. Fault attacks require the generation of multiple signatures over the same message digest. With an unsalted signature, it is sufficient to induce a victim to sign the same message twice with the same timestamp. With a salted signature, it is vanishingly improbable that the same digest will ever be produced. A From andrewg at andrewg.com Fri Dec 13 18:28:08 2024 From: andrewg at andrewg.com (andrewg) Date: Fri, 13 Dec 2024 17:28:08 +0000 Subject: Adding a nounce before hashing as covert channel In-Reply-To: References: <86CC5BFF-6B28-4F73-B787-1E9E1C0C9596@andrewg.com> <1db95a3e847f5a43860a76bc0af016a3@andrewg.com> Message-ID: On 2024-12-13 17:07, James Bottomley wrote: > On Fri, 2024-12-13 at 12:59 +0000, andrewg via Gnupg-devel wrote: >> >> Fault attacks require the generation of multiple signatures over the >> same message digest. With an unsalted signature, it is sufficient to >> induce a victim to sign the same message twice with the same >> timestamp. With a salted signature, it is vanishingly improbable that >> the same digest will ever be produced. > > Hey, that's a bit misleading. Sorry, I did gloss over a lot of detail... > For Elliptic Curves a distinct nonce is > a required part of the signature scheme and the weakness is that if two > different messages are ever signed by the same key using the *same* > nonce then the private key can be mathematically recovered. Sure, but in deterministic ECC signature schemes the nonce is calculated from the message. In OpenPGP, the ECC "message" is the OpenPGP digest, so adding a salt to the digest ensures that both the nonce and the message are unique for every signature. > However, while the faulted message attack sounds more > plausible the same signature faulted second message is only achievable > in a limited timeframe, the timespan for pulling off a faulted rng > attack is the key lifetime, giving a determined attacker much more > leeway to produce an identical nonce. In OpenPGP all signatures contain a timestamp, so even if a determined attacker was able to generate a large number of signatures using a faulty RNG, the timestamp field would keep incrementing. The attacker would need to either force a duplicate salt within ~1s, or find a hash collision. A From James.Bottomley at HansenPartnership.com Fri Dec 13 18:07:21 2024 From: James.Bottomley at HansenPartnership.com (James Bottomley) Date: Fri, 13 Dec 2024 12:07:21 -0500 Subject: Adding a nounce before hashing as covert channel In-Reply-To: <1db95a3e847f5a43860a76bc0af016a3@andrewg.com> References: <86CC5BFF-6B28-4F73-B787-1E9E1C0C9596@andrewg.com> <1db95a3e847f5a43860a76bc0af016a3@andrewg.com> Message-ID: On Fri, 2024-12-13 at 12:59 +0000, andrewg via Gnupg-devel wrote: > On 2024-12-12 11:58, Wiktor Kwapisiewicz wrote: > > > > On 12.12.2024 11:43, Andrew Gallagher via Gnupg-devel wrote: > > > It should be noted that the salt in v6 signatures also helps to > > > protect against fault-based attacks. > > > See?https://eprint.iacr.org/2017/1014 > > > > I'm not entirely sure that the v6 salt helps in this case - it > > influences the final digest but the fault attack then operates on > > that new digest. I've read section 9. Countermeasures and couldn't > > find any mention of salt being effective. > > Fault attacks require the generation of multiple signatures over the > same message digest. With an unsalted signature, it is sufficient to > induce a victim to sign the same message twice with the same > timestamp. With a salted signature, it is vanishingly improbable that > the same digest will ever be produced. Hey, that's a bit misleading. For Elliptic Curves a distinct nonce is a required part of the signature scheme and the weakness is that if two different messages are ever signed by the same key using the *same* nonce then the private key can be mathematically recovered. Producing the same signature for the same message twice is fine: that's why deterministic signature schemes work. In a fault attack on a deterministic signature scheme, you try to get the same message signed twice (so same nonce), but attempt to fault the message or digest before the second signing so the result is effectively two different messages signed with the same nonce. On the other hand, for random nonces, the worry is that weak random number generators or faulting the rng can also lead to the same nonce being reused, especially if the signer produces lots of signatures. The 'Attacking Deterministic Signature Schemes using Fault Attacks' paper discounts the latter problem in its analysis and concentrates on the former. However, while the faulted message attack sounds more plausible the same signature faulted second message is only achievable in a limited timeframe, the timespan for pulling off a faulted rng attack is the key lifetime, giving a determined attacker much more leeway to produce an identical nonce. The real problem, though, is the Elliptic Curve signature scheme itself: however the nonce is generated (whether deterministic or random or a mixture) the scheme is always vulnerable to faulting the nonce to produce one that was previously used in a signature. Regards, James From James.Bottomley at HansenPartnership.com Fri Dec 13 19:59:48 2024 From: James.Bottomley at HansenPartnership.com (James Bottomley) Date: Fri, 13 Dec 2024 13:59:48 -0500 Subject: Adding a nounce before hashing as covert channel In-Reply-To: References: <86CC5BFF-6B28-4F73-B787-1E9E1C0C9596@andrewg.com> <1db95a3e847f5a43860a76bc0af016a3@andrewg.com> Message-ID: <98defb8540232ba77798bd67733072f417f057e7.camel@HansenPartnership.com> On Fri, 2024-12-13 at 17:28 +0000, andrewg via Gnupg-devel wrote: [...] > > However, while the faulted message attack sounds more > > plausible the same signature faulted second message is only > > achievable in a limited timeframe, the timespan for pulling off a > > faulted rng attack is the key lifetime, giving a determined > > attacker much more leeway to produce an identical nonce. > > In OpenPGP all signatures contain a timestamp, so even if a > determined attacker was able to generate a large number of signatures > using a faulty RNG, the timestamp field would keep incrementing. The > attacker would need to either force a duplicate salt within ~1s, or > find a hash collision. I think there may be confusion here: the 'Nonce Reuse in deterministic ECDSA' section of the paper only presents a special case of the general problem: The EC signature algorithm requires an input nonce which must be unique for every signature otherwise the private key can be recovered mathematically from the two signatures that reused the nonce provided they were signatures over different messages. It's not about whether or not to salt the message and faulting the salt. I'm making the point that it's this signature nonce you try to fault to break the uniqueness guarantee; what you add to the message is irrelevant because exploiting a duplicate nonce to extract the private key requires the signed messages to be different anyway. Regards, James From andrewg at andrewg.com Sat Dec 14 11:21:48 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sat, 14 Dec 2024 10:21:48 +0000 Subject: Adding a nounce before hashing as covert channel In-Reply-To: <98defb8540232ba77798bd67733072f417f057e7.camel@HansenPartnership.com> References: <86CC5BFF-6B28-4F73-B787-1E9E1C0C9596@andrewg.com> <1db95a3e847f5a43860a76bc0af016a3@andrewg.com> <98defb8540232ba77798bd67733072f417f057e7.camel@HansenPartnership.com> Message-ID: <812352FA-301A-437A-B121-7A5BD69DE01B@andrewg.com> On 13 Dec 2024, at 18:59, James Bottomley wrote: > > I think there may be confusion here: the 'Nonce Reuse in deterministic > ECDSA' section of the paper only presents a special case of the general > problem: The EC signature algorithm requires an input nonce which must > be unique for every signature otherwise the private key can be > recovered mathematically from the two signatures that reused the nonce > provided they were signatures over different messages. It's not about > whether or not to salt the message and faulting the salt. Correct, that?s not what it?s about. I think perhaps the confusion arises because discussion of ECC signatures in the paper uses the terminology ?Message?, but this ?ECC Message? is not the same thing as the "OpenPGP Message?. Because OpenPGP applies a pre-hashing stage to all signatures, the ?Message? passed to the ECC layer is always a digest. Salting *this* digest ensures that the ECC nonce is never reused, because in deterministic ECC, the nonce is calculated from the ?ECC Message?, i.e. the OpenPGP digest, which if salted can never be the same twice. It is therefore not possible to perform the fault attack against a salted OpenPGP signature, because faulting a deterministic ECC signature requires an attacker to pass the same ?ECC message" to the signature algorithm twice, and then cause a fault between the calculation of the nonce and the calculation of the signature, so that the nonce is the same twice but the messages that effectively get signed are different. In OpenPGP v6 the nonce can never be the same because the input ECC message can never be the same. Bluntly, salting the OpenPGP digest works by forcing nonce uniqueness at a high level, regardless of where in the stack below a fault may arise. A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From wk at gnupg.org Mon Dec 16 13:54:40 2024 From: wk at gnupg.org (Werner Koch) Date: Mon, 16 Dec 2024 13:54:40 +0100 Subject: Adding a nounce before hashing as covert channel In-Reply-To: <152425d887215d2904fec454fb87c2c8@andrewg.com> (andrewg via Gnupg-devel's message of "Fri, 13 Dec 2024 12:43:53 +0000") References: <582422b1-91ad-4a1b-baba-b3b5c53da63d@gmail.com> <87msh1w3t4.fsf@jacob.g10code.de> <28517af5-92c5-4dca-8a8f-2555261fb2ce@gmail.com> <152425d887215d2904fec454fb87c2c8@andrewg.com> Message-ID: <871py7vldb.fsf@jacob.g10code.de> On Fri, 13 Dec 2024 12:43, andrewg said: > would equally be possible to create a collision in an unsalted > signature by manipulating the first N bits of the message. But while But these first N bits of the message may allow to detect a modification. A non-deterministic salt allows to hide the modification. I have not a problem with a _deterministic_ salt but I do have one with adding a new covert channel. And of course with the stupid way on how this was added to the specs. Extra data belongs into a signature subpacket and if you really want it at the begin of the subpacket area, well, specify it this way. The whole point here is to willy-nilly make it impossible to support the new signing packet. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From andrewg at andrewg.com Mon Dec 16 14:30:04 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 16 Dec 2024 13:30:04 +0000 Subject: Adding a nounce before hashing as covert channel In-Reply-To: <871py7vldb.fsf@jacob.g10code.de> References: <582422b1-91ad-4a1b-baba-b3b5c53da63d@gmail.com> <87msh1w3t4.fsf@jacob.g10code.de> <28517af5-92c5-4dca-8a8f-2555261fb2ce@gmail.com> <152425d887215d2904fec454fb87c2c8@andrewg.com> <871py7vldb.fsf@jacob.g10code.de> Message-ID: On 16 Dec 2024, at 12:54, Werner Koch wrote: > > On Fri, 13 Dec 2024 12:43, andrewg said: > >> would equally be possible to create a collision in an unsalted >> signature by manipulating the first N bits of the message. But while > > But these first N bits of the message may allow to detect a > modification. A non-deterministic salt allows to hide the modification. It depends on what you?re signing. If it?s an RFC3156 message, the first N bits are in the MIME header section. And that?s just one possibility that springs immediately to mind, I?m sure there are many others. > I have not a problem with a _deterministic_ salt but I do have one with > adding a new covert channel. If the salt was deterministic, I don?t see how it would address fault attacks... > And of course with the stupid way on how > this was added to the specs. Extra data belongs into a signature > subpacket Extra data like filenames? ;-) > and if you really want it at the begin of the subpacket area, > well, specify it this way. Putting it in the hashed subpacket area wouldn?t address either your concerns or those of the RFC authors though. It?s still a covert channel (just like any other unknown non-critical subpacket, BTW), and even if it?s at the beginning of the subpacket area it?s still hashed-in after the document, which doesn?t protect against chosen-prefix attacks. > The whole point here is to willy-nilly make it impossible to support the > new signing packet. I am genuinely interested to know why it is _impossible_. OpenPGP has never seriously attempted to eliminate covert channels - there are several existing ones that have a much higher bandwidth than signature salts, and would surely be worthy of greater attention if we were taking plaintext covert channels as a serious threat. Also, v5 signatures have extra free-text fields (filename, timestamp) that are hashed-in before the main document, rather than as subpackets. I?m not saying your concerns aren't genuine, but I am confused why these ones in particular are red lines, and other apparently similar ones are not. A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From lukele at gpgtools.org Mon Dec 16 14:05:41 2024 From: lukele at gpgtools.org (Lukas | GPGTools) Date: Mon, 16 Dec 2024 14:05:41 +0100 Subject: Libassuan API V2 vs V3 and pinentry Message-ID: Hi all, when trying to build pinentry and linking it against the latest libassuan 3.0.1 configure shows the warning: --- checking LIBASSUAN API version... does not match. want=2 got=3. ? and later fails with the error: ? *** You need libassuan to build this program. *** This library is for example available at *** ftp://ftp.gnupg.org/gcrypt/libassuan/ *** (at least version 2.1.0 (API 2) is required). ? I?ve manually patched the configure file to have it accept v3.x and from a few quick tests it appears that everything is working as expected. But I wanted to make sure and ask if API 3 is backwards compatible and as such I should not run into issues or if it works rather by chance and if I?ll see side-effects in the future. Thanks & cheers Lukas From wk at gnupg.org Mon Dec 16 15:43:45 2024 From: wk at gnupg.org (Werner Koch) Date: Mon, 16 Dec 2024 15:43:45 +0100 Subject: Libassuan API V2 vs V3 and pinentry In-Reply-To: (Lukas's message of "Mon, 16 Dec 2024 14:05:41 +0100") References: Message-ID: <87cyhru1r2.fsf@jacob.g10code.de> Hi Lukas, On Mon, 16 Dec 2024 14:05, Lukas | GPGTools said: > libassuan 3.0.1 configure shows the warning: > --- > checking LIBASSUAN API version... does not match. want=2 got=3. I see, we should relese a new Pinentry. I think for all other components we relaxed the requirement and allowed API version 2 and 3. Technically the change in Libassuan is an API break but all our components are not affected. Are you sure that you are building Pinentry 1.3.0 ? m4/libassuna/m4 should have a Last-changed line of at least: 2023-07-26 Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From wk at gnupg.org Mon Dec 16 15:51:59 2024 From: wk at gnupg.org (Werner Koch) Date: Mon, 16 Dec 2024 15:51:59 +0100 Subject: Adding a nounce before hashing as covert channel In-Reply-To: (Andrew Gallagher's message of "Mon, 16 Dec 2024 13:30:04 +0000") References: <582422b1-91ad-4a1b-baba-b3b5c53da63d@gmail.com> <87msh1w3t4.fsf@jacob.g10code.de> <28517af5-92c5-4dca-8a8f-2555261fb2ce@gmail.com> <152425d887215d2904fec454fb87c2c8@andrewg.com> <871py7vldb.fsf@jacob.g10code.de> Message-ID: <878qsfu1dc.fsf@jacob.g10code.de> On Mon, 16 Dec 2024 13:30, Andrew Gallagher said: > even if it?s at the beginning of the subpacket area it?s still > hashed-in after the document, which doesn?t protect against > chosen-prefix attacks. If you can imagine only chosen-prefix attacks than you are right. But we don't known and we have seen a lot of surprising research in mathemetics. > I am genuinely interested to know why it is _impossible_. OpenPGP has > never seriously attempted to eliminate covert channels - there are But we never introduced new ones without a good reason. > taking plaintext covert channels as a serious threat. Also, v5 > signatures have extra free-text fields (filename, timestamp) that are > hashed-in before the main document, rather than as subpackets. Yes, they can be used. But your WG removed the bug fix (i.e. hashing the meta data). And that is the very reason why it is not possible to support that new signing format. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From andrewg at andrewg.com Mon Dec 16 16:22:49 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 16 Dec 2024 15:22:49 +0000 Subject: Adding a nounce before hashing as covert channel In-Reply-To: <878qsfu1dc.fsf@jacob.g10code.de> References: <582422b1-91ad-4a1b-baba-b3b5c53da63d@gmail.com> <87msh1w3t4.fsf@jacob.g10code.de> <28517af5-92c5-4dca-8a8f-2555261fb2ce@gmail.com> <152425d887215d2904fec454fb87c2c8@andrewg.com> <871py7vldb.fsf@jacob.g10code.de> <878qsfu1dc.fsf@jacob.g10code.de> Message-ID: On 16 Dec 2024, at 14:51, Werner Koch wrote: > >> taking plaintext covert channels as a serious threat. Also, v5 >> signatures have extra free-text fields (filename, timestamp) that are >> hashed-in before the main document, rather than as subpackets. > > Yes, they can be used. But your WG removed the bug fix (i.e. hashing > the meta data). And that is the very reason why it is not possible to > support that new signing format. Werner, *you* proposed a solution for this in the LibrePGP draft: https://datatracker.ietf.org/doc/html/draft-koch-librepgp#section-5.2.3.33 > This subpacket MAY be used to protect the meta data from the Literal Data Packet with V4 signatures I then proposed extending this mechanism to v6 signatures: https://datatracker.ietf.org/doc/html/draft-gallagher-openpgp-literal-metadata > This document introduces the missing integrity check by adopting and extending the "Literal Data Meta Hash" subpacket from [LIBREPGP], section 5.2.3.33. And then *you* told *me* that it wasn?t worth the effort implementing the fix that *you* invented: https://lists.gnupg.org/pipermail/librepgp-discuss/2024/000005.html > Sure, you may use it for v6 signatures. But after all why should you do it, given that it was removed from crypto-refresh for some incomprehensible reason. Are these serious questions for which people can propose serious answers, or is it just a gish gallop? Because it feels like we?ve been going around the same circles for over a year now. A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From James.Bottomley at HansenPartnership.com Tue Dec 17 05:21:49 2024 From: James.Bottomley at HansenPartnership.com (James Bottomley) Date: Mon, 16 Dec 2024 23:21:49 -0500 Subject: Adding a nounce before hashing as covert channel In-Reply-To: <812352FA-301A-437A-B121-7A5BD69DE01B@andrewg.com> References: <86CC5BFF-6B28-4F73-B787-1E9E1C0C9596@andrewg.com> <1db95a3e847f5a43860a76bc0af016a3@andrewg.com> <98defb8540232ba77798bd67733072f417f057e7.camel@HansenPartnership.com> <812352FA-301A-437A-B121-7A5BD69DE01B@andrewg.com> Message-ID: On Sat, 2024-12-14 at 10:21 +0000, Andrew Gallagher via Gnupg-devel wrote: > On 13 Dec 2024, at 18:59, James Bottomley > wrote: > > > > I think there may be confusion here: the 'Nonce Reuse in > > deterministic > > ECDSA' section of the paper only presents a special case of the > > general > > problem: The EC signature algorithm requires an input nonce which > > must > > be unique for every signature otherwise the private key can be > > recovered mathematically from the two signatures that reused the > > nonce > > provided they were signatures over different messages.? It's not > > about > > whether or not to salt the message and faulting the salt. > > Correct, that?s not what it?s about. I think perhaps the confusion > arises because discussion of ECC signatures in the paper uses the > terminology ?Message?, but this ?ECC Message? is not the same thing > as the "OpenPGP Message?. Because OpenPGP applies a pre-hashing stage > to all signatures, the ?Message? passed to the ECC layer is always a > digest. Salting *this* digest ensures that the ECC nonce is never > reused, because in deterministic ECC, the nonce is calculated from > the ?ECC Message?, i.e. the OpenPGP digest, which if salted can never > be the same twice. > > It is therefore not possible to perform the fault attack against a > salted OpenPGP signature, because faulting a deterministic ECC > signature requires an attacker to pass the same ?ECC message" to the > signature algorithm twice, and then cause a fault between the > calculation of the nonce and the calculation of the signature, so > that the nonce is the same twice but the messages that effectively > get signed are different. In OpenPGP v6 the nonce can never be the > same because the input ECC message can never be the same. The EC signature nonce must be both unique and unknown (if you know it you can also recover the private key). This means that if you use the message hash as part of a deterministic nonce scheme, you have to mix it with something unknown (like the private key or another random number). The point being that this mixing is an attack point that can be faulted to make nonce re-use much more likely. This means it's possible to do fault attacks against *any* EC signature, regardless of the way the message is salted. > Bluntly, salting the OpenPGP digest works by forcing nonce uniqueness > at a high level, regardless of where in the stack below a fault may > arise. But not high enough to avoid EC signature nonce faulting because of the mixing requirement after the digest is obtained. Regards, James -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part URL: From wk at gnupg.org Tue Dec 17 09:02:31 2024 From: wk at gnupg.org (Werner Koch) Date: Tue, 17 Dec 2024 09:02:31 +0100 Subject: Adding a nounce before hashing as covert channel In-Reply-To: (Andrew Gallagher's message of "Mon, 16 Dec 2024 15:22:49 +0000") References: <582422b1-91ad-4a1b-baba-b3b5c53da63d@gmail.com> <87msh1w3t4.fsf@jacob.g10code.de> <28517af5-92c5-4dca-8a8f-2555261fb2ce@gmail.com> <152425d887215d2904fec454fb87c2c8@andrewg.com> <871py7vldb.fsf@jacob.g10code.de> <878qsfu1dc.fsf@jacob.g10code.de> Message-ID: <87ikri4u08.fsf@jacob.g10code.de> On Mon, 16 Dec 2024 15:22, Andrew Gallagher said: > Werner, *you* proposed a solution for this in the LibrePGP draft: > https://datatracker.ietf.org/doc/html/draft-koch-librepgp#section-5.2.3.33 5.2.3.33. Literal Data Meta Hash This subpacket MAY be used to protect the meta data from the Literal Data Packet with V4 signatures. The hash is computed using SHA2-256 from this data: This is a proposal to add this to v4 sinature in a backward compatible way. We had a direct hashing in the rfc4880bis which was then removed from the draft for no good reason. Adding a hack later is not what counts as a solid successor of rfc4880. As of know the demand for this is not hight enough to implement it for v4 packets. Inparticular due to the immediate pending mode to PQC and thus v5 (for encryption right now). The rollout strategy here is 1. Deploy PQC-resistent encryption keys along with standard encryption keys. 2. Enable a requirement for thus keys (--require-pqc-encryption) 3. Switch to v5 signing and encryption keys in selected user groups. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From andrewg at andrewg.com Tue Dec 17 11:15:56 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 17 Dec 2024 10:15:56 +0000 Subject: Adding a nounce before hashing as covert channel In-Reply-To: References: <86CC5BFF-6B28-4F73-B787-1E9E1C0C9596@andrewg.com> <1db95a3e847f5a43860a76bc0af016a3@andrewg.com> <98defb8540232ba77798bd67733072f417f057e7.camel@HansenPartnership.com> <812352FA-301A-437A-B121-7A5BD69DE01B@andrewg.com> Message-ID: <967E9ADE-0EA2-4116-977D-2480A76992E5@andrewg.com> On 17 Dec 2024, at 04:21, James Bottomley wrote: > > The EC signature nonce must be both unique and unknown (if you know it > you can also recover the private key). This means that if you use the > message hash as part of a deterministic nonce scheme, you have to mix > it with something unknown (like the private key or another random > number). The point being that this mixing is an attack point that can > be faulted to make nonce re-use much more likely. In EdDSA, this mixing is done by calculating a digest over (private key, message). Is this really a practical attack vector? How do you introduce a fault that causes a digest algorithm to produce a *known* result? In any case, nobody is claiming that the signature salt is a magic bullet. A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From andrewg at andrewg.com Tue Dec 17 11:34:32 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 17 Dec 2024 10:34:32 +0000 Subject: Adding a nounce before hashing as covert channel In-Reply-To: <87ikri4u08.fsf@jacob.g10code.de> References: <582422b1-91ad-4a1b-baba-b3b5c53da63d@gmail.com> <87msh1w3t4.fsf@jacob.g10code.de> <28517af5-92c5-4dca-8a8f-2555261fb2ce@gmail.com> <152425d887215d2904fec454fb87c2c8@andrewg.com> <871py7vldb.fsf@jacob.g10code.de> <878qsfu1dc.fsf@jacob.g10code.de> <87ikri4u08.fsf@jacob.g10code.de> Message-ID: <1638CA85-542A-41C3-A9EB-ECE1A1915DFA@andrewg.com> On 17 Dec 2024, at 08:02, Werner Koch wrote: > > On Mon, 16 Dec 2024 15:22, Andrew Gallagher said: > >> Werner, *you* proposed a solution for this in the LibrePGP draft: >> https://datatracker.ietf.org/doc/html/draft-koch-librepgp#section-5.2.3.33 > > This is a proposal to add this to v4 sinature in a backward compatible > way. We had a direct hashing in the rfc4880bis which was then removed > from the draft for no good reason. Adding a hack later is not what > counts as a solid successor of rfc4880. Putting extra metadata in a subpacket (alongside all the existing metadata) is hardly a ?hack?. Some solutions will of course be aesthetically ?better? than others by subjective metrics. If you don?t want to implement any of them, that?s your choice. But none of them are ?impossible?. A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From heiko.schaefer at posteo.de Tue Dec 17 14:27:28 2024 From: heiko.schaefer at posteo.de (=?UTF-8?Q?Heiko_Sch=C3=A4fer?=) Date: Tue, 17 Dec 2024 13:27:28 +0000 Subject: Adding a nonce before hashing as covert channel In-Reply-To: <87ikri4u08.fsf@jacob.g10code.de> References: <582422b1-91ad-4a1b-baba-b3b5c53da63d@gmail.com> <87msh1w3t4.fsf@jacob.g10code.de> <28517af5-92c5-4dca-8a8f-2555261fb2ce@gmail.com> <152425d887215d2904fec454fb87c2c8@andrewg.com> <871py7vldb.fsf@jacob.g10code.de> <878qsfu1dc.fsf@jacob.g10code.de> <87ikri4u08.fsf@jacob.g10code.de> Message-ID: <40447028-7a26-4f07-b298-f096d7dc7868@posteo.de> On 12/17/24 9:02 AM, Werner Koch via Gnupg-devel wrote: > On Mon, 16 Dec 2024 15:22, Andrew Gallagher said: > > [..] We had a direct hashing in the rfc4880bis which was then removed > from the draft for no good reason. [..] You keep varyingly insinuating that stupid, inexplicable or even sinister things happened in the IETF OpenPGP working group. And every now and then, people chime in to correct your endlessly repeated assertions. I'll do one more round of this, here. There is a very simple, coherent and non-sinister reason why the functionality you're referring to is not in RFC 9580: The IETF process that led to RFC 9580 (working title "crypto refresh") had a clear and limited charter. Produce an update to RFC 4880 (which was published in 2007), with a narrow focus on updating the cryptographic mechanisms. Additional specification work was put off to a separate step. The WG charter was defined this way to limit the work of producing a coherent and solid update for RFC 4880 to a manageable scope. Had the charter been more inclusive, I doubt if the process could ever have led to a result. So the WG, consisting of a broad set of stakeholders, did finally produce an update to RFC 4880. In a process that you opted to drop out of, at the very beginning, but are now complaining endlessly about. You endlessly repeat a small set of varyingly convincing arguments and complaints. Frankly, I find your communication about these matters outrageous, at times baffling, and often disturbing. Your life's work - GnuPG - is based on Phil Zimmermann's PGP, which he decided to specify as an open format under the name OpenPGP, so that a diverse group of implementers could collaborate on the further development of the technology. Phil has weighed in, close to the end of the crypto refresh work in 2022, saying in no uncertain terms that he considered the IETF draft (which has since become RFC 9580) compelling: https://mailarchive.ietf.org/arch/msg/openpgp/tX6anWN_QKy-FudFanZYLoy-oYk/ ("[..] the only draft that incorporates ideas from a wide range of implementers, with strong modern cryptographic primitives in all categories, with mechanisms that respond to documented attacks.") And yet you keep insinuating that the IETF process was flawed, illegitimate, sinister, and that truly the only reasonable path forward is for you to continue to evolve rfc4880bis (now under your new "LibrePGP" banner). I understand that you've painted yourself into a corner, and I am truly sorry to see this state of affairs. However, pretty please, stop repeating your complaints about the IETF process. It's undignified and silly. Heiko From James.Bottomley at HansenPartnership.com Tue Dec 17 14:40:28 2024 From: James.Bottomley at HansenPartnership.com (James Bottomley) Date: Tue, 17 Dec 2024 08:40:28 -0500 Subject: Adding a nounce before hashing as covert channel In-Reply-To: <967E9ADE-0EA2-4116-977D-2480A76992E5@andrewg.com> References: <86CC5BFF-6B28-4F73-B787-1E9E1C0C9596@andrewg.com> <1db95a3e847f5a43860a76bc0af016a3@andrewg.com> <98defb8540232ba77798bd67733072f417f057e7.camel@HansenPartnership.com> <812352FA-301A-437A-B121-7A5BD69DE01B@andrewg.com> <967E9ADE-0EA2-4116-977D-2480A76992E5@andrewg.com> Message-ID: <9425d76e29ebbe0c9436170362b6cb07c05660c2.camel@HansenPartnership.com> On Tue, 2024-12-17 at 10:15 +0000, Andrew Gallagher via Gnupg-devel wrote: > On 17 Dec 2024, at 04:21, James Bottomley > wrote: > > > > The EC signature nonce must be both unique and unknown (if you know > > it you can also recover the private key).? This means that if you > > use the message hash as part of a deterministic nonce scheme, you > > have to mix it with something unknown (like the private key or > > another random number).? The point being that this mixing is an > > attack point that can be faulted to make nonce re-use much more > > likely. > > > In EdDSA, this mixing is done by calculating a digest over (private > key, message). Is this really a practical attack vector? All rowhammer type attacks are probabalistic. The probability of success depends on the length of the target in memory and the time window to flip the bits. > How do you introduce a fault that causes a digest algorithm to > produce a *known* result? You don't need to. You just need to keep faulting it in a way that vastly increases the likelihood of collision over time (it's a classic rowhammer: set as many bits to 1 or 0 as possible in the nonce space). There's no detectable consequence to the attack and no alteration in victim behaviour you need to introduce. The probability of success is linear in the number of signatures produced (giving a vast time window, which is what makes success likely). I admit, since you would most need to execute this over the lifetime of a key and store as many signatures as you can, that it's a nation state type of attack rather than a quick hacker infiltration one. But these are also the types of attack we need to guard against. Regards, James > In any case, nobody is claiming that the signature salt is a magic > bullet. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part URL: From andrewg at andrewg.com Tue Dec 17 16:19:29 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 17 Dec 2024 15:19:29 +0000 Subject: Adding a nounce before hashing as covert channel In-Reply-To: <9425d76e29ebbe0c9436170362b6cb07c05660c2.camel@HansenPartnership.com> References: <86CC5BFF-6B28-4F73-B787-1E9E1C0C9596@andrewg.com> <1db95a3e847f5a43860a76bc0af016a3@andrewg.com> <98defb8540232ba77798bd67733072f417f057e7.camel@HansenPartnership.com> <812352FA-301A-437A-B121-7A5BD69DE01B@andrewg.com> <967E9ADE-0EA2-4116-977D-2480A76992E5@andrewg.com> <9425d76e29ebbe0c9436170362b6cb07c05660c2.camel@HansenPartnership.com> Message-ID: <4F5487AE-5CF4-44B6-91AE-C8B20DC95A6F@andrewg.com> On 17 Dec 2024, at 13:40, James Bottomley wrote: > I admit, since you would most > need to execute this over the lifetime of a key and store as many > signatures as you can, that it's a nation state type of attack rather > than a quick hacker infiltration one. But these are also the types of > attack we need to guard against. The type of attack that you?re describing appears at first glance to have no better probability of success than random chance. If you could calculate how much better than random such a method might be, it would help us all understand how seriously to take the possibility. But even if it were worth considering, adding random salt would be expected to *decrease* the chances of a digest collision, so it would be an argument *for* salting. A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From wk at gnupg.org Wed Dec 18 10:07:53 2024 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Dec 2024 10:07:53 +0100 Subject: Adding a nonce before hashing as covert channel In-Reply-To: <40447028-7a26-4f07-b298-f096d7dc7868@posteo.de> ("Heiko =?utf-8?Q?Sch=C3=A4fer?= via Gnupg-devel"'s message of "Tue, 17 Dec 2024 13:27:28 +0000") References: <582422b1-91ad-4a1b-baba-b3b5c53da63d@gmail.com> <87msh1w3t4.fsf@jacob.g10code.de> <28517af5-92c5-4dca-8a8f-2555261fb2ce@gmail.com> <152425d887215d2904fec454fb87c2c8@andrewg.com> <871py7vldb.fsf@jacob.g10code.de> <878qsfu1dc.fsf@jacob.g10code.de> <87ikri4u08.fsf@jacob.g10code.de> <40447028-7a26-4f07-b298-f096d7dc7868@posteo.de> Message-ID: <87v7vh2wba.fsf@jacob.g10code.de> Heiko, I don't want that such OpenPGP WG FUD now continues on this mailing list and thus I have only a few remarks just for the records. Don't expect any more replies on this topic from me. On Tue, 17 Dec 2024 13:27, Heiko Sch?fer said: > The IETF process that led to RFC 9580 (working title "crypto refresh") > had a clear and limited charter. Produce an update to RFC 4880 (which Right, which we achieved in 2018. It then got stuck by people who wanted to completely overhaul the spec and do an OpenPGP 2. Search the WG ML for this (sometime around 2017/2018). The end result of the WG is an extensive rework of the specification and not the planned move to newer algorithms (SHA-2, Modern AE) and integration of the ECC RFC. > Your life's work - GnuPG - is based on Phil Zimmermann's PGP, which he > decided to specify as an open format under the name OpenPGP, so that a > diverse group of implementers could collaborate on the further I started with GnuPG based on RFC1991 and not on the newly opened PGP 5 specification, which I became aware only late in November 1997 after I had already put some work in g10 (the working title of GnuPG back then). Right, PGP 5 was release with source code early this year but for copyright reasons I had no way to look at the code. That "diverse group" back then was pretty small and consisted of the PGP.com folks, other long term PGP 2 hackers, Tzeruch with his OPGP tool (which was also printed as abook), and me. > illegitimate, sinister, and that truly the only reasonable path I didn't say "sinister" at least not with its meaning of "threatening or foreshadowing evil or tragic developments" in mind. What I do say is that a few folks are bumping up their repudiation by trying to replace a matured and important protocol using incompatible and not thought ought replacement strategies. > forward is for you to continue to evolve rfc4880bis (now under your > new "LibrePGP" banner). Not mine. LibrePGP is a specification agred upon by the major real world implementations. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From andrewg at andrewg.com Wed Dec 18 12:30:17 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 18 Dec 2024 11:30:17 +0000 Subject: Adding a nonce before hashing as covert channel In-Reply-To: <87v7vh2wba.fsf@jacob.g10code.de> References: <582422b1-91ad-4a1b-baba-b3b5c53da63d@gmail.com> <87msh1w3t4.fsf@jacob.g10code.de> <28517af5-92c5-4dca-8a8f-2555261fb2ce@gmail.com> <152425d887215d2904fec454fb87c2c8@andrewg.com> <871py7vldb.fsf@jacob.g10code.de> <878qsfu1dc.fsf@jacob.g10code.de> <87ikri4u08.fsf@jacob.g10code.de> <40447028-7a26-4f07-b298-f096d7dc7868@posteo.de> <87v7vh2wba.fsf@jacob.g10code.de> Message-ID: On 18 Dec 2024, at 09:07, Werner Koch via Gnupg-devel wrote: > > It then got stuck by people who > wanted to completely overhaul the spec and do an OpenPGP 2. Anyone who has worked with OpenPGP for any length of time and who doesn?t have a burning desire to completely overhaul the spec IMO hasn?t been paying attention. Yes, some of the newer implementations have got it wrong at times. But you either find some imperfect way to work with the youngsters and their new-fangled ideas, or they will ignore you and leave you behind. That?s the great, timeless tragedy of existence. > Search the > WG ML for this (sometime around 2017/2018). The end result of the WG is > an extensive rework of the specification and not the planned move to > newer algorithms (SHA-2, Modern AE) and integration of the ECC RFC. It?s true that crypto-refresh performed a significant overhaul of the *structure* of the document, which does make detailed comparisons more difficult than perhaps they could have been. But the end result of the WG *was* the planned move to newer algorithms, and it *did not* extensively rework the semantics. For the record, there?s a great (if slightly outdated) summary of the non-editorial differences between ?crypto-refresh? (now RFC9580) and ?rfc4880-bis? (now LibrePGP) here: https://mailarchive.ietf.org/arch/msg/openpgp/aqBy97lj2P4DVxTds0eKZDVdmms/ NB at the time of writing, both crypto-refresh and rfc4880bis specified conflicting ?v5? formats. To fix the ambiguity, crypto-refresh's v5 => RFC9580?s v6. In addition, both specs have since adopted some ideas from each other, so the differences are not as great as the above summary suggests. The fundamental incompatibility between the two specifications is not technical. The irreconcilable difference is that one person has a veto over LibrePGP, but nobody has a veto in the IETF WG. Most implementors consider this a positive development. >> forward is for you to continue to evolve rfc4880bis (now under your >> new "LibrePGP" banner). > > Not mine. LibrePGP is a specification agred upon by the major real > world implementations. LibrePGP is a specification agreed upon by *two* implementations. If you arbitrarily include RNP (i.e. Thunderbird) but not openpgp.js (i.e. Protonmail, Mailvelope, FlowCrypt) in the ?major real world implementation? category then I?m not sure what else to say. A -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From heiko.schaefer at posteo.de Wed Dec 18 13:57:41 2024 From: heiko.schaefer at posteo.de (=?UTF-8?Q?Heiko_Sch=C3=A4fer?=) Date: Wed, 18 Dec 2024 12:57:41 +0000 Subject: Adding a nonce before hashing as covert channel In-Reply-To: <87v7vh2wba.fsf@jacob.g10code.de> References: <582422b1-91ad-4a1b-baba-b3b5c53da63d@gmail.com> <87msh1w3t4.fsf@jacob.g10code.de> <28517af5-92c5-4dca-8a8f-2555261fb2ce@gmail.com> <152425d887215d2904fec454fb87c2c8@andrewg.com> <871py7vldb.fsf@jacob.g10code.de> <878qsfu1dc.fsf@jacob.g10code.de> <87ikri4u08.fsf@jacob.g10code.de> <40447028-7a26-4f07-b298-f096d7dc7868@posteo.de> <87v7vh2wba.fsf@jacob.g10code.de> Message-ID: <72f9b2c0-0dd1-441f-a54f-1ca8e98df233@posteo.de> On 12/18/24 10:07 AM, Werner Koch via Gnupg-devel wrote: > Heiko, > > I don't want that such OpenPGP WG FUD now continues on this mailing list I reject your abuse of the term "FUD" to describe my message. I have raised neither "fears", "uncertainty", nor "doubt". Your attempt at such a blanket rebuttal borders on name-calling, and I resent this. In fact, I want to offer a counterpoint: *You* have consistently attempted to use FUD-style discursive tactics, including endless insinuations and innuendo. The entire point of your LibrePGP website is very obviously to raise uncertainty and doubt about RFC 9580. *You* are making a repetitive series of unfounded claims about the process, trying to raise fears about supposed compatibility issues and vaguely gesturing at supposed flaws of RFC 9580. In reality, you have raised no points of substance[1] over the past two years. You are complaining about matters of style, and even more so, implicitly, about power. It is abundantly clear that you want to be accepted as an authority, including in matters of mere style, and are unable and unwilling to collaborate with anyone who pushes back. [1]: https://blog.pgpkeys.eu/critique-critique.html From wk at gnupg.org Wed Dec 18 15:40:38 2024 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Dec 2024 15:40:38 +0100 Subject: Adding a nonce before hashing as covert channel In-Reply-To: (Andrew Gallagher's message of "Wed, 18 Dec 2024 11:30:17 +0000") References: <582422b1-91ad-4a1b-baba-b3b5c53da63d@gmail.com> <87msh1w3t4.fsf@jacob.g10code.de> <28517af5-92c5-4dca-8a8f-2555261fb2ce@gmail.com> <152425d887215d2904fec454fb87c2c8@andrewg.com> <871py7vldb.fsf@jacob.g10code.de> <878qsfu1dc.fsf@jacob.g10code.de> <87ikri4u08.fsf@jacob.g10code.de> <40447028-7a26-4f07-b298-f096d7dc7868@posteo.de> <87v7vh2wba.fsf@jacob.g10code.de> Message-ID: <87h6712gwp.fsf@jacob.g10code.de> On Wed, 18 Dec 2024 11:30, Andrew Gallagher said: > LibrePGP is a specification agreed upon by *two* implementations. If > you arbitrarily include RNP (i.e. Thunderbird) but not openpgp.js > (i.e. Protonmail, Mailvelope, FlowCrypt) in the ?major real world Web stuff which can be replaced in the blink of an eye. Nothing which needs complicated consideration for deployment. Interoperability is not about the number of implementations but about deployed implementations and infrastructure. BTW, the third player are all the big "commercial" and in-house applications which are neither using the old PGP, or RNP, or GnuPG but are using BouncyCastle which supports the LibrePGP specification (or name it rfc4880bis) for many years. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From rainer.perske at uni-muenster.de Mon Dec 23 16:31:10 2024 From: rainer.perske at uni-muenster.de (Rainer Perske) Date: Mon, 23 Dec 2024 16:31:10 +0100 (CET) Subject: --enable-gpg-is-gpg2 broken since 2.4.6 Message-ID: Hello, just for information: When you compile GnuPG 2.4.6 or 2.4.7 with --enable-gpg-is-gpg2, make install fails complaining about missing gpg.1 and gpgv.1. GnuPG 2.4.5 works. (I have seen that you completely remove this option from GnuPG 2.5 so decide yourself whether this is still worth a bug tracker entry.) Best regards and Merry Christmas -- Rainer Perske Systemdienste + Leiter der Zertifizierungsstelle (UCAM) -- Universit?t M?nster CIT - Center for Information Technology Rainer Perske, Systemdienste R?ntgenstra?e 7-13, Raum 006 48149 M?nster Tel.: +49 251 83-31582 E-Mail: rainer.perske at uni-muenster.de Website: www.uni-muenster.de/IT Universit?tszertifizierungsstelle M?nster (UCAM): Tel.: +49 251 83-31590 E-Mail: ca at uni-muenster.de WWW: www.uni-muenster.de/CA YouTube: youtube.com/@uni_muenster Instagram: instagram.com/uni_muenster LinkedIn: linkedin.com/school/university-of-muenster Facebook: facebook.com/unimuenster -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6319 bytes Desc: S/MIME cryptographic signature URL: