Hello,
I've been recently analyzing EdDSA signatures and found one interesting
case. Not sure if I did my analysis correctly or if that's a bug in the
beta but I'd be really glad if someone helped me to understand what's
happening.
One signature piqued my interest. It's attached to this e-mail:
https://lists.gnupg.org/pipermail/gnupg-devel/2021-February/034715.html
The relevant portion of the signature that looks suspicious is the
"EdDSA value s, in MPI" [0] at the end (00000055):
00000031 9b digest_prefix1
00000032 5b digest_prefix2
00000033 00 fe eddsa_sig_r_len
00000035 2b f9 10 a1 5d fb c6 69 33 60 1b eddsa_sig_r
00000040 d8 93 53 28 2e df 91 0a fb d1 59 5f fe 52 78 9f
00000050 46 cc c3 fe e6
00000055 01 00 00 6d b8 e1 70 78 1d ac c0 <--- here
00000060 41 07 57 b7 a2 e3 e7 93 3b 9b 41 1e 05 bb 0a 82
00000070 16 6a 9c 4e 88 80 06
MPI encoding is "two-octet scalar that is the length of the MPI in bits
followed by a string of octets that contain the actual integer." [1]
And since "The length field of an MPI describes the length starting from
its most significant non-zero bit" the initial "00" byte seems redundant
(and should not be included in the length value).
The MPI section of 4880bis even has an example that shows that zeros
should not be taken into account:
"Thus, the MPI [00 02 01] is not formed correctly. It should be [00 01
01]." [1].
The rest has a length of 248 bits:
6d b8 e1 70 78 1d ac c0 41 07 57 b7 a2 e3 e7 93 3b 9b 41 1e 05 bb 0a 82
16 6a 9c 4e 88 80 06 (31 bytes * 8 = 248 bits)
I'm also not sure how to could bits in the first byte. Since 6d is 0110
1101 in binary maybe it should count as 7 not 8 (since the most
significant bit is cleared)?
Is there an explanation to this behavior? I'm wondering why did GnuPG
generate such a signature and whether or not this is conformant with the
standard that is in development.
Thank you for your time!
Kind regards,
Wiktor
[0]:
https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-rfc4880bis-10#section-5.2.3
[1]:
https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-rfc4880bis-10#section-3.2
_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
I've been recently analyzing EdDSA signatures and found one interesting
case. Not sure if I did my analysis correctly or if that's a bug in the
beta but I'd be really glad if someone helped me to understand what's
happening.
One signature piqued my interest. It's attached to this e-mail:
https://lists.gnupg.org/pipermail/gnupg-devel/2021-February/034715.html
The relevant portion of the signature that looks suspicious is the
"EdDSA value s, in MPI" [0] at the end (00000055):
00000031 9b digest_prefix1
00000032 5b digest_prefix2
00000033 00 fe eddsa_sig_r_len
00000035 2b f9 10 a1 5d fb c6 69 33 60 1b eddsa_sig_r
00000040 d8 93 53 28 2e df 91 0a fb d1 59 5f fe 52 78 9f
00000050 46 cc c3 fe e6
00000055 01 00 00 6d b8 e1 70 78 1d ac c0 <--- here
00000060 41 07 57 b7 a2 e3 e7 93 3b 9b 41 1e 05 bb 0a 82
00000070 16 6a 9c 4e 88 80 06
MPI encoding is "two-octet scalar that is the length of the MPI in bits
followed by a string of octets that contain the actual integer." [1]
And since "The length field of an MPI describes the length starting from
its most significant non-zero bit" the initial "00" byte seems redundant
(and should not be included in the length value).
The MPI section of 4880bis even has an example that shows that zeros
should not be taken into account:
"Thus, the MPI [00 02 01] is not formed correctly. It should be [00 01
01]." [1].
The rest has a length of 248 bits:
6d b8 e1 70 78 1d ac c0 41 07 57 b7 a2 e3 e7 93 3b 9b 41 1e 05 bb 0a 82
16 6a 9c 4e 88 80 06 (31 bytes * 8 = 248 bits)
I'm also not sure how to could bits in the first byte. Since 6d is 0110
1101 in binary maybe it should count as 7 not 8 (since the most
significant bit is cleared)?
Is there an explanation to this behavior? I'm wondering why did GnuPG
generate such a signature and whether or not this is conformant with the
standard that is in development.
Thank you for your time!
Kind regards,
Wiktor
[0]:
https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-rfc4880bis-10#section-5.2.3
[1]:
https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-rfc4880bis-10#section-3.2
_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel