Re: [openssl-dev] Variable length of digest

[Ann]

Am 23.12.2015 um 23:18 schrieb Dr. Stephen Henson:
> That's an interesting question. What digest requires this? Is the output
> length arbitrary or do the standards specify a maximum size?
>
>
Is e.g. SHA-512/t (see 5.3.6 of FIPS 180-4) an appropriate example?
Here t is any positive integer without a leading zero such that t< 512,
and t is not 384.
/Ann.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Variable length of digest

[Dmitry Belyavsky]

Dear Victor,

On Thu, Dec 24, 2015 at 11:02 AM, Victor Wagner  wrote:

> On Thu, 24 Dec 2015 10:45:37 +0300
> Dmitry Belyavsky  wrote:
>
>
> > >
> > > If there's a new construct whose output size depends on the input
> > > data, that probably requires a new family of functions.
> > >
> >
> > Well, the gost-mac is treated specially itself and may be it can be
> > simplified introducing the new construction.
>
> Really it is MAC. I.e. it is combination of digest and pkey algorithms,
> and digest itself is never seen by any application. Applications only
> access MAC value via EVP_DigestSignFinal  interface. And it already
> allows variable size of signature.
>

If you try to change the output length via the -macopt option of the dgst
command, you'll see that the text output will be 4 bytes.
It seems to happen because of the internal call to the EVP_MD_size()
function.

If we change the EVP_MD_CTX_size() definition from a macro to a function
trying to call the ctrl function and then to fallback to the result of the
EVP_MD_size() function, it should improve the situation.

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

[openssl-dev] [openssl.org #4200] extra data for ec keys

[Roumen Petrov via RT]

Update patch sent to request tracker - without gap for CRYPTO_EX_INDEX


Salz, Rich wrote:
>> External cryptographic modules may store addition information to key.
>> What about to define CRYPTO_EX_DATA for ec keys?
> That is the plan -- we will remove EX_EX_DATA and the internal API and just 
> use the standard crypto_ex_data stuff.  Want to make a more complete patch as 
> a github pull request? :)  Otherwise I'll get to it soon.
>


>From 07ad1979667aeb2ba99a8ed88f679fb684b8cf1c Mon Sep 17 00:00:00 2001
From: Roumen Petrov 
Date: Thu, 24 Dec 2015 09:59:29 +0200
Subject: [PATCH 01/13] extra data for EC_KEY

---
 crypto/ec/ec_lcl.h   |  1 +
 crypto/ec/ec_lib.c   | 10 ++
 include/openssl/crypto.h | 17 -
 include/openssl/ec.h |  6 ++
 util/libeay.num  |  2 ++
 5 files changed, 27 insertions(+), 9 deletions(-)

diff --git a/crypto/ec/ec_lcl.h b/crypto/ec/ec_lcl.h
index ebfaae3..912aa8e 100644
--- a/crypto/ec/ec_lcl.h
+++ b/crypto/ec/ec_lcl.h
@@ -267,6 +267,7 @@ struct ec_key_st {
 point_conversion_form_t conv_form;
 int references;
 int flags;
+CRYPTO_EX_DATA ex_data;
 EC_EXTRA_DATA *method_data;
 } /* EC_KEY */ ;
 
diff --git a/crypto/ec/ec_lib.c b/crypto/ec/ec_lib.c
index 7cb4759..e9e5832 100644
--- a/crypto/ec/ec_lib.c
+++ b/crypto/ec/ec_lib.c
@@ -1091,3 +1091,13 @@ int ec_precompute_mont_data(EC_GROUP *group)
 BN_CTX_free(ctx);
 return ret;
 }
+
+int EC_KEY_set_ex_data(EC_KEY *key, int idx, void *arg)
+{
+return (CRYPTO_set_ex_data(>ex_data, idx, arg));
+}
+
+void *EC_KEY_get_ex_data(const EC_KEY *key, int idx)
+{
+return (CRYPTO_get_ex_data(>ex_data, idx));
+}
diff --git a/include/openssl/crypto.h b/include/openssl/crypto.h
index 0d88a06..7fedb77 100644
--- a/include/openssl/crypto.h
+++ b/include/openssl/crypto.h
@@ -270,15 +270,14 @@ DECLARE_STACK_OF(void)
 # define CRYPTO_EX_INDEX_X509_STORE_CTX   5
 # define CRYPTO_EX_INDEX_DH   6
 # define CRYPTO_EX_INDEX_DSA  7
-# define CRYPTO_EX_INDEX_ECDH 8
-# define CRYPTO_EX_INDEX_ECDSA9
-# define CRYPTO_EX_INDEX_RSA 10
-# define CRYPTO_EX_INDEX_ENGINE  11
-# define CRYPTO_EX_INDEX_UI  12
-# define CRYPTO_EX_INDEX_BIO 13
-# define CRYPTO_EX_INDEX_STORE   14
-# define CRYPTO_EX_INDEX_APP 15
-# define CRYPTO_EX_INDEX__COUNT  16
+# define CRYPTO_EX_INDEX_RSA  8
+# define CRYPTO_EX_INDEX_ENGINE   9
+# define CRYPTO_EX_INDEX_UI  10
+# define CRYPTO_EX_INDEX_BIO 11
+# define CRYPTO_EX_INDEX_STORE   12
+# define CRYPTO_EX_INDEX_APP 13
+# define CRYPTO_EX_INDEX_EC_KEY  14
+# define CRYPTO_EX_INDEX__COUNT  15
 
 /*
  * This is the default callbacks, but we can have others as well: this is
diff --git a/include/openssl/ec.h b/include/openssl/ec.h
index 1dc2db1..923844c 100644
--- a/include/openssl/ec.h
+++ b/include/openssl/ec.h
@@ -868,6 +868,12 @@ void *EC_KEY_insert_key_method_data(EC_KEY *key, void *data,
 void *(*dup_func) (void *),
 void (*free_func) (void *),
 void (*clear_free_func) (void *));
+
+#define EC_KEY_get_ex_new_index(l, p, newf, dupf, freef) \
+CRYPTO_get_ex_new_index(CRYPTO_EX_INDEX_EC_KEY, l, p, newf, dupf, freef)
+int EC_KEY_set_ex_data(EC_KEY *key, int idx, void *arg);
+void *EC_KEY_get_ex_data(const EC_KEY *key, int idx);
+
 /* wrapper functions for the underlying EC_GROUP object */
 void EC_KEY_set_asn1_flag(EC_KEY *eckey, int asn1_flag);
 
diff --git a/util/libeay.num b/util/libeay.num
index e10a4f1..f92fba4 100755
--- a/util/libeay.num
+++ b/util/libeay.num
@@ -4735,3 +4735,5 @@ OPENSSL_strlcat 5110	1_1_0	EXIST::FUNCTION:
 OPENSSL_memdup  5111	1_1_0	NOEXIST::FUNCTION:
 CRYPTO_memdup   5112	1_1_0	EXIST::FUNCTION:
 CRYPTO_strndup  5113	1_1_0	EXIST::FUNCTION:
+EC_KEY_get_ex_data  5114	1_1_0	EXIST::FUNCTION:EC
+EC_KEY_set_ex_data  5115	1_1_0	EXIST::FUNCTION:EC
-- 
1.8.4

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

Re: [openssl-dev] Variable length of digest

[Victor Wagner]

On Thu, 24 Dec 2015 10:45:37 +0300
Dmitry Belyavsky  wrote:


> >
> > If there's a new construct whose output size depends on the input
> > data, that probably requires a new family of functions.
> >  
> 
> Well, the gost-mac is treated specially itself and may be it can be
> simplified introducing the new construction.

Really it is MAC. I.e. it is combination of digest and pkey algorithms,
and digest itself is never seen by any application. Applications only
access MAC value via EVP_DigestSignFinal  interface. And it already
allows variable size of signature.

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

[openssl-dev] access-EC_KEY-method-property

[Roumen Petrov]

Salz, Rich wrote:

[SNIP]

I would like to request external applications to be able to change method -
see attached patch "0009-access-EC_KEY-method-property.patch".

Can you say how this would be used?  Since the key method is opaque...
Yes but a number of functions (see below) allow  implementation as 
external to openssl cryptographic module:

$  grep EC_KEY_ME util/libeay.num
EC_KEY_METHOD_set_compute_key   50601_1_0 EXIST::FUNCTION:EC
EC_KEY_METHOD_set_verify50641_1_0 EXIST::FUNCTION:EC
EC_KEY_METHOD_set_init  50651_1_0 EXIST::FUNCTION:EC
EC_KEY_METHOD_get_init  50711_1_0 EXIST::FUNCTION:EC
EC_KEY_METHOD_get_keygen50721_1_0 EXIST::FUNCTION:EC
EC_KEY_METHOD_free  50731_1_0 EXIST::FUNCTION:EC
EC_KEY_METHOD_new   50741_1_0 EXIST::FUNCTION:EC
EC_KEY_METHOD_set_sign  50761_1_0 EXIST::FUNCTION:EC
EC_KEY_METHOD_set_keygen50781_1_0 EXIST::FUNCTION:EC
EC_KEY_METHOD_get_verify50791_1_0 EXIST::FUNCTION:EC
EC_KEY_METHOD_get_sign  50811_1_0 EXIST::FUNCTION:EC
EC_KEY_METHOD_get_compute_key   50821_1_0 EXIST::FUNCTION:EC

I have working prototype that use... _new, ..._init, ..._sing and 
..._verify.



A cryptographic module  (engine) could be registered a method as 
default. In general engine that use externally stored keys should refuse 
to be register methods as default.


Lets engine load method use d2i_PUBKEY to decode "external" der encoded 
public key.

Result is EVP_KEY with KEY(public) with default method.

1) If default method match engine method then application could 
register(associate) extra data with key and to finish loading.


2) If methods differ then application:
a)
  could create new key with FOO_new_method(ENGINE)
  to duplicate public part to "new key"
  to associate "new key" to EVP_KEY with EVP_PKEY_set1_FOO
b)
  could change key method
  must associate engine with key

After above may register(associate) extra data with key and finally to 
finish loading.



Proposed patch adds EC_KEY_get_method that could be used in 1). It seems 
to me this is required part.


Under question is EC_KEY_set_method.
If a) recommended then EC_KEY_set_method is useless. I could drop from 
patch.
If b) is acceptable then in addition to EC_KEY_set_method API must 
support set engine method for opaque keys.



a) requires more memory, i.e. code to transfer(recreate) public key with 
engine

b) it is simple. For instance for rsa keys we could write:

RSA_set_method(pkey_rsa, meth);
pkey_rsa->engine = eng;
ENGINE_up_ref(eng);



Let me know how to proceed with this request.

Roumen Petrov

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

Re: [openssl-dev] Variable length of digest

[Dr. Stephen Henson]

On Thu, Dec 24, 2015, Dmitry Belyavsky wrote:

> 
> If you try to change the output length via the -macopt option of the dgst
> command, you'll see that the text output will be 4 bytes.
> It seems to happen because of the internal call to the EVP_MD_size()
> function.
> 
> If we change the EVP_MD_CTX_size() definition from a macro to a function
> trying to call the ctrl function and then to fallback to the result of the
> EVP_MD_size() function, it should improve the situation.
> 

If you're using it as a MAC via EVP_DigestSign*() you shouldn't need to do any
of that. The MAC size is indicated via EVP_DigestSignFinal, looking through
the code of the dgst application this should already work (though no current
MAC does this) as long as the digest implementation handles things
appropriately. By "appropriately" you have to specify "signctx" in the
underlying EVP_PKEY_METHOD: see the source for EVP_DigestSignFinal().

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] access-EC_KEY-method-property

[Salz, Rich]

> Yes but a number of functions (see below) allow  implementation as external
> to openssl cryptographic module:

Yes, I figured that out after I sent the mail :(

Patch is in code review now, thanks!
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4200] extra data for ec keys

[Salz, Rich via RT]

I fixed that, added docs.  It's in code review now.  Thanks!


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

Re: [openssl-dev] Variable length of digest

[Victor Wagner]

On Thu, 24 Dec 2015 11:24:37 +0300
Dmitry Belyavsky  wrote:


> 
> If you try to change the output length via the -macopt option of the
> dgst command, you'll see that the text output will be 4 bytes.

It is misfeature of dgst command. You have to use -signopt, not -macopt,
because dgst command doesn't keep EVP_PKEY_CTX during all the MAC
operation.

-macopt is used to configure EVP_PKEY_CTX, which is used during
EVP_DigestSignInit operation and then destroyed, and -signopt - to
configure context, which is used durint EVP_DigestSignFinal.

Forutnately, we don't need to configure GOST-MAC algorithm during init
state. Internal state is always 64 bit, and is truncated only on the
finalization stage.

When using API (such as python ctypescrypto.mac module) and preserving
same EVP_PKEY_CTX for the lifetime of digest, this problem doesn't
occur.

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