* bug#57576: Missing support for NIPT-P384 gpg algorithm in Guix channel authentication.
@ 2022-09-04 11:53 Zhu Zihao
2022-09-05 16:06 ` Ludovic Courtès
0 siblings, 1 reply; 13+ messages in thread
From: Zhu Zihao @ 2022-09-04 11:53 UTC (permalink / raw)
To: 57576
[-- Attachment #1: Type: text/plain, Size: 2874 bytes --]
I'm working with my private channel, And I update my gpg key using
NIPT-P384 algorithm. But `guix time-machine` complains that:
Updating channel 'cireguix' from Git repository at '/home/citreu/gitrepos/cireguix'...
Authenticating channel 'cireguix', commits 9b37ac0 to 6601a6a (1 new commits)...
[###########################################################################################################################################################################################################################################]Backtrace:
In guix/store.scm:
659:37 19 (thunk)
In guix/status.scm:
815:4 18 (call-with-status-report _ _)
In guix/store.scm:
1298:8 17 (call-with-build-handler #<procedure 7f6086416630 at g…> …)
In guix/inferior.scm:
904:34 16 (cached-channel-instance #<store-connection 256.99 7f6…> …)
In guix/channels.scm:
523:7 15 (loop _ _)
In guix/combinators.scm:
48:26 14 (fold2 #<procedure 7f60883758a0 at guix/channels.scm:5…> …)
In guix/channels.scm:
533:29 13 (_ #<<channel> name: cireguix url: "/home/citreu/gitre…> …)
421:12 12 (latest-channel-instance #<store-connection 256.99 7f6…> …)
In guix/git.scm:
290:7 11 (call-with-repository _ #<procedure 7f60883757e0 at gui…>)
In guix/git-authenticate.scm:
442:22 10 (authenticate-repository #<git-repository 861da0> _ _ # …)
In guix/progress.scm:
71:36 9 (call-with-progress-reporter _ _)
In srfi/srfi-1.scm:
460:18 8 (fold #<procedure 7f608943bfc0 at guix/git-authenticat…> …)
In guix/git-authenticate.scm:
290:24 7 (_ #<git-commit 6601a6ab9073cfe260e1563131990c786519a2…> …)
226:4 6 (authenticate-commit #<git-repository 861da0> #<git-co…> …)
129:23 5 (commit-signing-key _ #<oid 6601a6ab9073cfe260e1563131…> …)
In guix/openpgp.scm:
562:26 4 (verify-openpgp-signature _ _ _)
In gcrypt/pk-crypto.scm:
250:8 3 (key-type (unsupported-algorithm 19 #vu8(5 43 129 4 …)))
202:27 2 (_ (unsupported-algorithm 19 #vu8(5 43 129 4 0 34 3 …)) 0)
In ice-9/boot-9.scm:
1685:16 1 (raise-exception _ #:continuable? _)
1685:16 0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): (unsupported-algorithm 19 #vu8(5 43 129 4 0 34 3 3 4 53 239 158 105 250 133 46 247 192 56 245 48 43 60 70 47 46 85 221 226 213 94 248 254 218 85 176 252 233 119 26 85 65 191 47 159 193 86 129 155 186 183 151 233 81 178 42 30 81 234 192 184 140 230 226 26 72 186 82 18 213 187 6 28 34 39 197 75 37 138 226 98 216 187 185 223 222 126 181 122 255 104 171 201 51 254 7 235 245 151 247 168 215 165 73 181))
Does Guix support NIPT-P384 key?
--
Retrieve my PGP public key:
gpg --recv-keys 481F5EEEBA425ADC13247C76A6E672D981B8E744
Zihao
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 300 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread* bug#57576: Missing support for NIPT-P384 gpg algorithm in Guix channel authentication. 2022-09-04 11:53 bug#57576: Missing support for NIPT-P384 gpg algorithm in Guix channel authentication Zhu Zihao @ 2022-09-05 16:06 ` Ludovic Courtès 2022-09-05 16:09 ` [bug#57599] [PATCH] openpgp: Add support for ECDSA with NIST curves Ludovic Courtès 0 siblings, 1 reply; 13+ messages in thread From: Ludovic Courtès @ 2022-09-05 16:06 UTC (permalink / raw) To: Zhu Zihao; +Cc: 57576 Hi, Zhu Zihao <all_but_last@163.com> skribis: > I'm working with my private channel, And I update my gpg key using > NIPT-P384 algorithm. But `guix time-machine` complains that: [...] > 226:4 6 (authenticate-commit #<git-repository 861da0> #<git-co…> …) > 129:23 5 (commit-signing-key _ #<oid 6601a6ab9073cfe260e1563131…> …) > In guix/openpgp.scm: > 562:26 4 (verify-openpgp-signature _ _ _) > In gcrypt/pk-crypto.scm: > 250:8 3 (key-type (unsupported-algorithm 19 #vu8(5 43 129 4 …))) > 202:27 2 (_ (unsupported-algorithm 19 #vu8(5 43 129 4 0 34 3 …)) 0) > In ice-9/boot-9.scm: > 1685:16 1 (raise-exception _ #:continuable? _) > 1685:16 0 (raise-exception _ #:continuable? _) > > ice-9/boot-9.scm:1685:16: In procedure raise-exception: > In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): (unsupported-algorithm 19 #vu8(5 43 129 4 0 34 3 3 4 53 239 158 105 250 133 46 247 192 56 245 48 43 60 70 47 46 85 221 226 213 94 248 254 218 85 176 252 233 119 26 85 65 191 47 159 193 86 129 155 186 183 151 233 81 178 42 30 81 234 192 184 140 230 226 26 72 186 82 18 213 187 6 28 34 39 197 75 37 138 226 98 216 187 185 223 222 126 181 122 255 104 171 201 51 254 7 235 245 151 247 168 215 165 73 181)) > > Does Guix support NIPT-P384 key? Nope! (That’s NIST-P384.) To add it, we need to adjust (guix openpgp) to support it (and ECDSA, the “19” we see above). I’ll follow up with a patch. Ludo’. ^ permalink raw reply [flat|nested] 13+ messages in thread
* [bug#57599] [PATCH] openpgp: Add support for ECDSA with NIST curves. 2022-09-05 16:06 ` Ludovic Courtès @ 2022-09-05 16:09 ` Ludovic Courtès 2022-09-06 11:58 ` Ludovic Courtès 0 siblings, 1 reply; 13+ messages in thread From: Ludovic Courtès @ 2022-09-05 16:09 UTC (permalink / raw) To: 57599; +Cc: Ludovic Courtès, Zhu Zihao, 57576 Fixes <https://issues.guix.gnu.org/57576>. Reported by Zhu Zihao <all_but_last@163.com>. * guix/openpgp.scm (verify-openpgp-signature): Add case for ecdsa. (get-signature): Likewise for PUBLIC-KEY-ECDSA. (get-public-key): Likewise. * tests/keys/secp384.pub, tests/keys/secp384.sec, tests/keys/secp521.pub, tests/keys/secp521.sec: New files. * Makefile.am (EXTRA_DIST): Add them. * tests/openpgp.scm (%secp384-key-id, %secp384-key-fingerprint) (%hello-signature/secp384/sha384) (%secp521-key-id, %secp521-key-fingerprint) (%hello-signature/secp521/sha521): New variables. * tests/openpgp.scm ("get-openpgp-detached-signature/ascii") ("verify-openpgp-signature, good signatures") ("verify-openpgp-signature, bad signature"): Check with the secp384 and secp521 curves. --- Makefile.am | 4 +++ guix/openpgp.scm | 41 +++++++++++++++++++++----- tests/keys/secp384.pub | 11 +++++++ tests/keys/secp384.sec | 12 ++++++++ tests/keys/secp521.pub | 13 +++++++++ tests/keys/secp521.sec | 14 +++++++++ tests/openpgp.scm | 66 +++++++++++++++++++++++++++++++++++------- 7 files changed, 143 insertions(+), 18 deletions(-) create mode 100644 tests/keys/secp384.pub create mode 100644 tests/keys/secp384.sec create mode 100644 tests/keys/secp521.pub create mode 100644 tests/keys/secp521.sec diff --git a/Makefile.am b/Makefile.am index a0c4e941c1..71c3bd4a98 100644 --- a/Makefile.am +++ b/Makefile.am @@ -702,6 +702,10 @@ EXTRA_DIST += \ tests/keys/ed25519-2.sec \ tests/keys/ed25519-3.pub \ tests/keys/ed25519-3.sec \ + tests/keys/secp384.pub \ + tests/keys/secp384.sec \ + tests/keys/secp521.pub \ + tests/keys/secp521.sec \ build-aux/config.rpath \ bootstrap \ doc/build.scm \ diff --git a/guix/openpgp.scm b/guix/openpgp.scm index 9de7feb644..b999c30474 100644 --- a/guix/openpgp.scm +++ b/guix/openpgp.scm @@ -1,6 +1,6 @@ ;; -*- mode: scheme; coding: utf-8 -*- ;; Copyright © 2010, 2012 Göran Weinholt <goran@weinholt.se> -;; Copyright © 2020 Ludovic Courtès <ludo@gnu.org> +;; Copyright © 2020, 2022 Ludovic Courtès <ludo@gnu.org> ;; Permission is hereby granted, free of charge, to any person obtaining a ;; copy of this software and associated documentation files (the "Software"), @@ -290,7 +290,7 @@ (define PUBLIC-KEY-RSA-SIGN-ONLY 3) (define PUBLIC-KEY-ELGAMAL-ENCRYPT-ONLY 16) (define PUBLIC-KEY-DSA 17) (define PUBLIC-KEY-ECDH 18) ;RFC-6637 -(define PUBLIC-KEY-ECDSA 19) ;RFC-6639 +(define PUBLIC-KEY-ECDSA 19) ;RFC-6637 (define PUBLIC-KEY-ELGAMAL 20) ;encrypt + sign (legacy) (define PUBLIC-KEY-EDDSA 22) ;"not yet assigned" says GPG @@ -298,6 +298,7 @@ (define (public-key-algorithm id) (cond ((= id PUBLIC-KEY-RSA) 'rsa) ((= id PUBLIC-KEY-DSA) 'dsa) ((= id PUBLIC-KEY-ELGAMAL-ENCRYPT-ONLY) 'elgamal) + ((= id PUBLIC-KEY-ECDSA) 'ecdsa) ((= id PUBLIC-KEY-EDDSA) 'eddsa) (else id))) @@ -564,10 +565,16 @@ (define (check key sig) ;; See "(gcrypt) Cryptographic Functions". (sexp->canonical-sexp (if (eq? key-type 'ecc) - `(data - (flags eddsa) - (hash-algo sha512) - (value ,hash)) + (match (openpgp-signature-public-key-algorithm sig) + ('eddsa + `(data + (flags eddsa) + (hash-algo sha512) + (value ,hash))) + ('ecdsa + `(data + (hash-algo ,(openpgp-signature-hash-algorithm sig)) + (value ,hash)))) `(data (flags ,(match key-type ('rsa 'pkcs1) @@ -615,7 +622,8 @@ (define (get-sig p pkalg) (string->canonical-sexp (format #f "(sig-val (dsa (r #~a#) (s #~a#)))" (->hex r) (->hex s))))) - ((= pkalg PUBLIC-KEY-EDDSA) + ((or (= pkalg PUBLIC-KEY-EDDSA) + (= pkalg PUBLIC-KEY-ECDSA)) (print "EdDSA signature") (let ((r (get-mpi/bytevector p)) (s (get-mpi/bytevector p))) @@ -630,7 +638,8 @@ (define (bytevector->hex bv) str))) (string->canonical-sexp - (format #f "(sig-val (eddsa (r #~a#) (s #~a#)))" + (format #f "(sig-val (~a (r #~a#) (s #~a#)))" + (public-key-algorithm pkalg) (bytevector->hex r) (bytevector->hex s))))) (else (list 'unsupported-algorithm @@ -886,6 +895,22 @@ (define curve curve (if (eq? curve 'Curve25519) 'djb-tweak 'eddsa) (->hex q))))) + ((= alg PUBLIC-KEY-ECDSA) + (print "Public ECDSA key") + (let* ((len (get-u8 p)) + (oid (bytevector->uint (get-bytevector-n p len))) + (q (get-mpi p))) + (define curve + ;; RFC 6637, Section 11. + (match oid + (#x2a8648ce3d030107 "NIST P-256") + (#x2b81040022 "NIST P-384") + (#x2b81040023 "NIST P-521"))) + + (string->canonical-sexp + (format #f "(public-key (ecc (curve \"~a\")(q #~a#)))" + curve + (->hex q))))) (else (list 'unsupported-algorithm ;FIXME: throw (public-key-algorithm alg) diff --git a/tests/keys/secp384.pub b/tests/keys/secp384.pub new file mode 100644 index 0000000000..b90cf504e2 --- /dev/null +++ b/tests/keys/secp384.pub @@ -0,0 +1,11 @@ +-----BEGIN PGP PUBLIC KEY BLOCK----- + +mG8EYxYF9RMFK4EEACIDAwTHYxcyBiiPz4ZZIkmXnVu0Yv9DHGrnbdCR6U/RT1S4 +wszaHdsSEHlPwmy3WGgTubBDOuJODf5kV/HLL7QEPsOTkIsObK+prEJO3CGpRVim +a7nfVk2AH6D/GMkNacSXdwy0FTxleGFtcGxlQGV4YW1wbGUuY29tPoiwBBMTCQA4 +AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAFiEEzLZ9Sx8EBzgp+PzwLydGMf8+ +bFsFAmMWB+sACgkQLydGMf8+bFuD3gF/SMEDQP3Bvu0yb8KxE6j8lhOiKT186wwG +4hBsifRdEF+UHWEa7sx74tyc4R1B01FUAYC/4QqNup4EnPzQfSE3WyVvu+ja+xui +3vppYCpUjkHzkATsLzsN98/nkZ3q3YA8/lo= +=vIaC +-----END PGP PUBLIC KEY BLOCK----- diff --git a/tests/keys/secp384.sec b/tests/keys/secp384.sec new file mode 100644 index 0000000000..ae296dd9a1 --- /dev/null +++ b/tests/keys/secp384.sec @@ -0,0 +1,12 @@ +-----BEGIN PGP PRIVATE KEY BLOCK----- + +lKQEYxYF9RMFK4EEACIDAwTHYxcyBiiPz4ZZIkmXnVu0Yv9DHGrnbdCR6U/RT1S4 +wszaHdsSEHlPwmy3WGgTubBDOuJODf5kV/HLL7QEPsOTkIsObK+prEJO3CGpRVim +a7nfVk2AH6D/GMkNacSXdwwAAYC9iXZ9j+RWFB4rU103SCv6j68rS5Lmc7tHve9l +B5nri/AR+OEJ61q+w6w0XO5GBBUYLrQVPGV4YW1wbGVAZXhhbXBsZS5jb20+iLAE +ExMJADgCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AWIQTMtn1LHwQHOCn4/PAv +J0Yx/z5sWwUCYxYH6wAKCRAvJ0Yx/z5sW4PeAX9IwQNA/cG+7TJvwrETqPyWE6Ip +PXzrDAbiEGyJ9F0QX5QdYRruzHvi3JzhHUHTUVQBgL/hCo26ngSc/NB9ITdbJW+7 +6Nr7G6Le+mlgKlSOQfOQBOwvOw33z+eRnerdgDz+Wg== +=B1Nl +-----END PGP PRIVATE KEY BLOCK----- diff --git a/tests/keys/secp521.pub b/tests/keys/secp521.pub new file mode 100644 index 0000000000..077e8e7df2 --- /dev/null +++ b/tests/keys/secp521.pub @@ -0,0 +1,13 @@ +-----BEGIN PGP PUBLIC KEY BLOCK----- + +mJMEYxYamRMFK4EEACMEIwQB4EqA0zTAfhLeVjkNnzvTuSYs+TUlYdDaw9mYA7Gy +AiNvxr2F1hJi88Wxxr3YNGKx9s0yJ2Vl0dHlCLmlQAFc9MMACZKWZN68mqbYfSVf +qJxSG5F8qbF0+dGecwY+TjM4xdaUk4d0vD13/e+r/HLYNgwKrpO2SurNZX/isfkn +rvNSHPi0HTxleGFtcGxlLXNlY3A1MjFAZXhhbXBsZS5jb20+iNoEExMKAD4WIQQ7 +r36YQGm2cfPDEWnoSxOgtOevGwUCYxYamQIbAwUJA8JnAAULCQgHAgYVCgkICwIE +FgIDAQIeAQIXgAAKCRDoSxOgtOevG4GUAgkBN118FBDW896Iv+2U/29Fpfni4V6D +Vp6HTE5qAqmJUtKOOSxmDAmiJ4sinybTP4YCLQT9fmMQqrJSSY0d/hVg4fYCCQGD +Y6iRT8KPyxhlpsVVwdiUjOd4B5JUyJj0qOudY4yveyOl6c1bdxJALMbEHV4JREEE +1+ylYN1KRfpaQh42Zoms9Q== +=Nru3 +-----END PGP PUBLIC KEY BLOCK----- diff --git a/tests/keys/secp521.sec b/tests/keys/secp521.sec new file mode 100644 index 0000000000..663dbeaa3c --- /dev/null +++ b/tests/keys/secp521.sec @@ -0,0 +1,14 @@ +-----BEGIN PGP PRIVATE KEY BLOCK----- + +lNoEYxYamRMFK4EEACMEIwQB4EqA0zTAfhLeVjkNnzvTuSYs+TUlYdDaw9mYA7Gy +AiNvxr2F1hJi88Wxxr3YNGKx9s0yJ2Vl0dHlCLmlQAFc9MMACZKWZN68mqbYfSVf +qJxSG5F8qbF0+dGecwY+TjM4xdaUk4d0vD13/e+r/HLYNgwKrpO2SurNZX/isfkn +rvNSHPgAAgkBRPFeWJ3ZROkkbV7/dF8Z4LN6hlrSHWWS2sZmKxZprQy/j48eqWZz +6eY9IvDxfP9ATpfummdgrjexVqA3o3/wr00h/LQdPGV4YW1wbGUtc2VjcDUyMUBl +eGFtcGxlLmNvbT6I0gQTEwoAOAIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYh +BDuvfphAabZx88MRaehLE6C0568bBQJjFhroAAoJEOhLE6C0568bQl0CCNYMV2uF +6LA4GF8RchFQee4ZZo8aquEQ7t7a6NDBc1TbVkGLR+TWxkomEytp5EUoEEU2cNtg +TWRvti3aZvTbEMvdAgijAGTSiO3q5kjprGu1C35oc2JWj0q66XzHEJ0aEiTMQNrz +sJReJPQRmMnBTtzjJCmNPws/VYSEs26m36QCqePtwQ== +=/mn1 +-----END PGP PRIVATE KEY BLOCK----- diff --git a/tests/openpgp.scm b/tests/openpgp.scm index 1f20466772..68439f7485 100644 --- a/tests/openpgp.scm +++ b/tests/openpgp.scm @@ -1,5 +1,5 @@ ;;; GNU Guix --- Functional package management for GNU -;;; Copyright © 2020 Ludovic Courtès <ludo@gnu.org> +;;; Copyright © 2020, 2022 Ludovic Courtès <ludo@gnu.org> ;;; ;;; This file is part of GNU Guix. ;;; @@ -63,7 +63,7 @@ (define %civodul-key-id #x090B11993D9AEBB5) ;civodul.pub #| Test keys in ./tests/keys. They were generated in a container along these lines: - guix environment -CP --ad-hoc gnupg pinentry coreutils + guix shell -CP-hoc gnupg pinentry coreutils then, within the container: mkdir ~/.gnupg && chmod -R og-rwx ~/.gnupg gpg --batch --passphrase '' --quick-gen-key '<example@example.com>' ed25519 @@ -75,6 +75,8 @@ (define %civodul-key-id #x090B11993D9AEBB5) ;civodul.pub (define %rsa-key-id #xAE25DA2A70DEED59) ;rsa.pub (define %dsa-key-id #x587918047BE8BD2C) ;dsa.pub (define %ed25519-key-id #x771F49CBFAAE072D) ;ed25519.pub +(define %secp384-key-id #x2F274631FF3E6C5B) ;secp384.pub +(define %secp521-key-id #xE84B13A0B4E7AF1B) ;secp521.pub (define %rsa-key-fingerprint (base16-string->bytevector @@ -85,6 +87,12 @@ (define %dsa-key-fingerprint (define %ed25519-key-fingerprint (base16-string->bytevector (string-downcase "44D31E21AF7138F9B632280A771F49CBFAAE072D"))) +(define %secp384-key-fingerprint + (base16-string->bytevector + (string-downcase "CCB67D4B1F04073829F8FCF02F274631FF3E6C5B"))) +(define %secp521-key-fingerprint + (base16-string->bytevector + (string-downcase "3BAF7E984069B671F3C31169E84B13A0B4E7AF1B"))) \f ;;; The following are detached signatures created commands like: @@ -148,6 +156,28 @@ (define %hello-signature/ed25519/sha1 ;digest-algo: sha1 =AE4G -----END PGP SIGNATURE-----") +(define %hello-signature/secp384/sha384 ;digest-algo: sha384 + "\ +-----BEGIN PGP SIGNATURE----- + +iJUEABMJAB0WIQTMtn1LHwQHOCn4/PAvJ0Yx/z5sWwUCYxYIKAAKCRAvJ0Yx/z5s +WxD2AX0QMeTHLJvJxRKTBP8O9kGMY9Nz0kzRBO0OJG2gYyxu9sZ+NAEQF01jAOXl +ApL2zVkBgLUyyleJtR24LKxK73waLJb51TA29NXJJZ2fiRZ50u/lNfrFR3PYnK7/ +gvSkL3Ldzw== +=+7h3 +-----END PGP SIGNATURE-----") + +(define %hello-signature/secp521/sha512 + "\ +-----BEGIN PGP SIGNATURE----- + +iLcEABMKAB0WIQQ7r36YQGm2cfPDEWnoSxOgtOevGwUCYxYb+wAKCRDoSxOgtOev +G+ByAgdwIBTnCtzo+lFuahhMMScXZZeTH055IOhTsXmptZaE3MaazTsUw3en8C9i +EWiy/GDQKaJEZMP3dwN1+3tNTl/NUAIIiV/BFly9Ha/cYJG+p3LG24JoHVfJx04q +LfSXejfMIvu33h8wjMA2tRQSlqdDylMWKThJgp6GH6svp+Zr4z+Smnw= +=1zW0 +-----END PGP SIGNATURE-----") + \f (test-begin "openpgp") @@ -193,7 +223,9 @@ (define %hello-signature/ed25519/sha1 ;digest-algo: sha1 `(,%rsa-key-id ,%rsa-key-fingerprint rsa sha256) `(,%ed25519-key-id ,%ed25519-key-fingerprint eddsa sha256) `(,%ed25519-key-id ,%ed25519-key-fingerprint eddsa sha512) - `(,%ed25519-key-id ,%ed25519-key-fingerprint eddsa sha1)) + `(,%ed25519-key-id ,%ed25519-key-fingerprint eddsa sha1) + `(,%secp384-key-id ,%secp384-key-fingerprint ecdsa sha384) + `(,%secp521-key-id ,%secp521-key-fingerprint ecdsa sha512)) (map (lambda (str) (let ((signature (get-openpgp-detached-signature/ascii (open-input-string str)))) @@ -205,7 +237,9 @@ (define %hello-signature/ed25519/sha1 ;digest-algo: sha1 %hello-signature/rsa %hello-signature/ed25519/sha256 %hello-signature/ed25519/sha512 - %hello-signature/ed25519/sha1))) + %hello-signature/ed25519/sha1 + %hello-signature/secp384/sha384 + %hello-signature/secp521/sha512))) (test-equal "verify-openpgp-signature, missing key" `(missing-key ,%rsa-key-fingerprint) @@ -221,7 +255,9 @@ (define %hello-signature/ed25519/sha1 ;digest-algo: sha1 (good-signature ,%dsa-key-id) (good-signature ,%ed25519-key-id) (good-signature ,%ed25519-key-id) - (good-signature ,%ed25519-key-id)) + (good-signature ,%ed25519-key-id) + (good-signature ,%secp384-key-id) + (good-signature ,%secp521-key-id)) (map (lambda (key signature) (let* ((key (search-path %load-path key)) (keyring (get-openpgp-keyring @@ -235,18 +271,24 @@ (define %hello-signature/ed25519/sha1 ;digest-algo: sha1 (list "tests/keys/rsa.pub" "tests/keys/dsa.pub" "tests/keys/ed25519.pub" "tests/keys/ed25519.pub" - "tests/keys/ed25519.pub") + "tests/keys/ed25519.pub" + "tests/keys/secp384.pub" + "tests/keys/secp521.pub") (list %hello-signature/rsa %hello-signature/dsa %hello-signature/ed25519/sha256 %hello-signature/ed25519/sha512 - %hello-signature/ed25519/sha1))) + %hello-signature/ed25519/sha1 + %hello-signature/secp384/sha384 + %hello-signature/secp521/sha512))) (test-equal "verify-openpgp-signature, bad signature" `((bad-signature ,%rsa-key-id) (bad-signature ,%dsa-key-id) (bad-signature ,%ed25519-key-id) (bad-signature ,%ed25519-key-id) - (bad-signature ,%ed25519-key-id)) + (bad-signature ,%ed25519-key-id) + (bad-signature ,%secp384-key-id) + (bad-signature ,%secp521-key-id)) (let ((keyring (fold (lambda (key keyring) (let ((key (search-path %load-path key))) (get-openpgp-keyring @@ -256,7 +298,9 @@ (define %hello-signature/ed25519/sha1 ;digest-algo: sha1 %empty-keyring '("tests/keys/rsa.pub" "tests/keys/dsa.pub" "tests/keys/ed25519.pub" "tests/keys/ed25519.pub" - "tests/keys/ed25519.pub")))) + "tests/keys/ed25519.pub" + "tests/keys/secp384.pub" + "tests/keys/secp521.pub")))) (map (lambda (signature) (let ((signature (string->openpgp-packet signature))) (let-values (((status key) @@ -266,6 +310,8 @@ (define %hello-signature/ed25519/sha1 ;digest-algo: sha1 (list %hello-signature/rsa %hello-signature/dsa %hello-signature/ed25519/sha256 %hello-signature/ed25519/sha512 - %hello-signature/ed25519/sha1)))) + %hello-signature/ed25519/sha1 + %hello-signature/secp384/sha384 + %hello-signature/secp521/sha512)))) (test-end "openpgp") base-commit: aae98c297214f87eb45302863adb021078c41a6f -- 2.37.2 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* [bug#57599] [PATCH] openpgp: Add support for ECDSA with NIST curves. 2022-09-05 16:09 ` [bug#57599] [PATCH] openpgp: Add support for ECDSA with NIST curves Ludovic Courtès @ 2022-09-06 11:58 ` Ludovic Courtès 2022-09-06 15:26 ` bug#57576: bug#57599: " Zhu Zihao 2022-09-06 16:10 ` Maxime Devos 0 siblings, 2 replies; 13+ messages in thread From: Ludovic Courtès @ 2022-09-06 11:58 UTC (permalink / raw) To: 57599; +Cc: 57576, Zhu Zihao Hi, ECDSA and the NIST curves (and in fact a large part of NIST’s crypto standardization work¹) are actually considered with skepticism by some: https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm#Concerns That makes me wonder whether supporting them is a good idea, after all. Evidently they’re not widely used in OpenPGP and not supporting them hasn’t been much of a problem, it seems. On one hand, we don’t want Guix’s OpenPGP implementation to limit what users do with their OpenPGP keys; on the other hand, we don’t want to encourage algorithms that bring little to the table at best and are suspicious at worst. What do people think? Ludo’. ¹ https://blog.cr.yp.to/20220805-nsa.html ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#57576: bug#57599: [PATCH] openpgp: Add support for ECDSA with NIST curves. 2022-09-06 11:58 ` Ludovic Courtès @ 2022-09-06 15:26 ` Zhu Zihao 2022-09-06 16:10 ` Maxime Devos 1 sibling, 0 replies; 13+ messages in thread From: Zhu Zihao @ 2022-09-06 15:26 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 57576, 57599 My opinion: Maybe NSA recommend NIST family because they know how to get around it. But they also have to believe foreign government can't break it easily. -- Retrieve my PGP public key: gpg --recv-keys 481F5EEEBA425ADC13247C76A6E672D981B8E744 Zihao ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#57576: bug#57599: [PATCH] openpgp: Add support for ECDSA with NIST curves. 2022-09-06 11:58 ` Ludovic Courtès 2022-09-06 15:26 ` bug#57576: bug#57599: " Zhu Zihao @ 2022-09-06 16:10 ` Maxime Devos 2022-09-06 20:02 ` Ludovic Courtès 1 sibling, 1 reply; 13+ messages in thread From: Maxime Devos @ 2022-09-06 16:10 UTC (permalink / raw) To: Ludovic Courtès, 57599; +Cc: 57576, Zhu Zihao [-- Attachment #1.1.1: Type: text/plain, Size: 2720 bytes --] On 06-09-2022 13:58, Ludovic Courtès wrote: > Hi, > > ECDSA and the NIST curves (and in fact a large part of NIST’s crypto > standardization work¹) are actually considered with skepticism by some: > > https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm#Concerns > > That makes me wonder whether supporting them is a good idea, after all. > Evidently they’re not widely used in OpenPGP and not supporting them > hasn’t been much of a problem, it seems. On one hand, we don’t want > Guix’s OpenPGP implementation to limit what users do with their OpenPGP > keys; on the other hand, we don’t want to encourage algorithms that > bring little to the table at best and are suspicious at worst. > > What do people think? We disallow signing with SHA-1, because it is known to be vulnerable and as there are alternatives that are considered good, even if this limits what users can do with their OpenPGP keys. In case of those curves, I'm not aware of any 'crytopgraphic proof' (*) that the curves are vulnerable (unlike for SHA-1), but as noted in ¹ and elsewhere, there are other kinds of evidence that something is wrong. Except for the different nature of the evidence of vulnerability, it seems about the same situation to me. As such, I don't think we should support them (some nice error messages like 'This algorithm [...] is not supported yet’ or ‘This algorithm [...] is (likely/known to be) vulnerable’ would be good though!). (*) I mean proof, like in mathematical proofs, not merely evidence. An alternative option would be to allow the channel .guix-authorization (of the previous commits, not the commit that is about to be verified!) to decide what's considered a 'good algorithm' (with some defaults) (with a field). Maybe we'll have to deprecate, say, RSA or SHA-3 eventually, it would be nice to have a migration method in place as early as possible, to minimise the risk of some people doing a "guix pull" from a Guix that does not support that field to a Guix or other channel that _does_ use that field. Zhu Zihao wrote: > My opinion: Maybe NSA recommend NIST family because they know how to get > around it. If so, I believe this is an argument against allowing these curves, to avoid a method NSA could use for attacks. > But they also have to believe foreign government can't break > it easily. For people outside the US, the US (of which the NSA is an agency) _is_ a foreign government. As Guix is not an US-specific project, I do not think this is an argument for allowing the curves. Greetings, Maxime. > Ludo’. > > ¹ https://blog.cr.yp.to/20220805-nsa.html > > [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 929 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 236 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#57576: bug#57599: [PATCH] openpgp: Add support for ECDSA with NIST curves. 2022-09-06 16:10 ` Maxime Devos @ 2022-09-06 20:02 ` Ludovic Courtès 2022-09-07 10:34 ` Andreas Enge 2022-09-07 11:13 ` [bug#57599] " Maxime Devos 0 siblings, 2 replies; 13+ messages in thread From: Ludovic Courtès @ 2022-09-06 20:02 UTC (permalink / raw) To: Maxime Devos; +Cc: 57576, 57599, Zhu Zihao, Andreas Enge Hi, (Cc’ing Andreas for extra advice.) Maxime Devos <maximedevos@telenet.be> skribis: > We disallow signing with SHA-1, because it is known to be vulnerable > and as there are alternatives that are considered good, even if this > limits what users can do with their OpenPGP keys. Right, we know it’s affordable to break SHA-1 these days. > In case of those curves, I'm not aware of any 'crytopgraphic proof' > (*) that the curves are vulnerable (unlike for SHA-1), but as noted in > ¹ and elsewhere, there are other kinds of evidence that something is > wrong. It’s different from SHA-1 though: ECDSA is not known to be vulnerable, and AIUI we can’t tell that there’s a possibility NIST/NSA has a backdoor as is the case for DualEC. However, the whole NIST design process is tainted. So my understanding is that it’s really a gray area. > Except for the different nature of the evidence of vulnerability, it > seems about the same situation to me. As such, I don't think we should > support them (some nice error messages like 'This algorithm [...] is > not supported yet’ or ‘This algorithm [...] is (likely/known to be) > vulnerable’ would be good though!). Yes, that we can improve. :-) > An alternative option would be to allow the channel > .guix-authorization (of the previous commits, not the commit that is > about to be verified!) to decide what's considered a 'good algorithm' > (with some defaults) (with a field). Maybe we'll have to deprecate, > say, RSA or SHA-3 eventually, it would be nice to have a migration > method in place as early as possible, to minimise the risk of some > people doing a "guix pull" from a Guix that does not support that > field to a Guix or other channel that _does_ use that field. It’s tempting, but I’d rather avoid introducing such mechanisms to keep things as simple as possible. Thanks, Ludo’. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#57576: bug#57599: [PATCH] openpgp: Add support for ECDSA with NIST curves. 2022-09-06 20:02 ` Ludovic Courtès @ 2022-09-07 10:34 ` Andreas Enge 2022-09-07 11:13 ` [bug#57599] " Maxime Devos 1 sibling, 0 replies; 13+ messages in thread From: Andreas Enge @ 2022-09-07 10:34 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 57599, Maxime Devos, Zhu Zihao, 57576 Hello, Am Tue, Sep 06, 2022 at 10:02:55PM +0200 schrieb Ludovic Courtès: > (Cc’ing Andreas for extra advice.) well, I agree with your analysis. There is no concrete evidence that the NIST curves may be flawed, and a general belief that not all crypto standards of NIST are flawed or backdoored... So it makes sense to accept the curves, but ultimately this is a political decision (and a personal decision about which type of key a user creates). Andreas ^ permalink raw reply [flat|nested] 13+ messages in thread
* [bug#57599] bug#57576: bug#57599: [PATCH] openpgp: Add support for ECDSA with NIST curves. 2022-09-06 20:02 ` Ludovic Courtès 2022-09-07 10:34 ` Andreas Enge @ 2022-09-07 11:13 ` Maxime Devos 2022-09-07 12:02 ` Andreas Enge 1 sibling, 1 reply; 13+ messages in thread From: Maxime Devos @ 2022-09-07 11:13 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 57576, 57599, Zhu Zihao, Andreas Enge [-- Attachment #1.1.1.1: Type: text/plain, Size: 2266 bytes --] On 06-09-2022 22:02, Ludovic Courtès wrote: >> In case of those curves, I'm not aware of any 'crytopgraphic proof' >> (*) that the curves are vulnerable (unlike for SHA-1), but as noted in >> ¹ and elsewhere, there are other kinds of evidence that something is >> wrong. > It’s different from SHA-1 though: ECDSA is not known to be vulnerable, > and AIUI we can’t tell that there’s a possibility NIST/NSA has a > backdoor as is the case for DualEC. However, the whole NIST design > process is tainted. So my understanding is that it’s really a gray > area. In cryptography (and security), being a grey area and not known to be vulnerable is not sufficient -- rather, there has to be a reason for confidence that that the crypto is actually good and not-vulnerable for a decent amount of time. Or, in other words, in cryptography and security there is no assumption of innocence -- rather, it starts with the assumption that anyone might be an attacker and whoever proposes a crypto thing has to convince others that their crypto is secure, and a communication party has to proof to the other party that they aren't an imposter (public key signing, with an previously agreed on key and algorithm). Andreas wrote: > well, I agree with your analysis. There is no concrete evidence that the > NIST curves may be flawed, and a general belief that not all crypto > standards of NIST are flawed or backdoored... So it makes sense to accept > the curves, (and a personal decision about which type of key a user creates). I followed you right until the conclusion, it appears that you are starting from an assumption of innocence, which might explain our different conclusions? Also, we _do_ have concrete evidence that the curves are flawed -- the website on the link mentions many issues in the process and it has been shown in the past that the NSA is in the habit of subverting communications (*). (*) I can give some sources if you don't know of them already. Channels are for sharing things between multiple people. The keys are for authenticating channels. As multiple people are involved for a channel, this seems be be a non-personal decision by definition. Greetings, Maxime. [-- Attachment #1.1.1.2: Type: text/html, Size: 3026 bytes --] [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 929 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 236 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#57576: bug#57599: [PATCH] openpgp: Add support for ECDSA with NIST curves. 2022-09-07 11:13 ` [bug#57599] " Maxime Devos @ 2022-09-07 12:02 ` Andreas Enge 2022-09-07 12:51 ` Ludovic Courtès 0 siblings, 1 reply; 13+ messages in thread From: Andreas Enge @ 2022-09-07 12:02 UTC (permalink / raw) To: Maxime Devos; +Cc: 57576, Ludovic Courtès, 57599, Zhu Zihao Am Wed, Sep 07, 2022 at 01:13:25PM +0200 schrieb Maxime Devos: > Also, we _do_ have concrete evidence that the curves are flawed -- the website > on the link mentions many issues in the process The website (you mean the blog by D. Bernstein?) also mentions the use of a hash function to arrive at the parameters. Maybe I overlooked something, but I did not find other mentions of the curves (but I did not read the page from A to Z). > past that the NSA is in the habit of subverting communications. But this is not concrete evidence that these curves are flawed. As far as is publicly known, there are a few weak (and sparse) classes of insecure elliptic curves, and the NIST curves do not belong to them. So the only way these curves could be flawed is that there is an unknown class of insecure curves, where the insecurity is known by the NSA. Then if this class is sufficiently dense, one could start with a random seed, hash the seed, and repeat until one obtains a weak instance; see this link by a well-known cryptologist https://miracl.com/blog/backdoors-in-nist-elliptic-curves/ and the link given there (to another post by Bernstein). This is possible, but speculation instead of evidence. Newer constructions are better, but not perfect; optimally one would want a process of "generation of public random numbers" as described here: https://eprint.iacr.org/2015/366 > Channels are for sharing things between multiple people. The keys are for > authenticating channels. As multiple people are involved for a channel, this > seems be be a non-personal decision by definition. I said "political", which fits well the setting of multiple people involved. And I meant this in opposition to "scientific", given the lack of evidence against the NIST curves. Andreas ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#57576: bug#57599: [PATCH] openpgp: Add support for ECDSA with NIST curves. 2022-09-07 12:02 ` Andreas Enge @ 2022-09-07 12:51 ` Ludovic Courtès 2022-09-07 15:27 ` zimoun 2022-09-24 9:53 ` Ludovic Courtès 0 siblings, 2 replies; 13+ messages in thread From: Ludovic Courtès @ 2022-09-07 12:51 UTC (permalink / raw) To: Andreas Enge; +Cc: 57599, Maxime Devos, Zhu Zihao, 57576 Hi, Thanks a lot for the explanations, Andreas! As you write, the decision will be “political” as there’s no scientific evidence to guide us. I’d like to see what other free software OpenPGP implementors decided (primarily Sequoia; GnuPG/Libgcrypt implement them). Ludo’. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#57576: bug#57599: [PATCH] openpgp: Add support for ECDSA with NIST curves. 2022-09-07 12:51 ` Ludovic Courtès @ 2022-09-07 15:27 ` zimoun 2022-09-24 9:53 ` Ludovic Courtès 1 sibling, 0 replies; 13+ messages in thread From: zimoun @ 2022-09-07 15:27 UTC (permalink / raw) To: Ludovic Courtès, Andreas Enge; +Cc: Maxime Devos, 57599, Zhu Zihao, 57576 Hi, On Wed, 07 Sep 2022 at 14:51, Ludovic Courtès <ludo@gnu.org> wrote: > I’d like to see what other free software OpenPGP implementors decided > (primarily Sequoia; GnuPG/Libgcrypt implement them). Maybe related <https://sequoia-pgp.org/status/>. Cheers, simon ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#57576: bug#57599: [PATCH] openpgp: Add support for ECDSA with NIST curves. 2022-09-07 12:51 ` Ludovic Courtès 2022-09-07 15:27 ` zimoun @ 2022-09-24 9:53 ` Ludovic Courtès 1 sibling, 0 replies; 13+ messages in thread From: Ludovic Courtès @ 2022-09-24 9:53 UTC (permalink / raw) To: 57599-done; +Cc: 57576, Andreas Enge, Maxime Devos, Zhu Zihao Hi! All things considered, I prefer to drop this patch. In the unlikely event that we’ll get more requests to support these curves, we can always revisit the issue. What we should do, though, is improve error reporting in case an unsupported curve or algorithm is encountered. Thanks, Ludo’. ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2022-09-24 9:54 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-09-04 11:53 bug#57576: Missing support for NIPT-P384 gpg algorithm in Guix channel authentication Zhu Zihao 2022-09-05 16:06 ` Ludovic Courtès 2022-09-05 16:09 ` [bug#57599] [PATCH] openpgp: Add support for ECDSA with NIST curves Ludovic Courtès 2022-09-06 11:58 ` Ludovic Courtès 2022-09-06 15:26 ` bug#57576: bug#57599: " Zhu Zihao 2022-09-06 16:10 ` Maxime Devos 2022-09-06 20:02 ` Ludovic Courtès 2022-09-07 10:34 ` Andreas Enge 2022-09-07 11:13 ` [bug#57599] " Maxime Devos 2022-09-07 12:02 ` Andreas Enge 2022-09-07 12:51 ` Ludovic Courtès 2022-09-07 15:27 ` zimoun 2022-09-24 9:53 ` Ludovic Courtès
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/guix.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.