Re: GPG Signature Verification
This was exactly the issue! I was originally using the bouncy castle
ASN1Encodable library to generate the encoded hash value which for some
reason does not seem to produce the value defined/expected by the PGP.
Instead I now just use ASN1 full hash prefixes defined in the RFC directly
and the issue was resolved.
Very much appreciated Peter!
Thanks,
Paul Taukatch
Advanced Technologies Team / zOS Cloud Crypto
From: Peter Lebbing
To: Paul Taukatch/Poughkeepsie/IBM@IBMUS, gnupg-users@gnupg.org
Date: 04/26/2017 06:24 AM
Subject:Re: GPG Signature Verification
On 24/04/17 19:23, Peter Lebbing wrote:
> The part of "cmp" that would correspond to the constant part of the DER
> encoding I do not recognise.
It is still proper ASN.1, but it encodes a slightly different structure.
I wondered whether it was DER encoded or BER encoded, because I read
that BER was valid for old PKCS#1 v1.5 structures. DER is a subset of
BER. If the Python ASN.1 module pyasn1 rejects malformed DER encoding
then it is proper DER; or would pyasn1 be liberal in what it accepts?
Anyway, the two ASN.1 encoded objects are slightly different:
$ python
[...]
>>> import pyasn1.codec.der.decoder
>>> sha256der = b'\x30\x31\x30\x0d\x06\x09\x60\x86\x48\x01\x65\x03\x04\x02
\x01\x05\x00\x04\x20' + chr(0)*32
>>> unknown_enc=b'\x30\x2f\x30\x0b\x06\x09\x60\x86\x48\x01\x65\x03\x04\x02
\x01\x04\x20'+chr(0)*32
>>> pyasn1.codec.der.decoder.decode(sha256der)
(Sequence().setComponentByPosition(0, Sequence().setComponentByPosition(0,
ObjectIdentifier(2.16.840.1.101.3.4.2.1)).setComponentByPosition(1, Null
(''))).setComponentByPosition(1, OctetString
(hexValue='')),
'')
>>> pyasn1.codec.der.decoder.decode(unknown_enc)
(Sequence().setComponentByPosition(0, Sequence().setComponentByPosition(0,
ObjectIdentifier(2.16.840.1.101.3.4.2.1))).setComponentByPosition(1,
OctetString
(hexValue='')),
'')
There's an extra setComponentByPosition(1, Null('')) in the properly
encoded ASN.1. It would appear that the library you're using *is*
trying to generate a PKCS#1 v1.5 message, but that it ends up with a
slightly different DER encoding than what is defined for OpenPGP. You
will have to find a way to generate a EMSA-PKCS1-v1_5 structure that is
compatible to RFC 4880 (and RFC 3447 PKCS #1 Version 2.1).
I don't know much about ASN.1, so I can't really say anything useful
about the results of the experiment above.
HTH,
Peter.
--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>
[attachment "signature.asc" deleted by Paul Taukatch/Poughkeepsie/IBM]
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GPG Signature Verification
Appreciate the feedback but I have indeed reread the RFC specification
quite thoroughly and still can't seem to figure out the issue. Don't mean
to spam the mailing list but is there any chance someone might have a bit
more insight into this. Quite stumped!
Thanks,
Paul Taukatch
Advanced Technologies Team / zOS Cloud Crypto
From: Kristian Fiskerstrand
To: Paul Taukatch/Poughkeepsie/IBM@IBMUS, gnupg-users@gnupg.org
Date: 04/21/2017 06:29 AM
Subject:Re: GPG Signature Verification
On 04/21/2017 09:16 AM, Kristian Fiskerstrand wrote:
> On 04/20/2017 09:17 PM, Paul Taukatch wrote:
>> I've attached my public key and debug log but please let me know if
there
>> is any other information that might be helpful.
>
> The first reference that springs to mind is [RFC4880] Section 5.2.4.
> Computing Signatures
Of course you already mentioned this in your initial email :) Looks
correct to me.
--
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
"If your kids are giving you a headache, follow the directions on the
aspirin bottle, especially the part that says "keep away from children."
(Neil McElroy)
[attachment "signature.asc" deleted by Paul Taukatch/Poughkeepsie/IBM]
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
GPG Signature Verification
Hello and thank you for taking the time to help out! I am developing my own implementation of the PGP specification and have a question regarding the signature generation/verification for Transferable Public Keys that maybe one of you could help shed some light on. Currently I create a single primary RSA key and userID and bind the two with a certification self-signature (0x13). When importing this certificate into GPG I get a a signature verification failure which prevents the certificate from importing. I've read through the rfc4880, 5.2.4 - Computing Signatures section quite thoroughly and believe I am generating the signature properly - Signing the Hash context of the primary key + user ID + signature data (V4). One thing I notice in the debug info is that the first several few bytes of the rsa_verify data and rsa_verify cmp do not match. DBG: rsa_verify data:+01ff \ DBG: \ DBG:ff0030 31300d06096086480165030402010500042007 \ DBG: 3d952c71b2d7c2c945c60f828f087e1d517774f84fe30825f18709659466e7 DBG: rsa_verify cmp:+01ff \ DBG: \ DBG:ff0030 2f300b0609608648016503040201042007 \ DBG: 3d952c71b2d7c2c945c60f828f087e1d517774f84fe30825f18709659466e7 Does anyone know exactly what this verify data is comprised of? I notice that the hash of the (Primary Key + UserID + Signature Data hash context) = 073D952C71B2D7C2C945C60F828F087E1D517774F84FE30825F18709659466E7 which seems to match for both the verify data and cmp. I've attached my public key and debug log but please let me know if there is any other information that might be helpful. (See attached file: exportZPGPTest.bin)(See attached file: debug.txt) Thanks Again! exportZPGPTest.bin Description: Binary data gpg: NOTE: no default option file `C:/Users/IBM_ADMIN/AppData/Roaming/gnupg/gpg.conf' gpg: enabled debug flags: packet mpi cipher filter iobuf memory cache memstat trust hashing extprog cardio assuan gpg: DBG: fd_cache_open (C:\\cygwin\\home\\Paul\\exportZPGPTest.bin) not cached gpg: DBG: iobuf-1.0: open `C:\\cygwin\\home\\Paul\\exportZPGPTest.bin' fd=216 gpg: DBG: armor-filter: control: 5 gpg: DBG: iobuf-1.1: push `armor_filter' gpg: DBG: armor-filter: control: 5 gpg: DBG: iobuf chain: 1.1 `armor_filter' filter_eof=0 start=0 len=0 gpg: DBG: iobuf chain: 1.0 `file_filter(fd)' filter_eof=0 start=0 len=0 gpg: DBG: armor-filter: control: 1 gpg: DBG: iobuf-1.1: underflow: req=8192 gpg: DBG: armor-filter: control: 3 gpg: DBG: iobuf-1.0: underflow: req=8192 gpg: DBG: iobuf-1.0: underflow: got=489 rc=0 gpg: DBG: iobuf-1.1: underflow: got=339 rc=0 gpg: DBG: parse_packet(iob=1): type=6 length=266 (new_ctb) (parse.../../gnupg2-2.0.30/g10/import.c.426) gpg: DBG: parse_packet(iob=1): type=13 length=33 (new_ctb) (parse.../../gnupg2-2.0.30/g10/import.c.426) gpg: DBG: parse_packet(iob=1): type=2 length=183 (new_ctb) (parse.../../gnupg2-2.0.30/g10/import.c.426) gpg: DBG: iobuf-1.1: underflow: req=8192 gpg: DBG: armor-filter: control: 3 gpg: DBG: iobuf-1.0: underflow: req=8192 gpg: DBG: iobuf-1.0: underflow: got=0 rc=-1 gpg: DBG: C:\\cygwin\\home\\Paul\\exportZPGPTest.bin: close handle 00D8 gpg: DBG: fd_cache_close (C:\\cygwin\\home\\Paul\\exportZPGPTest.bin) new slot created gpg: DBG: iobuf-1.0: underflow: eof gpg: DBG: iobuf-1.1: underflow: got=150 rc=0 gpg: DBG: iobuf-1.1: underflow: req=8192 gpg: DBG: armor-filter: control: 3 gpg: DBG: iobuf-1.0: underflow: eof (due to filter eof) gpg: DBG: iobuf-1.1: underflow: got=0 rc=-1 gpg: DBG: armor-filter: control: 2 gpg: DBG: iobuf-1.1: pop in underflow (!len) gpg: DBG: iobuf chain: 1.0 `[none]' filter_eof=0 start=489 len=489 gpg: DBG: iobuf-1.0: underflow: eof DBG: rsa_verify data:+01ff \ DBG: \ DBG: ff003031300d06096086480165030402010500042007 \ DBG: 3d952c71b2d7c2c945c60f828f087e1d517774f84fe30825f18709659466e7 DBG: rsa_verify sig:+4b51361220fd95fd2a927d40e18408a37d3a2dcad3394afe71e2236181f612a6 \ DBG: 0e425b0cd93c7f0d1039717a86a054f5900519266fd23c09d40944ff9c8ae8e8 \ DBG: 1e40d9aa7e22447503625f7fdb825abb49e4aef939d58ff3678b338c6bcfa8ef \ DBG: 41e5eac439d49a94483e5d923590895b8e6f3b6ae00c5f0c0d5a9dc47cbb8e46 DBG: rsa_verify n:+e2bcdf54bea85f021949eb68eb5641d829b2020d76e6ec224fe41fc5da38ffd5 \ DBG: fc8bd703ae7c2af04155a5896756d5c91fcf9d1fb45c83d74fbeeb1369423e15 \ DBG: 32b26af4d47e354b6761db4a9244bfc7e017c8568ada52e399bd14f3c53e6a6a \ DBG: ffc393c600c
Re: GPG Private Key Export Question
Hey everyone thanks for all the contributions, really helped clear some things up. Was just hoping you could help clarify one more thing. Why exactly are the numerical values for skey[0] and skey[1] equal to pkey[0] and pkey[1]? Is it because the numerical value listed is actually the key value of the entire public/private key pair? If so, is a specific portion of that key value used as the "secret key" and another portion used as the "public key"? Also, is there any command I can use to view the entire contents of the exported secret key packet? Thanks again! On Fri, Sep 27, 2013 at 2:44 PM, Robert J. Hansen wrote: > On 9/27/2013 10:40 AM, Peter Pentchev wrote: > > Also, if you're really writing software for parsing and extracting data > > from OpenPGP keys or messages, then you absolutely *must* start by > > reading RFC 4880, then reading it again, then bookmarking it and keeping > > it always open in a browser window or a text pager, so you can refer to > > it as often as you *will* need to :) > > For the last week I've been writing a parser suitable for filesystem > forensics. All I can say is, "preach it, brother." I printed out > hardcopy of the whole of RFC4880 and have pages from it pinned up to my > cubicle walls. > > There is also a sheet of paper pinned up there that has a red circle > about six inches across and a caption beneath of, "BEAT HEAD HERE." I > find myself referring to that almost as much as I do to RFC4880. > > (Speaking of that project: thank you, Peter and David, for pointing me > towards the file(1) magic numbers library. It works well enough for my > purposes.) > > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GPG Private Key Export Question
Really appreciate the help and the quick response! I just wanted to clarify, where exactly is the public key information stored within the exported secret key data? Is it part of the Secret key packet as part of the "Encrypted stuff follows section" or is following that? I'm currently trying to develop some software and would like to extract the public key value along with the fingerprint/ID information from the exported secret key packet. I'm assuming that when GPG imports such a secret key packet it is able to extract the public key info and able to link it to the corresponding public key (if one exists within the keyring already) or is able to reconstruct and place the public key if it does not already exist. Thanks again, -Paul On Thu, Sep 26, 2013 at 4:53 PM, David Shaw wrote: > On Sep 26, 2013, at 12:54 PM, Paul Taukatch wrote: > > > I had a question regarding exporting a private key using GPG. > > > > I generated a Key pair using GPG 1.4.13 and then used the export command > to export the private key into another file. > > > > Based on the RFC 4880 documentation: > >A Secret-Key packet contains all the information that is found in a > >Public-Key packet, including the public-key material, but also > >includes the secret-key material after all the public-key fields. > > > > But when I --list-packets on the file it does not seem to contain any > information about the public key. So my question is, do GPG private key > packets contain the public key information as specified by the RFC 4880 > documentation? > > Yes. This isn't an actual public key packet - just the contents of the > public key packet at the end of the secret data, so it doesn't show up as a > ":public key packet:" in --list-packets. > > > Also, is there anyway to export a key pair using a single GPG command > into a single file? > > Not exactly, but (at least using GPG) you get the same effect. If you > import a secret key and you don't have the public key, GPG will use the > embedded public key data to recreate the public key, so effectively an > exported secret key is like exporting a key pair. > > > Also, I had a question regarding the Key Fingerprint/Key ID and its > relation to the public/private key pair. While viewing my keys using GPG it > seems that the private key has the same Key ID as the public key. > > Correct. > > > Based on the RFC4880 specifications I know that a fingerprint is > generated by : > > > > A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99, > >followed by the two-octet packet length, followed by the entire > >Public-Key packet starting with the version field. for the secre > > > > My question then is, when I attempt to import my exported secret key, > how is the key fingerprint calculated for the secret key, is it based only > on the "public key packet" portion or is it also based on the secret key > information? > > It's based only on the public key information. > > David > > ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
GPG Private Key Export Question
I had a question regarding exporting a private key using GPG. I generated a Key pair using GPG 1.4.13 and then used the export command to export the private key into another file. Based on the RFC 4880 documentation: A Secret-Key packet contains all the information that is found in a Public-Key packet, including the public-key material, but also includes the secret-key material after all the public-key fields. But when I --list-packets on the file it does not seem to contain any information about the public key. So my question is, do GPG private key packets contain the public key information as specified by the RFC 4880 documentation? Also, is there anyway to export a key pair using a single GPG command into a single file? The following is the out of my private key export using --list-packets: :secret key packet: version 4, algo 1, created 1376423121, expires 0 skey[0]: [2048 bits] skey[1]: [17 bits] iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: 5e4fccb70f72afef protect count: 65536 (96) protect IV: d1 7c 18 34 ab c7 be 14 f6 3d ec 49 86 1e ae 62 encrypted stuff follows :user ID packet: "Testee McTestin (Test All Day) " :signature packet: algo 1, keyid 611F977E042D92BD version 4, created 1376423121, md5len 0, sigclass 0x13 digest algo 2, begin of digest 48 b8 hashed subpkt 2 len 4 (sig created 2013-08-13) hashed subpkt 27 len 1 (key flags: 03) hashed subpkt 11 len 5 (pref-sym-algos: 9 8 7 3 2) hashed subpkt 21 len 5 (pref-hash-algos: 8 2 9 10 11) hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1) hashed subpkt 30 len 1 (features: 01) hashed subpkt 23 len 1 (key server preferences: 80) subpkt 16 len 8 (issuer key ID 611F977E042D92BD) data: [2048 bits] :secret sub key packet: version 4, algo 1, created 1376423121, expires 0 skey[0]: [2048 bits] skey[1]: [17 bits] iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: 5e4fccb70f72afef protect count: 65536 (96) protect IV: 0a 16 bb e5 4a 91 84 0c 34 da 62 c4 2f 66 03 ef encrypted stuff follows :signature packet: algo 1, keyid 611F977E042D92BD version 4, created 1376423121, md5len 0, sigclass 0x18 digest algo 2, begin of digest 79 b1 hashed subpkt 2 len 4 (sig created 2013-08-13) hashed subpkt 27 len 1 (key flags: 0C) subpkt 16 len 8 (issuer key ID 611F977E042D92BD) data: [2048 bits] Also, I had a question regarding the Key Fingerprint/Key ID and its relation to the public/private key pair. While viewing my keys using GPG it seems that the private key has the same Key ID as the public key. Output of editing my key pair using GPG: pub 2048R/042D92BD created: 2013-08-13 expires: never usage: SC trust: ultimate validity: ultimate sub 2048R/87E42A5D created: 2013-08-13 expires: never usage: E [ultimate] (1). Testee McTestin (Test All Day) gpg> toggle sec 2048R/042D92BD created: 2013-08-13 expires: never ssb 2048R/87E42A5D created: 2013-08-13 expires: never (1) Testee McTestin (Test All Day) Based on the RFC4880 specifications I know that a fingerprint is generated by : A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99, followed by the two-octet packet length, followed by the entire Public-Key packet starting with the version field. for the secre My question then is, when I attempt to import my exported secret key, how is the key fingerprint calculated for the secret key, is it based only on the "public key packet" portion or is it also based on the secret key information? Sorry for the very long question and I really appreciate any help on the matter! ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
