[Opendnssec-develop] [bert.hubert at netherlabs.nl: [Botan-devel] Solved! Botan Patch inside Re: potential problem with 'GOST 3410-2001' parameters, or with my code]
bert hubert
bert.hubert at netherlabs.nl
Thu Jan 27 14:57:09 UTC 2011
Dear OpenDNSSEC developers,
In trying to get PowerDNSSEC to validate the GOST samples from RFC 5933, I
discovered problems. On browsing the Botan website I found that OpenDNSSEC
added the GOST code to Botan.
After a day and a night of debugging, I found a small error in the GOST code
in Botan that caused the problem.
Perhaps the message below will save you a day and night of debugging too )
And thanks for the code!
Good luck!
----- Forwarded message from bert hubert <bert.hubert at netherlabs.nl> -----
Date: Thu, 27 Jan 2011 15:49:42 +0100
From: bert hubert <bert.hubert at netherlabs.nl>
To: botan-devel at randombit.net
Subject: [Botan-devel] Solved! Botan Patch inside Re: potential problem with
'GOST 3410-2001' parameters, or with my code
Quoting RFC 4490:
"The signature algorithm GOST R 34.10-2001 generates a digital
signature in the form of two 256-bit numbers, r and s. Its octet
string representation consists of 64 octets, where the first
32 octets contain the big-endian representation of s and the second
32 octets contain the big-endian representation of r".
Note 's and then r', and observe the code below. OpenSSL also does 's and
then r'.
With this patch included, the samples from RFC 5933 validate correctly.
--- src/pubkey/gost_3410/gost_3410.cpp c5f656397e7037f2ad8d4dd14da5c764ffd6ccb7
+++ src/pubkey/gost_3410/gost_3410.cpp dea8eaebdb5d0f8d4c954f02805bd5c8cf76d3d8
@@ -130,8 +130,8 @@ GOST_3410_Signature_Operation::sign(cons
throw Invalid_State("GOST 34.10: r == 0 || s == 0");
SecureVector<byte> output(2*order.bytes());
+ s.binary_encode(&output[output.size() - s.bytes()]);
r.binary_encode(&output[output.size() / 2 - r.bytes()]);
- s.binary_encode(&output[output.size() - s.bytes()]);
return output;
}
@@ -150,8 +150,8 @@ bool GOST_3410_Verification_Operation::v
BigInt e = decode_le(msg, msg_len);
+ BigInt s(sig + sig_len / 2, sig_len / 2);
BigInt r(sig, sig_len / 2);
- BigInt s(sig + sig_len / 2, sig_len / 2);
if(r < 0 || r >= order || s < 0 || s >= order)
return false;
On Thu, Jan 27, 2011 at 11:38:15AM +0100, bert hubert wrote:
> Hi everybody,
>
> First, let me thank you for writing & working on the wonderful Botan
> library! It is a joy to work with. Even the source code mostly is a joy to
> read, which is rare in the world of crypto ;-)
>
> Ok, now on to my problem. I'm working on implementing a compliant GOST
> 3410-2001 signature & verification engine for PowerDNS
> (http://www.powerdnssec.org) DNSSEC.
>
> This is described in RFC 5933 (DNS) and RFC 4357 (more GOST details).
>
> Sadly, the signatures I make with Botan verify fine, but the ones from the
> internets don't. It appears I'm not compatible with the world. The GOST hash
> has been verified to be correct.
>
> The code can be seen on:
> http://wiki.powerdns.com/trac/browser/trunk/pdns/pdns/botan19signers.cc
> Tarball: http://powerdnssec.org/downloads/pdns-3.0-pre.20110127.1915.tar.gz
> To test, ./configure --enable-botan1.9, compile and run: ./pdnssec verify-crypto nlnetlabs
> where file nlnetlabs contains:
>
> nlnetlabs.nl. 3600 IN DNSKEY 256 3 12 9SZY+xB3wKtrLoRHzkBs9L3fjcvazjnk5HF3gMaD1PVp4pthrwgHIm0TUaLrd3YCa2VCl5wj+MzbhZi8NEJ/Cg==
> open.nlnetlabs.nl. 600 IN A 213.154.224.1
> open.nlnetlabs.nl. 600 IN RRSIG A 12 3 600 20090903100515 20090806100515 60385 nlnetlabs.nl. XVxDmt7/gRk13Yv+U+RPuEZ86iCGSVPmTcpMZYJs14Yn6Y/On8X+vgLV6IzxQTxAwGb+D35/dUfT55p6pFo8YQ==
>
> verify-crypto will output that the signature does not validate. There may of
> course be problems unrelated to the crypto, but the same code for RSA works.
>
> 5933 specifies that the id-GostR3410-2001-CryptoPro-A-ParamSet
> (1.2.643.2.2.35.1) parameters should be used, and this oid is indeed present
> in Botan, and is called 'Gost_256A'.
>
> However, if I 'dumpasn1' the contents of Gost_256A from
> src/libstate/policy.cpp, I get a BER sequence that looks quite a lot like
> that in RFC 4357, not not quite enough to ease my doubts.
>
> RFC 4357 says:
> 163 30 159: SEQUENCE {
> 166 06 7: OBJECT IDENTIFIER
> : id-GostR3410-2001-CryptoPro-A-ParamSet
> 175 30 147: SEQUENCE {
> 178 02 33: INTEGER
> : 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
> : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FD
> : 94
> 213 02 2: INTEGER 166
> 217 02 33: INTEGER
> : 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
> : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FD
> : 97
> 252 02 33: INTEGER
> : 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
> : FF 6C 61 10 70 99 5A D1 00 45 84 1B 09 B7 61 B8
> : 93
> 287 02 1: INTEGER 1
> 290 02 33: INTEGER
> : 00 8D 91 E4 71 E0 98 9C DA 27 DF 50 5A 45 3F 2B
> : 76 35 29 4F 2D DF 23 E3 B1 22 AC C9 9C 9E 9F 1E
> : 14
> : }
> : }
>
> And Botan contains:
> 0 224: SEQUENCE {
> 3 1: INTEGER 1
> 6 44: SEQUENCE {
> 8 7: OBJECT IDENTIFIER prime-field (1 2 840 10045 1 1)
> 17 33: INTEGER
> : 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
> : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FD
> : 97
> : }
> 52 68: SEQUENCE {
> 54 32: OCTET STRING
> : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
> : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FD 94
> 88 32: OCTET STRING
> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 A6
> : }
> 122 65: OCTET STRING
> : 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> : 01 8D 91 E4 71 E0 98 9C DA 27 DF 50 5A 45 3F 2B
> : 76 35 29 4F 2D DF 23 E3 B1 22 AC C9 9C 9E 9F 1E
> : 14
> 189 33: INTEGER
> : 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
> : FF 6C 61 10 70 99 5A D1 00 45 84 1B 09 B7 61 B8
> : 93
> 224 1: INTEGER 1
> : }
>
> There is a lot of similarity though, but I wonder if people have used Botan
> to generate interoperale signatures before?
>
> Thanks!
_______________________________________________
botan-devel mailing list
botan-devel at randombit.net
http://lists.randombit.net/mailman/listinfo/botan-devel
----- End forwarded message -----
More information about the Opendnssec-develop
mailing list