Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

2018-01-24 Thread Dr. Matthias St. Pierre 

On 24.01.2018 19:08, Viktor Dukhovni wrote:
>
> Well, but we now have "openssl-project" for discussions of the
> ongoing development of OpenSSL.  It is mostly for team members,
> but though it is moderated, IIRC others can join and post.
Ok, I didn't know that. If anyone seriously participating on GitHub can
join the moderated openssl-project list then this sounds like a good
replacement for openssl-dev, because that list will be more focused
and not bothered with so many misplaced posts that should have
gone to openssl-users.

Matthias

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

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

2018-01-24 Thread Dr. Matthias St. Pierre 


On 24.01.2018 18:32, Viktor Dukhovni wrote:
>
>> On Jan 24, 2018, at 9:27 AM, Michael Richardson  wrote:
>>
>>> email clients are designed to handle hundreds to thousands of messages
>>> a day, Github UI isn't
> Indeed email is best for informal ad-hoc back and forth threaded
> discussion, while Github et. al. are for issue tracking.
>
> If there's a clear problem that requires tracking and resolution,
> then the right forum is Github.  If there's a topic to discuss,
> we have openssl-users.  Most openssl-dev threads were more
> appropriate for openssl-users.
>
> So I'm not convinced we need two free-form discussion lists, but
> concur that if it is discussion one wants, then email clearly
> superior to Github issue tracking.  The key question is whether
> openssl-users suffices to meet that need.
>

Although GitHub issues provide nice features like markdown and
syntax highlighting, I agree with Viktor that in general mailing lists are
much more suitable for general discussion. If nothing else, then because
they are open for everyone to read and search (via the mail archives)
and don't require a login.

So IMHO GitHub issues should remain for topics like bug reports and
specific discussions related to current pull requests.

As for the two mailing lists openssl-users and openssl-dev: It was always
my understanding that the former was for usability questions starting
from newbie questions up to very sophisticated subjects, whereas
openssl-dev was for discussion around the development process itself.
If we agree that mailing lists are preferrable to GitHub threads, then we
should not close down openssl-dev. Because openssl-project is readonly
for most developers and I don't think it would be a good idea
to join openssl-dev and openssl-users.

Matthias

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

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

2018-01-23 Thread Dr. Matthias St. Pierre 
On 23.01.2018 15:54, Hubert Kario wrote:
> On Tuesday, 23 January 2018 15:36:26 CET Salz, Rich wrote:
>> ➢ this feature sends notifications about _all_ conversations happening.
>> 
>> For me, I get the actual comments that are posted.  Don’t you?
> when I comment in an issue/PR or mark it as followed I'm getting only 
> messages 
> from that issue/PR
>
> when I mark project as followed I'm getting messages from all issues and all 
> PRs - likely dozens if not hundred messages a day

Have you checked Github > Settings > Emails > Email preferences ? 
Maybe yours are set to "Receive all emails"?

My settings are as follows:

   ( )  Receive all emails, except those I unsubscribe from.

   (*) Only receive account related emails, and those I subscribe to.

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

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

2017-09-03 Thread Dr. Matthias St. Pierre 
>
> The 'RAND_add()/RAND_bytes()' pattern is broken
> ===
> 
> In OpenSSL, the classical way for the RNG consumer to add his own randomness 
> is to call 'RAND_add()' before
> calling 'RAND_bytes()'. If the new 'RAND_OpenSSL()' method (the 
> "compatibility layer" hiding the public
> RAND_DRBG instance)  is the default, then this does not work as expected 
> anymore:
> 
> The reason is that a call to 'RAND_add()' adds the provided randomness only 
> to a global buffer
> ('rand_bytes'), from which it will be pulled during the next reseed. But no 
> reseed is triggered. So the next
> RAND_bytes() call will be unaffected from the RAND_add(), which is not what 
> the consumer expected. (The same
> holds for 'RAND_seed()', since 'drbg_seed()' only calls into 'drbg_add()')
> 
> Reseeding of DRBGs occurs only at the following occasions:
> 
> * immediately after a 'fork()' (new)
> * if the 'reseed_counter' exceeds the 'reseed_interval'
> * if 'RAND_DRBG_generate()' is called requesting 'prediction_resistance'
> * 'RAND_DRBG_reseed()' is called explicitely
> 
> *Note:* Currently it looks like the situation is even worse: if 'RAND_add()' 
> is called multiple times before
> a reseed occurs, then the result of the previous call is overwritten.


I just posted GitHub PR #4328 related to this issue

[openssl/openssl] WIP: Fix the RAND_add() reseeding issue (#4328)

 
Matthias St. Pierre



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

2017-08-30 Thread Dr. Matthias St. Pierre 

> -Ursprüngliche Nachricht-
> Von: openssl-dev [mailto:openssl-dev-boun...@openssl.org] Im Auftrag von 
> Blumenthal, Uri - 0553 - MITLL
> Gesendet: Mittwoch, 30. August 2017 17:23
> An: openssl-dev@openssl.org
> Betreff: Re: [openssl-dev] Plea for a new public OpenSSL RNG API
>
> ...
> >  The only tricky part was to deal with temporary failures of the entropy 
> > source.
> 
> Did you experience that often? How did you deal with it?
> 

1) If the SmartCard is missing when our VPN service starts at boot time, the 
initial instantiation of the DRBG fails. This error is ignored, the DRBG 
remains uninstantiated.
2) If the SmartCard is pulled after the VPN connection is established and a 
rekey occurs, the DRBG fails, because it pulls entropy on every generate 
request and the entropy source fails. The NIST standard demands that this is a 
fatal error and the DRBG has to be uninstantiated. So we uninstantiate and our 
custom drbg_bytes() returns an error, which leads to a VPN disconnect.

In order to account for 1) and 2), in our custom drbg_bytes() implementation

3) we do a just-in-time (re-)instantiation of the DRBG before calling 
RAND_DRBG_generate().


Note that everything said above applies to the legacy setup of libcrypto 1.0.2x 
with FIPS DRBG.  In the future, we would use RAND_DRBG_generate() directly.


Regards, Matthias
 


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

2017-08-30 Thread Dr. Matthias St. Pierre 

> >  We have a similar situation, on a small hardware device with little 
> own entropy
> > but with a smartcard reader.
> 
> Yes, but in most cases you cannot count on the smartcard (or smartcard-like 
> device) being in the reader.
> Which is why in my opinion this is an ideal case for “additional input” 
> source, but rather poor as the
> “main” entropy source.
> 
> ...
> 
>>  We implemented a get_entropy() call which fetches the entropy via 
> PKCS#11, and
>>  modified the rand_method such that RAND_DRBG_generate() is always 
> called with
>> prediction_resistance=1. So every generate() triggers a reseed(), the 
> entropy is fetched
>> from the smartcard and it is immediately postprocessed by the AES-CTR 
> DRBG.
>> The /dev/urandom device was only used as additional input.
>> So we didn't feel the need for an extra API call.
> 
> I would do exactly the opposite. “Normal” entropy is fetched from the default 
> sources (/dev/urandom). But
> when a sensitive (aka long-term) keys are generated, a (portable :) hardware 
> RNG is plugged in and used with
> RAND_add() equivalent. Reason – in my setup reliable trusted hardware RNG is 
> not always on. If it were, I’d
> use it as the main entropy source and be done with it.


In general, I would agree with you. In our case, it was a requirement of the 
government to trust only the SmartCard RNG. Since we use it for VPN connections 
with SmartCard authentication this was no problem, because the SmartCard must 
be present in order to initiate the IKEv2 exchange. The only tricky part was to 
deal with temporary failures of the entropy source.

Matthias



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

2017-08-30 Thread Dr. Matthias St. Pierre 

> -Ursprüngliche Nachricht-
> Von: openssl-dev [mailto:openssl-dev-boun...@openssl.org] Im Auftrag von Matt 
> Caswell
> Gesendet: Dienstag, 29. August 2017 16:36
> An: openssl-dev@openssl.org
> Betreff: Re: [openssl-dev] Plea for a new public OpenSSL RNG API
> 
> 
> 
> On 29/08/17 15:02, Salz, Rich via openssl-dev wrote:
> >
> > dev asap. If there are problems with it we can always revert it before
> > it makes it into a release.
> >
> > Someone on the OMC called that “flip-flopping” and seemed to be against 
> > this kind of thing.
> >
> > If we are going to have an additional API, then we should at least see a 
> > draft of the header file first.
> 
> Matthias, would you be willing to create such a draft as a github PR
> (marked as WIP for now)?
> 
> Matt

Oh thanks, that's a great honor to be asked to do this. I will give it a 
thought. Currently, the RAND_add()/RAND_bytes() problem needs to fixed first, 
so it will take a little while.

Matthias




smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

2017-08-30 Thread Dr. Matthias St. Pierre 
> I realize that reseed() not only mixes my “additional input” but also 
> replaces the entire state. NIST does
> not specify interface to “just” mix the “additional input” into the state 
> without replacing the whole state
> with some fresh entropy by calling Get_entropy_input(). Maybe we can provide 
> such a function call (that’s
> what I think RAND_add() is supposed to do), but I’m not certain here…

The reseed() operation pulls fresh entropy, but the old state is not discarded. 
Instead, the fresh entropy is mixed in, just like the additional input (and the 
reseed_counter is reset). Have a look at ctr_update() and ctr_df() and you will 
see that the 'entropy' and the 'adin' input are treated the same way to change 
the internal state. The derivation function treats 'entropy' and 'adin' 
equally, it's just a difference in interpretation (trusted vs. untrusted 
randomness).   

The NIST document has also a lot of nice graphics to explain the inner 
workings. This helped me a lot to understand the details.


Matthias




smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

2017-08-29 Thread Dr. Matthias St. Pierre 
> Essentially, the argument for your last remark is in-structure vtable
> vs refered to vtable.  I tend to prefer the latter (and that's the
> usual OpenSSL pattern too, even though there are exceptions).

You are the experts and much more familiar with the code then I am. My role was 
only to give the starting shot, the rest is up to you.

Regards,
Matthias




smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

2017-08-29 Thread Dr. Matthias St. Pierre 
> -Ursprüngliche Nachricht-
> Von: openssl-dev [mailto:openssl-dev-boun...@openssl.org] Im Auftrag von Matt 
> Caswell
> Gesendet: Dienstag, 29. August 2017 12:17
> An: openssl-dev@openssl.org
> Betreff: Re: [openssl-dev] Plea for a new public OpenSSL RNG API
> 
> 
> On 29/08/17 10:45, Dr. Matthias St. Pierre wrote
> > ...
> > The 'RAND_add()/RAND_bytes()' pattern is broken
> > ===
> >
> > In OpenSSL, the classical way for the RNG consumer to add his own
> > randomness is to call 'RAND_add()' before calling 'RAND_bytes()'. If
> > the new 'RAND_OpenSSL()' method (the "compatibility layer" hiding the
> > public RAND_DRBG instance)  is the default, then this does not work
> > as expected anymore:
> > ...
> 
> Is there a potential security vulnerability here? Applications using the
> "old" APIs expect RAND_add() to behave in a particular way. If we have
> silently changed this behaviour in 1.1.1 are they exposed?

Don't worry, this issue is new, the global 'rand_bytes' buffer has only been 
introduced by the DRBG port to master in August. I don't think it's a big deal 
to fix it. The reason I mentioned it here was to emphasize, that it is really 
hard to get the different philosophies (push vs. pull) of the two APIs working 
together correctly. The code was reviewed by several people and nobody noticed 
it. By the way: the approach using the fixed size global 'rand_bytes' buffer 
has another issue, which I will try to write down on GitHub within the next 
days.

Matthias
 



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Plea for a new public OpenSSL RNG API

2017-08-29 Thread Dr. Matthias St. Pierre 
Hi everybody,

on the [openssl-dev] mailing list, there has been a long ongoing discussion 
about the new RAND_DRBG API and comparing it with the old RAND_METHOD API (see 
"[openssl-dev] Work on a new RNG for OpenSSL"). Two of the most controversal 
questions were:

 - Do we really need a new RNG API? Should the RAND_DRBG API be made public or 
kept private? (Currently, it's exported from libcrypto but only used internally 
by libssl.)
 - How much control should the user (programmer) be given over the reseeding 
process and/or should he be allowed to add his own additional randomness?

Many developers seem to be realizing the interesting possibilities of the DRBG 
API and are asking for public access to this new and promising API. One of the 
driving forces behind it is the question about how to do seeding and reseeding 
right. Among others, Uri Blumenthal asked for making the DRBG API public.

Currently, the OpenSSL core members seem to be reluctant to make the API 
public, at least at this early stage. I understand Rich Salz's viewpoint that 
this requires a thorough discussion, because a public interface can't be easily 
changed and wrong decisions in the early phase can become a heavy burdon.

Nevertheless, I agree with Uri Blumenthal that the DRBG API should be made 
public. So here comes my

==
Plea for a new public OpenSSL RNG API:
==

The new RAND_DRBG is the superior API. It shouldn't be kept private and 
hidden behind the ancient RAND_METHOD API.
The philosophy of the two APIs is not very well compatible, in particular 
when it comes to reseeding and adding
additional unpredictable input. Hiding the RAND_DRBG behind the RAND_METHOD 
API only causes problems.
Also, it will force people to patch their OpenSSL copy if they want to 
use the superior API.

The RAND_DRBG API should become the new public OpenSSL RNG API and the old 
RAND_METHOD API should be deprecated
in the long run. This transition does not need to be rushed, but it would 
be good if there would be early consent
on the road map. I am thinking of a smooth transition with a phase of 
coexistence and a compatibility layer
mapping the default RAND_METHOD to the default public RAND_DRBG instance. 
(This compatibility layer already exists,
it's the 'RAND_OpenSSL()' method.)



Historical Background
=

As Rich already mentioned in his blog post, the RAND_DRBG isn't new. It's been 
a part of OpenSSL for a long time, hidden in the FIPS 2.0 Object Module.

I have been working with the FIPS DRBG for quite a while now, using a 
FIPS-capable OpenSSL 1.0.2x crypto library. The reason why our company switched 
to the FIPS DRBG is that one of our products runs on a small hardware device 
which does not have a reliable entropy source, but the product has to meet high 
security standards, in particular w.r.t. its RNG. So we decided to use the 
SmartCard RNG as primary entropy source for a deterministic AES-CTR based RNG 
and use /dev/urandom as additional input. Reseeding should occur on every 
generate request. Using the FIPS DRBG, these requirements were easily met, 
because the API gives such a fine grained control over reseeding and adding 
additional entropy.

The DRBG was well documented, its design in NIST SP800-90A (now: NIST 
SP800-90Ar1)  and its API in the OpenSSL FIPS 2.0 User Guide. The 
implementation was thoroughly tested and assessed during the FIPS certification 
process. So the only minor obstacle was that we had to patch the crypto library 
(not the FIPS object module) in order to get public access to the FIPS_drbg_*() 
methods.

I always considered the DRBG API more mature than the good old RAND_METHOD API 
and I wondered, why the DRBG code lay forgotten for so many years in the FIPS 
2.0 object module sources and was never ported to master.

When in June of this year the thread "[openssl-dev] Work on a new RNG for 
OpenSSL" popped up (https://mta.openssl.org/pipermail/openssl-dev/2017-June), I 
closely watched the discussion, and when John Denker suggested having a look at 
NIST SP800-90A, I was electrified:

> Constructive suggestion:  If you want to see what a RNG looks
> like when designed by cryptographers, take a look at:
>   Elaine Barker and John Kelsey,>   "Recommendation for Random Number 
Generation Using Deterministic Random Bit Generators"
>   http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf
> 
> That design may look complicated, but if you think you can
> leave out some of the blocks in their diagram, proceed with
> caution.  Every one of those blocks is there for a reason.



>From his mail and the reaction to it, I had the impression that nobody seemed 
>to remember the fact that the DRBG code was already present in the FIPS object 
>module. The hidden treasure

[openssl-dev] [openssl.org #4685] [PATCH v2] Add missing prototype for FIPS callback

2016-09-26 Thread Dr. Matthias St. Pierre via RT 
The call to FIPS_crypto_set_id_callback() was added in revision 
a43cfd7bb1fc681d563e,
but there is no prototype for it in .
---

Moved the function prototype upwards, because declarations can only be placed
at the top of a function in C.


 crypto/o_init.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/crypto/o_init.c b/crypto/o_init.c
index 185841e..18bb858 100644
--- a/crypto/o_init.c
+++ b/crypto/o_init.c
@@ -58,6 +58,11 @@
 #ifdef OPENSSL_FIPS
 # include 
 # include 
+
+# ifndef OPENSSL_NO_DEPRECATED
+/* the prototype is missing in  */
+void FIPS_crypto_set_id_callback(unsigned long (*func)(void));
+# endif
 #endif
 
 /*
-- 
2.7.3


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4685
Please log in as guest with password guest if prompted

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

[openssl-dev] [openssl.org #4685] [PATCH] Add missing prototype for FIPS callback

2016-09-26 Thread Dr. Matthias St. Pierre via RT 
The call to FIPS_crypto_set_id_callback() was added in revision 
a43cfd7bb1fc681d563e,
but there is no prototype for it in .
---

This leads to warnings on some platforms (e.g. x86_64-ncp-linux-gnu-gcc):
o_init.c:77:5: warning: implicit declaration of function 
'FIPS_crypto_set_id_callback' [-Wimplicit-function-declaration]

and to an error on iOS (clang -arch arm64):
o_init.c:77:5: error: implicit declaration of function 
'FIPS_crypto_set_id_callback' is invalid in C99 
[-Werror,-Wimplicit-function-declaration]


 crypto/o_init.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/crypto/o_init.c b/crypto/o_init.c
index 185841e..a399318 100644
--- a/crypto/o_init.c
+++ b/crypto/o_init.c
@@ -74,6 +74,8 @@ void OPENSSL_init(void)
 #ifdef OPENSSL_FIPS
 FIPS_set_locking_callbacks(CRYPTO_lock, CRYPTO_add_lock);
 # ifndef OPENSSL_NO_DEPRECATED
+/* the prototype is missing in  */
+void FIPS_crypto_set_id_callback(unsigned long (*func)(void));
 FIPS_crypto_set_id_callback(CRYPTO_thread_id);
 # endif
 FIPS_set_error_callbacks(ERR_put_error, ERR_add_error_vdata);
-- 
2.7.3


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4685
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] 1.1 release being delayed

2016-06-25 Thread Dr. Matthias St. Pierre 
> > And as far as regressions after beta 2 release are concerned, it looks
> > like there was a change in the API that is not backwards compatible. I
> > was hoping this would not happen after the "Beta 2 - Opaque work
> > complete". Did I misunderstand what that note means?
> >
> > The non-compatible change (this actually broke wpa_supplicant build..)
> > is this one:
> >
> > commit fd809cfdbd6e32b6b67b68c59f6d55fbed7a9327
> > Constify the parameter getters for RSA, DSA and DH
> >
> > -void DH_get0_key(const DH *dh, BIGNUM **pub_key, BIGNUM **priv_key)
> > +void DH_get0_key(const DH *dh, const BIGNUM **pub_key, const BIGNUM 
> > **priv_key)
> >
> >
> > Is there a clear point in time after which the OpenSSL 1.1.0 API is
> > expected to be fully frozen for the release (well, other than the final
> > public release showing up)?
> >
> 
> We are not planning any more opaque work before release, and are trying
> to avoid API breaks at this late stage - but we can't fully rule it out
> either.
> 
> Matt


+1 for the change. IMHO, the constification is a bug fix of the api, not a
deliberate change. Having a const-incorrect api is always a nuisance and it
is better to have it fixed now than after the final elease.

Matthias



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3676] Resolved: [PATCH] Export ASN1 templates for DH and ECDH groups

2016-03-23 Thread Dr. Matthias St. Pierre via RT 
> > The fact we don't export the DHparameters item I'd regard as a bug which 
> > should be fixed.

Will the missing export for DHparameters still be fixed for 1.1?

Matthias St. Pierre

> -Ursprüngliche Nachricht-----
> Von: Dr. Matthias St. Pierre via RT [mailto:r...@openssl.org]
> Gesendet: Donnerstag, 10. März 2016 00:51
> An: Dr. Matthias St. Pierre
> Cc: openssl-dev@openssl.org
> Betreff: AW: [openssl.org #3676] Resolved: [PATCH] Export ASN1 templates for 
> DH and ECDH groups
> 
> > According to our records, your request has been resolved. If you have any
> > further questions or concerns, please respond to this message.
> 
> Thanks a lot for finally adding the patch. Since our software is not ready 
> for version 1.1
> yet, I can't try it directly with the master, but I will backport it for us 
> to 1.0.2.
> 
> Reviewing the commit everything looks perfect, except for a small omission: 
> You probably
> overlooked the changes for exporting the DHparameters. According to Stephen,
> 
> > The fact we don't export the DHparameters item I'd regard as a bug which 
> > should be fixed.
> 
> Essentually it's the following changes to dh.h and libcrypto.num (formerly 
> libeay.num), which are
> missing:
> 
> include/openssl/dh.h:
> 
> 
> +#include 
> ...
> +DECLARE_ASN1_ITEM(DHparams)
> 
> 
> util/libcrypto.num:
> ==
> 
> +DHparams_it1_1_0 
> EXIST:!EXPORT_VAR_AS_FUNCTION:VARIABLE:DH
> +DHparams_it1_1_0 
> EXIST:EXPORT_VAR_AS_FUNCTION:FUNCTION:DH
> 
> 
> 
> Regards,
> Matthias St. Pierre
> 
> 
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3676
> Please log in as guest with password guest if prompted


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3676
Please log in as guest with password guest if prompted



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3676] Resolved: [PATCH] Export ASN1 templates for DH and ECDH groups

2016-03-09 Thread Dr. Matthias St. Pierre via RT 
> According to our records, your request has been resolved. If you have any
> further questions or concerns, please respond to this message.

Thanks a lot for finally adding the patch. Since our software is not ready for 
version 1.1
yet, I can't try it directly with the master, but I will backport it for us to 
1.0.2.

Reviewing the commit everything looks perfect, except for a small omission: You 
probably
overlooked the changes for exporting the DHparameters. According to Stephen,

> The fact we don't export the DHparameters item I'd regard as a bug which 
> should be fixed.

Essentually it's the following changes to dh.h and libcrypto.num (formerly 
libeay.num), which are missing:

include/openssl/dh.h:


+#include 
...
+DECLARE_ASN1_ITEM(DHparams)


util/libcrypto.num:
==

+DHparams_it1_1_0 
EXIST:!EXPORT_VAR_AS_FUNCTION:VARIABLE:DH
+DHparams_it1_1_0 
EXIST:EXPORT_VAR_AS_FUNCTION:FUNCTION:DH



Regards,
Matthias St. Pierre


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3676
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #3676] [PATCH] Export ASN1 templates for DH and ECDH groups

2016-03-05 Thread Dr. Matthias St. Pierre via RT 
> Von: Stephen Henson via RT [mailto:r...@openssl.org]
> Gesendet: Samstag, 5. März 2016 17:53
> An: Dr. Matthias St. Pierre
> Cc: openssl-dev@openssl.org
> Betreff: [openssl.org #3676] [PATCH] Export ASN1 templates for DH and ECDH 
> groups
>
> ...
>
> The fact we don't export the DHparameters item I'd regard as a bug which 
> should
> be fixed.
>
> The EC one I'm less sure about. This ends up exposing what were previously
> internal functions. I'll see if there is an alternative way to achieve the 
> same
> result.
>

These functions, although internal, appear to me to be the natural way to 
serialize
and deserialize private ECDH groups. They are well tested and reusable and the 
only
reason why they are not public is probably because OpenSSL is focused on 
supplying
standardized named curves for TLS. Using private ECDH curves might not make 
much sense
for TLS, but in my case it did: I used it for a VPN client/server where the 
customer
requested the ability to use private ECDH groups in the IKEv2 protocol, in 
addition
to the official IANA groups.

With the proposed change it was easy for me to serialize the entire set of all 
public
and private [EC]DH-Groups in single file by creating a few ASN1 rules based on 
the
existing ASN1  structures (DHparameters  resp. EC[PK]PARAMETERS). So instead of
reinventing the wheel, I let OpenSSL do the main part of the serialization.

There is a thread that predates the creation of my ticket, where I discussed my 
motivation
with Daniel Kahn Gillmor, see below. I hope my arguments convince you that it 
is a good
idea to add these ASN1 structures and the related functions to the public api.

Best Regards,

Matthias St. Pierre


http://thread.gmane.org/gmane.comp.encryption.openssl.devel/28272:
>>> On Tue 2015-01-27 11:15:37 -0500, Dr. Matthias St. Pierre wrote:
>>>> Add missing forward declarations and export declarations for DHparams
>>>> and EC[PK]PARAMETERS.
>>>>
>>>> Add public functions to convert between EC_GROUP objects and 
>>>> EC[PK]PARAMETERS
>>>> objects: EC_GROUP_new_from_ec[pk]parameters(), 
>>>> EC_GROUP_get_ec[pk]parameters().
>>>
>>> fwiw, the IETF TLS WG is moving away from the possibility of arbitrary
>>> EC groups, and toward the requirement of specified and vetted EC
>>> groups.  I'm not sure how much extra work should be done to maintain
>>> that as a public-facing interface.
>>
>> As for TLS, you maybe right. However, the use of Diffie-Hellman is not 
>> limited
>> to TLS (in my case, it's IKEv2). The proposed changes are not for libssl, 
>> but for
>> the 'low level' libcrypto library, which is in my opinion a general purpose 
>> crypto
>> library. As such, it should not make assumptions on or impose restrictions 
>> to possible
>> use cases of the library. Neither should it enforce standards, but provide 
>> algorithms.
>>
>> My patch does not introduce new features or change existing ones. It just 
>> makes
>> functionality available for reuse. I needed this particular functionality 
>> and I
>> had the choice between 1) copy & paste the code 2) patch OpenSSL privately, 
>> or
>> 3) submit a patch. So I chose the latter.
>
>Your choice of action makes sense to me, thanks!
>
> --dkg



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3676
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #3676] [PATCH] Export ASN1 templates for DH and ECDH groups

2016-03-05 Thread Dr. Matthias St. Pierre via RT 
Is there any chance that this change will find it's way into OpenSSL 1.1 ?

Regards,
Matthias St. Pierre


-Ursprüngliche Nachricht-
Von: Rich Salz via RT [mailto:r...@openssl.org] 
Gesendet: Mittwoch, 2. März 2016 15:28
An: Dr. Matthias St. Pierre
Cc: openssl-dev@openssl.org
Betreff: [openssl.org #3676] [PATCH] Export ASN1 templates for DH and ECDH 
groups

Steve, what do you thnk?
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3676
Please log in as guest with password guest if prompted


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3676
Please log in as guest with password guest if prompted



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Improving OpenSSL default RNG

2015-10-26 Thread Dr. Matthias St. Pierre 

On 10/24/2015 05:55 PM, Marcus Meissner wrote:
> On Fri, Oct 23, 2015 at 07:19:11PM +0200, Alessandro Ghedini wrote:
>> On Fri, Oct 23, 2015 at 04:34:11PM +0200, Dr. Matthias St. Pierre wrote:
>> ...
>> In general the NIST DRBGs seem fairly complicated (or completely 
>> untrustworthy
>> like Dual EC DRBG), so I'd rather have a different implementation as default
>> RNG for OpenSSL.
> 
> Well, the Dual EC has been removed from the guidance.
> 
> The other 3 modes described in NIST 800-90a make sense though. I suggest to 
> read
> the standard, the main things making it long are all the error handling and
> reseeding strategies.
> 
> Ciao, Marcus

I agree, to me it seems to be a rather straightforward implementation of a 
hybrid RNG. To get an impression of the
essentials, e.g. for the DRBG based on AES-CTR, it helps to have a look at 
Figures 11 (p.49) and 12 (p.51)
of  <http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf>.

The nice part about the DRBG is that one can connect it to an external entropy 
source and configure 
the reseed interval. It also supports prediction resistance on demand, although 
this feature is not available through
FIPS_drbg_method(), only if one uses FIPS_drbg_generate() directly.

So it would be convenient for us to have it available in the normal OpenSSL 
library without having to fiddle
with the FIPS object module. It wouldn't have to be the default OpenSSL RNG, 
though.

Regards, Matthias

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

Re: [openssl-dev] Improving OpenSSL default RNG

2015-10-23 Thread Dr. Matthias St. Pierre 

Hi,

I have a related question concerning alternative RNGs, hope it is not too 
off-topic:

Currently we are using the NIST-SP800-90a compliant DRBG (FIPS_drbg_method()), 
because it seemed to us to be more
sophisticated and mature than the default RAND_SSLeay(). At least it's better 
documented and tested.

Currently this DRBG is only available through the FIPS object module, so you 
need to build a FIPS capable OpenSSL library in 
order to use it.

Shouldn't the FIPS DRBG code be added to the normal code base in master, too, 
as an alternative RNG implemtation?
Or is the NIST-SP800-90a DRG construction already obsolete outside of FIPS 
world?


Regards,
Matthias











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

Re: [openssl-dev] Openssl 1.0.2c include the FIPS 140-2 Object Module

2015-09-25 Thread Dr. Matthias St. Pierre 

On 09/21/2015 12:01 AM, Jan Ehrhardt wrote:
> Dr. Matthias St. Pierre in gmane.comp.encryption.openssl.devel (Sun, 16
> Aug 2015 23:52:21 +0200):
>>
>> Thank you once more for the detailed reply. I applied your patches 
>> provisorily before going on vacation last friday to keep the builds 
>> going. After my vacation we will have to decide what to do about the 
>> FIPS problem.
> 
> Surely, your holiday must be over by now ;-)
> 
> Jan
> 
> ___
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> 


Sorry for not answering earlier, I overlooked your post. Not because of 
holidays,
but because I was busy with other problems.

As you might have guessed, my provisional arrangement is still in place ;-)
I noticed there has been some movement on issue #4042 recently and hope there
will be an official solution to the problem soon.

Thanks for persisting on the subject, anyway.

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

Re: [openssl-dev] Openssl 1.0.2c include the FIPS 140-2 Object Module

2015-08-16 Thread Dr. Matthias St. Pierre 


Am 14.08.2015 um 16:22 schrieb Jan Ehrhardt:
I guess there was a change from optional (in VC9/VC11) to required in 
VC14, but only for the 1.0.2 branch. The PHP devs were the first to 
notice and included applink.c in the VS2015/VC14 builds of PHP7. 
Apachelounge followed by including applink.c in the VS2015/VC14 builds 
of Apache 2.4.16. Then I tried to compile OpenSSL 1.0.2c + FIPS 2.0.9 
with VC14 and ran into the error. 
Thank you once more for the detailed reply. I applied your patches 
provisorily before going on vacation last friday to keep the builds 
going. After my vacation we will have to decide what to do about the 
FIPS problem.


Regards,
Matthias



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

Re: [openssl-dev] Openssl 1.0.2c include the FIPS 140-2 Object Module

2015-08-14 Thread Dr. Matthias St. Pierre 
Hello Jan,

thank you for sharing your observations and your patch. I stumbled over it,
because we are currently having a similar problem with our Windows builds 
producing
these OPENSSL_Uplink/no OPENSSL_Applink errors.

However, I'm in doubt whether your patch really fixes the cause of the problem
or just the symptoms. I believe that there must be a fix for the problem without
modifying the sequestered code of the fips module.

You say that FIPS 140-2 was broken by the introduction of applink.c .

However the applink.c module was introduced way back in 2004 and nevertheless
OpenSSL 1.0.1 and the FIPS 2.0.9 module built happily together on Windows ever 
since.
(and you can see in the build logs that '-DOPENSSL_USE_APPLINK' appears a lot)

Even OpenSSL 1.0.2 and FIPS 2.0.9 build together perfectly on our Windows 
machines
with VS2012. Only after migrating to VS2015 we started to have this problem.

So I am quite sure that the true cause of the problem does not lie in 
incompatible
changes between 1.0.1 and 1.0.2, the problem must lie elsewhere. But 
unfortunately,
I have no solution yet.

If you (or anybody else) disagree(s), I would be happy to hear from you.

Regards,

Matthias

On 07/11/2015 06:08 PM, Jan Ehrhardt wrote:
 Steve Marquess in gmane.comp.encryption.openssl.devel (Wed, 01 Jul 2015
 09:53:14 -0400):
 On 07/01/2015 02:24 AM, Patil, Ashwini IN BLR STS wrote:
 Hello All,
  
 Please let me know if openssl-1.0.2c include FIPS 140-2 Object Module.
 Also please explain how to validate the application.

 This question would be more appropriate for the openssl-users list. The
 -dev list is for OpenSSL development issues, not for basic usage questions.
 
 Patil has a point, because FIPS 140-2 building on Windows is broken
 since the introduction of applink.c. The generated fips_premain_dso.exe
 fails during the building process:
 
 link /nologo /subsystem:console /opt:ref /debug /dll /fixed /map
 /base:0xFB0 /out:out32dll\libeay32.dll /def:ms/LIBEAY32.def
 @D:\Temp\nmB1D5.tmp
Creating library out32dll\libeay32.lib and object
 out32dll\libeay32.exp
 out32dll\fips_premain_dso.exe out32dll\libeay32.dll
 OPENSSL_Uplink(00CBB000,08): no OPENSSL_Applink
 Get hash failure at \usr\local\ssl\fips-2.0\bin\fipslink.pl line 60.
 NMAKE : fatal error U1077: 'C:\Perl64\bin\perl.EXE' : return code '0x1'
 
 Outside of the building script the error is the same
 C:\opensslout32dll\fips_premain_dso.exe out32dll\libeay32.dll
 OPENSSL_Uplink(010CB000,08): no OPENSSL_Applink
 
 Solution: fips/fips_premain.c in the FIPS sources should include
 applink.c on Windows
 
 I managed to build a fips_premain_dso.exe with Applink and use that to
 create Openssl 1.0.2d fips, but this was certainly not without breaking
 the FIPS rules.
 
 It is time for openssl-fips-2.0.10
 
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3925] [PATCH] Removed trailing semicolon from macro body of three function-like macros

2015-06-24 Thread Dr. Matthias St. Pierre via RT 
The trailing semicolon turned the macros into statements and prevented
them from being used in arbitrary expressions.
---
 include/openssl/bio.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/openssl/bio.h b/include/openssl/bio.h
index 7fe88ec..12f59ac 100644
--- a/include/openssl/bio.h
+++ b/include/openssl/bio.h
@@ -540,11 +540,11 @@ int BIO_read_filename(BIO *b, const char *name);
 # define BIO_get_ssl(b,sslp) BIO_ctrl(b,BIO_C_GET_SSL,0,(char *)sslp)
 # define BIO_set_ssl_mode(b,client)  BIO_ctrl(b,BIO_C_SSL_MODE,client,NULL)
 # define BIO_set_ssl_renegotiate_bytes(b,num) \
-BIO_ctrl(b,BIO_C_SET_SSL_RENEGOTIATE_BYTES,num,NULL);
+BIO_ctrl(b,BIO_C_SET_SSL_RENEGOTIATE_BYTES,num,NULL)
 # define BIO_get_num_renegotiates(b) \
-BIO_ctrl(b,BIO_C_GET_SSL_NUM_RENEGOTIATES,0,NULL);
+BIO_ctrl(b,BIO_C_GET_SSL_NUM_RENEGOTIATES,0,NULL)
 # define BIO_set_ssl_renegotiate_timeout(b,seconds) \
-BIO_ctrl(b,BIO_C_SET_SSL_RENEGOTIATE_TIMEOUT,seconds,NULL);
+BIO_ctrl(b,BIO_C_SET_SSL_RENEGOTIATE_TIMEOUT,seconds,NULL)
 
 /* defined in evp.h */
 /* #define BIO_set_md(b,md) BIO_ctrl(b,BIO_C_SET_MD,1,(char *)md) */
-- 
2.3.6

___
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] [openssl.org #3920] ECDSA_METHOD_new() argument should be constified?

2015-06-23 Thread Dr. Matthias St. Pierre 
On 06/22/2015 09:17 PM, Dmitry Belyavsky via RT wrote:
 Hello all,
 
 I try to provide my own ECDSA method using engine. I want to use common
 functions for verifying the signature and a custom one for signing.
 
 My code is
 
 ...
   const ECDSA_METHOD * meth1 = ECDSA_OpenSSL();
   forwarder_ec_method = ECDSA_METHOD_new(meth1);
 ...
 
 Compiling it, I get an error:
 
 error: passing argument 1 of ‘ECDSA_METHOD_new’ discards ‘const’ qualifier
 from pointer target type [-Werror]
 
 Shouldn't the argument of the ECDSA_METHOD_new() function be const struct
 ECDSA_METHOD * instead of struct ECDSA_METHOD *?


Just happened to submit a patch fixing two const-correctness issues of the 
ECDSA_METHOD api
almost simultaneously to your post, see [openssl.org #3921]

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

[openssl-dev] Comments on the new ECDSA_METHOD_*() and RSA_METHOD_*() APIs

2015-06-22 Thread Dr. Matthias St. Pierre 

Hello,

first of all, I'd like to say that I agree with the core developers that it's a 
good idea to make
all these OpenSSL structs opaque and provide an API for creation/desruction and 
member access instead.

I have two comments on the new ECDSA_METHOD_*() and RSA_METHOD_*() APIs in 
particular,
and a general question concerning the *_METHOD_*() API in general.


1) The ECDSA_METHOD_*() api is not const correct: the copy constructor and 
the name setter
   are lacking a 'const' in the last argument.
   
 ECDSA_METHOD *ECDSA_METHOD_new(ECDSA_METHOD *ecdsa_meth)
 void ECDSA_METHOD_set_name(ECDSA_METHOD *ecdsa_method, char *name)   

   Instead, I should be 

 ECDSA_METHOD *ECDSA_METHOD_new(const ECDSA_METHOD *ecdsa_meth)
 void ECDSA_METHOD_set_name(ECDSA_METHOD *ecdsa_method, const char *name)

   I have prepared a patch fixing the const-correctness, which I'll post to the 
request tracker.
   
   It would be nice if the change could be added to the 1.0.2 stable branch. 
Although it's a header change
   it would not break the ABI and force no recompilation of existing code, as 
far as I understand it,
   since there is no name decoration in C. This opion was also shared by Rich 
Salz recently:

   Re: [openssl-dev] Missing API features
   On 04/20/2015 10:25 PM, Salz, Rich wrote:
Changing the return type here should be binary compatible on any sane 
platform, but it might cause source incompatibilities.


   I think it would be better to correct the error right away, before people 
start working around it
   by casting away the const's in their code.
   
 

2) A corresponding RSA_METHOD_*() api is still completely missing (even on 
master) and the 'struct rsa_meth_st'
   members are still publicly visible.

   Are there any plans to add it in the near future? 



3) Looking at the set of exported functions in util/libeay.num, one sees that 
the *_METHOD_*() API is still
   rather rudimentary. Are there any plans to change this?

   util/libeay.num:
 DSO_METHOD_null 2270EXIST::FUNCTION:
 DSO_METHOD_openssl  2271EXIST::FUNCTION:
 DSO_METHOD_dlfcn2272EXIST::FUNCTION:
 DSO_METHOD_win322273EXIST::FUNCTION:
 DSO_METHOD_dl   2275EXIST::FUNCTION:
 DSO_METHOD_vms  2462EXIST::FUNCTION:
 EC_METHOD_get_field_type3528EXIST::FUNCTION:EC
 DSO_METHOD_beos 4122NOEXIST::FUNCTION:
 X509_CRL_METHOD_free4241EXIST::FUNCTION:
 X509_CRL_METHOD_new 4371EXIST::FUNCTION:
 ECDSA_METHOD_set_name   4723EXIST::FUNCTION:EC
 ECDSA_METHOD_set_flags  4726EXIST::FUNCTION:EC
 ECDSA_METHOD_set_sign_setup 4727EXIST::FUNCTION:EC
 ECDSA_METHOD_set_sign   4733EXIST::FUNCTION:EC
 ECDSA_METHOD_new4751EXIST::FUNCTION:EC
 ECDSA_METHOD_set_verify 4755EXIST::FUNCTION:EC
 ECDSA_METHOD_free   4759EXIST::FUNCTION:EC
 ECDSA_METHOD_set_app_data   4768EXIST::FUNCTION:EC
 ECDSA_METHOD_get_app_data   4770EXIST::FUNCTION:EC

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

[openssl-dev] [openssl.org #3921] [PATCH] Fix const-correctness issues of new ECDSA_METHOD api

2015-06-22 Thread Dr. Matthias St. Pierre via RT 
- The function ECDSA_METHOD_new() acts like a copy constructor, but 
unfortunately
  its argument is not declared const. This leads to compiler errors when it is
  used as follows:

ECDSA_METHOD * method = ECDSA_METHOD_new(ECDSA_OpenSSL());

- The ECDSA_METHOD_set_name() should take a 'const char *' instead of a 'char 
*',
  because that's the type of the ecdsa_method 'name' member.
---
 crypto/ecdsa/ecdsa.h   | 4 ++--
 crypto/ecdsa/ecs_lib.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/crypto/ecdsa/ecdsa.h b/crypto/ecdsa/ecdsa.h
index c4016ac..d31cebc 100644
--- a/crypto/ecdsa/ecdsa.h
+++ b/crypto/ecdsa/ecdsa.h
@@ -233,7 +233,7 @@ void *ECDSA_get_ex_data(EC_KEY *d, int idx);
  *  \return pointer to a ECDSA_METHOD structure or NULL if an error occurred
  */
 
-ECDSA_METHOD *ECDSA_METHOD_new(ECDSA_METHOD *ecdsa_method);
+ECDSA_METHOD *ECDSA_METHOD_new(const ECDSA_METHOD *ecdsa_method);
 
 /** frees a ECDSA_METHOD structure
  *  \param  ecdsa_method  pointer to the ECDSA_METHOD structure
@@ -295,7 +295,7 @@ void ECDSA_METHOD_set_flags(ECDSA_METHOD *ecdsa_method, int 
flags);
  *   \param  flags flags value to set
  */
 
-void ECDSA_METHOD_set_name(ECDSA_METHOD *ecdsa_method, char *name);
+void ECDSA_METHOD_set_name(ECDSA_METHOD *ecdsa_method, const char *name);
 
 /**  Set the name field in the ECDSA_METHOD
  *   \param  ecdsa_method  pointer to existing ECDSA_METHOD
diff --git a/crypto/ecdsa/ecs_lib.c b/crypto/ecdsa/ecs_lib.c
index 1c02310..05dab09 100644
--- a/crypto/ecdsa/ecs_lib.c
+++ b/crypto/ecdsa/ecs_lib.c
@@ -276,7 +276,7 @@ void *ECDSA_get_ex_data(EC_KEY *d, int idx)
 return (CRYPTO_get_ex_data(ecdsa-ex_data, idx));
 }
 
-ECDSA_METHOD *ECDSA_METHOD_new(ECDSA_METHOD *ecdsa_meth)
+ECDSA_METHOD *ECDSA_METHOD_new(const ECDSA_METHOD *ecdsa_meth)
 {
 ECDSA_METHOD *ret;
 
@@ -332,7 +332,7 @@ void ECDSA_METHOD_set_flags(ECDSA_METHOD *ecdsa_method, int 
flags)
 ecdsa_method-flags = flags | ECDSA_METHOD_FLAG_ALLOCATED;
 }
 
-void ECDSA_METHOD_set_name(ECDSA_METHOD *ecdsa_method, char *name)
+void ECDSA_METHOD_set_name(ECDSA_METHOD *ecdsa_method, const char *name)
 {
 ecdsa_method-name = name;
 }
-- 
2.3.6

___
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

[openssl-dev] [openssl.org #3676] [PATCH] Export ASN1 templates for DH and ECDH groups

2015-01-30 Thread Dr. Matthias St. Pierre via RT 
From: Dr. Matthias St. Pierre m...@ncp-e.com

Add missing forward declarations and export declarations for DHparams
and EC[PK]PARAMETERS.

Add public functions to convert between EC_GROUP objects and EC[PK]PARAMETERS
objects: EC_GROUP_new_from_ec[pk]parameters(), EC_GROUP_get_ec[pk]parameters().

Signed-off-by: Dr. Matthias St. Pierre matthias.st.pie...@ncp-e.com
---
 crypto/dh/dh.h  |  4 
 crypto/ec/ec.h  | 38 ++
 crypto/ec/ec_asn1.c | 30 ++
 util/libeay.num | 10 ++
 4 files changed, 78 insertions(+), 4 deletions(-)

This patch amends my previous one and fixes a minor issue which affects only 
windows:

The 'DHparams_it' symbol was not exported from the libeay32.dll library.

The cause was a missing 'DECLARE_ASN1_ITEM(DHparams)' statement in the 
crypto/dh/dh.h
header file, which is required by the  mkdef.pl perl script in order operate 
correctly
when generating the linker definition file.


Matthias

diff --git a/crypto/dh/dh.h b/crypto/dh/dh.h
index 0502f1a..9123276 100644
--- a/crypto/dh/dh.h
+++ b/crypto/dh/dh.h
@@ -65,6 +65,8 @@
 #  error DH is disabled.
 # endif
 
+# include openssl/asn1.h
+
 # ifndef OPENSSL_NO_BIO
 #  include openssl/bio.h
 # endif
@@ -181,6 +183,8 @@ struct dh_st {
  */
 # define DH_CHECK_P_NOT_STRONG_PRIME DH_CHECK_P_NOT_SAFE_PRIME
 
+DECLARE_ASN1_ITEM(DHparams)
+
 # define d2i_DHparams_fp(fp,x) (DH *)ASN1_d2i_fp((char *(*)())DH_new, \
 (char *(*)())d2i_DHparams,(fp),(unsigned char **)(x))
 # define i2d_DHparams_fp(fp,x) ASN1_i2d_fp(i2d_DHparams,(fp), \
diff --git a/crypto/ec/ec.h b/crypto/ec/ec.h
index 98edfdf..97ccee8 100644
--- a/crypto/ec/ec.h
+++ b/crypto/ec/ec.h
@@ -128,6 +128,9 @@ typedef struct ec_group_st
 
 typedef struct ec_point_st EC_POINT;
 
+typedef struct ecpk_parameters_st ECPKPARAMETERS;
+typedef struct ec_parameters_st ECPARAMETERS;
+
 //
 /*   EC_METHODs for curves over GF(p)   */
 //
@@ -393,6 +396,38 @@ EC_GROUP *EC_GROUP_new_curve_GF2m(const BIGNUM *p, const 
BIGNUM *a,
  */
 EC_GROUP *EC_GROUP_new_by_curve_name(int nid);
 
+/** Creates a new EC_GROUP object from an ECPARAMETERS object
+ *  \param  params  pointer to the ECPARAMETERS object
+ *  \return newly created EC_GROUP object with specified curve or NULL
+ *  if an error occurred
+ */
+EC_GROUP *EC_GROUP_new_from_ecparameters(const ECPARAMETERS *params);
+
+/** Creates an ECPARAMETERS object for the the given EC_GROUP object.
+ *  \param  group   pointer to the EC_GROUP object
+ *  \param  params  pointer to an existing ECPARAMETERS object or NULL
+ *  \return pointer to the new ECPARAMETERS object or NULL
+ *  if an error occurred.
+ */
+ECPARAMETERS *EC_GROUP_get_ecparameters(const EC_GROUP *group,
+ECPARAMETERS *params);
+
+/** Creates a new EC_GROUP object from an ECPKPARAMETERS object
+ *  \param  params  pointer to an existing ECPKPARAMETERS object, or NULL
+ *  \return newly created EC_GROUP object with specified curve, or NULL
+ *  if an error occurred
+ */
+EC_GROUP *EC_GROUP_new_from_ecpkparameters(const ECPKPARAMETERS *params);
+
+/** Creates an ECPKPARAMETERS object for the the given EC_GROUP object.
+ *  \param  group   pointer to the EC_GROUP object
+ *  \param  params  pointer to an existing ECPKPARAMETERS object or NULL
+ *  \return pointer to the new ECPKPARAMETERS object or NULL
+ *  if an error occurred.
+ */
+ECPKPARAMETERS *EC_GROUP_get_ecpkparameters(const EC_GROUP *group,
+ECPKPARAMETERS *params);
+
 //
 /*   handling of internal curves*/
 //
@@ -702,6 +737,9 @@ int EC_GROUP_have_precompute_mult(const EC_GROUP *group);
 /*   ASN1 stuff */
 //
 
+DECLARE_ASN1_ITEM(ECPKPARAMETERS)
+DECLARE_ASN1_ITEM(ECPARAMETERS)
+
 /*
  * EC_GROUP_get_basis_type() returns the NID of the basis type used to
  * represent the field elements
diff --git a/crypto/ec/ec_asn1.c b/crypto/ec/ec_asn1.c
index 2924374..d84c6d2 100644
--- a/crypto/ec/ec_asn1.c
+++ b/crypto/ec/ec_asn1.c
@@ -306,6 +306,28 @@ static EC_GROUP *ec_asn1_pkparameters2group(const 
ECPKPARAMETERS *);
 static ECPKPARAMETERS *ec_asn1_group2pkparameters(const EC_GROUP *,
   ECPKPARAMETERS *);
 
+EC_GROUP *EC_GROUP_new_from_ecparameters(const ECPARAMETERS *params)
+{
+return ec_asn1_parameters2group(params);
+}
+
+ECPARAMETERS *EC_GROUP_get_ecparameters(const EC_GROUP *group

Re: [openssl-dev] [PATCH] Export ASN1 templates for DH and ECDH groups

2015-01-28 Thread Dr. Matthias St. Pierre 
Hello,

On 01/28/2015 12:52 AM, Matt Caswell wrote:
 Please submit patches to r...@openssl.org.

Sorry about that, I will repost it.

I overlooked https://www.openssl.org/support/rt.html. Instead, 
I followed the FAQ which sent me to the README file, and there 
was no mention of the request tracker. 

Maybe you could update the FAQ and the README accordingly?


Matthias

see
https://www.openssl.org/support/faq.html#MISC3
https://github.com/openssl/openssl/blob/master/README

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

Re: [openssl-dev] [PATCH] Export ASN1 templates for DH and ECDH groups

2015-01-28 Thread Dr. Matthias St. Pierre 
On 01/28/2015 06:02 AM, Daniel Kahn Gillmor wrote:
 On Tue 2015-01-27 11:15:37 -0500, Dr. Matthias St. Pierre wrote:
 Add missing forward declarations and export declarations for DHparams
 and EC[PK]PARAMETERS.

 Add public functions to convert between EC_GROUP objects and EC[PK]PARAMETERS
 objects: EC_GROUP_new_from_ec[pk]parameters(), 
 EC_GROUP_get_ec[pk]parameters().
 
 fwiw, the IETF TLS WG is moving away from the possibility of arbitrary
 EC groups, and toward the requirement of specified and vetted EC
 groups.  I'm not sure how much extra work should be done to maintain
 that as a public-facing interface.

As for TLS, you maybe right. However, the use of Diffie-Hellman is not limited
to TLS (in my case, it's IKEv2). The proposed changes are not for libssl, but 
for
the 'low level' libcrypto library, which is in my opinion a general purpose 
crypto
library. As such, it should not make assumptions on or impose restrictions to 
possible
use cases of the library. Neither should it enforce standards, but provide 
algorithms.

My patch does not introduce new features or change existing ones. It just makes
functionality available for reuse. I needed this particular functionality and I 
had the choice between 1) copy  paste the code 2) patch OpenSSL privately, or
3) submit a patch. So I chose the latter.


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

[openssl-dev] [openssl.org #3676] [PATCH] Export ASN1 templates for DH and ECDH groups

2015-01-28 Thread Dr. Matthias St. Pierre via RT 
Add missing forward declarations and export declarations for DHparams
and EC[PK]PARAMETERS.

Add public functions to convert between EC_GROUP objects and EC[PK]PARAMETERS
objects: EC_GROUP_new_from_ec[pk]parameters(), EC_GROUP_get_ec[pk]parameters().

Signed-off-by: Dr. Matthias St. Pierre m...@ncp-e.com
---
 crypto/ec/ec.h  | 38 ++
 crypto/ec/ec_asn1.c | 30 ++
 util/libeay.num | 10 ++
 3 files changed, 74 insertions(+), 4 deletions(-)

This patch makes the ASN1 templates used internally by OpenSSL for
serializing DH and ECDH group parameters publicly available for reuse.

For example, if one wants to save a set of [EC]DH Groups together with
application defined data (like, group-name, group-id) to a file, it is
much easier to define a small set of ASN1 rules extending the existing
ones and let OpenSSL do the serialization, than having to fiddle around
with i2d_DHparams(), i2d_ECParameters(), etc., to embed the curve data
as a blob into an opaque ASN1 octet string.

diff --git a/crypto/ec/ec.h b/crypto/ec/ec.h
index 98edfdf..97ccee8 100644
--- a/crypto/ec/ec.h
+++ b/crypto/ec/ec.h
@@ -128,6 +128,9 @@ typedef struct ec_group_st
 
 typedef struct ec_point_st EC_POINT;
 
+typedef struct ecpk_parameters_st ECPKPARAMETERS;
+typedef struct ec_parameters_st ECPARAMETERS;
+
 //
 /*   EC_METHODs for curves over GF(p)   */
 //
@@ -393,6 +396,38 @@ EC_GROUP *EC_GROUP_new_curve_GF2m(const BIGNUM *p, const 
BIGNUM *a,
  */
 EC_GROUP *EC_GROUP_new_by_curve_name(int nid);
 
+/** Creates a new EC_GROUP object from an ECPARAMETERS object
+ *  \param  params  pointer to the ECPARAMETERS object
+ *  \return newly created EC_GROUP object with specified curve or NULL
+ *  if an error occurred
+ */
+EC_GROUP *EC_GROUP_new_from_ecparameters(const ECPARAMETERS *params);
+
+/** Creates an ECPARAMETERS object for the the given EC_GROUP object.
+ *  \param  group   pointer to the EC_GROUP object
+ *  \param  params  pointer to an existing ECPARAMETERS object or NULL
+ *  \return pointer to the new ECPARAMETERS object or NULL
+ *  if an error occurred.
+ */
+ECPARAMETERS *EC_GROUP_get_ecparameters(const EC_GROUP *group,
+ECPARAMETERS *params);
+
+/** Creates a new EC_GROUP object from an ECPKPARAMETERS object
+ *  \param  params  pointer to an existing ECPKPARAMETERS object, or NULL
+ *  \return newly created EC_GROUP object with specified curve, or NULL
+ *  if an error occurred
+ */
+EC_GROUP *EC_GROUP_new_from_ecpkparameters(const ECPKPARAMETERS *params);
+
+/** Creates an ECPKPARAMETERS object for the the given EC_GROUP object.
+ *  \param  group   pointer to the EC_GROUP object
+ *  \param  params  pointer to an existing ECPKPARAMETERS object or NULL
+ *  \return pointer to the new ECPKPARAMETERS object or NULL
+ *  if an error occurred.
+ */
+ECPKPARAMETERS *EC_GROUP_get_ecpkparameters(const EC_GROUP *group,
+ECPKPARAMETERS *params);
+
 //
 /*   handling of internal curves*/
 //
@@ -702,6 +737,9 @@ int EC_GROUP_have_precompute_mult(const EC_GROUP *group);
 /*   ASN1 stuff */
 //
 
+DECLARE_ASN1_ITEM(ECPKPARAMETERS)
+DECLARE_ASN1_ITEM(ECPARAMETERS)
+
 /*
  * EC_GROUP_get_basis_type() returns the NID of the basis type used to
  * represent the field elements
diff --git a/crypto/ec/ec_asn1.c b/crypto/ec/ec_asn1.c
index 2924374..d84c6d2 100644
--- a/crypto/ec/ec_asn1.c
+++ b/crypto/ec/ec_asn1.c
@@ -306,6 +306,28 @@ static EC_GROUP *ec_asn1_pkparameters2group(const 
ECPKPARAMETERS *);
 static ECPKPARAMETERS *ec_asn1_group2pkparameters(const EC_GROUP *,
   ECPKPARAMETERS *);
 
+EC_GROUP *EC_GROUP_new_from_ecparameters(const ECPARAMETERS *params)
+{
+return ec_asn1_parameters2group(params);
+}
+
+ECPARAMETERS *EC_GROUP_get_ecparameters(const EC_GROUP *group,
+ECPARAMETERS *params)
+{
+return ec_asn1_group2parameters(group, params);
+}
+
+EC_GROUP *EC_GROUP_new_from_ecpkparameters(const ECPKPARAMETERS *params)
+{
+return ec_asn1_pkparameters2group(params);
+}
+
+ECPKPARAMETERS *EC_GROUP_get_ecpkparameters(const EC_GROUP *group,
+ECPKPARAMETERS *params)
+{
+return ec_asn1_group2pkparameters(group, params);
+}
+
 /* the function definitions */
 
 static int ec_asn1_group2fieldid(const EC_GROUP *group, X9_62_FIELDID *field)
@@ -540,7 +562,7 @@ static

[openssl-dev] [PATCH] Export ASN1 templates for DH and ECDH groups

2015-01-27 Thread Dr. Matthias St. Pierre 
From: Dr. Matthias St. Pierre m...@ncp-e.com

Add missing forward declarations and export declarations for DHparams
and EC[PK]PARAMETERS.

Add public functions to convert between EC_GROUP objects and EC[PK]PARAMETERS
objects: EC_GROUP_new_from_ec[pk]parameters(), EC_GROUP_get_ec[pk]parameters().

Signed-off-by: Dr. Matthias St. Pierre matthias.st.pie...@ncp-e.com
---
 crypto/ec/ec.h  | 38 ++
 crypto/ec/ec_asn1.c | 30 ++
 util/libeay.num | 10 ++
 3 files changed, 74 insertions(+), 4 deletions(-)

This patch makes the ASN1 templates used internally by OpenSSL for
serializing DH and ECDH group parameters publicly available for reuse.

For example, if one wants to save a set of [EC]DH Groups together with
application defined data (e.g, group-name, group-id) to a file, it
is much easier to define a small set of ASN1 rules extending the existing
ones and let OpenSSL do the serialization, than fiddling around with
i2d_DHparams, i2d_ECParameters, etc. to embed the curve data as an 
opaque blob into an OCTET_STREAM.

The patch was created against the OpenSSL_1_0_2-stable branch. If possible,
it would be nice if it could be merged into the next 1.0.2 release.

diff --git a/crypto/ec/ec.h b/crypto/ec/ec.h
index 98edfdf..97ccee8 100644
--- a/crypto/ec/ec.h
+++ b/crypto/ec/ec.h
@@ -128,6 +128,9 @@ typedef struct ec_group_st
 
 typedef struct ec_point_st EC_POINT;
 
+typedef struct ecpk_parameters_st ECPKPARAMETERS;
+typedef struct ec_parameters_st ECPARAMETERS;
+
 //
 /*   EC_METHODs for curves over GF(p)   */
 //
@@ -393,6 +396,38 @@ EC_GROUP *EC_GROUP_new_curve_GF2m(const BIGNUM *p, const 
BIGNUM *a,
  */
 EC_GROUP *EC_GROUP_new_by_curve_name(int nid);
 
+/** Creates a new EC_GROUP object from an ECPARAMETERS object
+ *  \param  params  pointer to the ECPARAMETERS object
+ *  \return newly created EC_GROUP object with specified curve or NULL
+ *  if an error occurred
+ */
+EC_GROUP *EC_GROUP_new_from_ecparameters(const ECPARAMETERS *params);
+
+/** Creates an ECPARAMETERS object for the the given EC_GROUP object.
+ *  \param  group   pointer to the EC_GROUP object
+ *  \param  params  pointer to an existing ECPARAMETERS object or NULL
+ *  \return pointer to the new ECPARAMETERS object or NULL
+ *  if an error occurred.
+ */
+ECPARAMETERS *EC_GROUP_get_ecparameters(const EC_GROUP *group,
+ECPARAMETERS *params);
+
+/** Creates a new EC_GROUP object from an ECPKPARAMETERS object
+ *  \param  params  pointer to an existing ECPKPARAMETERS object, or NULL
+ *  \return newly created EC_GROUP object with specified curve, or NULL
+ *  if an error occurred
+ */
+EC_GROUP *EC_GROUP_new_from_ecpkparameters(const ECPKPARAMETERS *params);
+
+/** Creates an ECPKPARAMETERS object for the the given EC_GROUP object.
+ *  \param  group   pointer to the EC_GROUP object
+ *  \param  params  pointer to an existing ECPKPARAMETERS object or NULL
+ *  \return pointer to the new ECPKPARAMETERS object or NULL
+ *  if an error occurred.
+ */
+ECPKPARAMETERS *EC_GROUP_get_ecpkparameters(const EC_GROUP *group,
+ECPKPARAMETERS *params);
+
 //
 /*   handling of internal curves*/
 //
@@ -702,6 +737,9 @@ int EC_GROUP_have_precompute_mult(const EC_GROUP *group);
 /*   ASN1 stuff */
 //
 
+DECLARE_ASN1_ITEM(ECPKPARAMETERS)
+DECLARE_ASN1_ITEM(ECPARAMETERS)
+
 /*
  * EC_GROUP_get_basis_type() returns the NID of the basis type used to
  * represent the field elements
diff --git a/crypto/ec/ec_asn1.c b/crypto/ec/ec_asn1.c
index 2924374..d84c6d2 100644
--- a/crypto/ec/ec_asn1.c
+++ b/crypto/ec/ec_asn1.c
@@ -306,6 +306,28 @@ static EC_GROUP *ec_asn1_pkparameters2group(const 
ECPKPARAMETERS *);
 static ECPKPARAMETERS *ec_asn1_group2pkparameters(const EC_GROUP *,
   ECPKPARAMETERS *);
 
+EC_GROUP *EC_GROUP_new_from_ecparameters(const ECPARAMETERS *params)
+{
+return ec_asn1_parameters2group(params);
+}
+
+ECPARAMETERS *EC_GROUP_get_ecparameters(const EC_GROUP *group,
+ECPARAMETERS *params)
+{
+return ec_asn1_group2parameters(group, params);
+}
+
+EC_GROUP *EC_GROUP_new_from_ecpkparameters(const ECPKPARAMETERS *params)
+{
+return ec_asn1_pkparameters2group(params);
+}
+
+ECPKPARAMETERS *EC_GROUP_get_ecpkparameters(const EC_GROUP *group,
+ECPKPARAMETERS *params)
+{
+return