Re: draft-ietf-openpgp-rfc4880bis-04

2018-02-02 Thread FuzzyDrawrings via Gnupg-users
I don't know if this is an error in the documentation, but I cannot obtain the sha256 result here: | A.2. Sample EdDSA signature | |The signature is created using the sample key over the input data |"OpenPGP" on 2015-09-16 12:24:53 and thus the input to the hash |function is: | |

Re: draft-ietf-openpgp-rfc4880bis-04

2018-02-03 Thread Tapio Sokura
Hello, On 3.2.2018 7:25, FuzzyDrawrings via Gnupg-users wrote: |m: 4f70656e504750040016080006050255f95f9504ff000c | |Using the SHA2-256 hash algorithm yields the digest: | |d: f6220a3f757814f4c2176ffbb68b00249cd4ccdc059c4b34ad871f30b1740280 I can obtain m, no problem. But fail t

Re: draft-ietf-openpgp-rfc4880bis-04

2018-02-06 Thread Werner Koch
On Sat, 3 Feb 2018 06:25, gnupg-users@gnupg.org said: > I don't know if this is an error in the documentation, but I cannot obtain > the sha256 result here: Using the gpg option --debug hashing will create files with the hashed material. This is often very helful. Shalom-Salam, Wern

Re: draft-ietf-openpgp-rfc4880bis-04

2018-02-08 Thread FuzzyDrawrings via Gnupg-users
It is definitely my error in the m value I was hashing, which I failed to notice was not the same given in the documentation. I somehow repeatedly overlooked the fact that my obtained m value was different and only noticed that d (the hash) mismatch. Oops. Looking more carefully, I see did no

Re: draft-ietf-openpgp-rfc4880bis-04

2018-02-13 Thread Werner Koch
On Fri, 9 Feb 2018 03:18, gnupg-users@gnupg.org said: > ...and that's the end of hashed subpackets. That should be all that is hashed > for the signature, yet there is the remaining octets in m: > > 04ff000c See 5.2.4, Computing Signatures: | V4 signatures also hash in a final trailer of