Interestingly, it is part of standard (automated) operations
here. Specifically, we use it to verify that data from the
past was actually signed with certificates that were valid at
that (past) point in time.
It is not an ideal interface, but seems reliable in the
controlled environment where it
I got my application to support openssl s_client connections using the
ephemeral ECDH cipher suites. I didn't initialize it properly.
Now I am looking at how to get my application accept openssl connections
from a client with multiple curves instead of just "NID_X9_62_prime256v1".
I appreciate any
+1
I agree with Daniel's sentiment and respectfully suggest EPV_Seal* and
EVP_Open be updated and kept up to date.
We all know how easy it is to get crypto wrong. Having "one stop shop"
functions like these are invaluable for when it comes to getting crypto
right.
Norm Green
On 9/9/2016
Hi Jakob,
Thanks. It solved my problem for now. I agree with your suggestion.
In our scenario this would be a regular thing for coming years and will
not be seen as standard way for operations.
--
Rishi Pathak
On Fri, Sep 9, 2016 at 5:00 PM, Jakob Bohm wrote:
> On 09/09/2016 12:11, Rishi P
On Fri, Sep 9, 2016 at 8:26 AM, Pfluegl, Andreas wrote:
> We started using OpenSSL in 2010 for Windows and Linux. We gladly followed
> the release strategy suggestion, as it allowed us to deliver patches without
> recompiling our code. So we still compile and link our code against 1.0.0
> while de
We started using OpenSSL in 2010 for Windows and Linux. We gladly followed the
release strategy suggestion, as it allowed us to deliver patches without
recompiling our code. So we still compile and link our code against 1.0.0 while
delivering the current 1.0.2x versions (which by the way works g
On Fri, Sep 09, 2016, Aleksandr Konstantinov wrote:
> Hello,
>
> Thanks for your answer. Here is one of d2i functions simplified:
>
> MYEXT * d2i_MYEXT(MYEXT ** myext, unsigned char ** pp, long length) {
> M_ASN1_D2I_vars(myext, MYEXT *, MYEXT_new);
> M_ASN1_D2I_Init();
> M_ASN1_D2I_start_
On 09/09/2016 12:11, Rishi Pathak wrote:
Hi,
For a reason we require lastUpdate to be set to a date in the
previous year, with
nextUpdate a year from now in our CRL. Search on google led me to a
patch which
allows use of startDate/endDate for CRL generation as well apart from
certificat
Thanks for the reply! Unfortunately I'm not sure I understand what
you're saying.
If EVP_Seal* is an old function, is there a new function with which we
can accomplish the same functionality?
What I mean is that the EVP_PKEY_encrypt() looks functionally the same
as RSA_public_encrypt() (just encr
Hi,
For a reason we require lastUpdate to be set to a date in the
previous year, with
nextUpdate a year from now in our CRL. Search on google led me to a patch
which
allows use of startDate/endDate for CRL generation as well apart from
certificates.
Seems like 1.0-1 does not have it. Any poi
10 matches
Mail list logo