[openssl-dev] [openssl.org #3328] [PATCH] Support for GOST R 34.10-2012 digital signature algorithm

2016-01-30 Thread Rich Salz via RT 
GOST is now a separately-maintained engine, thanks to Dmittry :)
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl.org #3328] [PATCH] Support for GOST R 34.10-2012 digital signature algorithm

2014-04-29 Thread Дмитрий Ольшанский 

On 28.04.2014 16:49, Andrey Kulikov wrote:


Дмитрий, а есть ли у вас планы по внедрению  TLS, основанного на новых 
ГОСТах, в OpenSSL ?

Сам собирался занятся этим в начале лета, после отпуска.
С вашей помощью, теперь, это совсем тривиально должно получиться.

Можно скооперироваться как-нибудь.
Если вы, конечно, всё сами не сделаете до этого. :-)


I thought it wasn't customary to use Russian on a public mail list ;)
Anyhow, indeed the last missing piece of new GOST support is TLS
and I have plans to add that with 3rd patch.

I believe it should be straight-forward:
- add a new key exchange (VKO 34.10-2012) that simply uses HMAC of new 
hash instead of GOST 34.11-94

- twiddle with registration of new cipher-suites in libssl

Any help is welcome, e.g. pull requests for my openssl fork.

--
Dmitry Olshansky
Systems Engineer
Demos llc.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3328] [PATCH] Support for GOST R 34.10-2012 digital signature algorithm

2014-04-28 Thread Andrey Kulikov 
Дмитрий, а есть ли у вас планы по внедрению  TLS, основанного на новых
ГОСТах, в OpenSSL ?
Сам собирался занятся этим в начале лета, после отпуска.
С вашей помощью, теперь, это совсем тривиально должно получиться.

Можно скооперироваться как-нибудь.
Если вы, конечно, всё сами не сделаете до этого. :-)

[openssl.org #3328] [PATCH] Support for GOST R 34.10-2012 digital signature algorithm

2014-04-23 Thread Дмитрий Ольшанский via RT 
This is a second patch to add new Russian standard GOST algorithms.

Needs GOST 34.11-2012 hash implementation listed in RT #3311.

See also both patches required in a pull request on github:
https://github.com/openssl/openssl/pull/75

No test cases added, as there are none present in ccgost nor the format 
of such is apparent.
However generated certificates were tested against CryptoPro CSP 4.0 and 
vise-versa.

Some examples of usage:

dmitry@linux64 ~/openssl/apps $ ./openssl req -engine gost -keyout 
new.pem -newkey gost2012-512 -pkeyopt paramset:B -batch   new.req
engine gost set.
Generating a 2048 bit GOST2012-512 private key
writing new private key to 'new.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-
dmitry@linux64 ~/openssl/apps $ ./openssl x509 -engine gost -signkey 
new.pem -req  new.req
engine gost set.
Signature ok
subject=/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
Getting Private key
Enter pass phrase for new.pem:
-BEGIN CERTIFICATE-
MIICCjCCAXQCCQDa+tA+pJiE/DAMBggqhQMHAQEDAwUAMEUxCzAJBgNVBAYTAkFV
MRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRz
IFB0eSBMdGQwHhcNMTQwNDIzMTMzMzIzWhcNMTQwNTIzMTMzMzIzWjBFMQswCQYD
VQQGEwJBVTETMBEGA1UECAwKU29tZS1TdGF0ZTEhMB8GA1UECgwYSW50ZXJuZXQg
V2lkZ2l0cyBQdHkgTHRkMIGqMCEGCCqFAwcBAQECMBUGCSqFAwcBAgECAgYIKoUD
BwEBAgMDgYQABIGAxmt61J1wPiggpm21ILxGboDoMekKHo+9ZD+uhlCIRgNFnIZ9
FBjPyUGvMKPwicE4QPyouId4+pAzf7W3gxP9SQtIIJ9cEKUyHwaF1fU8RgQ4P3JF
qzVo5O5u5Gpj0TgdriCjRig1Z0n2CWw045tsqK+AScj2Wer/3BDbiVEgon0wDAYI
KoUDBwEBAwMFAAOBgQAi7B2eNIFJt/B+uCxh5Bey9OoRbwgnkU00rZf8Yx83jYrb
C7P6+jtJg4XDihaLzHXIScG4Qvoi0LGMa7ZYxzG9OhCGpNH7koxA4t/78JIqn7zY
sFvbj/HZx7DjyiAGnqNh1uBDjPQrFEFm1jJyNooypYHjFyUvt9EbxKDXbiPP9w==
-END CERTIFICATE-


-- 
Dmitry Olshansky

Systems Engineer
Demos llc.
security.demos.ru


diff --git a/crypto/objects/obj_dat.h b/crypto/objects/obj_dat.h
index f9e422c..64134bd 100644
--- a/crypto/objects/obj_dat.h
+++ b/crypto/objects/obj_dat.h
@@ -62,12 +62,12 @@
  * [including the GNU Public Licence.]
  */
 
-#define NUM_NID 963
-#define NUM_SN 954
-#define NUM_LN 954
-#define NUM_OBJ 893
+#define NUM_NID 975
+#define NUM_SN 966
+#define NUM_LN 966
+#define NUM_OBJ 905
 
-static const unsigned char lvalues[6282]={
+static const unsigned char lvalues[6382]={
 0x00,/* [  0] OBJ_undef */
 0x2A,0x86,0x48,0x86,0xF7,0x0D,   /* [  1] OBJ_rsadsi */
 0x2A,0x86,0x48,0x86,0xF7,0x0D,0x01,  /* [  7] OBJ_pkcs */
@@ -961,6 +961,18 @@ static const unsigned char lvalues[6282]={
 0x2A,0x85,0x03,0x07,0x01,/* [6260] OBJ_tc_26 */
 0x2A,0x85,0x03,0x07,0x01,0x01,0x02,0x02, /* [6265] 
OBJ_id_tc26_gost3411_12_256 */
 0x2A,0x85,0x03,0x07,0x01,0x01,0x02,0x03, /* [6273] 
OBJ_id_tc26_gost3411_12_512 */
+0x2A,0x85,0x03,0x07,0x01,0x01,0x01,0x01, /* [6281] 
OBJ_id_tc26_gost3410_12_256 */
+0x2A,0x85,0x03,0x07,0x01,0x01,0x01,0x02, /* [6289] 
OBJ_id_tc26_gost3410_12_512 */
+0x2A,0x85,0x03,0x07,0x01,0x01,0x03,0x02, /* [6297] 
OBJ_id_tc26_signwithdigest_gost3410_12_256 */
+0x2A,0x85,0x03,0x07,0x01,0x01,0x03,0x03, /* [6305] 
OBJ_id_tc26_signwithdigest_gost3410_12_512 */
+0x2A,0x85,0x03,0x07,0x01,0x01,0x04,0x01, /* [6313] 
OBJ_id_tc26_hmac_gost_3411_12_256 */
+0x2A,0x85,0x03,0x07,0x01,0x01,0x04,0x02, /* [6321] 
OBJ_id_tc26_hmac_gost_3411_12_512 */
+0x2A,0x85,0x03,0x07,0x01,0x01,0x06,0x01, /* [6329] 
OBJ_id_tc26_agreement_gost_3410_12_256 */
+0x2A,0x85,0x03,0x07,0x01,0x01,0x06,0x02, /* [6337] 
OBJ_id_tc26_agreement_gost_3410_12_512 */
+0x2A,0x85,0x03,0x07,0x01,0x02,0x01,0x02,0x00,/* [6345] 
OBJ_id_tc26_gost_3410_12_512_paramSetTest */
+0x2A,0x85,0x03,0x07,0x01,0x02,0x01,0x02,0x01,/* [6354] 
OBJ_id_tc26_gost_3410_12_512_paramSetA */
+0x2A,0x85,0x03,0x07,0x01,0x02,0x01,0x02,0x02,/* [6363] 
OBJ_id_tc26_gost_3410_12_512_paramSetB */
+0x2A,0x85,0x03,0x07,0x01,0x02,0x05,0x01,0x01,/* [6372] 
OBJ_id_tc26_gost_28147_param_A */
 };
 
 static const ASN1_OBJECT nid_objs[NUM_NID]={
@@ -2531,6 +2543,37 @@ static const ASN1_OBJECT nid_objs[NUM_NID]={
NID_id_tc26_gost3411_12_256,8,(lvalues[6265]),0},
 {md_gost12_512,GOST R 34.11-2012 512-bit length,
NID_id_tc26_gost3411_12_512,8,(lvalues[6273]),0},
+{gost2012_256,GOST R 34.10-2012 with 256-bit key,
+   NID_id_tc26_gost3410_12_256,8,(lvalues[6281]),0},
+{gost2012_512,GOST R 34.10-2012 with 512-bit key,
+   NID_id_tc26_gost3410_12_512,8,(lvalues[6289]),0},
+{id-tc26-signwithdigest-gost3410-12-256,
+   GOST R 34.10-2012 with 34.11-2012 256-bit,
+   NID_id_tc26_signwithdigest_gost3410_12_256,8,(lvalues[6297]),0},
+{id-tc26-signwithdigest-gost3410-12-512,
+   GOST R 34.10-2012 with 34.11-2012 512-bit,
+   NID_id_tc26_signwithdigest_gost3410_12_512,8,(lvalues[6305]),0},
+{id-tc26-hmac-gost-3411-12-256,HMAC GOST R 34.11-2012 L=32 B=64,
+   NID_id_tc26_hmac_gost_3411_12_256,8,(lvalues[6313]),0},
+{id-tc26-hmac-gost-3411-12-512,HMAC GOST R 34.11-2012 L=64 B=64,
+

Re: [openssl.org #3328] [PATCH] Support for GOST R 34.10-2012 digital signature algorithm

2014-04-23 Thread Dmitry Olshansky 

23-Apr-2014 20:48, Billy Brumley пишет:
Please read CVE-2011-1945. You need to propagate the fix in 
gost2001_do_sign. If you're unsure, check the comments in 
crypto/ecdsa/ecs_ossl.c.


I see the place you refer to. What I can't quite get in this piece is 
adding `order` 2 times. Shouldn't the first BN_add get us where we want 
(that is a number as wide as `order`)?


/* We do not want timing information to leak the length of k,
 * so we compute G*k using an equivalent scalar of fixed
 * bit-length. */

if (!BN_add(k, k, order)) goto err;  //---here I would expect 
k to be  order afterwards
if (BN_num_bits(k) = BN_num_bits(order)) // then this is 
trivially false?
if (!BN_add(k, k, order)) goto err;  //and this should not 
even be reached?

...


BBB





--
Dmitry Olshansky
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3328] [PATCH] Support for GOST R 34.10-2012 digital signature algorithm

2014-04-23 Thread Billy Brumley 
Say order is m bits. Then k+order is either m or m+1 bits. The condition
fixes it at m+1. (You're right that for most standardized curves the branch
is either negligibly taken or overwhelmingly taken, depending on what the
order looks like.)

BBB
On Apr 23, 2014 12:52 PM, Dmitry Olshansky dmitry.o...@gmail.com wrote:

 23-Apr-2014 20:48, Billy Brumley пишет:

 Please read CVE-2011-1945. You need to propagate the fix in
 gost2001_do_sign. If you're unsure, check the comments in
 crypto/ecdsa/ecs_ossl.c.

  I see the place you refer to. What I can't quite get in this piece is
 adding `order` 2 times. Shouldn't the first BN_add get us where we want
 (that is a number as wide as `order`)?

 /* We do not want timing information to leak the length of k,
  * so we compute G*k using an equivalent scalar of fixed
  * bit-length. */

 if (!BN_add(k, k, order)) goto err;  //---here I would expect k
 to be  order afterwards
 if (BN_num_bits(k) = BN_num_bits(order)) // then this is
 trivially false?
 if (!BN_add(k, k, order)) goto err;  //and this should not
 even be reached?
 ...

  BBB




 --
 Dmitry Olshansky
 __
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org