Re: [openssl-users] How to override methods in EVP_PKEY_METHOD structure that is attached to a EVP_PKEY_CTX?

2017-02-27 Thread Stephan Mühlstrasser

Steve,

Am 25.02.17 um 05:53 schrieb Dr. Stephen Henson:

On Fri, Feb 17, 2017, Stephan M?hlstrasser wrote:
...

Is it possible to override methods in an EVP_PKEY_METHOD structure,
or would it be necessary to implement a whole OpenSSL engine to do
what I want?



It should be possible yes, though AFAIK no one has yet tried to do this so
there may be some pieces missing.

In outline you'd retrieve the appropriate EVP_PKEY_METHOD for the algorithm of
interest, make a copy of it and then set the operation you wish to override,
you can also retrieve the original operation in case you sometimes wish to
call that.


thanks for confirming that this should be possible in principle.

I guess my problem was that I thought one must retrieve the 
EVP_PKEY_METHOD from the EVP_PKEY_CTX pointer. As you are saying it must 
be retrieved for the algorithm, I think I understood now that it must be 
fetched via EVP_PKEY_meth_find().


Is the following sketch roughly appropriate?

int my_sign_init_function(EVP_PKEY_CTX *ctx);
int my_sign_function(EVP_PKEY_CTX *ctx, unsigned char *sig, size_t 
*siglen, const unsigned char *tbs, size_t tbslen);


const EVP_PKEY_METHOD *rsa_meth = EVP_PKEY_meth_find(EVP_PKEY_RSA);
EVP_PKEY_METHOD *new_rsa_meth = EVP_PKEY_meth_new(EVP_PKEY_RSA, 0);
EVP_PKEY_meth_copy(new_rsa_meth, rsa_meth);
EVP_PKEY_meth_set_sign(new_rsa_meth, my_sign_init_function, 
my_sign_function);

EVP_PKEY_meth_add0(new_rsa_meth);

What is still unclear to me is how to retrieve the original function 
pointers from the EVP_PKEY_METHOD. EVP_PKEY_METHOD is an opaque 
structure, and I could not find a getter counterpart for 
EVP_PKEY_meth_set_sign().


How is it supposed to be possible to retrieve the original operations 
from an EVP_PKEY_METHOD pointer?


Thanks.

--
Stephan
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


[openssl-users] POODLE attack on TLS1.2

2017-02-27 Thread Akshar Kanak
Dear Team
   In https://en.wikipedia.org/wiki/POODLE , It is mentioned that
POODLE attack is possible aganist *TLS *also . has this issue been alredy
addressed in openssl .

Thanks and regards
Akshar
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


Re: [openssl-users] POODLE attack on TLS1.2

2017-02-27 Thread Matt Caswell


On 27/02/17 12:03, Akshar Kanak wrote:
> Dear Team
>In https://en.wikipedia.org/wiki/POODLE , It is mentioned that
> POODLE attack is possible aganist *TLS *also . has this issue been
> alredy addressed in openssl .

This was never an issue in OpenSSL - so there is nothing to address.
This issue only affected certain implementations that did not correctly
handle TLS padding (notably F5 and A10 devices). See:

https://www.imperialviolet.org/2014/12/08/poodleagain.html

Matt
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


Re: [openssl-users] POODLE attack on TLS1.2

2017-02-27 Thread Richard Könning

On 27.02.2017 13:03, Akshar Kanak wrote:

Dear Team
   In https://en.wikipedia.org/wiki/POODLE , It is mentioned that 
POODLE attack is possible aganist *TLS *also . has this issue been 
alredy addressed in openssl .


Thanks and regards
Akshar


As the corresponding section in the Wikipedia article says that is not a 
flaw in the TLS protocol but a flaw in it's implementations, more 
exactly in the implementation of CBC encryption mode. For being on the 
safe side take cipher suites not using CBC mode.

Best regards,
Richard
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


Re: [openssl-users] How to override methods in EVP_PKEY_METHOD structure that is attached to a EVP_PKEY_CTX?

2017-02-27 Thread Dr. Stephen Henson
On Mon, Feb 27, 2017, Stephan M?hlstrasser wrote:

> Steve,
> 
> Am 25.02.17 um 05:53 schrieb Dr. Stephen Henson:
> >On Fri, Feb 17, 2017, Stephan M?hlstrasser wrote:
> >...
> >>Is it possible to override methods in an EVP_PKEY_METHOD structure,
> >>or would it be necessary to implement a whole OpenSSL engine to do
> >>what I want?
> >>
> >
> >It should be possible yes, though AFAIK no one has yet tried to do this so
> >there may be some pieces missing.
> >
> >In outline you'd retrieve the appropriate EVP_PKEY_METHOD for the algorithm 
> >of
> >interest, make a copy of it and then set the operation you wish to override,
> >you can also retrieve the original operation in case you sometimes wish to
> >call that.
> 
> thanks for confirming that this should be possible in principle.
> 
> I guess my problem was that I thought one must retrieve the
> EVP_PKEY_METHOD from the EVP_PKEY_CTX pointer. As you are saying it
> must be retrieved for the algorithm, I think I understood now that
> it must be fetched via EVP_PKEY_meth_find().
> 
> Is the following sketch roughly appropriate?
> 
> int my_sign_init_function(EVP_PKEY_CTX *ctx);
> int my_sign_function(EVP_PKEY_CTX *ctx, unsigned char *sig, size_t
> *siglen, const unsigned char *tbs, size_t tbslen);
> 
> const EVP_PKEY_METHOD *rsa_meth = EVP_PKEY_meth_find(EVP_PKEY_RSA);
> EVP_PKEY_METHOD *new_rsa_meth = EVP_PKEY_meth_new(EVP_PKEY_RSA, 0);
> EVP_PKEY_meth_copy(new_rsa_meth, rsa_meth);
> EVP_PKEY_meth_set_sign(new_rsa_meth, my_sign_init_function,
> my_sign_function);
> EVP_PKEY_meth_add0(new_rsa_meth);
> 
> What is still unclear to me is how to retrieve the original function
> pointers from the EVP_PKEY_METHOD. EVP_PKEY_METHOD is an opaque
> structure, and I could not find a getter counterpart for
> EVP_PKEY_meth_set_sign().
> 
> How is it supposed to be possible to retrieve the original
> operations from an EVP_PKEY_METHOD pointer?
> 

Ah I see you're using OpenSSL 1.0.2. There isn't a way to get the existing
function pointers in 1.0.2, the "getter" functions are only in 1.1.0.

There shouldn't be any need to add the method to the list: it should be
possible to associate an EVP_PKEY with a non-default method (e.g. explicitly
or implemented in an ENGINE). I say *should* because there doesn't seem to be
currently a way to do that without changing EVP_PKEY internal fields (which
isn't possible in 1.1.0 anyway).

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


Re: [openssl-users] How to override methods in EVP_PKEY_METHOD structure that is attached to a EVP_PKEY_CTX?

2017-02-27 Thread Stephan Mühlstrasser

Am 27.02.17 um 15:34 schrieb Dr. Stephen Henson:

On Mon, Feb 27, 2017, Stephan M?hlstrasser wrote:



How is it supposed to be possible to retrieve the original
operations from an EVP_PKEY_METHOD pointer?



Ah I see you're using OpenSSL 1.0.2. There isn't a way to get the existing
function pointers in 1.0.2, the "getter" functions are only in 1.1.0.


Ok, I looked at the evp.h header in the 1.1.0 branch, and there I can 
see the getter functions. So I understand that I would have to backport 
those getter functions to the 1.0.2 branch in my repository if I wanted 
to use them with 1.0.2.



There shouldn't be any need to add the method to the list: it should be
possible to associate an EVP_PKEY with a non-default method (e.g. explicitly
or implemented in an ENGINE). I say *should* because there doesn't seem to be
currently a way to do that without changing EVP_PKEY internal fields (which
isn't possible in 1.1.0 anyway).


I'm sorry, I don't get what you are trying to tell me in the above 
paragraph. Are you talking about an alternative way to set up the 
methods in the EVP_PKEY_METHOD structure?


--
Stephan
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


Re: [openssl-users] How to override methods in EVP_PKEY_METHOD structure that is attached to a EVP_PKEY_CTX?

2017-02-27 Thread Dr. Stephen Henson
On Mon, Feb 27, 2017, Stephan M?hlstrasser wrote:

> Am 27.02.17 um 15:34 schrieb Dr. Stephen Henson:
> 
> >There shouldn't be any need to add the method to the list: it should be
> >possible to associate an EVP_PKEY with a non-default method (e.g. explicitly
> >or implemented in an ENGINE). I say *should* because there doesn't seem to be
> >currently a way to do that without changing EVP_PKEY internal fields (which
> >isn't possible in 1.1.0 anyway).
> 
> I'm sorry, I don't get what you are trying to tell me in the above
> paragraph. Are you talking about an alternative way to set up the
> methods in the EVP_PKEY_METHOD structure?
> 

Well this is by analogy with how the other algorithm specific methods work.

With RSA_METHOD et al there are two ways to provide your own mechanisms for
operations.

If it's a general purpose mechanism (e.g. a crypto accelerator) which should
perform all RSA operations you can provide the default method.

If you want to only affect certain keys (e.g. those tied to a specific HSM)
you *can* do this via the default method and just check each key as it goes
through (e.g. some ex_data attached to it) and only handle those of interest
passing the rest to the default operation.

There is an alternative way. You create a custom method and set that as the
key's internal method. Then any existing keys use the default method as usual
but the keys you care about go through the custom method.

For EVP_PKEY_METHOD you can provide the default implementation for an
algorithm but unfortunately there is no way to provide a key specific method
which is transparently used.

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


Re: [openssl-users] How to override methods in EVP_PKEY_METHOD structure that is attached to a EVP_PKEY_CTX?

2017-02-27 Thread Stephan Mühlstrasser

Am 27.02.17 um 16:33 schrieb Dr. Stephen Henson:

On Mon, Feb 27, 2017, Stephan M?hlstrasser wrote:


Am 27.02.17 um 15:34 schrieb Dr. Stephen Henson:


There shouldn't be any need to add the method to the list: it should be
possible to associate an EVP_PKEY with a non-default method (e.g. explicitly
or implemented in an ENGINE). I say *should* because there doesn't seem to be
currently a way to do that without changing EVP_PKEY internal fields (which
isn't possible in 1.1.0 anyway).


I'm sorry, I don't get what you are trying to tell me in the above
paragraph. Are you talking about an alternative way to set up the
methods in the EVP_PKEY_METHOD structure?



Well this is by analogy with how the other algorithm specific methods work.

With RSA_METHOD et al there are two ways to provide your own mechanisms for
operations.

If it's a general purpose mechanism (e.g. a crypto accelerator) which should
perform all RSA operations you can provide the default method.

If you want to only affect certain keys (e.g. those tied to a specific HSM)
you *can* do this via the default method and just check each key as it goes
through (e.g. some ex_data attached to it) and only handle those of interest
passing the rest to the default operation.

There is an alternative way. You create a custom method and set that as the
key's internal method. Then any existing keys use the default method as usual
but the keys you care about go through the custom method.

For EVP_PKEY_METHOD you can provide the default implementation for an
algorithm but unfortunately there is no way to provide a key specific method
which is transparently used.


Ok, thank you for this explanation! I will try to make sense of this and 
I will see whether I am able to map this to the corresponding API calls 
and data structures...


--
Stephan
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


Re: [openssl-users] RSA_method_set_sign

2017-02-27 Thread Melvyn Sopacua
On Saturday 25 February 2017 12:22:09 Dr. Stephen Henson wrote:
 
> You can set the values in place using something like this:
> 
> unsigned char *tmps = NULL;
> int tmpslen;
> X509_SIG *sig = X509_SIG_new();
> X509_ALGOR *alg;
> ASN1_OCTET_STRING *digest;
> X509_SIG_getm(sig, &alg, &digest);
> X509_ALGOR_set0(alg, OBJ_nid2obj(type), V_ASN1_NULL, NULL);
> ASN1_STRING_set(digest, m, m_len);
> /* Allocate and encode */
> tmpslen = i2d_X509_SIG(&sig, &tmps);
> X509_SIG_free(sig);

Thanks. Totally clear now. But, I have to say, this method is badly named. It 
walks and 
talks like a set0() but is called getm(). This is why I assumed, the pointers 
may have 
been filled by X509_SIG_new() and I'd be responsible for them.

-- 
Melvyn Sopacua
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users