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
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
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
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
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:
|
|
