Re: Q: creating CSR for encryption-only cert?

[Blumenthal, Uri - 0553 - MITLL]

Thank you - and it’s great to see that 100% PQ Key Exchange is working with the 
existing code (I assume - based on liboqs?). 

But generating signature is not acceptable in my use case, which is why we 
settled on a KEMTLS-like approach. Or, conceptually, like MQV/HMQV. 
Authenticating the peer implicitly by having its long-term (certified) public 
key participating in the Key Exchange. 

I fully realize that the current TLS-1.3 does not support this kind of Key 
Exchange. Which is fine, because we’re not using TLS. :-)

Thanks

Regards,
Uri

> On Oct 3, 2022, at 17:02, Mark Hack  wrote:
> 
> 
> In this case you need to look at certificate / signature generation 
> separately from the key exchange.  In classical terms, I can have anRSA key 
> with a RSA-SHA256 signature and use DHE elliptic curves to exchange a secret 
> without knowing the elliptic curve public private key pair.
> 
> For example to use Dilthium public/private keys and a Dilithium signature , 
> you can use the following to generate a csr ( or self sign):
> 
> openssl req -new -newkey dilithium2  -keyout qsc.key -config openssl.cnf 
> -nodes 
> 
> 
> After you have the signed certificate, TLS uses that certificate but 
> specifies Kyber for the key exchanges.
> 
> I self signed a dilithium certificate and started a server using:
> openssl s_server -cert  dilithium.crt -key dilithium.key -groups kyber768 
> 
> 
> Then connected with a client using:
> openssl s_client -connect 127.0.0.1:4433  -groups kyber768
> 
> This return a good connection:
> 
> No client certificate CA names sent
> Peer signature type: Dilithium2
> Server Temp Key: kyber768
> ---
> SSL handshake has read 7911 bytes and written 1589 bytes
> Verification error: self signed certificate
> ---
> New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
> Server public key is 10496 bit
> 
> 
> Regards
> Mark Hack
> 
> 
> 
>> On Mon, 2022-10-03 at 15:11 +, Blumenthal, Uri - 0553 - MITLL wrote:
>> TLDR;
>> Need to create a CSR for a key pair whose algorithm does not allow signing 
>> (either because it’s something like Kyber, or because restriction enforced 
>> by HSM). How to do it?
>>  
>> There are several use cases that require certifying long-term asymmetric 
>> keys that are only capable of encryption/decryption – but not 
>> signing/verification. That could be either because the algorithm itself does 
>> not do signing, or because the private key is generated and kept in a secure 
>> hardware that enforces usage restriction.
>>  
>> CSR is supposed to be signed by the corresponding private key to prove 
>> possession. Obviously, it cannot be done with a key such as described above. 
>> How is this problem addressed in the real world?  With AuthKEM and KEMTLS, 
>> how would these protocols get their certificates?
>>  
>> Thanks!
>> --
>> V/R,
>> Uri Blumenthal  Voice: (781) 981-1638 
>> Secure Resilient Systems and Technologies   Cell:  (339) 223-5363
>> MIT Lincoln Laboratory 
>> 244 Wood Street, Lexington, MA  02420-9108  
>>  
>> Web: https://www.ll.mit.edu/biographies/uri-blumenthal
>> Root CA: https://www.ll.mit.edu/llrca2.pem
>>  
>> There are two ways to design a system. One is to make it so simple there are 
>> obviously no deficiencies.
>> The other is to make it so complex there are no obvious deficiencies.
>>  
>> -  C. A. R. Hoare
>>  


smime.p7s
Description: S/MIME cryptographic signature

Re: creating CSR for encryption-only cert?

[Blumenthal, Uri - 0553 - MITLL]

David,

 

Thank you! That’s a great answer. It looks like OpenSSL does support CRMF? 
Would you or somebody else have an example of how to work with CRMF (to create 
it, and to process/sign it)?

 

Do you happen to know if CRMF is accepted by the “big players” in the CA field? 

 

Thank you again!

--

V/R,

Uri

 

There are two ways to design a system. One is to make it so simple there are 
obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.


 -  C. A. R. Hoare

 

 

From: David von Oheimb 
Date: Monday, October 3, 2022 at 15:13
To: Uri Blumenthal , openssl-users 
Subject: Re: Q: creating CSR for encryption-only cert?

 

Requesting a cert in a CSR for a key pair that cannot be used for signing is 
indeed impossible in the widely used PKCS#10 format 
(except if one break sthe PKCS#10 requirement of a self-signature, e.g., by 
applying a dummy signature). 

A viable solution is to use a different CSR format, such as CRMF. 
This format is the preferred one by CMP and CMC (while they also support 
PKCS#10) because it is much more flexible. 
CRMF does not strictly require to provide a proof-of-possession (PoP), and it 
offeres also indirect ways of doing a PoP. 
For instance, for encryption keys the new cert can be returned by the CA in 
encrypted form (using the new public key) to the EE, 
and the EE will only be able to make use of the cert if it is able to decrypt 
it, which proves possession of the private key. 

David 


On Mon, 2022-10-03 at 15:11 +, Blumenthal, Uri - 0553 - MITLL wrote: 

> TLDR; 
> Need to create a CSR for a key pair whose algorithm does not allow 
> signing (either because it’s something like Kyber, or because 
> restriction enforced by HSM). How to do it? 
>   
> There are several use cases that require certifying long-term 
> asymmetric keys that are only capable of encryption/decryption – but 
> not signing/verification. That could be either because the algorithm 
> itself does not do signing, or because the private key is generated 
> and kept in a secure hardware that enforces usage restriction. 
>   
> CSR is supposed to be signed by the corresponding private key to 
> prove possession. Obviously, it cannot be done with a key such as 
> described above. How is this problem addressed in the real world? 
>  With AuthKEM and KEMTLS, how would these protocols get their 
> certificates? 
>   
> Thanks! 
> -- 
> V/R, 
> Uri Blumenthal  Voice: (781) 981-1638  
> Secure Resilient Systems and Technologies   Cell:  (339) 223-5363 
> MIT Lincoln Laboratory  
> 244 Wood Street, Lexington, MA  02420-9108   
>   
> Web: https://www.ll.mit.edu/biographies/uri-blumenthal 
> Root CA: https://www.ll.mit.edu/llrca2.pem 
>   



smime.p7s
Description: S/MIME cryptographic signature

Q: creating CSR for encryption-only cert?

[Blumenthal, Uri - 0553 - MITLL]

TLDR; 

Need to create a CSR for a key pair whose algorithm does not allow signing 
(either because it’s something like Kyber, or because restriction enforced by 
HSM). How to do it?

 

There are several use cases that require certifying long-term asymmetric keys 
that are only capable of encryption/decryption – but not signing/verification. 
That could be either because the algorithm itself does not do signing, or 
because the private key is generated and kept in a secure hardware that 
enforces usage restriction.

 

CSR is supposed to be signed by the corresponding private key to prove 
possession. Obviously, it cannot be done with a key such as described above. 
How is this problem addressed in the real world?  With AuthKEM and KEMTLS, how 
would these protocols get their certificates?

 

Thanks!

--

V/R,

Uri Blumenthal  Voice: (781) 981-1638 

Secure Resilient Systems and Technologies   Cell:  (339) 223-5363

MIT Lincoln Laboratory  

244 Wood Street, Lexington, MA  02420-9108  

 

Web: https://www.ll.mit.edu/biographies/uri-blumenthal

Root CA: https://www.ll.mit.edu/llrca2.pem

 

There are two ways to design a system. One is to make it so simple there are 
obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.


 -  C. A. R. Hoare

 



smime.p7s
Description: S/MIME cryptographic signature

Re: 3.0.3 - EVP_EC_gen() segfault without init

[Blumenthal, Uri - 0553 - MITLL]

What platform?

$ bat ossl3-tst.c
───┬──
   │ File: ossl3-tst.c
   │ Size: 216 B
───┼──
   1   │ #include 
   2   │ #include 
   3   │ #include 
   4   │ 
   5   │ int main(int argc, const char *argv[]) {
   6   │  //OPENSSL_init_crypto(0, NULL);
   7   │  if (! EVP_EC_gen("P-384")) return -1;
   8   │  return 0;
   9   │ }
───┴──
$ gcc -Wall -Werror -pedantic -o ossl3-tst ossl3-tst.c -I/opt/local/include 
-L/opt/local/lib -lcrypto
$ ./ossl3-tst 
$

Above is on MacOS Monterey with GCC-11.
--
V/R,
Uri
 
There are two ways to design a system. One is to make it so simple there are 
obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.

 -  C. A. R. Hoare
 

On 5/4/22, 15:58, "openssl-users on behalf of Klaus Keppler" 
 wrote:

Hello,

yesterday we updated OpenSSL from 3.0.2 to 3.0.3, what made some of our 
unit tests crash.

I've boiled the problem down to the following example code:

---cut---
#include 
#include 
#include 

int main(int argc, const char *argv[]) {
 //OPENSSL_init_crypto(0, NULL);
 if (! EVP_EC_gen("P-384")) return -1;
 return 0;
}
---/cut---

Compile with:

   gcc -Wall -Werror -pedantic -o test test.c -lcrypto

With OpenSSL 3.0.2 this runs just fine, with OpenSSL 3.0.3 we get a 
segmentation fault during a string comparison within EVP_PKEY_Q_keygen 
(EVP_EC_gen is just a macro).

I assume that the curve names are not properly initialized, when you 
uncomment the call to "OPENSSL_init_crypto()", everything works just fine.

The documentation [1] of OPENSSL_init_crypto() states that explicit 
initialization is not required. Man page of EVP_EC_gen [2] says nothing 
about initialization.
Considering that 3.0.3 is only a minor update and 3.0.2 worked as 
expected, we might have hit a bug. If this (above) is "just" a usage 
error, the documentation should describe in which cases an explicit 
initialization is required.

Anyway, thank you for all your efforts!

Best regards

-Klaus Keppler


[1] https://www.openssl.org/docs/man3.0/man3/OPENSSL_init_crypto.html
[2] https://www.openssl.org/docs/man3.0/man3/EVP_EC_gen.html


smime.p7s
Description: S/MIME cryptographic signature

Re: Mac OS X and openssl 3

[Blumenthal, Uri - 0553 - MITLL]

>> Just wondering if Apple OS is compatible with OPenssl 3 .
>> 
>
>MacOS should work just fine with OpenSSL 3.0. At least master is 
>regularly tested, e.g.
>
>https://github.com/openssl/openssl/runs/6151999376?check_suite_focus=true

It works fine on all of my MacOS machines, varying from Catalina (back when) to 
Monterey (now).


smime.p7s
Description: S/MIME cryptographic signature

Re: EVP_PKEY_get_int_param is not getting degree from EC key

[Blumenthal, Uri - 0553 - MITLL]

The problem that I see is that there's a set of parameters (such as 
OSSL_PKEY_PARAM_EC_COFACTOR), not described in the man pages, with 
under-specified type. 
E.g., how is one to know where's "normal" ~~sloppiness~~ imperfection in 
writing, and where "unsigned integer" truly means 'NOT C type "unsigned int"', 
especially since it's all in a C API description (so one tends to expect C 
types, unless CLEARLY stated otherwise)?

Beneficial - would be a man page that lists these parameters, their types, and 
the appropriate method for retrieving them (e.g., EVP_PKEY_get_int_param() or 
EVP_PKEY_get_bn_param()).

I support specifying the type in the comments as "unsigned BIGNUM" over "just 
adding a note".
--
Regards,
Uri
 
There are two ways to design a system. One is to make it so simple there are 
obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.

 -  C. A. R. Hoare
 

On 1/5/22, 18:17, "openssl-users on behalf of Dr Paul Dale" 
 wrote:

Better might be just adding a note to the parameters unlikely to fit 
into a machine integer rather than confounding things with an additional 
type which isn't really a separate type.


Pauli

> "unsigned BIGNUM" instead of "unsigned integer" would be short and 
> much clearer
> in the description and naming of parameters unlikely to fit in a C 
> int/long.
>



smime.p7s
Description: S/MIME cryptographic signature

Re: EVP_PKEY_get_int_param is not getting degree from EC key

[Blumenthal, Uri - 0553 - MITLL]

>  > But, considering that the man pages describe C API, wouldn't it be
>  > nice to mention (even though it may be obvious that a number of order
>  > 2^384 might not fit into 32 or even 64 bits) that the actual type is
>  > BIGNUM?
>
>  No, the type is not a BIGNUM. Please read "man OSSL_PARAM" it contains
>  the information on what types OSSL_PARAM support.

I did that before playing with and modifying the OP's code. Obviously, either 
I'm too dense to understand it, or it's too dense.

>  > Also, what should arguments to that C call EVP_PKEY_get_int_param()
>  > look like to succeed? Do I need to pass a pointer to BN there???
>
>  Please read "man EVP_PKEY_get_int_param".

See above. Some verbiage, very little clues - especially for somebody who 
doesn't already know how it works.

   int EVP_PKEY_get_int_param(const EVP_PKEY *pkey, const char *key_name,
  int *out);
   EVP_PKEY_get_int_param() retrieves a key pkey integer value *out associated 
with a name of key_name.

Overall, VERY confusing.

How does one know (without going through EVP_PKEY_gettable_params(EVP_PKEY 
*pkey) and EVP_PKEY_get_params(const EVP_PKEY *pkey, OSSL_PARAM params[])) what 
method to use to retrieve what parameter?


smime.p7s
Description: S/MIME cryptographic signature

Re: EVP_PKEY_get_int_param is not getting degree from EC key

[Blumenthal, Uri - 0553 - MITLL]

>  > In other words, the man page says it's unsigned int, but in fact it's
>  > BIGNUM? Because the pointer I gave was to "unsigned int", like in the
>  > OP's code.
>
>  The param is too big to fit into int. If you were using some
>  ridiculously small EC curve the call would succeed. The parameter types
>  != C types and the manual page does not say "unsigned int" but
>  "unsigned integer" for a reason.

Yes, that makes sense. 

But, considering that the man pages describe C API, wouldn't it be nice to 
mention (even though it may be obvious that a number of order 2^384 might not 
fit into 32 or even 64 bits) that the actual type is BIGNUM?

Also, what should arguments to that C call EVP_PKEY_get_int_param() look like 
to succeed? Do I need to pass a pointer to BN there???


smime.p7s
Description: S/MIME cryptographic signature

Re: EVP_PKEY_get_int_param is not getting degree from EC key

[Blumenthal, Uri - 0553 - MITLL]

On 1/4/22, 11:23, "Tomas Mraz"  wrote:

>  > Theoretically, shouldn’t
>  > 
>  > EVP_PKEY_get_int_param(pkey, OSSL_PARAM_EC_ORDER, &(unsigned int)order)
>  > 
>  > work? I verified that it does not seem to work, at least in the
>  > obvious context. 
>
>  OSSL_PARAM_EC_ORDER is an unsigned integer (also a bignum) and it won't
>  fit into int. So that's the reason why that call fails.

In other words, the man page says it's unsigned int, but in fact it's BIGNUM? 
Because the pointer I gave was to "unsigned int", like in the OP's code.

This works, BTW:

  if (!(ec_grp = EC_GROUP_new_by_curve_name(ECCTYPE)))
ERR("EC_GROUP_new_by_curve_name");
  const BIGNUM *ord = EC_GROUP_get0_order(ec_grp);
  fprintf(stderr, "order = ");
  BN_print_fp(stderr, ord); fprintf(stderr, "\n");
  printf("order = %s\n", BN_bn2dec(ord));


>  Also the order is not a degree (maximum number of bits of a curve
>  coordinate).

Yeah, I was trying to figure if *any* of EC-related parameters would work...




smime.p7s
Description: S/MIME cryptographic signature

Re: EVP_PKEY_get_int_param is not getting degree from EC key

[Blumenthal, Uri - 0553 - MITLL]

Now I became interested. ;-)

Theoretically, shouldn’t

EVP_PKEY_get_int_param(pkey, OSSL_PARAM_EC_ORDER, &(unsigned int)order)

work? I verified that it does not seem to work, at least in the obvious 
context. 

What is the purpose of that parameter and function call, and where/how can one 
use it?

Regards,
Uri

> On Jan 4, 2022, at 03:36, Tomas Mraz  wrote:
> 
> On Tue, 2022-01-04 at 02:33 +0100, Wolf wrote:
>> Thank you for the answer!
>> 
>>> On 2022-01-03 10:11:19 +0100, Tomas Mraz wrote:
>>> You're using the secp384r1 curve which is a prime field curve. The
>>> OSSL_PKEY_PARAM_EC_CHAR2_M parameter can be obtained only for
>>> binary
>>> field curves.
>>> 
>>> If you have a group NID for the curve of the EC key, you could use:
>>> 
>>> EC_GROUP *group = EC_GROUP_new_by_curve_name_ex(NULL, NULL, nid);
>>> 
>>> to create the group to call EC_GROUP_get_degree() on.
>>> 
>>> Of course if you can have an EC key with arbitrary explicit group
>>> parameters, that would not work.
>> 
>> That is sadly the case of me.
>> 
>>> But you can then use number of bits of the OSSL_PKEY_PARAM_EC_P
>>> parameter as the degree for prime field curves.
>> 
>> So, I've tried following your advice, but for some reason it is still
>> failing for me. I've modified my example program to be:
> 
> You need to use EVP_PKEY_get_bn_param() to get the P parameter and
> BN_num_bits() to count the number of bits of the P value.
> 
> 
> -- 
> Tomáš Mráz, OpenSSL
> 
> 


smime.p7s
Description: S/MIME cryptographic signature

Re: OpenSSL 1.1 on OSX

[Blumenthal, Uri - 0553 - MITLL]

The problem is that symlinking doesn't work in this case. Sure, I can install 
openSSL, and then it works. For me. But I'm trying to distribute an 
application, and to do that on modern macs, I need a hardened run time. And the 
rule for that is that all code your application uses must be signed either by 
you or by apple. 

 

It is trivial to install OpenSSL-1.1.1 via Macports, and build/link an app with 
hardened run time against it. XCode offers an option to embed and sign the 
libraries you’re linking against.

 

Another option is to state in the docs that this app depends on user installing 
Macports port “openssl11”.

 

If neither option is sufficient, I can’t help you, sorry.

 

 

On Sat, Nov 20, 2021 at 5:28 AM Blumenthal, Uri - 0553 - MITLL 
 wrote:

Here's how Macports did it:

1. Installed OpenSSL-1.1.1 into /opt/local/libexec/openssl11;
2. Installed OpenSSL-3.0.0 into /opt/local/libexec/openssl3;
3. Symlinked OpenSSL-3.0.0 libraries into /opt/local/lib (primary directory 
where stuff lives);

I added symlinking /opt/local/libexec/openssl11/lib/libcrypto.1.1.dylib into 
/opt/local/lib too.

This allows compiling new apps against OpenSSL-1.1.1 in 
/opt/local/libexec/openssl11. Old binaries do not need to be recompiled, as 
they can find libcrypto.1.1.dylib and libssl.1.1.dylib in the "standard" 
location (/opt/local/lib).

Hope this helps.
--
Regards,
Uri

There are two ways to design a system. One is to make is so simple there are 
obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.

 -  C. A. R. Hoare


On 11/19/21, 13:16, "openssl-users on behalf of Viktor Dukhovni" 
 
wrote:

On Fri, Nov 19, 2021 at 05:36:24PM +1100, Grahame Grieve wrote:

> It's very definitely something active that OSX is doing. Here's an OSX
> error generated:
> 
> System Integrity Protection: enabled
> 
> Crashed Thread:0  Dispatch queue: com.apple.main-thread
> 
> Exception Type:EXC_CRASH (SIGABRT)
> Exception Codes:   0x, 0x
> Exception Note:EXC_CORPSE_NOTIFY
> 
> Application Specific Information:
> abort() called
> Invalid dylib load. Clients should not load the unversioned libcrypto
> dylib as it does not have a stable ABI.

Well, I think that's evidence of confusion about which "libcrypto" to
load.  It sure seems that you're trying to load the default system
libcrypto, not the one in the application bundle.

You should probably arrange to "salt" the names of the libssl and
libcrypto libraries used by your application, so that there can't
be any confusion with the platform's libssl and libcrypto.

May also need to do something to avoid symbol name collisions, but I
haven't looked into how that works on Darwin, so can't offer specific
advice.

-- 
Viktor.


 

-- 

-
http://www.healthintersections.com.au / grah...@healthintersections.com.au / 
+61 411 867 065

Benson & Grieve:   Principles of Health Interoperability (Health Information 
Technology Standards), 4th ed -  http://www.springer.com/978-3-030-56882-5



smime.p7s
Description: S/MIME cryptographic signature

Re: OpenSSL 1.1 on OSX

[Blumenthal, Uri - 0553 - MITLL]

Here's how Macports did it:

1. Installed OpenSSL-1.1.1 into /opt/local/libexec/openssl11;
2. Installed OpenSSL-3.0.0 into /opt/local/libexec/openssl3;
3. Symlinked OpenSSL-3.0.0 libraries into /opt/local/lib (primary directory 
where stuff lives);

I added symlinking /opt/local/libexec/openssl11/lib/libcrypto.1.1.dylib into 
/opt/local/lib too.

This allows compiling new apps against OpenSSL-1.1.1 in 
/opt/local/libexec/openssl11. Old binaries do not need to be recompiled, as 
they can find libcrypto.1.1.dylib and libssl.1.1.dylib in the "standard" 
location (/opt/local/lib).

Hope this helps.
--
Regards,
Uri
 
There are two ways to design a system. One is to make is so simple there are 
obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.

 -  C. A. R. Hoare
 

On 11/19/21, 13:16, "openssl-users on behalf of Viktor Dukhovni" 
 
wrote:

On Fri, Nov 19, 2021 at 05:36:24PM +1100, Grahame Grieve wrote:

> It's very definitely something active that OSX is doing. Here's an OSX
> error generated:
> 
> System Integrity Protection: enabled
> 
> Crashed Thread:0  Dispatch queue: com.apple.main-thread
> 
> Exception Type:EXC_CRASH (SIGABRT)
> Exception Codes:   0x, 0x
> Exception Note:EXC_CORPSE_NOTIFY
> 
> Application Specific Information:
> abort() called
> Invalid dylib load. Clients should not load the unversioned libcrypto
> dylib as it does not have a stable ABI.

Well, I think that's evidence of confusion about which "libcrypto" to
load.  It sure seems that you're trying to load the default system
libcrypto, not the one in the application bundle.

You should probably arrange to "salt" the names of the libssl and
libcrypto libraries used by your application, so that there can't
be any confusion with the platform's libssl and libcrypto.

May also need to do something to avoid symbol name collisions, but I
haven't looked into how that works on Darwin, so can't offer specific
advice.

-- 
Viktor.


smime.p7s
Description: S/MIME cryptographic signature

Re: OpenSSL 1.1 on OSX

[Blumenthal, Uri - 0553 - MITLL]

I don't use Brew. I've installed OpenSSL-1.1.1 (and 3.0.0) via Macports, and 
have no problem linking and running apps against 1.1.1.

--
Regards,
Uri
 
There are two ways to design a system. One is to make is so simple there are 
obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.

 -  C. A. R. Hoare
 

On 11/19/21, 08:03, "openssl-users on behalf of Hubert Kario" 
 wrote:

On Friday, 19 November 2021 07:36:24 CET, Grahame Grieve wrote:
> It's very definitely something active that OSX is doing. Here's 
> an OSX error generated:
>
> System Integrity Protection: enabled
>
> Crashed Thread:0  Dispatch queue: com.apple.main-thread
>
> Exception Type:EXC_CRASH (SIGABRT)
> Exception Codes:   0x, 0x
> Exception Note:EXC_CORPSE_NOTIFY
>
> Application Specific Information:
> abort() called
> Invalid dylib load. Clients should not load the unversioned 
> libcrypto dylib as it does not have a stable ABI.

and you're sure it's trying to load the libcrypto of the OpenSSL 1.1.1, 
not,
for example a 0.9.8 version of it?

>
>
> On Fri, Nov 19, 2021 at 5:29 PM Viktor Dukhovni 
>  wrote:
> On Fri, Nov 19, 2021 at 04:31:26PM +1100, Grahame Grieve wrote:
>
>> I'm trying to get my application that uses openSSL 1.1 running 
>> on OSX. I've
>> installed them using homebrew, but I can't get past Apple's gates around
>> blocking use of openSSL.
>
> I don't think they're actively doing blocking here, though I could
> perhaps be wrong...
>
>> I've copied both dylibs into my app /Contents/MacOS folder, and signed
>> both of them, and I load them from the that location, but OSX still
>> blocks loading.
>
> More accurately I think, the libraries fail to load.
>
>> It actually blocks loading libssl.1.1.dylib, with a message 
>> about libcrypto
>> - presumably libssl has a non-version dependence on libcrypto that OSX is
>> blocking?
>
> The problem is likely that "libssl" not built to locate "libcrypto"
> relative to its own location, but rather expects to find it at a fixed
> location.  This would be some MacOS-specific instance of setting the
> runpath to $ORIGIN on ELF systems.
>
> With OpenSSL installed at a fixed location, OpenSSL is working just
> fine for me (and of course in HomeBrew, ...).
>
> So the issue most probably the inability of "libssl.dylib" to find
> "libcrypt.dylib", not because of some policy enforcement by Apple's
> evil overlords, but simply because the runtime linker does not
> expect to look in the location where you have libcrypt installed.
>
> The only thing that gives me some pause is Whether or not notarisation
> also complicates relocation, but presumably applications can ship
> shared libraries with the application code without running into
> major obstacles.
>
> Perhaps the presence of LibreSSL on MacOS is another complication,
> but that libssl and libcrypt should have different version suffixes,
> and should not get in the way, provided that MacOS has something
> akin to symbol versioning, to allow separate API versions of the
> same library to exist in a process side by side without getting
> in each other's way.
>
> If the symbol namespace in MacOS is "flat", then you may indeed
> run into trouble because of symbol conflicts between the real
> OpenSSL and the LibreSSL fork.
>
> Good luck.
>

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic



smime.p7s
Description: S/MIME cryptographic signature

Re: OpenSSL-3.+ how to configure [random]?

[Blumenthal, Uri - 0553 - MITLL]

On 11/10/21, 15:20, "openssl-users on behalf of Dr Paul Dale" 
 wrote:
>
>  I'm pretty sure the underlying problem is that there is a call to 
>  RAND_set_rand_method() or RAND_set_rand_engine() occurring (likely the 
>  latter).

Probably...

>  These completely replace the built in RNG infrastructure with the 
>  RAND_METHOD/engine.  If the engine then fails to produce output for any 
>  reason, the observed results will present.

And randomness retrieval in PKCS#11 engine is broken, because otherwise it 
would've gotten some randomness form the hardware token, right?

>  Adding the RDRAND engine again replaces the RAND_METHOD and things begin 
>  working.

Yes...

>  I've no idea why the PKCS#11 engine has stopped working with 3.0. It 
>  wasn't meant to.

This made me questioning what's going on. It's been quite some time since I 
updated 'pkcs11' engine for OSSL-1.1.1.

And I observe that the current version of the PKCS#11 engine does not work 
correctly, i.e., does not serve randomness, on OpenSSL-1.1.1 *and* 3.x.

$ OPENSSL_CONF="" openssl version
OpenSSL 3.0.0 7 sep 2021 (Library: OpenSSL 3.0.0 7 sep 2021)
$ OPENSSL_CONF="" openssl rand -engine pkcs11 -hex 8
Engine "pkcs11" set.
$ OPENSSL_CONF="" openssl-1.1 rand -engine pkcs11 -hex 8
engine "pkcs11" set.
$ OPENSSL_CONF="" ~/openssl-3/bin/openssl version
OpenSSL 3.1.0-dev  (Library: OpenSSL 3.1.0-dev )
$ OPENSSL_CONF="" ~/openssl-3/bin/openssl rand -engine pkcs11 -hex 8
Engine "pkcs11" set.
$ OPENSSL_CONF="" openssl rand -hex 8
71f7744c5190385f
$

I'll bring this up with its maintainers.

Thanks!


On 11/11/21 1:36 am, Blumenthal, Uri - 0553 - MITLL wrote:
> Yes, it's related to https://github.com/openssl/openssl/issues/16996, and 
yes - the same solution worked.
>
> There's something wrong with how PKCS#11 engine deals with (or presents 
itself as) rand provider.
> In any case, removing PKCS#11 engine from the [engines] section 
alleviated this problem.
>
> Thanks!
>
> P.S. I configured rand seed sources the standard way: 
"--with-rand-seed=rdcpu,os", as I think everybody does.



smime.p7s
Description: S/MIME cryptographic signature

Re: OpenSSL-3.+ how to configure [random]?

[Blumenthal, Uri - 0553 - MITLL]

Yes, it's related to https://github.com/openssl/openssl/issues/16996, and yes - 
the same solution worked.

There's something wrong with how PKCS#11 engine deals with (or presents itself 
as) rand provider.
In any case, removing PKCS#11 engine from the [engines] section alleviated this 
problem.

Thanks!

P.S. I configured rand seed sources the standard way: 
"--with-rand-seed=rdcpu,os", as I think everybody does.
-- 
Regards,
Uri
 

On 11/10/21, 06:03, "Nicola Tuveri"  wrote:

Just chiming in quickly to mention that this could be related to
https://github.com/openssl/openssl/issues/16996

Nicola

On Wed, Nov 10, 2021 at 10:33 AM Tomas Mraz  wrote:
>
> On Wed, 2021-11-10 at 03:38 +0000, Blumenthal, Uri - 0553 - MITLL
> wrote:
> > On 11/9/21, 22:23, "Dr Paul Dale"  wrote:
> >
> > >Currently I've no idea and can't reproduce locally :(
> >
> > Maybe you'd know how to force the "-engine rdrand" path through
> > "openssl.cnf"?
> >
> > >A rogue configuration file could cause the DRBGs/seeds to fail.
> > > Do you
> > >have seed=rdrand line in the random section?  That will cause
> > > the
> > >seeding source to fail to load at all.
> >
> > No, I don't - and providing empty config causes the same result:
> >
> > $ OPENSSL_CONF=/dev/null openssl3 rand -hex 4
> > $ OPENSSL_CONF=/dev/null openssl3 rand -engine rdrand -hex 4
> > Engine "rdrand" set.
> > 61f1666d
>
> How did you configure the rand seed sources when building OpenSSL? I
> think rather than trying to make the rdrand engine default it would
> make more sense to try to resolve the problem with the rand provider
> and its seeding. What is the exit code of the first execution of the
> rand command? Could you try to run it under strace and/or gdb to
> investigate?
> --
> Tomáš Mráz
> No matter how far down the wrong road you've gone, turn back.
>   Turkish proverb
> [You'll know whether the road is wrong if you carefully listen to your
> conscience.]
>
>


smime.p7s
Description: S/MIME cryptographic signature

Re: OpenSSL-3.+ how to configure [random]?

[Blumenthal, Uri - 0553 - MITLL]

On 11/9/21, 23:07, "Dr Paul Dale"  wrote:

>There is documentation: 
> https://www.openssl.org/docs/man3.0/man5/config.html

Yes, I know. Alas, it's not helpful at all. RDRAND is an *engine*, but it does 
not seem to have a "separate" physical presence, like a shared library. For 
other engines I specify something like

[openssl_init]
providers = provider_sect
engines = engine_section

# List of providers to load
[provider_sect]
default = default_sect
legacy = legacy_sect

[default_sect]
activate = 1

[legacy_sect]
activate = 1

[engine_section]
pkcs11 = pkcs11_section
gost = gost_section

[pkcs11_section]
engine_id = pkcs11
dynamic_path = /opt/local/libexec/openssl3/lib/engines-3/pkcs11.dylib
MODULE_PATH = /Library/OpenSC/lib/opensc-pkcs11.so
init = 0

[gost_section]
engine_id = gost
dynamic_path = /opt/local/libexec/openssl3/lib/engines-3/gost.dylib
#default_algorithms = ALL
#CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet
PBE_PARAMS = "gost12_512"


Where does "rdrand" engine fit in, and how do I tell OpenSSL to load it? 
There's no "dynamic_path" that I know of.


I don't think the rdrand engine takes any extras.


    Pauli

On 10/11/21 1:38 pm, Blumenthal, Uri - 0553 - MITLL wrote:
> On 11/9/21, 22:23, "Dr Paul Dale"  wrote:
>
>> Currently I've no idea and can't reproduce locally :(
> Maybe you'd know how to force the "-engine rdrand" path through 
"openssl.cnf"?
>
>> A rogue configuration file could cause the DRBGs/seeds to fail.  Do 
you
>> have seed=rdrand line in the random section?  That will cause the
>> seeding source to fail to load at all.
> No, I don't - and providing empty config causes the same result:
>
> $ OPENSSL_CONF=/dev/null openssl3 rand -hex 4
> $ OPENSSL_CONF=/dev/null openssl3 rand -engine rdrand -hex 4
    > Engine "rdrand" set.
> 61f1666d
> $
>
>
>  Pauli
>
>  On 10/11/21 1:10 pm, Blumenthal, Uri - 0553 - MITLL wrote:
>  > Thank you!
>  >
>  > I'm trying to:
>  >
>  > a. understand why something like "openssl-3 rand -hex 4" does not 
work (returns empty string), but "openssl-3 rand -engine rdrand -hex 4" works 
fine, and gives me my random bytes - here's an illustration
>  >
>  > $ openssl3 version
>  > OpenSSL 3.1.0-dev  (Library: OpenSSL 3.1.0-dev )
>  > $ openssl3 info -seeds
>  > rdrand ( rdseed rdrand ) os-specific
>  > $ openssl3 rand -hex 4
>  > $ openssl3 rand -engine rdrand -hex 4
>  > Engine "rdrand" set.
>  > d9b8f268
>  >
>  > and
>  >
>  > b. somehow force RDRAND engine to be loaded and initialized by 
default, so I don't have to include "-engine rdrand" in every invocation, 
especially since I often need to specify other engines (like "pkcs11").
>  >
>  > Here's my config, in case you spot something wrong with it (and 
yes, it includes "rdcpu"):
>  >
>  > ./config --prefix=${OPENSSL_DIR} --debug 
--openssldir=${OPENSSL_DIR}/etc --with-rand-seed=rdcpu,os 
enable-ec_nistp_64_gcc_128 enable-md2 enable-rc5 enable-rmd160 
enable-weak-ssl-ciphers zlib-dynamic enable-ssl-trace enable-trace threads 
enable-buildtest-c++
>  >
>  > Thanks
>  > --
>  > Regards,
>  > Uri
>  >
>  > There are two ways to design a system. One is to make is so simple 
there are obviously no deficiencies.
>  > The other is to make it so complex there are no obvious 
deficiencies.
>  >
   -  C. A. R. 
Hoare
>  >
>  >
>  > On 11/9/21, 21:49, "openssl-users on behalf of Dr Paul Dale" 
 wrote:
>  >
>  >  Currently there is exactly one seed source that is usable in 
OpenSSL
>  >  3.0: "SEED-SRC".  It is documented in EVP_RAND-SEED-SRC.  The 
reason the
>  >  seed source can be set is to allow you to use a third party 
provider
>  >  than includes one.
>  >
>  >  If you want to force RDRAND as the only seeding source, this 
needs to be
>  >  done at configuration time with the --with-rand-seed 
configuration
>  >  option.  Note that this will enable RDSEED in preference to 
RDRAND but
>  

Re: OpenSSL-3.+ how to configure [random]?

[Blumenthal, Uri - 0553 - MITLL]

On 11/9/21, 22:23, "Dr Paul Dale"  wrote:

>Currently I've no idea and can't reproduce locally :(

Maybe you'd know how to force the "-engine rdrand" path through "openssl.cnf"?

>A rogue configuration file could cause the DRBGs/seeds to fail.  Do you 
>have seed=rdrand line in the random section?  That will cause the 
>seeding source to fail to load at all.

No, I don't - and providing empty config causes the same result:

$ OPENSSL_CONF=/dev/null openssl3 rand -hex 4
$ OPENSSL_CONF=/dev/null openssl3 rand -engine rdrand -hex 4
Engine "rdrand" set.
61f1666d
$


    Pauli

    On 10/11/21 1:10 pm, Blumenthal, Uri - 0553 - MITLL wrote:
> Thank you!
>
> I'm trying to:
>
> a. understand why something like "openssl-3 rand -hex 4" does not work 
(returns empty string), but "openssl-3 rand -engine rdrand -hex 4" works fine, 
and gives me my random bytes - here's an illustration
>
> $ openssl3 version
> OpenSSL 3.1.0-dev  (Library: OpenSSL 3.1.0-dev )
> $ openssl3 info -seeds
> rdrand ( rdseed rdrand ) os-specific
> $ openssl3 rand -hex 4
> $ openssl3 rand -engine rdrand -hex 4
> Engine "rdrand" set.
> d9b8f268
>
> and
>
> b. somehow force RDRAND engine to be loaded and initialized by default, 
so I don't have to include "-engine rdrand" in every invocation, especially 
since I often need to specify other engines (like "pkcs11").
>
> Here's my config, in case you spot something wrong with it (and yes, it 
includes "rdcpu"):
>
> ./config --prefix=${OPENSSL_DIR} --debug --openssldir=${OPENSSL_DIR}/etc 
--with-rand-seed=rdcpu,os enable-ec_nistp_64_gcc_128 enable-md2 enable-rc5 
enable-rmd160 enable-weak-ssl-ciphers zlib-dynamic enable-ssl-trace 
enable-trace threads enable-buildtest-c++
>
> Thanks
> --
> Regards,
> Uri
>   
> There are two ways to design a system. One is to make is so simple there 
are obviously no deficiencies.
> The other is to make it so complex there are no obvious deficiencies.
>   
-  C. A. R. Hoare
>   
>
> On 11/9/21, 21:49, "openssl-users on behalf of Dr Paul Dale" 
 wrote:
>
>  Currently there is exactly one seed source that is usable in OpenSSL
>  3.0: "SEED-SRC".  It is documented in EVP_RAND-SEED-SRC.  The reason 
the
>  seed source can be set is to allow you to use a third party provider
>  than includes one.
>
>  If you want to force RDRAND as the only seeding source, this needs 
to be
>  done at configuration time with the --with-rand-seed configuration
>  option.  Note that this will enable RDSEED in preference to RDRAND 
but
>  will use RDRAND if RDSEED isn't available.
>
>  I assume that you meant openssl info -seeds not openssl list -seeds.
>  This lists the seed sources that were configured at build time.
>
>
>  There is no relationship between the RDRAND engine and the seed
>  sources.  Well, they both use the same machine instruction to get the
>  seed material but it's called from completely different places.
>
>
>  Yes, the man pages could be more informative and user friendly :(
>
>
>  Pauli
>
>  On 10/11/21 12:35 pm, Blumenthal, Uri - 0553 - MITLL wrote:
>  > "man config" for OpenSSL-3.0 and newer says that there can be 
"[random]" section in "openssl.cnf", where I can specify type of RNG, other 
things, and *seed*, and seed *properties*.
>  >
>  > Unfortunately, it did not bother to even list the possible/allowed 
values, let alone explain what they'd mean:
>  >
>  > Random Configuration
>  > The name random in the initialization section names the 
section containing the random number
>  > generater settings.
>  >
>  > Within the random section, the following names have 
meaning:
>  >
>  > random
>  > This is used to specify the random bit generator.  For 
example:
>  >
>  >  [random]
>  >  random = CTR-DRBG
>  >
>  > The available random bit generators are:
>  >
>  > CTR-DRBG
>  > HASH-DRBG
>  >

Re: OpenSSL-3.+ how to configure [random]?

[Blumenthal, Uri - 0553 - MITLL]

Thank you!

I'm trying to:

a. understand why something like "openssl-3 rand -hex 4" does not work (returns 
empty string), but "openssl-3 rand -engine rdrand -hex 4" works fine, and gives 
me my random bytes - here's an illustration

$ openssl3 version
OpenSSL 3.1.0-dev  (Library: OpenSSL 3.1.0-dev )
$ openssl3 info -seeds
rdrand ( rdseed rdrand ) os-specific
$ openssl3 rand -hex 4
$ openssl3 rand -engine rdrand -hex 4
Engine "rdrand" set.
d9b8f268

and

b. somehow force RDRAND engine to be loaded and initialized by default, so I 
don't have to include "-engine rdrand" in every invocation, especially since I 
often need to specify other engines (like "pkcs11").

Here's my config, in case you spot something wrong with it (and yes, it 
includes "rdcpu"):

./config --prefix=${OPENSSL_DIR} --debug --openssldir=${OPENSSL_DIR}/etc 
--with-rand-seed=rdcpu,os enable-ec_nistp_64_gcc_128 enable-md2 enable-rc5 
enable-rmd160 enable-weak-ssl-ciphers zlib-dynamic enable-ssl-trace 
enable-trace threads enable-buildtest-c++

Thanks
--
Regards,
Uri
 
There are two ways to design a system. One is to make is so simple there are 
obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.

 -  C. A. R. Hoare
 

On 11/9/21, 21:49, "openssl-users on behalf of Dr Paul Dale" 
 wrote:

Currently there is exactly one seed source that is usable in OpenSSL 
3.0: "SEED-SRC".  It is documented in EVP_RAND-SEED-SRC.  The reason the 
seed source can be set is to allow you to use a third party provider 
than includes one.

If you want to force RDRAND as the only seeding source, this needs to be 
done at configuration time with the --with-rand-seed configuration 
option.  Note that this will enable RDSEED in preference to RDRAND but 
will use RDRAND if RDSEED isn't available.

I assume that you meant openssl info -seeds not openssl list -seeds.  
This lists the seed sources that were configured at build time.


There is no relationship between the RDRAND engine and the seed 
sources.  Well, they both use the same machine instruction to get the 
seed material but it's called from completely different places.


Yes, the man pages could be more informative and user friendly :(


Pauli

On 10/11/21 12:35 pm, Blumenthal, Uri - 0553 - MITLL wrote:
> "man config" for OpenSSL-3.0 and newer says that there can be "[random]" 
section in "openssl.cnf", where I can specify type of RNG, other things, and 
*seed*, and seed *properties*.
>
> Unfortunately, it did not bother to even list the possible/allowed 
values, let alone explain what they'd mean:
>
> Random Configuration
> The name random in the initialization section names the section 
containing the random number
> generater settings.
>
> Within the random section, the following names have meaning:
>
> random
> This is used to specify the random bit generator.  For 
example:
>
>  [random]
>  random = CTR-DRBG
>
> The available random bit generators are:
>
> CTR-DRBG
> HASH-DRBG
> HMAC-DRBG
> .  .  .  .  .
> properties
> This sets the property query used when fetching the random 
bit generator and any
> underlying algorithms.
>
> seed
> This sets the randomness source that should be used.  By 
default SEED-SRC will be used
> outside of the FIPS provider.  The FIPS provider uses call 
backs to access the same
> randomness sources from outside the validated boundary.
>
> seed_properties
> This sets the property query used when fetching the 
randomness source.
>
> I want to configure this [random] to use CTR-DRBG, using RDRAND as 
"seed". Based on "openssl list -seeds", I guess "seed = rdrand" should be OK. 
What properties can I set, if any? How does this "[random]" relate to the 
RDRAND *engine* (see below)?
>
> $ openssl3 engine rdrand -t
> (rdrand) Intel RDRAND engine
>   [ available ]
>
>
> Thanks!
> --
> Regards,
> Uri Blumenthal  Voice: (781) 981-1638
> Secure Resilient Systems and Technologies   Cell:  (339) 223-5363
> MIT Lincoln Laboratory
> 244 Wood Street, Lexington, MA  02420-9108
>   
> We

OpenSSL-3.+ how to configure [random]?

[Blumenthal, Uri - 0553 - MITLL]

"man config" for OpenSSL-3.0 and newer says that there can be "[random]" 
section in "openssl.cnf", where I can specify type of RNG, other things, and 
*seed*, and seed *properties*.

Unfortunately, it did not bother to even list the possible/allowed values, let 
alone explain what they'd mean:

   Random Configuration
   The name random in the initialization section names the section 
containing the random number
   generater settings.

   Within the random section, the following names have meaning:

   random
   This is used to specify the random bit generator.  For example:

[random]
random = CTR-DRBG

   The available random bit generators are:

   CTR-DRBG
   HASH-DRBG
   HMAC-DRBG
.  .  .  .  .
   properties
   This sets the property query used when fetching the random bit 
generator and any
   underlying algorithms.

   seed
   This sets the randomness source that should be used.  By default 
SEED-SRC will be used
   outside of the FIPS provider.  The FIPS provider uses call backs to 
access the same
   randomness sources from outside the validated boundary.

   seed_properties
   This sets the property query used when fetching the randomness 
source.

I want to configure this [random] to use CTR-DRBG, using RDRAND as "seed". 
Based on "openssl list -seeds", I guess "seed = rdrand" should be OK. What 
properties can I set, if any? How does this "[random]" relate to the RDRAND 
*engine* (see below)?

$ openssl3 engine rdrand -t
(rdrand) Intel RDRAND engine
 [ available ]


Thanks!
--
Regards,
Uri Blumenthal  Voice: (781) 981-1638 
Secure Resilient Systems and Technologies   Cell:  (339) 223-5363
MIT Lincoln Laboratory  
244 Wood Street, Lexington, MA  02420-9108  
 
Web: https://www.ll.mit.edu/biographies/uri-blumenthal
Root CA: https://www.ll.mit.edu/llrca2.pem
 
There are two ways to design a system. One is to make is so simple there are 
obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.

 -  C. A. R. Hoare
 


smime.p7s
Description: S/MIME cryptographic signature

Re: openssl cms -encrypt error: error setting recipientinfo

[Blumenthal, Uri - 0553 - MITLL]

At least one problem I can see with your EC certificate is wrong Key Usage. For 
EC it should be "Key Agreement".

I'd not use the same cert for signing and encrypting. If you do, then add 
Signature and Non-Repudiation (but I've never done that).
--
Regards,
Uri
 
There are two ways to design a system. One is to make is so simple there are 
obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.

 -  C. A. R. Hoare
 

On 5/5/21, 22:07, "openssl-users on behalf of Ted Wynnychenko" 
 wrote:

Hello


I recently decided to change from RSA to EC keys/certs.
I do this primarily as a learning exercise (there is no real corporate or
professional demand to have this working).
I am running OpenBSD current (6.9) from about 1 month ago.


Previously, I have been using "openssl smime" to sign and encrypt emails.

Now that I am migrating to EC keys/certificates, I need to switch to
"openssl cms".

However, I am unable to encrypt using the EC certificate.

When I use:
(I am going to obfuscate the emails in plain text, although I understand
there will be some encoded in the public key that follows.)

cat text.in | /usr/bin/openssl cms -encrypt -from 'User '
-to 'Admin ' -subject "Test Email" -aes256 encryption.pem
> encrypted.out

with the old RSA certificate, everything works as expected.

But, when I replace the RSA cert with the EC certificate, it does not.
Instead, I see:

15724089243112:error:2EFFF06F:CMS routines:CRYPTO_internal:ctrl
failure:/usr/src/lib/libcrypto/cms/cms_env.c:124:
15724089243112:error:2EFFF074:CMS routines:CRYPTO_internal:error setting
recipientinfo:/usr/src/lib/libcrypto/cms/cms_env.c:944:
15724089243112:error:2EFFF068:CMS routines:CRYPTO_internal:cms
lib:/usr/src/lib/libcrypto/cms/cms_smime.c:850:

And the output file is zero size.
The "-to" email address used is encoded as a SAN email in the EC
certificate.

I tried a more basic command:

openssl cms -encrypt -in text.in -out encrypted.out -recip encryption.pem

Works with RSA certificate, same error with EC certificate.

I also tried (not really understanding, but it is in the man page example):

openssl cms -encrypt -in text.in -out encrypted.out -recip encryption.pem
-keyopt ecdh_kdf_md:sha256

and got the same error.

I am not sure what this error means, or how to address it.

I was wondering if I needed to add the email to the certificate's DN, but
since (I understand) emails in the DN are depreciated, and the email is
included as a SAN, that seems unlikely.

Any suggestions would be great.

I have pasted the output from, "openssl x509 -in encryption.pem -noout
-text" below.
As I said, the plain text has been altered, but the public key is unchanged.

Thanks

Ted


$ openssl x509 -in encryption.pem -noout -text

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 25 (0x19)
Signature Algorithm: ecdsa-with-SHA384
Issuer: C=US, ST=State, L=Town, O=Example, OU=Home, CN=example.com
Validity
Not Before: Jan  2 00:00:00 2019 GMT
Not After : Apr 17 13:57:06 2051 GMT
Subject: C=US, ST=State, L=Town, O=Example, OU=Home,
CN=admin.example.com
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (384 bit)
pub:
04:80:34:1b:cf:63:94:33:47:37:39:42:89:cd:80:
86:44:2f:df:5f:e2:cb:3f:1b:08:3b:2c:c8:20:ec:
4e:68:2a:ac:1d:ba:7b:09:3d:78:84:cc:e5:7c:f1:
5f:3c:36:c1:89:c1:8d:95:dc:ec:dd:7c:18:e9:58:
a2:83:bc:f9:db:82:cc:c3:fe:17:87:e3:52:78:70:
3b:2a:9e:ca:44:f6:f0:ff:42:82:8b:5a:51:9f:94:
63:4b:ef:08:d1:53:37
ASN1 OID: secp384r1
NIST CURVE: P-384
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Subject Key Identifier:
C6:1E:C2:DD:D2:89:2A:64:58:F2:94:1F:EB:80:CA:AC:3C:9B:43:DC
X509v3 CRL Distribution Points:

Full Name:
  URI:https://crl.example.com/example.ca.crl
CRL Issuer:
  DirName: C = US, O = Example, CN = example.com

Authority Information Access:
OCSP - URI:http://ocsp.example.com:2560

X509v3 Issuer Alternative Name:
DNS:example.com, email:ad...@example.com
X509v3 Authority Key Identifier:

Re: Maiising Daily Snapshots for 20210416

[Blumenthal, Uri - 0553 - MITLL]

IMHO, GitHub should be sufficient.

--
Regards,
Uri
 
There are two ways to design a system. One is to make is so simple there are 
obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.

 -  C. A. R. Hoare
 

On 4/16/21, 10:54, "openssl-users on behalf of Dr. Matthias St. Pierre" 
 
wrote:

It seems a bit outdated nowadays to publish daily snapshots imho.

   https://www.openssl.org/source/snapshot/

Instead of maintaining those snapshots, couldn't we just advertise the 
GitHub download links?
Any branch or commit can be downloaded easily as ZIP or compressed TAR 
file, whatever you prefer.

Matthias

--

$ curl -JOL 
https://github.com/openssl/openssl/archive/refs/heads/master.tar.gz
$ curl -JOL 
https://github.com/openssl/openssl/archive/refs/heads/OpenSSL_1_1_1-stable.tar.gz

$ curl -JOL 
https://github.com/openssl/openssl/archive/refs/heads/master.zip
$ curl -JOL 
https://github.com/openssl/openssl/archive/refs/heads/OpenSSL_1_1_1-stable.zip


$ ls -l openssl-*.tar.gz openssl-*.zip
-rw-r--r-- 1 msp msp 14548457 Apr 16 16:34 openssl-master.tar.gz
-rw-r--r-- 1 msp msp  9996650 Apr 16 16:35 
openssl-OpenSSL_1_1_1-stable.tar.gz

$ ls -l openssl-*.tar.gz openssl-*.zip
-rw-r--r-- 1 msp msp 17122833 Apr 16 16:41 openssl-master.zip
-rw-r--r-- 1 msp msp 11844030 Apr 16 16:41 
openssl-OpenSSL_1_1_1-stable.zip

> -Original Message-
> From: openssl-users  On Behalf Of Matt 
Caswell
> Sent: Friday, April 16, 2021 4:12 PM
> To: openssl-users@openssl.org
> Subject: Re: Maiising Daily Snapshots for 20210416
> 
> There was a power outage at the datacentre last night. Everything should
> hopefully be back to normal now, so hopefully the snapshots will arrive
> as normal tonight.
> 
> Matt
> 
> 
> On 16/04/2021 14:25, The Doctor wrote:
> > Anyone knows what happened?
> >



smime.p7s
Description: S/MIME cryptographic signature

Re: error: redefinition of ‘struct rsa_meth_st’

[Blumenthal, Uri - 0553 - MITLL]

Is there an analog of the "dummy async engine" for the OpenSSL-3.0 Provider?

TNX
--
Regards,
Uri
 
There are two ways to design a system. One is to make is so simple there are 
obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.

 -  C. A. R. Hoare
 

On 4/12/21, 12:43, "openssl-users on behalf of Matt Caswell" 
 wrote:

You can look at the dummy async engine which wraps the standard RSA 
functions inside an engine (as well as various other crypto primitives). 
You can see it here:


https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/engines/e_dasync.c

Matt

On 12/04/2021 17:32, Shariful Alam wrote:
> Dr. Pauli,
> Goodmorning. Thank you for replying. I found the documentation a bit 
> difficult for me to understand. I was wondering if you can direct me to 
> a sample skeleton code for creating a custom RSA engine.
> 
> Regards,
> Shariful Alam
> 
> On Sun, Apr 11, 2021 at 6:00 PM Dr Paul Dale  > wrote:
> 
> You shouldn't be accessing the internal of a private structure. That
> structure was made private for a reason and duplicating it in your
> engine will break when we change the structure's contents.
> 
> Your engine should be using the EVP_PKEY_meth_set_* function to do
> what you want (for 1.1.1).  For 3.0, you should be writing a
> provider instead.
> 
> 
> Pauli
> 
> On 12/4/21 5:04 am, Shariful Alam wrote:
>> Hello,
>> Hope you guys are doing well. I'm trying to develop an RSA engine.
>> My engine was somewhat working until I try to integrate my engine
>> with an apache httpd server. After installing the httpd from the
>> source code, it turns out that, I can't compile my engine anymore.
>> I get the following error while I try to compile (it was compiling
>> before and I did not make any changes to my engine code).
>>
>> ==
>>
>> *$gcc -fPIC -c r_engine.c*
>> *r_engine.c:29:8: error: redefinition of ‘struct rsa_meth_st’
>>  struct rsa_meth_st {
>> ^
>> In file included from /usr/include/openssl/crypto.h:131:0,
>>  from r_engine.c:7:
>> /usr/include/openssl/ossl_typ.h:147:16: note: originally defined here
>>  typedef struct rsa_meth_st RSA_METHOD;*
>>
>> =
>>
>> and my *struct rsa_meth_st *looks like the following,
>>
>> 

>>
>> *struct rsa_meth_st {
>>
>> const char *name;
>> int (*rsa_pub_enc) (int flen, const unsigned char *from,
>> unsigned char *to, RSA *rsa, int padding);
>> int (*rsa_pub_dec) (int flen, const unsigned char *from,
>> unsigned char *to, RSA *rsa, int padding);
>> int (*rsa_priv_enc) (int flen, const unsigned char *from,
>> unsigned char *to, RSA *rsa, int padding);
>> int (*rsa_priv_dec) (int flen, const unsigned char *from,
>> unsigned char *to, RSA *rsa, int padding);
>>
>> int (*rsa_mod_exp) (BIGNUM *r0, const BIGNUM *I, RSA *rsa,
>> BN_CTX *ctx);
>>
>> int (*bn_mod_exp) (BIGNUM *r, const BIGNUM *a, const BIGNUM
>> *p, const BIGNUM *m, BN_CTX *ctx, BN_MONT_CTX *m_ctx);
>>
>> int (*init) (RSA *rsa);
>>
>> int (*finish) (RSA *rsa);
>>
>> int flags;
>>
>> char *app_data;
>>
>> int (*rsa_sign) (int type, const unsigned char *m, unsigned
>> int m_length, unsigned char *sigret, unsigned int *siglen, const
>> RSA *rsa);
>>
>> int (*rsa_verify) (int dtype, const unsigned char *m, unsigned
>> int m_length, const unsigned char *sigbuf, unsigned int siglen,
>> const RSA *rsa);
>>
>> int (*rsa_keygen) (RSA *rsa, int bits, BIGNUM *e, BN_GENCB *cb);
>>
>> };
>> *
>>
>> 
=
>>
>> My sample skeleton code is here https://pastebin.com/uNXYknEA
>> 
>>
>> Can anyone please tell me what I'm I doing wrong?
>>
>> Regards,
>> Shariful Alam
> 


smime.p7s
Description: S/MIME cryptographic signature

Re: Why does OpenSSL report google's certificate is "self-signed"?

[Blumenthal, Uri - 0553 - MITLL]

In general - I concur, but there are nuances: sending root CA cert is mostly 
harmless, but mostly useless - except when there's a human on the receiving end 
that can and is allowed to make a decision to accept and trust that CA cert.

Re. PQC - even the "smallest" among them are much larger than what the Classic 
keys and signatures are. E.g., Falcon-1024 signature is 1330 bytes (or often 
less - say, 1200 bytes). Falcon-1024 public key is 1793 bytes. Compare to, 
e.g., ECC-384 sizes... NTRU public keys are "easier", but not by that much: 
1230 bytes. Kyber public key is 1568 bytes. And I picked the *smallest* ones - 
those I'd consider using myself.  

There's also McEliece... __
--
Regards,
Uri
 
There are two ways to design a system. One is to make is so simple there are 
obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.

 -  C. A. R. Hoare
 

On 4/1/21, 10:23, "openssl-users on behalf of Michael Wojcik" 
 
wrote:

Thanks to everyone who responded. You've confirmed my impression:

- There doesn't appear to be any applicable standard which requires or 
forbids including the root, or even endorses or discourages it).

- It's harmless except for performance issues and possible low-severity 
flags from analyses like Qualys's. (I wouldn't be surprised to have a customer 
raise this -- many of our customers run various scanning tools -- but for the 
products I work with, customers configure certificate chains anyway, so it's 
not a product issue.)

- Performance issues are likely negligible in many cases, where servers 
aren't dealing with huge workloads, but it's worth remembering that eventually 
people will be deploying PQC and most of the NIST finalists involve 
significantly larger keys or signatures. (They don't *all* have much larger 
keys/signatures; Falcon has a small combined public key and signature, if 
memory serves.)

--
Michael Wojcik


smime.p7s
Description: S/MIME cryptographic signature

Re: Why does OpenSSL report google's certificate is "self-signed"?

[Blumenthal, Uri - 0553 - MITLL]

You are right - there’s no urgency in PQ signatures. 

However, PQ KEM keys aren’t small. And, as I said, für austere links every 
unnecessary byte of crap hurts. 

Also, sending root certs seems (marginally) useful only when the recipient is a 
Web browser. And even then I  assume most of the IT people would want to block 
the ability of a “mere” user to add an “unblessed” trusted root. 

Regards,
Uri

> On Mar 31, 2021, at 14:15, Viktor Dukhovni  wrote:
> 
> 
>> 
>> On Mar 31, 2021, at 2:01 PM, Blumenthal, Uri - 0553 - MITLL 
>>  wrote:
>> 
>> For a Web GUI with the user at the console (e.g., a Web browser), it might 
>> be OK. 
>> 
>> For my needs (devices talking to each other over austere links), sending the 
>> root CA very is both useless and wasteful. One you factor in the sizes of 
>> Post-Quantum keys and signatures - you’ll start disliking this idea even 
>> more. 
> 
> There's no urgency in post-quantum keys for CA signatures in TLS.  Their
> future weakness does not compromise today's traffic.  Until actual scalable
> QCs start cracking RSA and ECDSA in near real-time only the ephemeral key
> agreement algorithm needs to be PQ-resistant now to future-proof session
> confidentiality.
> 
> So certificates can continue to use RSA and ECDSA for quite some time.
> 
> -- 
>Viktor.
> 


smime.p7s
Description: S/MIME cryptographic signature

Re: Why does OpenSSL report google's certificate is "self-signed"?

[Blumenthal, Uri - 0553 - MITLL]

For a Web GUI with the user at the console (e.g., a Web browser), it might be 
OK. 

For my needs (devices talking to each other over austere links), sending the 
root CA very is both useless and wasteful. One you factor in the sizes of 
Post-Quantum keys and signatures - you’ll start disliking this idea even more. 

Regards,
Uri

> On Mar 31, 2021, at 13:49, Viktor Dukhovni  wrote:
> 
> 
>> 
>> On Mar 31, 2021, at 1:43 PM, Michael Wojcik  
>> wrote:
>> 
>> As far as I can see, neither PKIX (RFC 5280) nor the CA/BF Baseline 
>> Requirements say anything about the practice, though I may have missed 
>> something. I had a vague memory that some standard or "best practice" 
>> guideline somewhere said the server should send the chain up to but not 
>> including the root, but I don't know what that might have been.
> 
> Inclusion of the self-signed root is harmless.  The only case that
> I know of where this is actually necessary is with DANE-TA(2) when
> the TLSA RRset has a hash of the trusted root cert or public key.
> 
> -- 
>Viktor.
> 


smime.p7s
Description: S/MIME cryptographic signature

Re: Encoding of AlgorithmIdentifier with NULL parameters

[Blumenthal, Uri - 0553 - MITLL]

“OPTIONAL” means the parser must deal with complete absence, not only encoded 
as ASN.1 NULL.

 

Broken parsers should be fixed.

--

Regards,

Uri

 

There are two ways to design a system. One is to make is so simple there are 
obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.


 -  C. A. R. Hoare

 

 

From: openssl-users-bounce  on behalf of 
openssl-users 
Organization: WiseMo A/S
Reply-To: Jakob Bohm 
Date: Thursday, January 28, 2021 at 21:10
To: openssl-users 
Subject: Re: Encoding of AlgorithmIdentifier with NULL parameters

 

Also note that the official ASN.1 declaration for 
AlgorithmIdentifier (from X.509 (2012), section 7.2) marks 
the parameters field as OPTIONAL, so parsers really should 
accept its absence.

However if broken parsers are common (this thread 
only found one such parser), maybe it would be 
good practice to include the NULL value for compatibility.

AlgorithmIdentifier{ALGORITHM:SupportedAlgorithms} ::= SEQUENCE {
algorithm ALGORITHM.({SupportedAlgorithms}),
parameters ALGORITHM.({SupportedAlgorithms}{@algorithm}) OPTIONAL,
... }



smime.p7s
Description: S/MIME cryptographic signature

Re: OPenssl 3.0 issues

[Blumenthal, Uri - 0553 - MITLL]

On 1/25/21, 10:13, "openssl-users on behalf of The Doctor" 
 wrote:

Anyone using BSD running into basename issues?

Basename issues on MacOS. Presumably the same as you're having on BSD.
 


smime.p7s
Description: S/MIME cryptographic signature

Re: Parsing and generating CBOR certificates?

[Blumenthal, Uri - 0553 - MITLL]

> I'd welcome support for CBOR(-encoded) certificates since they can save a lot 
> of space
> for both the data itself and the code handling it, which may be vital for IoT 
> scenarios, for instance.
> It looks like the standardization of their definition got pretty far already.

Exactly! And there’s been a bunch of publications, describing/defining CBOR 
encoding for IoT certificates, such as 
http://kth.diva-portal.org/smash/get/diva2:1153958/FULLTEXT01.pdf 
 
> Although it is certainly possible to convert between DER-encoded ASN.1 (or at 
> least its subset needed for X.509 certs) and CBOR,
> this is not strictly needed since there is a definition of natively signed 
> CBOR certs.
> Thus all the ASN.1 fuzz, which is bulky and error-prone to implement and use, 
> can be avoided then.

Yes. My primary goal is to reduce the overhead on the wire – but simplifying 
the processing code would be welcome as well.

> It may be also worth noting in this context that due to it sheer size the 
> OpenSSL code itself is not suited for constrained systems.
> Yet even then it would make sense if OpenSSL supported CBOR certs because 
> they could be used by TLS peers on constrained systems.

Yes.

> Moreover, when using only natively signed CBOR certs it should be possible 
> (though likely hard to achieve with the current strongly ASN.1 entangled 
> libcrypto code)
> to build OpenSSL without any ASN.1 support, which should reduce code size 
> drastically.

Something I don't urgently need, but would welcome regardless.

> I suggest opening a feature request at 
> https://github.com/openssl/openssl/issues

Done: https://github.com/openssl/openssl/issues/13925 

Thanks!


On 21.01.21 02:07, Blumenthal, Uri - 0553 - MITLL wrote:
On 1/20/21, 19:42, "Benjamin Kaduk" mailto:bka...@akamai.com wrote:
   And again, where do you believe such a conversion is specified?
What do you mean "specified"? There's an ASN.1 "specification" of the 
certificate format, which theoretically can be encoded into whatever - DER, 
PER, OER, etc. One such tool (https://github.com/mouse07410/asn1c.git that I 
use) generates from ASN.1 file codecs for many encoding formats, and is able to 
convert between them.

Unfortunately, there's no ASN.1 -> CBOR codec generator, AFAIK, which is why 
I'm asking here.

  The IETF internet-draft I reference is a way to do so, but it is (to repeat)
  very much a work in progress.
Understood. Do you know if there's any code behind it? Or just the "theory"?

Thanks!

On Thu, Jan 21, 2021 at 12:35:24AM +, Blumenthal, Uri - 0553 - MITLL wrote:
I meant not "CBOR protocol" (which,  in all likelihood, doesn't and shouldn't 
exist) but CBOR encoding of X.509 certificates (which, hopefully, does exists).

At least, I'm looking for a tool that would convert between these two encodings 
(DER and CBOR) for specific objects (X.509-conformant certificates).

Thanks

Regards,
Uri

On Jan 20, 2021, at 19:26, Kaduk, Ben mailto:bka...@akamai.com wrote:

No.  OpenSSL does not include any CBOR protocol support.
I'm also not sure what you mean by "CBOR-encoded certificate"; I don't
know of any such thing other than
https://datatracker.ietf.org/doc/draft-mattsson-cose-cbor-cert-compress/
which is very much still a work in progress.

-Ben


From: Blumenthal, Uri - 0553 - MITLL mailto:u...@ll.mit.edu
Sent: Wednesday, January 20, 2021 4:22 PM
To: openssl-users
Subject: Parsing and generating CBOR certificates?

I need to work with CBOR-encoded certificates. Is there any way to use OpenSSL 
to parse and/or generate certs in CBOR encoding?

Thanks

Regards,
Uri


smime.p7s
Description: S/MIME cryptographic signature

Re: Parsing and generating CBOR certificates?

[Blumenthal, Uri - 0553 - MITLL]

On 1/20/21, 19:42, "Benjamin Kaduk"  wrote:
>And again, where do you believe such a conversion is specified?

What do you mean "specified"? There's an ASN.1 "specification" of the 
certificate format, which theoretically can be encoded into whatever - DER, 
PER, OER, etc. One such tool (https://github.com/mouse07410/asn1c.git that I 
use) generates from ASN.1 file codecs for many encoding formats, and is able to 
convert between them.

Unfortunately, there's no ASN.1 -> CBOR codec generator, AFAIK, which is why 
I'm asking here.

>   The IETF internet-draft I reference is a way to do so, but it is (to repeat)
>   very much a work in progress.

Understood. Do you know if there's any code behind it? Or just the "theory"?

Thanks!

On Thu, Jan 21, 2021 at 12:35:24AM +, Blumenthal, Uri - 0553 - MITLL 
wrote:
> I meant not "CBOR protocol" (which,  in all likelihood, doesn't and 
shouldn't exist) but CBOR encoding of X.509 certificates (which, hopefully, 
does exists).
> 
> At least, I'm looking for a tool that would convert between these two 
encodings (DER and CBOR) for specific objects (X.509-conformant certificates).
> 
> Thanks
> 
> Regards,
> Uri
> 
> > On Jan 20, 2021, at 19:26, Kaduk, Ben  wrote:
> > 
> > No.  OpenSSL does not include any CBOR protocol support.
> > I'm also not sure what you mean by "CBOR-encoded certificate"; I don't
> > know of any such thing other than
> > https://datatracker.ietf.org/doc/draft-mattsson-cose-cbor-cert-compress/
> > which is very much still a work in progress.
> > 
> > -Ben
> > 
> > 
> > From: Blumenthal, Uri - 0553 - MITLL 
> > Sent: Wednesday, January 20, 2021 4:22 PM
> > To: openssl-users
> > Subject: Parsing and generating CBOR certificates?
> > 
> > I need to work with CBOR-encoded certificates. Is there any way to use 
OpenSSL to parse and/or generate certs in CBOR encoding?
> > 
> > Thanks
> > 
> > Regards,
> > Uri




smime.p7s
Description: S/MIME cryptographic signature

Re: Parsing and generating CBOR certificates?

[Blumenthal, Uri - 0553 - MITLL]

I meant not "CBOR protocol" (which,  in all likelihood, doesn't and shouldn't 
exist) but CBOR encoding of X.509 certificates (which, hopefully, does exists).

At least, I'm looking for a tool that would convert between these two encodings 
(DER and CBOR) for specific objects (X.509-conformant certificates).

Thanks

Regards,
Uri

> On Jan 20, 2021, at 19:26, Kaduk, Ben  wrote:
> 
> No.  OpenSSL does not include any CBOR protocol support.
> I'm also not sure what you mean by "CBOR-encoded certificate"; I don't
> know of any such thing other than
> https://datatracker.ietf.org/doc/draft-mattsson-cose-cbor-cert-compress/
> which is very much still a work in progress.
> 
> -Ben
> 
> ________________
> From: Blumenthal, Uri - 0553 - MITLL 
> Sent: Wednesday, January 20, 2021 4:22 PM
> To: openssl-users
> Subject: Parsing and generating CBOR certificates?
> 
> I need to work with CBOR-encoded certificates. Is there any way to use 
> OpenSSL to parse and/or generate certs in CBOR encoding?
> 
> Thanks
> 
> Regards,
> Uri


smime.p7s
Description: S/MIME cryptographic signature

Parsing and generating CBOR certificates?

[Blumenthal, Uri - 0553 - MITLL]

I need to work with CBOR-encoded certificates. Is there any way to use OpenSSL 
to parse and/or generate certs in CBOR encoding?

Thanks

Regards,
Uri

smime.p7s
Description: S/MIME cryptographic signature

Re: EC curve preferences

[Blumenthal, Uri - 0553 - MITLL]

Those "rigid curves" that will be used in the future - future how distant, and 
for how long? 

Regards,
Uri

> On Nov 20, 2020, at 13:54, Phillip Hallam-Baker  wrote:
> 


smime.p7s
Description: S/MIME cryptographic signature

Master fails tests (mentioning # TODO Currently not supported)

[Blumenthal, Uri - 0553 - MITLL]

MacOS 10.15.5, Xcode-11.5, current OpenSSL master (3.0 dev)

Is this expected:


genpkey: Error setting ec_param_enc:explicit parameter:
C00D090F0100:error::digital envelope 
routines:legacy_ctrl_str_to_param:command not 
supported:crypto/evp/pmeth_lib.c:1011:
../../util/wrap.pl ../../apps/openssl genpkey -genparam -algorithm EC -pkeyopt 
'ec_paramgen_curve:Oakley-EC2N-3' -pkeyopt 'ec_param_enc:explicit' -text => 1
not ok 1 - genpkey EC params Oakley-EC2N-3 with ec_param_enc:'explicit' 
(text) # TODO Currently not supported
# --
#   Failed (TODO) test 'genpkey EC params Oakley-EC2N-3 with 
ec_param_enc:'explicit' (text)'
#   at test/recipes/15-test_genec.t line 37.
genpkey: Error setting ec_param_enc:explicit parameter:
C0CDBE160100:error::digital envelope 
routines:legacy_ctrl_str_to_param:command not 
supported:crypto/evp/pmeth_lib.c:1011:
../../util/wrap.pl ../../apps/openssl genpkey -genparam -algorithm EC -pkeyopt 
'ec_paramgen_curve:Oakley-EC2N-3' -pkeyopt 'ec_param_enc:explicit' -outform PEM 
-out ecgen.Oakley-EC2N-3.explicit.pem => 1
not ok 2 - genpkey EC params Oakley-EC2N-3 with ec_param_enc:'explicit' 
(PEM) # TODO Currently not supported
# --
#   Failed (TODO) test 'genpkey EC params Oakley-EC2N-3 with 
ec_param_enc:'explicit' (PEM)'
#   at test/recipes/15-test_genec.t line 37.
genpkey: Error setting ec_param_enc:explicit parameter:
C01D251B0100:error::digital envelope 
routines:legacy_ctrl_str_to_param:command not 
supported:crypto/evp/pmeth_lib.c:1011:
../../util/wrap.pl ../../apps/openssl genpkey -genparam -algorithm EC -pkeyopt 
'ec_paramgen_curve:Oakley-EC2N-3' -pkeyopt 'ec_param_enc:explicit' -outform DER 
-out ecgen.Oakley-EC2N-3.explicit.der => 1
not ok 3 - genpkey EC params Oakley-EC2N-3 with ec_param_enc:'explicit' 
(DER) # TODO Currently not supported
# --
#   Failed (TODO) test 'genpkey EC params Oakley-EC2N-3 with 
ec_param_enc:'explicit' (DER)'
#   at test/recipes/15-test_genec.t line 37.
genpkey: Error setting ec_param_enc:explicit parameter:
C07DD70A0100:error::digital envelope 
routines:legacy_ctrl_str_to_param:command not 
supported:crypto/evp/pmeth_lib.c:1011:
../../util/wrap.pl ../../apps/openssl genpkey -algorithm EC -pkeyopt 
'ec_paramgen_curve:Oakley-EC2N-3' -pkeyopt 'ec_param_enc:explicit' -text => 1
not ok 4 - genpkey EC key on Oakley-EC2N-3 with ec_param_enc:'explicit' 
(text) # TODO Currently not supported
# --
#   Failed (TODO) test 'genpkey EC key on Oakley-EC2N-3 with 
ec_param_enc:'explicit' (text)'
#   at test/recipes/15-test_genec.t line 37.
genpkey: Error setting ec_param_enc:explicit parameter:
C00D34120100:error::digital envelope 
routines:legacy_ctrl_str_to_param:command not 
supported:crypto/evp/pmeth_lib.c:1011:
../../util/wrap.pl ../../apps/openssl genpkey -algorithm EC -pkeyopt 
'ec_paramgen_curve:Oakley-EC2N-3' -pkeyopt 'ec_param_enc:explicit' -outform PEM 
-out ecgen.Oakley-EC2N-3.explicit.pem => 1
not ok 5 - genpkey EC key on Oakley-EC2N-3 with ec_param_enc:'explicit' 
(PEM) # TODO Currently not supported
# --
#   Failed (TODO) test 'genpkey EC key on Oakley-EC2N-3 with 
ec_param_enc:'explicit' (PEM)'
#   at test/recipes/15-test_genec.t line 37.
genpkey: Error setting ec_param_enc:explicit parameter:
C0FDFE100100:error::digital envelope 
routines:legacy_ctrl_str_to_param:command not 
supported:crypto/evp/pmeth_lib.c:1011:
../../util/wrap.pl ../../apps/openssl genpkey -algorithm EC -pkeyopt 
'ec_paramgen_curve:Oakley-EC2N-3' -pkeyopt 'ec_param_enc:explicit' -outform DER 
-out ecgen.Oakley-EC2N-3.explicit.der => 1
not ok 6 - genpkey EC key on Oakley-EC2N-3 with ec_param_enc:'explicit' 
(DER) # TODO Currently not supported
# --
genpkey: Error setting ec_param_enc:explicit parameter:
C09D39110100:error::digital envelope 
routines:legacy_ctrl_str_to_param:command not 
supported:crypto/evp/pmeth_lib.c:1011:
../../util/wrap.pl ../../apps/openssl genpkey -genparam -algorithm EC -pkeyopt 
'ec_paramgen_curve:Oakley-EC2N-4' -pkeyopt 'ec_param_enc:explicit' -text => 1
not ok 13 - genpkey EC params Oakley-EC2N-4 with ec_param_enc:'explicit' 
(text) # TODO Currently not supported
# --
#   Failed (TODO) test 'genpkey EC params Oakley-EC2N-4 with 
ec_param_enc:'explicit' (text)'
#   at test/recipes/15-test_genec.t line 37.
genpkey: Error setting ec_param_enc:explicit parameter:
C04DD9180100:error::digital envelope 

Re: CMAC timings

[Blumenthal, Uri - 0553 - MITLL]

On 6/18/20, 12:46, "openssl-users on behalf of Kurt Roeckx" 
 wrote:

On Thu, Jun 18, 2020 at 10:41:40AM +0200, Tomas Mraz wrote:
>> > I question the default behaviour, I think most people don't need
>> > that support.
>> 
>> Unfortunately that would be an API break that could be very hard to
>> discover, so I do not think we can change this even in 3.0.
>
> But I think the old CMAC API didn't support that, and so we can
> change the internal calls to use the flag now (if needed). The
> EVP_MAC API probably supports this too, and we can consider
> changing the default there.

Yes please!



smime.p7s
Description: S/MIME cryptographic signature

Re: CMAC timings

[Blumenthal, Uri - 0553 - MITLL]

I think that the default behavior should change for 3.0, and the API change 
described in the Release Notes. I find that alternative less impacting that 
this silent sudden performance deterioration.


On 6/18/20, 04:42, "openssl-users on behalf of Tomas Mraz" 
 wrote:

On Wed, 2020-06-17 at 23:02 +0200, Kurt Roeckx wrote:
> On Wed, Jun 17, 2020 at 03:50:05AM -0700, Hal Murray wrote:
> > levi...@openssl.org said:
> > > What does surprise me, though, is that direct EVP_MAC calls would
> > > be slower
> > > than going through the PKEY bridge.  I would very much like to
> > > see your code
> > > to see what's going on. 
> > 
> > Over on an ntpsec list, Kurt Roeckx reported that he was still
> > waiting...
> > 
> > Richard's message said "I", so I sent him a copy off
> > list.  Correcting that...
> 
> So I took a look at at the EVP_PKEY case, and it seems we spend most
> of our time doing:
> - alloc/free. 12 alloc and 16 free calls per signature
> - OPENSSL_cleanse: 10 calls per signature
> - EVP_CIPHER_CTX_reset: 6 calls per signature
> 
> Most of the time is spent in those functions.
> 
> The manpage documents:
> The call to EVP_DigestSignFinal() internally finalizes a
> copy of the digest context. This means that calls to
> EVP_DigestSignUpdate() and EVP_DigestSignFinal() can be called
> later to digest and sign additional data.
> 
> And:
>EVP_MD_CTX_FLAG_FINALISE
>Some functions such as EVP_DigestSign only finalise
>copies of internal contexts so additional data can be
>included after the finalisation call. This is
>inefficient if this functionality is not required, and
>can be disabled with this flag.
> 
> (A reference to the EVP_MD_CTX_set_flags manpage would have been
> useful.)
> 
> So after the EVP_MD_CTX_new(), I added an:
> EVP_MD_CTX_set_flags(ctx, EVP_MD_CTX_FLAG_FINALISE);
> 
> For me it changed things with 3.0 from:
>  AES-128  16 48
> 16   1696   1.696  475ac1c053379e7dbd4ce80b87d2178e
> to:
>  AES-128  16 48
> 16754   0.754  475ac1c053379e7dbd4ce80b87d2178e
> 
> While 1.1 gives me this without the change:
>  AES-128  16 48
> 16739   0.739  475ac1c053379e7dbd4ce80b87d2178e
> and with the change:
>  AES-128  16 48
> 16291   0.291  475ac1c053379e7dbd4ce80b87d2178e
> 
> I question the default behaviour, I think most people don't need
> that support.

Unfortunately that would be an API break that could be very hard to
discover, so I do not think we can change this even in 3.0.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




smime.p7s
Description: S/MIME cryptographic signature

Re: Asymetric crypto and OpenSSL 3.0 deprecated functions

[Blumenthal, Uri - 0553 - MITLL]

Emmanuel,

Would you mind explaining why you choose to continue encrypting the AES key, 
which - admittedly - is an unnecessary overkill? Is it merely to preserve the 
established process itself?



On 5/26/20, 04:26, "openssl-users on behalf of Emmanuel Deloget" 
 wrote:

Hello Richard and everybody,

First, thanks all for your valuable responses ; be sure that I heard
you and I fully understand your remarks (for the record, I do generate
a signature on the binary using yet another key pair and I fully get
that encrypting the AES key in my case is a bit overkill given the
fact that it does not provide any added security).

On Mon, May 25, 2020 at 6:14 PM Richard Levitte  wrote:
>
> On Mon, 25 May 2020 13:20:28 +0200,
> Emmanuel Deloget wrote:
> > In my development I'm using a idiom that's not as widely used as I
> > thought (as I get it after multiple days of searching out there). In
> > order to securely distribute a binary, I encrypt it using an AES key
> > and the AES key itself is encrypted using a /private/ RSA key I own.
>
> That's a perfectly viable thing to do, and is usually called "signing",
> and what you're signing here is the AES key.
>
> > Only owners of the /public/ key (which, as it is a publilc key, may
> > leak) can decrypt the AES key, and therefore the binary.
>
> Which is usually called "verifying the signature".
>
> This looks like object signing to me.

It definitely looks like this, yes.

> > Of course, in order to do this I rely on RSA_private_encrypt() and
> > RSA_public_decrypt() because EVP_PKEY_encrypt() / EVP_PKEY_decrypt()
> > cannot be used(*).
>
> EVP_PKEY_encrypt() and EVP_PKEY_decrypt() are the wrong functions to
> use.  However, there are EVP_PKEY_sign() and EVP_PKEY_verify_recover()
> (if I read you correctly, that's the function you need, rather than a
> mere EVP_PKEY_verify()).
>
> > So, after that long introduction, here is my question : is there any
> > OpenSSL 3.0 sanctionned, EVP_PKEY-based way to crypt using a private
> > key and decrypt using a public key?
>
> Yes, see above.  Those functions have been around for a while, I think
> you can start playing with them in any current OpenSSL version.

The _recover() function was the missing piece in  my understanding of
the library. I'll check that as soon as possible. Thanks a lot !

BTW, maybe this information should be made more easily available (on
the man page for RSA_private_encrypt()/RSA_public_decrypt() maybe ?)

> Cheers,
> Richard
>
> --
> Richard Levitte levi...@openssl.org
> OpenSSL Project http://www.openssl.org/~levitte/

Best regards,

-- Emmanuel Deloget


smime.p7s
Description: S/MIME cryptographic signature

Re: How to get all certs into a .der file.

[Blumenthal, Uri - 0553 - MITLL]

As far as I know, CURL (app and library) is perfectly happy to use a text file 
comprised of concatenated PEM certificates. 

I really wonder if there’s a real use case. 

On May 22, 2020, at 18:49, Salz, Rich via openssl-users 
 wrote:


application/pkix-pkipath
Defined in RFC4366 (section 8) and RFC6066 (section 10.1)
 
I doubt that it is worth doing this.  First, because OpenSSL doesn’t support it 
now, then CURL (what the original poster was talking about) can’t use it when 
using OpenSSL.  Instead, as others have pointed out, they should use a text 
file that has a bunch of PEM blobs concatenated.
 
Do we know any application that needs this?

smime.p7s
Description: S/MIME cryptographic signature

Re: CONF_MODULE undefined?

[Blumenthal, Uri - 0553 - MITLL]

On 4/28/20, 04:38, "Richard Levitte"  wrote:

> Would you mind testing 

Not at all! ;-)

> if https://github.com/openssl/openssl/pull/11655 fixes this?

As you suspected - it does! ;-)

Thank you!



On Mon, 27 Apr 2020 18:29:12 +0200,
    Blumenthal, Uri - 0553 - MITLL wrote:
> 
> I hit this problem recompiling libp11 with the current OpenSSL-3.0 
master. It's on MacOS Catalina 10.15.4 with the latest Xcode-11.4.1, but I 
think that's irrelevant. I checked through all the .h files in the OpenSSL 
sources, and found no definition o CONF_MODULE. OpenSSL-3.0 is installed into 
/Users/ur20980/openssl-3 (as is obvious from the following).
> 
> Here are the errors:
> 
> 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
 -g -I/Users/ur20980/openssl-3/include -Os -Ofast -std=gnu17 -march=native 
-msha -mavx512f -isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
 -MT evp-sign.o -MD -MP -MF $depbase.Tpo -c -o evp-sign.o evp-sign.c &&\
>   mv -f $depbase.Tpo $depbase.Po
> In file included from evp-sign.c:40:
> /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown 
type name 'CONF_MODULE'
> DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE)
>^
> /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown 
type name 'CONF_MODULE'
> /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown 
type name 'CONF_MODULE'
> /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown 
type name 'CONF_MODULE'
> /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown 
type name 'CONF_MODULE'
> /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown 
type name 'CONF_MODULE'
> /Users/ur20980/openssl-3/include/openssl/conf.h:37:1: error: expected 
expression
> DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE)
> ^
> /Users/ur20980/openssl-3/include/openssl/safestack.h:175:40: note: 
expanded from macro 'DEFINE_OR_DECLARE_STACK_OF'
> # define DEFINE_OR_DECLARE_STACK_OF(s) DEFINE_STACK_OF(s)
>^
> /Users/ur20980/openssl-3/include/openssl/safestack.h:135:29: note: 
expanded from macro 'DEFINE_STACK_OF'
> # define DEFINE_STACK_OF(t) SKM_DEFINE_STACK_OF(t, t, t)
> ^
> /Users/ur20980/openssl-3/include/openssl/safestack.h:39:21: note: 
expanded from macro 'SKM_DEFINE_STACK_OF'
> return (t2 *)OPENSSL_sk_value((const OPENSSL_STACK *)sk, idx); \
> ^
> In file included from evp-sign.c:40:
> /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: use of 
undeclared identifier 'CONF_MODULE'
> DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE)
>^
> /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown 
type name 'CONF_MODULE'
> /Users/ur20980/openssl-3/include/openssl/conf.h:37:1: error: expected 
expression
> DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE)
> ^
> /Users/ur20980/openssl-3/include/openssl/safestack.h:175:40: note: 
expanded from macro 'DEFINE_OR_DECLARE_STACK_OF'
> # define DEFINE_OR_DECLARE_STACK_OF(s) DEFINE_STACK_OF(s)
>^
> /Users/ur20980/openssl-3/include/openssl/safestack.h:135:29: note: 
expanded from macro 'DEFINE_STACK_OF'
> # define DEFINE_STACK_OF(t) SKM_DEFINE_STACK_OF(t, t, t)
> ^
> /Users/ur20980/openssl-3/include/openssl/safestack.h:67:21: note: 
expanded from macro 'SKM_DEFINE_STACK_OF'
> return (t2 *)OPENSSL_sk_delete((OPENSSL_STACK *)sk, i); \
> ^
> In file included from evp-sign.c:40:
> /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: use of 
undeclared identifier 'CONF_MODULE'
> DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE)
>^
> /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown 
type name 'CONF_MODULE'
> /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown 
type name 'CONF_MODULE'
> /Users/ur20980/openssl-3/include/openssl/conf.h:37:1: error: expected 
expression
> DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE)
> ^
> /Users/ur20980/openssl-3/include/openssl/safestack.h:175:40: note: 
expanded from macro 'DEFINE_OR_DECLARE_STACK_OF'
> # define DEFINE_OR_DECLARE_STACK_OF(s) DEFINE_STACK_OF(s)
>^
> /Users/ur20980/openssl-3/include/openssl/safestack.h:135:29: note: 
expanded from macro 'DEFINE_STACK_OF'
> # define DEFINE_STACK_OF(t) SKM_DEFINE_STACK_OF(t, t, t

CONF_MODULE undefined?

[Blumenthal, Uri - 0553 - MITLL]

I hit this problem recompiling libp11 with the current OpenSSL-3.0 master. It's 
on MacOS Catalina 10.15.4 with the latest Xcode-11.4.1, but I think that's 
irrelevant. I checked through all the .h files in the OpenSSL sources, and 
found no definition o CONF_MODULE. OpenSSL-3.0 is installed into 
/Users/ur20980/openssl-3 (as is obvious from the following).

Here are the errors:

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
 -g -I/Users/ur20980/openssl-3/include -Os -Ofast -std=gnu17 -march=native 
-msha -mavx512f -isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
 -MT evp-sign.o -MD -MP -MF $depbase.Tpo -c -o evp-sign.o evp-sign.c &&\
mv -f $depbase.Tpo $depbase.Po
In file included from evp-sign.c:40:
/Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 
'CONF_MODULE'
DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE)
   ^
/Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 
'CONF_MODULE'
/Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 
'CONF_MODULE'
/Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 
'CONF_MODULE'
/Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 
'CONF_MODULE'
/Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 
'CONF_MODULE'
/Users/ur20980/openssl-3/include/openssl/conf.h:37:1: error: expected expression
DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE)
^
/Users/ur20980/openssl-3/include/openssl/safestack.h:175:40: note: expanded 
from macro 'DEFINE_OR_DECLARE_STACK_OF'
# define DEFINE_OR_DECLARE_STACK_OF(s) DEFINE_STACK_OF(s)
   ^
/Users/ur20980/openssl-3/include/openssl/safestack.h:135:29: note: expanded 
from macro 'DEFINE_STACK_OF'
# define DEFINE_STACK_OF(t) SKM_DEFINE_STACK_OF(t, t, t)
^
/Users/ur20980/openssl-3/include/openssl/safestack.h:39:21: note: expanded from 
macro 'SKM_DEFINE_STACK_OF'
return (t2 *)OPENSSL_sk_value((const OPENSSL_STACK *)sk, idx); \
^
In file included from evp-sign.c:40:
/Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: use of undeclared 
identifier 'CONF_MODULE'
DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE)
   ^
/Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 
'CONF_MODULE'
/Users/ur20980/openssl-3/include/openssl/conf.h:37:1: error: expected expression
DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE)
^
/Users/ur20980/openssl-3/include/openssl/safestack.h:175:40: note: expanded 
from macro 'DEFINE_OR_DECLARE_STACK_OF'
# define DEFINE_OR_DECLARE_STACK_OF(s) DEFINE_STACK_OF(s)
   ^
/Users/ur20980/openssl-3/include/openssl/safestack.h:135:29: note: expanded 
from macro 'DEFINE_STACK_OF'
# define DEFINE_STACK_OF(t) SKM_DEFINE_STACK_OF(t, t, t)
^
/Users/ur20980/openssl-3/include/openssl/safestack.h:67:21: note: expanded from 
macro 'SKM_DEFINE_STACK_OF'
return (t2 *)OPENSSL_sk_delete((OPENSSL_STACK *)sk, i); \
^
In file included from evp-sign.c:40:
/Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: use of undeclared 
identifier 'CONF_MODULE'
DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE)
   ^
/Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 
'CONF_MODULE'
/Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 
'CONF_MODULE'
/Users/ur20980/openssl-3/include/openssl/conf.h:37:1: error: expected expression
DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE)
^
/Users/ur20980/openssl-3/include/openssl/safestack.h:175:40: note: expanded 
from macro 'DEFINE_OR_DECLARE_STACK_OF'
# define DEFINE_OR_DECLARE_STACK_OF(s) DEFINE_STACK_OF(s)
   ^
/Users/ur20980/openssl-3/include/openssl/safestack.h:135:29: note: expanded 
from macro 'DEFINE_STACK_OF'
# define DEFINE_STACK_OF(t) SKM_DEFINE_STACK_OF(t, t, t)
^
/Users/ur20980/openssl-3/include/openssl/safestack.h:71:21: note: expanded from 
macro 'SKM_DEFINE_STACK_OF'
return (t2 *)OPENSSL_sk_delete_ptr((OPENSSL_STACK *)sk, \
^
In file included from evp-sign.c:40:
/Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: use of undeclared 
identifier 'CONF_MODULE'
DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE)
   ^
/Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 
'CONF_MODULE'
/Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 
'CONF_MODULE'
/Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 
'CONF_MODULE'
/Users/ur20980/openssl-3/include/openssl/conf.h:37:1: error: expected expression
DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE)
^

Current master fails test

[Blumenthal, Uri - 0553 - MITLL]

You probably already noticed, but if not…

MacOS Mojave 10.14.6, Xcode 11.3.1. Current OpenSSL master (OpenSSL 3.0 dev) 
with PR 11193 applied (latest variant).

Test Summary Report
---
25-test_req.t(Wstat: 512 Tests: 15 Failed: 2)
  Failed tests:  14-15
  Non-zero exit status: 2
25-test_verify_store.t   (Wstat: 256 Tests: 10 Failed: 1)
  Failed test:  4
  Non-zero exit status: 1
80-test_ca.t (Wstat: 256 Tests: 6 Failed: 1)
  Failed test:  4
  Non-zero exit status: 1
80-test_ssl_old.t(Wstat: 1536 Tests: 6 Failed: 6)
  Failed tests:  1-6
  Non-zero exit status: 6
Files=192, Tests=1947, 212 wallclock secs ( 2.87 usr  0.69 sys + 144.91 cusr 
42.68 csys = 191.15 CPU)
Result: FAIL
make[1]: *** [_tests] Error 1
make: *** [tests] Error 2

-- 
Regards,
Uri
 


smime.p7s
Description: S/MIME cryptographic signature

Re: Fails on verifying signature - RSA_padding_check_PKCS1_type_1:invalid padding

[Blumenthal, Uri - 0553 - MITLL]

If you generated a keypair in a smartcard, how did you extract the private key 
out of it??? The whole point of a smartcard is to prevent that from being 
possible.

 

So, like Ken suggested, I’ve no idea where the private key you posted was 
coming from – but reasonably sure it has no relation to what’s in the smartcard.

 

To use keys on the smartcard, you need libp11 package, something like (my 
test-script uses RSA-PSS, but that doesn’t matter – adjust the OpenSSL 
parameters):

 

$ pkcs11-rsa-pss-sign-demo2

This is not a CAC

Generating ephemeral file /tmp/derive.20560.text to test RSA-PSS signature...

 

openssl rand -engine rdrand -hex -out /tmp/derive.20560.text 5120

engine "rdrand" set.

 

Signing file /tmp/derive.20560.text...

openssl dgst -engine pkcs11 -keyform engine -sign 
"pkcs11:manufacturer=piv_II;object=SIGN%20key;type=private" -sha384 -sigopt 
rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 -out /tmp/derive.20560.text.sig 
/tmp/derive.20560.text

engine "pkcs11" set.

Enter PKCS#11 token PIN for :

Signature for /tmp/derive.20560.text is stored in /tmp/derive.20560.text.sig

 

Verifying signature:

openssl dgst -engine pkcs11 -keyform engine -verify 
"pkcs11:manufacturer=piv_II;object=SIGN%20pubkey;type=public" -sha384 -sigopt 
rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 -signature 
/tmp/derive.20560.text.sig  /tmp/derive.20560.text

engine "pkcs11" set.

Verified OK

 

$

 

IMHO, it is a bad idea to use “rsautl” here – better to follow my example 
above. But if you must – here it is:

 

$ openssl rand -hex -out /tmp/t.text 24

$ openssl rsautl -engine pkcs11 -keyform engine -sign -inkey 
"pkcs11:manufacturer=piv_II;object=SIGN%20key;type=private" -in /tmp/t.text 
-out /tmp/t.text.sig

engine "pkcs11" set.

Enter PKCS#11 token PIN for Blumenthal, Uri (UR20980):

$ openssl rsautl -engine pkcs11 -keyform engine -pubin -verify -inkey 
"pkcs11:manufacturer=piv_II;object=SIGN%20pubkey;type=public" -in 
/tmp/t.text.sig 

engine "pkcs11" set.

c0e78791e0eb900eb36436da9cd4dcf85619c61a486e4b03

$ cat /tmp/t.text

c0e78791e0eb900eb36436da9cd4dcf85619c61a486e4b03

$

 

 

From: openssl-users  on behalf of Pedro 
Lopes 
Date: Thursday, February 13, 2020 at 12:40 PM
To: openssl-users 
Subject: Fails on verifying signature - RSA_padding_check_PKCS1_type_1:invalid 
padding

 

Hello, 

 

I'm generating a key pair in a smartcard (as a session object), then I convert 
both keys to RSA openssl objects.

 

Then I save both into different files.

I tried use these keys to sign and verify (private encrypts and public 
decrypts).

When I try to verify the signature, fails with 
RSA_padding_check_PKCS1_type_1:invalid padding.

 

I run following commands:
echo "test" > "test.txt"
openssl rsautl -sign -in test.txt -inkey privKey.pem -out sig
openssl rsautl -verify -in sig -inkey pubKeyp8.pem -pubin

 

Below pub and priv key:

 

-BEGIN RSA PRIVATE KEY-
MIICXAIBAAKBgQDsCXvs8rmEDP+NuB4mCvztondC+yfzy6DYswE6jvSJdgZe8PAh
kNagyoWsCNGqNEqpQmXY1Ufmxh4tdInod/KyT4uZ8vpu+yhqujRlwill+T9JCtA+
DnUSn0QiOV7OVFRMkleGW0ADr1LUp+wRe4aS/xxoc5GAc7UhAy7VZyj6jQIDAQAB
AoGBALWREhgSGqy+hvKQN/jRqQBvYkhPBMufzwoCoKZYAzmeZYYw1rcrQD6Nq0fL
vOSttuT+o3OplNarfdk/dToy0qfnDcNqmY3XTQbhn5SG/R8Ye5qFmyP/lZuN4NYI
TGiPO6Dt7y6IUp2inhAUkWcqMlr/5y2Kg6/Mh5CtghuhGriBAkEA+xht1GA7gc/N
pfam97iwlj6EBQUk8sX1UjSHWy5vH6RHNW0w1hDq9PrBYTT8mFuDMKA3kNdTw3JZ
2vTce4QELQJBAPClwe40HA9RKHfn5RjEFvvf0rt4/4LU3TAnmWZRuF+KU2JoxSs8
Ue+jx82PeqyH4KAD0tTboJBFt5PJLDz86+ECQHoiydmR7aAY+kkODu1UMuECC6l9
dRl53PhdgLGDhp33hIOiVyzpEcCT8FheM7fQW6HdbOnRM3dQOhDdJhoWfwkCQH+g
GTLAliUVcLXu2VSCIoJgWP2uFSyIwenZBoT6UCLzVHe7gt4ENpw2Ky/8qR25Tkru
3DChbg01vD93kKujo2ECQFQH9eMd1jr8K+/AZKdVUU0Nd3aSq3se+g25bTLBPt7k
x0yYAdd3XrfAys55ujSFEwFL9eGzNWXrBN9S2/yS8kU=
-END RSA PRIVATE KEY-

 

-BEGIN RSA PUBLIC KEY-
MIGHAoGBAOwJe+zyuYQM/424HiYK/O2id0L7J/PLoNizATqO9Il2Bl7w8CGQ1qDK
hawI0ao0SqlCZdjVR+bGHi10ieh38rJPi5ny+m77KGq6NGXCKWX5P0kK0D4OdRKf
RCI5Xs5UVEySV4ZbQAOvUtSn7BF7hpL/HGhzkYBztSEDLtVnKPqNAgEB
-END RSA PUBLIC KEY-

 

-BEGIN PUBLIC KEY-
MIGdMA0GCSqGSIb3DQEBAQUAA4GLADCBhwKBgQDsCXvs8rmEDP+NuB4mCvztondC
+yfzy6DYswE6jvSJdgZe8PAhkNagyoWsCNGqNEqpQmXY1Ufmxh4tdInod/KyT4uZ
8vpu+yhqujRlwill+T9JCtA+DnUSn0QiOV7OVFRMkleGW0ADr1LUp+wRe4aS/xxo
c5GAc7UhAy7VZyj6jQIBAQ==
-END PUBLIC KEY-

 

Could you please help me with this?
Thanks in advance.

-- 

Regards, 

Pedro Lopes



smime.p7s
Description: S/MIME cryptographic signature

MacOS: lost ability to use p11-kit???

[Blumenthal, Uri - 0553 - MITLL]

macOS 10.14.6, Xcode-11.3 (with older Xcode it used to work), p11-kit 0.23.18, 
OpenSSL-1.1.1d, current master of OpenSC and libp11.

Somehow, p11-kit proxy that selects the correct PKCS#11 library to pass the 
request to, is no longer invoked.

Any help is appreciated!

$ openssl cms -engine pkcs11 -keyform engine -aes256 -decrypt -binary -inform 
PEM -in /tmp/derive.95470.text.cms -out /tmp/derive.95470.text.dec -inkey 
"pkcs11:manufacturer=piv_II;object=KEY%20MAN%20key;object-type=private"
engine "pkcs11" set.
GOST engine already loaded
Unable to load module /opt/local/lib/p11-kit-proxy.dylib
GOST engine already loaded
Unable to load module /opt/local/lib/p11-kit-proxy.dylib
PKCS11_get_private_key returned NULL
cannot load signing key file from engine
4458096064:error:260B606D:engine routines:dynamic_load:init 
failed:crypto/engine/eng_dyn.c:485:
4458096064:error:260BC066:engine routines:int_engine_configure:engine 
configuration error:crypto/engine/eng_cnf.c:141:section=gost_section, 
name=dynamic_path, value=/opt/local/lib/engines-1.1/gost.dylib
4458096064:error:0E07606D:configuration file routines:module_run:module 
initialization error:crypto/conf/conf_mod.c:177:module=engines, 
value=engine_section, retcode=-1  
4458096064:error:83065006:PKCS#11 module:pkcs11_check_token:Function 
failed:p11_load.c:92:
4458096064:error:26096080:engine routines:ENGINE_load_private_key:failed 
loading private key:crypto/engine/eng_pkey.c:78:
unable to load signing key file
$ ll /opt/local/lib/p11-kit-proxy.dylib 
lrwxr-xr-x  1 root  admin  18 Dec 11 13:21 /opt/local/lib/p11-kit-proxy.dylib@ 
-> libp11-kit.0.dylib
$ ll /opt/local/lib/libp11-kit.0.dylib 
-rwxr-xr-x  1 root  admin  1442912 Dec 11 13:23 
/opt/local/lib/libp11-kit.0.dylib*
$ 
—
Regards,
Uri



smime.p7s
Description: S/MIME cryptographic signature

Writing an ENGINE for OpenSSL-1.1.1 and 3.0

[Blumenthal, Uri - 0553 - MITLL]

In preparation for writing a new engine that supports message digest and 
asymmetric crypto (sign and decrypt), I am trying to port the existing 
simple/demo engines from the Engine Corner examples (thanks, Richard!).

The fork of https://github.com/engine-corner/Lesson-2-A-digest.git that 
compiles and runs correctly (apparently) on OpenSSL-1.1.1 is 
https://github.com/mouse07410/Lesson-2-A-digest.git .

But no matter what, I was unable to make either of these two repos to run 
successfully with OpenSSL-3.0 (master), even though the latter repo at least 
seems to compile correctly, and answers “Available”. Here’s what I’m getting 
(for both versions I built the sample “emd5”engine and copied to the 
appropriate subdir of the lib/;  “openssl3” is an alias that points 
OPENSSL_CONF at the correct file, and invokes the correct OpenSSL-3.0 “openssl” 
binary, as it’s not on the main path):


$ penssl version

OpenSSL 1.1.1d  10 Sep 2019

$ openssl engine -t -c emd5

(emd5) A simple md5 engine for demonstration purposes

 [MD5]

 [ available ]

$ echo "shoot" | openssl dgst -md5 -engine emd5

engine "emd5" set.

(stdin)= 61a08703a6a4c774cad650afaedd9c10

$ echo "shoot" | openssl dgst -md5

(stdin)= 61a08703a6a4c774cad650afaedd9c10

$

$ openssl3 version

OpenSSL 3.0.0-dev xx XXX  (Library: OpenSSL 3.0.0-dev xx XXX )

$ openssl3 engine -t -vv -c emd5

(emd5) A simple md5 engine for demonstration purposes

 [MD5]

 [ available ]

$ echo "shoot" | openssl3 dgst -md5

MD5(stdin)= 61a08703a6a4c774cad650afaedd9c10

$ echo "shoot" | openssl3 dgst -md5 -engine emd5

engine "emd5" set.

Error setting digest

C0:05:98:0C:01:00:00:00:error:digital envelope 
routines:EVP_DigestInit_ex:initialization error:crypto/evp/digest.c:224:

$


Something must be missing from the configuration/setup – but what…? Help would 
be greatly appreciated!

Thanks!
—
Regards,
Uri

Re: Blake2b with key

[Blumenthal, Uri - 0553 - MITLL]

 >   > Is keyed blake2b supported in openssl-dgst (latest OpenSSL release)?

 >   No, sorry.  It has been added for upcoming OpenSSL 3.0, though.

Doesn't look like it's there:

$ openssl3 version
OpenSSL 3.0.0-dev xx XXX  (Library: OpenSSL 3.0.0-dev xx XXX )
$ echo -n "hello" | openssl3 dgst -blake2b512
BLAKE2b512(stdin)= 
e4cfa39a3d37be31c59609e807970799caa68a19bfaa15135f165085e01d41a65ba1e1b146aeb6bd0092b49eac214c103ccfa3a365954bbbe52f74a2b3620c94
$ echo -n "hello" | openssl3 dgst -blake2b512 -mac blake2bmac -macopt key:secret
Algorithm blake2bmac not found
$

Besides, how does one print a list of supported MAC algorithms?

  




smime.p7s
Description: S/MIME cryptographic signature

Re: Blake2b with key

[Blumenthal, Uri - 0553 - MITLL]

Answered my own questions:

$ openssl3 list -mac-algorithms
Provided MACs:
  BLAKE2bMAC @ default
  BLAKE2sMAC @ default
  CMAC @ default
  GMAC @ default
  HMAC @ default
  KMAC128 @ default
  KMAC256 @ default
  Poly1305 @ default
  SipHash @ default
$
$ echo -n "hello" | openssl3 mac -macopt key:secret blake2bmac

6EDF9AA44DFC7590DE00FCFDBE2F0D917CDEEB170301416929CC625D19D24EDC1040FF760C1F9BB61AD439A0AF5D492FBB01B46ED3FEB4E6076383B7885A9486
$


On 10/8/19, 11:03 AM, "Uri Blumenthal"  wrote:

 >   > Is keyed blake2b supported in openssl-dgst (latest OpenSSL release)?

 >   No, sorry.  It has been added for upcoming OpenSSL 3.0, though.

Doesn't look like it's there:

$ openssl3 version
OpenSSL 3.0.0-dev xx XXX  (Library: OpenSSL 3.0.0-dev xx XXX )
$ echo -n "hello" | openssl3 dgst -blake2b512
BLAKE2b512(stdin)= 
e4cfa39a3d37be31c59609e807970799caa68a19bfaa15135f165085e01d41a65ba1e1b146aeb6bd0092b49eac214c103ccfa3a365954bbbe52f74a2b3620c94
$ echo -n "hello" | openssl3 dgst -blake2b512 -mac blake2bmac -macopt 
key:secret
Algorithm blake2bmac not found
$

Besides, how does one print a list of supported MAC algorithms?

  





smime.p7s
Description: S/MIME cryptographic signature

Re: Format and standard for CSR

[Blumenthal, Uri - 0553 - MITLL]

>  Uri, Greetings!

Hello there! ;-)

> On 8/28/19 6:09 PM, Blumenthal, Uri - 0553 - MITLL wrote:
 > > Do you have an ASN.1 definition fit the content of CSR, or are you willing 
 > > to create one?
>
 > For now working with ASN.1.

In that case, I would use one of the available defined standards, which are 
well-supported by already existing Open Source software.

If you don’t have any extreme need for compactness of the binary representation 
– DER has been around long enough, is understood well enough, and the codecs 
are reasonably-well debugged. That would be my first choice.

If you do have a very austere link, perhaps UPER or OER, as they provide a 
tighter/more-compact encoding.
In addition to ASN.1, I found XER to be a good format for documenting examples 
(sample packets/messages), but I wouldn’t send it over the wire (though some 
people do that – I won’t say what I think of them).  

> >  IMHO, DER would be a pretty good choice, fat better than something 
> > home-brewed and non-standard.
>
> take a look at rfc 7049.  This is the standard for data objects over 
> constrained networks.  Then look at
> draft-birkholz-core-coid

I did. They favor schema-less data. I abhor it.  But then, I knew some people 
who didn't like to sit down and think before starting to write code. ;-)

Their argument against PER is

  Few (if any) IETF protocols have adopted one of the several variants
  of Packed Encoding Rules (PER).  There could be many reasons for
  this, but one that is commonly stated is that PER makes use of the
  schema even for parsing the surface structure of the data stream,
  requiring significant tool support.  There are different versions of
  the ASN.1 schema language in use, which has also hampered adoption.

I'm not sure I agree with the "significant tool support" above. I use 
https://github.com/vlm/asn1c.git, and it provides all I need (actually, I use 
the https://github.com/mouse07410/asn1c.git fork, as I also use APER, which it 
supports ;).

I'm also surprised that they did not provide encoding comparison with one of 
the PER variants (UPER, APER), or OER. It would've been far more instructive, 
IMHO, than comparing CBOR and BER to BSON.

> For work being done to define by a good team to meld x.509 stuff with CBOR.

[Un?]fortunately, I don't have time to invent a new encoding standard, 
implement + debug it, and some time down the road find that I need to extend it 
because it doesn't cover the case I didn't think of back then.

IMHO, the problem with X.509 is not with DER encoding, so I don't see much 
benefit in expressing it in CBOR instead.

> "The wonderful thing about standards is there are so many to choose from."

Which is yet another reason to stop and check whether really none of the 
existing ones could satisfy your needs. ;-)

Thanks!

P.S. You mentioned that CSR is in PEM. PEM (Privacy Enhanced Mail) is a base64 
encoding of (typically) DER. PEM is your payment by space for your DER not 
being mangled en-route by mail servers. You may base64-encode any binary 
format, if you suspect it would traverse binary-data-unfriendly links. If you 
want to dump CSR content, first convert it to DER (strip PEM encoding) via, 
e.g., "base64 --decode -i my.csr -o my.der", and then dump DER content with, 
e.g., "dumpasn1 my.der".

P.P.S. Re. CSR being a one-time document - that's true more often than not, but 
unless you only intend to use *one* CA that you control, it might make sense to 
stick to publicly-accepted formats, or at least something that can be 
easily/automatically converted to them.
--
Regards, 
Uri

Sent from my iPhone

On Aug 28, 2019, at 17:49, Robert Moskowitz <mailto:r...@htt-consult.com> wrote:
CSR is an object in a container that goes over a 'wire'.   Sometimes the wire 
is very small (BT4) so the container needs to be tightly designed.

It should be a standard, not something totally off the wall.  Well I could do 
it in CBOR, and probably will at some point, but for now something more common 
in PKIX world should work.

Mangle it, stuff it down the wire, de-mangle it and use it.  For now I am 
referencing RFC 2986.

What do you suggest.  Please reference documents that can be referenced in the 
document.

Thanks

On 8/28/19 5:23 PM, Michael Sierchio wrote:

I don't see the point in DER encoding for a CSR – The RA and CA decide the 
composition of the cert, based on the rules and CPA that they follow, and of 
course any cert issued will be in DER format, and may include reordering or 
modified/expanded extensions and key use restrictions.  A CSR is basically an 
assertion that includes pubkey, proof of possession of the private key, and any 
request elements required by policy.  It's a one-time document that needs to be 
validated precisely once.


On Wed, Aug 28, 2019 at 6:49 AM Robert Moskowitz <mailto:r...@htt-consult.com&g

Re: Format and standard for CSR

[Blumenthal, Uri - 0553 - MITLL]

Do you have an ASN.1 definition fit the content of CSR, or are you willing to 
create one?

IMHO, DER would be a pretty good choice, fat better than something home-brewed 
and non-standard.

Regards,
Uri

Sent from my iPhone

> On Aug 28, 2019, at 17:49, Robert Moskowitz  wrote:
> 
> CSR is an object in a container that goes over a 'wire'.   Sometimes the wire 
> is very small (BT4) so the container needs to be tightly designed.
> 
> It should be a standard, not something totally off the wall.  Well I could do 
> it in CBOR, and probably will at some point, but for now something more 
> common in PKIX world should work.
> 
> Mangle it, stuff it down the wire, de-mangle it and use it.  For now I am 
> referencing RFC 2986.
> 
> What do you suggest.  Please reference documents that can be referenced in 
> the document.
> 
> Thanks
> 
> 
>> On 8/28/19 5:23 PM, Michael Sierchio wrote:
>> 
>> I don't see the point in DER encoding for a CSR – The RA and CA decide the 
>> composition of the cert, based on the rules and CPA that they follow, and of 
>> course any cert issued will be in DER format, and may include reordering or 
>> modified/expanded extensions and key use restrictions.  A CSR is basically 
>> an assertion that includes pubkey, proof of possession of the private key, 
>> and any request elements required by policy.  It's a one-time document that 
>> needs to be validated precisely once.
>> 
>> 
>>> On Wed, Aug 28, 2019 at 6:49 AM Robert Moskowitz  
>>> wrote:
>>> I am writing an Internet Draft that will include transmission of a CSR, 
>>> so I need to reference the proper source.  No more sloppy, "well it 
>>> works...".
>>> 
>>> Some digging said it is in PKCS#10 - CSR.  But I did not stop with that.
>>> 
>>> A bit more googling lead me to RFC 4211...
>>> 
>>> When I create a CSR with:
>>> 
>>> openssl req -config openssl-intermediate.cnf\
>>> -key ./private/client.key.pem \
>>> -subj "$DN" -new -out ./csr/client.csr.pem
>>> 
>>> What format is this?  Are there better, more concise formats (e.g. DER?) 
>>> for transmission over constrained networks?
>>> 
>>> I can dump it with
>>> 
>>> openssl req -text -noout -verify -in ./csr/client.csr.pem
>>> 
>>> But that does not really tell me the format, only what is in the cert.
>>> 
>>> Thanks
>>> 
>> 
>> 
>> -- 
>> 
>> "Well," Brahmā said, "even after ten thousand explanations, a fool is no 
>> wiser, but an intelligent person requires only two thousand five hundred."
>> 
>> - The Mahābhārata
> 


smime.p7s
Description: S/MIME cryptographic signature

Re: question about certificate verify

[Blumenthal, Uri - 0553 - MITLL]

Is there a potential problem - if a certificate has multiple issues, such as 
bad signature and certificate expired? Would all of these conditions be 
reported, or only the first one detected?

Regards,
Uri

Sent from my iPhone

On Aug 26, 2019, at 10:11, Viktor Dukhovni  wrote:

>> On Aug 26, 2019, at 5:24 AM, forston_...@trendmicro.com wrote:
>> 
>> We check a sub-certificate with a lot of root certificates.
>> We don’t want to check sub-certificate’s expire time, but we want to get an 
>> error when root certificate expired.
>> 
>> I try to verify it by following option,
>>  X509_VERIFY_PARAM* pm = X509_STORE_CTX_get0_param(xstore_ctx);
>>  X509_VERIFY_PARAM_set_flags(pm, X509_V_FLAG_NO_CHECK_TIME);
>> 
>>  iret = X509_verify_cert(xstore_ctx); 
>> 
>> But it also will ignore root certificate’s expire.
>> 
>> So, can you give me some suggestion for my question.
> 
> To ignore expiration of only the leaf certificate, you
> need a verification callback that checks the error
> reason at depth 0 and if it is expiration, returns
> "ok = 1" anyway.
> 
> -- 
>Viktor.
> 


smime.p7s
Description: S/MIME cryptographic signature

Re: master branch: EC test broken AGAIN?

[Blumenthal, Uri - 0553 - MITLL]

On 8/7/19, 10:57 AM, "openssl-users on behalf of Matt Caswell" 
 wrote:
  >  >> ../test/recipes/15-test_ec.t (Wstat: 256 Tests: 5 
Failed: 1)
   > > 
   > > Assuming you are building with enable-ec_nistp_64_gcc_128 then the fix 
for this
   > > issue is here:
   > > 
   > > https://github.com/openssl/openssl/pull/9546
   >
   > ...now pushed to master.

Thank you - yes the build was with "enable-ec_nistp_64_gcc_128", and I confirm 
that the fix works.





smime.p7s
Description: S/MIME cryptographic signature

master branch: EC test broken AGAIN?

[Blumenthal, Uri - 0553 - MITLL]

Test Summary Report

---

../test/recipes/15-test_ec.t (Wstat: 256 Tests: 5 Failed: 1)

  Failed test:  2

  Non-zero exit status: 1

Files=174, Tests=1660, 122 wallclock secs ( 1.27 usr  0.34 sys + 81.53 cusr 
29.91 csys = 113.05 CPU)

Result: FAIL

 

Does it seem to have become repetitive? ;-)

-- 

Regards,

Uri



smime.p7s
Description: S/MIME cryptographic signature

Apps hang when openssl.cnf defines PKCS#11 engine

[Blumenthal, Uri - 0553 - MITLL]

It is weird. MacOS 10.14.6, Xcode-10.3, OpenSSL-1.1.1c (Macports-installed), 
current master of libp11.

Symptoms: when PKCS#11 engine is defined, git hangs upon HTTPS retrieval. If I 
comment the engine out in openssl.cnf, or tell git to not load openssl.cnf - it 
works fine:

$ openssl version -d
OPENSSLDIR: "/opt/local/etc/openssl"
$ openssl version
OpenSSL 1.1.1c  28 May 2019
$ openssl engine -t pkcs11
(pkcs11) pkcs11 engine
 [ available ]
$ echo $OPENSSL_CONF
/opt/local/etc/openssl/openssl.cnf
$ git pull
^C   [hangs until killed]
$ OPENSSL_CONF=/dev/null git pull
Already up to date.
$ git pull
^C [hangs until killed]
$


Here's the openssl.cnf file with the middle cut off (to save space and make 
reading easier):

# OpenSSL example configuration file.
# This is mostly being used for generation of certificate requests.
#

# Note that you can include other files from the main configuration
# file using the .include directive.
#.include filename

openssl_conf = openssl_init

# This definition stops the following lines choking if HOME isn't
# defined.
HOME= .

# Extra OBJECT IDENTIFIER info:
#oid_file   = $ENV::HOME/.oid
oid_section = new_oids
. . . . .
[openssl_init]

engines = engine_section

[engine_section]
pkcs11 = pkcs11_section
gost   = gost_section

[pkcs11_section]
engine_id = pkcs11
dynamic_path = /opt/local/lib/engines-1.1/libpkcs11.so
MODULE_PATH  = /Library/OpenSC/lib/opensc-pkcs11.so
init = 0

[gost_section]
engine_id = gost
dynamic_path = /opt/local/lib/engines-1.1/gost.dylib
default_algorithms = ALL
CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet
PBE_PARAMS = "gost12_512"


Note: commenting out "gost" engine had no effect. Commenting out "pkcs11" 
engine completely resolved this problem, but caused a different problem with an 
app that uses OpenSSL and libp11 to access smartcards.

Here's the hanging process snap, in case it can help figuring what's wrong:

Sampling process 31833 for 3 seconds with 1 millisecond of run time between 
samples
Sampling completed, processing symbols...
Analysis of sampling git-remote-https (pid 31833) every 1 millisecond
Process: git-remote-https [31833]
Path:/opt/local/libexec/*/git-remote-https
Load Address:0x103bb3000
Identifier:  git-remote-https
Version: 0
Code Type:   X86-64
Parent Process:  git [31832]

Date/Time:   2019-07-23 18:28:11.777 -0400
Launch Time: 2019-07-23 18:27:35.376 -0400
OS Version:  Mac OS X 10.14.6 (18G84)
Report Version:  7
Analysis Tool:   /usr/bin/sample

Physical footprint: 1640K
Physical footprint (peak):  1648K


Call graph:
2889 Thread_367826   DispatchQueue_1: com.apple.main-thread  (serial)
  2889 start  (in libdyld.dylib) + 1  [0x7fff707a53d5]
2889 main  (in git-remote-https) + 131  [0x103bbd983]
  2889 cmd_main  (in git-remote-https) + 2241  [0x103bb4bc1]
2889 discover_refs  (in git-remote-https) + 762  [0x103bb635a]
  2889 http_request_reauth  (in git-remote-https) + 34  
[0x103bb9dd2]
2889 http_request  (in git-remote-https) + 1225  [0x103bbc109]
  2889 run_one_slot  (in git-remote-https) + 147  [0x103bb9c33]
2889 run_active_slot  (in git-remote-https) + 69  
[0x103bb9875]
  2889 step_active_slots  (in git-remote-https) + 31  
[0x103bb977f]
2889 curl_multi_perform  (in libcurl.4.dylib) + 133  
[0x103dbcfb1]
  2889 multi_runsingle  (in libcurl.4.dylib) + 889  
[0x103dbd430]
2889 Curl_http_connect  (in libcurl.4.dylib) + 365  
[0x103da2742]
  2889 https_connecting  (in libcurl.4.dylib) + 23  
[0x103da2793]
2889 Curl_ssl_connect_nonblocking  (in 
libcurl.4.dylib) + 105  [0x103de24f0]
  2889 ossl_connect_common  (in 
libcurl.4.dylib) + 1829  [0x103dddfbe]
2874 Curl_ossl_seed  (in libcurl.4.dylib) + 
174  [0x103ddd75b]
+ 2873 Curl_wait_ms  (in libcurl.4.dylib) + 
98  [0x103dc0c87]
+ ! 2873 __select  (in 
libsystem_kernel.dylib) + 10  [0x7fff708e161a]
+ 1 Curl_wait_ms  (in libcurl.4.dylib) + 36 
 [0x103dc0c49]
+   1 Curl_now  (in libcurl.4.dylib) + 23  
[0x103d9b90f]
+ 1 clock_gettime  (in 
libsystem_c.dylib) + 184  [0x7fff707f01b2]
+   1 _mach_boottime_usec  (in 
libsystem_c.dylib) + 51  [0x7fff707f00cf]
+ 1 gettimeofday  (in 
libsystem_c.dylib) + 45  [0x7fff707fedcd]
+   1 
__commpage_gettimeofday_internal  (in libsystem_kernel.dylib) + 36  
[0x7fff708db23c]
  

Re: Ciphers provided by engine not accessible...?

[Blumenthal, Uri - 0553 - MITLL]

On 7/22/19, 3:38 PM, "Richard Levitte"  wrote:
   > > Turned out the failure was my misconfiguration - but the "config"
> > man page doesn't seem to describe the *exact* order of the
>  > statements/sections.
>
> It does, but perhaps not in a way you expected.

:-)
 
   >  So the "openssl_conf = openssl_init" line must be early in the config
   >  file. 

Yep, as proven by my experience.

   >  The order of the different named sections doesn't (or
   >  shouldn't) really matter.

I agree with the "shouldn't", but in my experience it did. I had to move

[openssl_init]
engines = engine_section

to just above the [engine_section] itself - placing it in *any* other location 
in the file, including just after the "openssl_conf = " line, caused problems.

 


smime.p7s
Description: S/MIME cryptographic signature

Re: Ciphers provided by engine not accessible...?

[Blumenthal, Uri - 0553 - MITLL]

Turned out the failure was my misconfiguration - but the "config" man page 
doesn't seem to describe the *exact* order of the statements/sections.

What I found experimentally, was:

1. "openssl_conf = openssl_init" line must be the first non-comment line in the 
openssl.cnf file, otherwise engines won't be loaded.

2. "[openssl_init]\n engines = engine_section" lines must *both* be at the end 
of the openssl.cnf file, just before the "[engine_section]" section.

These are the errors I get if the above order is violated:

$ openssl engine -t gost pkcs11 rdrand
(gost) Reference implementation of GOST engine
 [ available ]
(pkcs11) pkcs11 engine
 [ available ]
(rdrand) Intel RDRAND engine
 [ available ]
4566365632:error:25066067:DSO support routines:dlfcn_load:could not load the 
shared library:crypto/dso/dso_dlfcn.c:119:filename(libHOME.dylib): 
dlopen(libHOME.dylib, 2): image not found
4566365632:error:25070067:DSO support routines:DSO_load:could not load the 
shared library:crypto/dso/dso_lib.c:162:
4566365632:error:0E07506E:configuration file routines:module_load_dso:error 
loading dso:crypto/conf/conf_mod.c:224:module=HOME, path=HOME
4566365632:error:0E076071:configuration file routines:module_run:unknown module 
name:crypto/conf/conf_mod.c:165:module=HOME
$ ll /opt/local/lib/engines-1.1/pkcs11.dylib
-rwxr-xr-x  1 root  admin  79952 Jun 12 09:37 
/opt/local/lib/engines-1.1/pkcs11.dylib*
$ /Library/OpenSC/lib/opensc-pkcs11.so
-bash: /Library/OpenSC/lib/opensc-pkcs11.so: cannot execute binary file
$ ll /Library/OpenSC/lib/opensc-pkcs11.so
-rwxr-xr-x  1 root  wheel  1666552 Jul 22 12:35 
/Library/OpenSC/lib/opensc-pkcs11.so*
$

Here's the *current* openssl.cnf (I removed the middle part that deals with the 
certificate parameters, as it seems irrelevant to this issue) - your comments 
are welcome:

# Note that you can include other files from the main configuration
# file using the .include directive.
#.include filename

openssl_conf = openssl_init

# This definition stops the following lines choking if HOME isn't
# defined.
HOME= .

# Extra OBJECT IDENTIFIER info:
#oid_file   = $ENV::HOME/.oid
oid_section = new_oids

# To use this configuration file with the "-extfile" option of the
# "openssl x509" utility, name here the section containing the
# X.509v3 extensions to use:
# extensions=
# (Alternatively, use a configuration file that has only
# X.509v3 extensions in its main [= default] section.)

[ new_oids ]
. . . . .
[openssl_init]
engines = engine_section

#
[engine_section]
pkcs11 = pkcs11_section
gost   = gost_section

[pkcs11_section]
engine_id = pkcs11
dynamic_path = /opt/local/lib/engines-1.1/pkcs11.dylib
MODULE_PATH  = /Library/OpenSC/lib/opensc-pkcs11.so
init = 0

[gost_section]
engine_id = gost
dynamic_path = /opt/local/lib/engines-1.1/gost.dylib
default_algorithms = ALL
CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet

#####


On 7/19/19, 2:10 PM, "openssl-users on behalf of Blumenthal, Uri - 0553 - 
MITLL"  wrote:

MacOS Mojave 10.14.5, OpenSSL-1.1.1c (Macports-installed).

Engines defined in the openssl.cnf file:

#
[engine_section]
pkcs11 = pkcs11_section
gost   = gost_section

[pkcs11_section]
engine_id = pkcs11
dynamic_path = /opt/local/lib/engines-1.1/libpkcs11.so
MODULE_PATH  = /Library/OpenSC/lib/opensc-pkcs11.so
init = 0

[gost_section]
engine_id = gost
dynamic_path = /opt/local/lib/engines-1.1/gost.dylib
default_algorithms = ALL
CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet
init = 1
#

Note, whether the above has "init = 1" or not, does not alter the outcome.

Engine in question is "gost". 

First, the engine does not load automatically/dynamically. For "openssl 
dgst" I have to specify it explicitly, otherwise the algorithms it provides, 
are not available:

$ openssl dgst -md_gost94 ~/LastTest.log
dgst: Unrecognized flag md_gost94
dgst: Use -help for summary.
$ openssl dgst -engine gost -md_gost94 ~/LastTest.log
engine "gost" set.
md_gost94(/Users/ur20980/LastTest.log)= 
e82e6e515c86851498eac606722b50b724b1f95952d4edb7202029f127751816
$

Second - even when I explicitly specify the engine, "openssl speed" refuses 
to recognize the ciphers provided by it, though "openssl enc" shows that it can 
access them:

$ openssl speed -engine gost -evp gost89-cbc
speed: gost89-cbc is an unknown cipher or digest
$ openssl enc -engine gost -ciphers
engine "gost" set.
Supported ciphers:
-aes-128-cbc   -aes-128-cfb   -aes-128-cfb1 

-aes-128-cfb8  -aes-128-ctr  

Re: Ciphers provided by engine not accessible...?

[Blumenthal, Uri - 0553 - MITLL]

Are there any other parts of the openssl.cnf that could be related to this 
issue, or help diagnose it’s cause?
Does your configuration file contain a header similar to described in the Gost 
engine documentation? If no, the gost section is not processed. 

I don't remember any significant changes in 1.1.1 engine processing, and it 
works with 1.0.2

Sorry for brevity, I'll be able to look in more details only at the beginning 
of August. 

Darn… You were right – that header (openssl_conf = openssl_def) was NOT 
present. Adding it resulted in success (with some error messages):

$ openssl speed -engine gost -evp gost89-cbc
engine "gost" set.
Doing gost89-cbc for 3s on 16 size blocks: 13107440 gost89-cbc's in 2.99s
Doing gost89-cbc for 3s on 64 size blocks: 3383428 gost89-cbc's in 3.00s
Doing gost89-cbc for 3s on 256 size blocks: 849765 gost89-cbc's in 3.00s
Doing gost89-cbc for 3s on 1024 size blocks: 211166 gost89-cbc's in 3.00s
Doing gost89-cbc for 3s on 8192 size blocks: 26167 gost89-cbc's in 3.01s
Doing gost89-cbc for 3s on 16384 size blocks: 13338 gost89-cbc's in 3.00s
4571538880:error:8106A07A:lib(129):GOST_CIPHER_CTL:rng 
error:/Users/ur20980/src/engine/gost_crypt.c:671:
4571538880:error:0607C085:digital envelope routines:EVP_CIPHER_CTX_ctrl:ctrl 
operation not implemented:crypto/evp/evp_enc.c:628:
4571538880:error:8106A07A:lib(129):GOST_CIPHER_CTL:rng 
error:/Users/ur20980/src/engine/gost_crypt.c:671:
4571538880:error:0607C085:digital envelope routines:EVP_CIPHER_CTX_ctrl:ctrl 
operation not implemented:crypto/evp/evp_enc.c:628:
4571538880:error:8106A07A:lib(129):GOST_CIPHER_CTL:rng 
error:/Users/ur20980/src/engine/gost_crypt.c:671:
4571538880:error:0607C085:digital envelope routines:EVP_CIPHER_CTX_ctrl:ctrl 
operation not implemented:crypto/evp/evp_enc.c:628:
4571538880:error:8106A07A:lib(129):GOST_CIPHER_CTL:rng 
error:/Users/ur20980/src/engine/gost_crypt.c:671:
4571538880:error:0607C085:digital envelope routines:EVP_CIPHER_CTX_ctrl:ctrl 
operation not implemented:crypto/evp/evp_enc.c:628:
4571538880:error:8106A07A:lib(129):GOST_CIPHER_CTL:rng 
error:/Users/ur20980/src/engine/gost_crypt.c:671:
4571538880:error:0607C085:digital envelope routines:EVP_CIPHER_CTX_ctrl:ctrl 
operation not implemented:crypto/evp/evp_enc.c:628:
4571538880:error:8106A07A:lib(129):GOST_CIPHER_CTL:rng 
error:/Users/ur20980/src/engine/gost_crypt.c:671:
4571538880:error:0607C085:digital envelope routines:EVP_CIPHER_CTX_ctrl:ctrl 
operation not implemented:crypto/evp/evp_enc.c:628:
$ openssl speed -engine gost -evp grasshopper-cfb
engine "gost" set.
Doing grasshopper-cfb for 3s on 16 size blocks: 19210088 grasshopper-cfb's in 
3.00s
Doing grasshopper-cfb for 3s on 64 size blocks: 5210373 grasshopper-cfb's in 
3.00s
Doing grasshopper-cfb for 3s on 256 size blocks: 1320249 grasshopper-cfb's in 
3.00s
Doing grasshopper-cfb for 3s on 1024 size blocks: 328343 grasshopper-cfb's in 
3.00s
Doing grasshopper-cfb for 3s on 8192 size blocks: 41459 grasshopper-cfb's in 
3.00s
Doing grasshopper-cfb for 3s on 16384 size blocks: 20488 grasshopper-cfb's in 
3.00s
4541392320:error:8106A07A:lib(129):GOST_CIPHER_CTL:rng 
error:/Users/ur20980/src/engine/gost_grasshopper_cipher.c:558:
4541392320:error:0607C085:digital envelope routines:EVP_CIPHER_CTX_ctrl:ctrl 
operation not implemented:crypto/evp/evp_enc.c:628:
4541392320:error:8106A07A:lib(129):GOST_CIPHER_CTL:rng 
error:/Users/ur20980/src/engine/gost_grasshopper_cipher.c:558:
4541392320:error:0607C085:digital envelope routines:EVP_CIPHER_CTX_ctrl:ctrl 
operation not implemented:crypto/evp/evp_enc.c:628:
4541392320:error:8106A07A:lib(129):GOST_CIPHER_CTL:rng 
error:/Users/ur20980/src/engine/gost_grasshopper_cipher.c:558:
4541392320:error:0607C085:digital envelope routines:EVP_CIPHER_CTX_ctrl:ctrl 
operation not implemented:crypto/evp/evp_enc.c:628:
4541392320:error:8106A07A:lib(129):GOST_CIPHER_CTL:rng 
error:/Users/ur20980/src/engine/gost_grasshopper_cipher.c:558:
4541392320:error:0607C085:digital envelope routines:EVP_CIPHER_CTX_ctrl:ctrl 
operation not implemented:crypto/evp/evp_enc.c:628:
4541392320:error:8106A07A:lib(129):GOST_CIPHER_CTL:rng 
error:/Users/ur20980/src/engine/gost_grasshopper_cipher.c:558:
4541392320:error:0607C085:digital envelope routines:EVP_CIPHER_CTX_ctrl:ctrl 
operation not implemented:crypto/evp/evp_enc.c:628:
4541392320:error:8106A07A:lib(129):GOST_CIPHER_CTL:rng 
error:/Users/ur20980/src/engine/gost_grasshopper_cipher.c:558:
4541392320:error:0607C085:digital envelope routines:EVP_CIPHER_CTX_ctrl:ctrl 
operation not implemented:crypto/evp/evp_enc.c:628:
$




пт, 19 июля 2019 г., 21:09 Blumenthal, Uri - 0553 - MITLL 
<mailto:u...@ll.mit.edu>:
MacOS Mojave 10.14.5, OpenSSL-1.1.1c (Macports-installed).

Engines defined in the openssl.cnf file:

#
[engine_section]
pkcs11 = pkcs11_section
gost   = gost_section

[pkcs11_section]
engine_id = pkcs11
dynamic_path = /opt/local/lib/engines-1.1/libpkcs11.so
MODULE_PATH  = /Library/OpenSC

Re: Ciphers provided by engine not accessible...?

[Blumenthal, Uri - 0553 - MITLL]

Is this a full configuration file?

 

It certainly isn’t – but I figured I’d post only the relevant part of it, 
rather than “crowding” the mailing list with something unnecessary.

 

Are there any other parts of the openssl.cnf that could be related to this 
issue, or help diagnose it’s cause?

 

 

 

пт, 19 июля 2019 г., 21:09 Blumenthal, Uri - 0553 - MITLL :

MacOS Mojave 10.14.5, OpenSSL-1.1.1c (Macports-installed).

Engines defined in the openssl.cnf file:

#
[engine_section]
pkcs11 = pkcs11_section
gost   = gost_section

[pkcs11_section]
engine_id = pkcs11
dynamic_path = /opt/local/lib/engines-1.1/libpkcs11.so
MODULE_PATH  = /Library/OpenSC/lib/opensc-pkcs11.so
init = 0

[gost_section]
engine_id = gost
dynamic_path = /opt/local/lib/engines-1.1/gost.dylib
default_algorithms = ALL
CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet
init = 1
#

Note, whether the above has "init = 1" or not, does not alter the outcome.

Engine in question is "gost". 

First, the engine does not load automatically/dynamically. For "openssl dgst" I 
have to specify it explicitly, otherwise the algorithms it provides, are not 
available:

$ openssl dgst -md_gost94 ~/LastTest.log
dgst: Unrecognized flag md_gost94
dgst: Use -help for summary.
$ openssl dgst -engine gost -md_gost94 ~/LastTest.log
engine "gost" set.
md_gost94(/Users/ur20980/LastTest.log)= 
e82e6e515c86851498eac606722b50b724b1f95952d4edb7202029f127751816
$

Second - even when I explicitly specify the engine, "openssl speed" refuses to 
recognize the ciphers provided by it, though "openssl enc" shows that it can 
access them:

$ openssl speed -engine gost -evp gost89-cbc
speed: gost89-cbc is an unknown cipher or digest
$ openssl enc -engine gost -ciphers
engine "gost" set.
Supported ciphers:
-aes-128-cbc   -aes-128-cfb   -aes-128-cfb1 
-aes-128-cfb8  -aes-128-ctr   -aes-128-ecb   
. . . . .
-des3-wrap -desx  -desx-cbc 
-gost89-gost89-cbc-gost89-cnt   
-gost89-cnt-12 -grasshopper-cbc   -grasshopper-cfb  
-grasshopper-ctr   -grasshopper-ecb   -grasshopper-ofb  
-id-aes128-wrap-id-aes128-wrap-pad-id-aes192-wrap


Seems like a bug...?
-- 
Regards,
Uri



smime.p7s
Description: S/MIME cryptographic signature

Ciphers provided by engine not accessible...?

[Blumenthal, Uri - 0553 - MITLL]

MacOS Mojave 10.14.5, OpenSSL-1.1.1c (Macports-installed).

Engines defined in the openssl.cnf file:

#
[engine_section]
pkcs11 = pkcs11_section
gost   = gost_section

[pkcs11_section]
engine_id = pkcs11
dynamic_path = /opt/local/lib/engines-1.1/libpkcs11.so
MODULE_PATH  = /Library/OpenSC/lib/opensc-pkcs11.so
init = 0

[gost_section]
engine_id = gost
dynamic_path = /opt/local/lib/engines-1.1/gost.dylib
default_algorithms = ALL
CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet
init = 1
#

Note, whether the above has "init = 1" or not, does not alter the outcome.

Engine in question is "gost". 

First, the engine does not load automatically/dynamically. For "openssl dgst" I 
have to specify it explicitly, otherwise the algorithms it provides, are not 
available:

$ openssl dgst -md_gost94 ~/LastTest.log
dgst: Unrecognized flag md_gost94
dgst: Use -help for summary.
$ openssl dgst -engine gost -md_gost94 ~/LastTest.log
engine "gost" set.
md_gost94(/Users/ur20980/LastTest.log)= 
e82e6e515c86851498eac606722b50b724b1f95952d4edb7202029f127751816
$

Second - even when I explicitly specify the engine, "openssl speed" refuses to 
recognize the ciphers provided by it, though "openssl enc" shows that it can 
access them:

$ openssl speed -engine gost -evp gost89-cbc
speed: gost89-cbc is an unknown cipher or digest
$ openssl enc -engine gost -ciphers
engine "gost" set.
Supported ciphers:
-aes-128-cbc   -aes-128-cfb   -aes-128-cfb1 
-aes-128-cfb8  -aes-128-ctr   -aes-128-ecb   
. . . . .
-des3-wrap -desx  -desx-cbc 
-gost89-gost89-cbc-gost89-cnt   
-gost89-cnt-12 -grasshopper-cbc   -grasshopper-cfb  
-grasshopper-ctr   -grasshopper-ecb   -grasshopper-ofb  
-id-aes128-wrap-id-aes128-wrap-pad-id-aes192-wrap


Seems like a bug...?
-- 
Regards,
Uri


smime.p7s
Description: S/MIME cryptographic signature

Re: Errors building 1.1.1 on RHEL 7

[Blumenthal, Uri - 0553 - MITLL]

Probably, disregard: the problem seems to be related to the incomplete support 
for ISO C11 in GCC on CentOS (and I'm willing to bet - on RHEL). 

Changing the standard to "-std=gnu99" lead to a successful build with all the 
tests passing.


On 7/18/19, 12:28 PM, "openssl-users on behalf of Blumenthal, Uri - 0553 - 
MITLL"  wrote:

I'm getting a somewhat different error trying to build OpenSSL_1_1_1-stable 
on CentOS 7 (similar to RHEL 7).

Configuration:

./config --prefix=$HOME/openssl-1.1 --debug 
--openssldir=$HOME/openssl-1.1/etc --with-rand-seed=rdcpu enable-aria 
enable-ec_nistp_64_gcc_128 enable-md2 enable-rc5 enable-weak-ssl-ciphers 
enable-zlib-dynamic shared threads enable-rfc3779 enable-ssl-trace

Followed by 

  make depend && make clean && make -j 2 all && make test && make install

I'm appending the output of "perl configdata.pm -d" at the end.

Here's the problem:

. . . . .
gcc  -I. -Icrypto/include -Iinclude -fPIC -pthread -m64 -Wa,--noexecstack 
-std=gnu11 -O3 -march=native -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC 
-DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT 
-DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM 
-DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM 
-DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM 
-DOPENSSLDIR="\"/home/ur20980/openssl-1.1/etc\"" 
-DENGINESDIR="\"/home/ur20980/openssl-1.1/lib/engines-1.1\"" -DZLIB 
-DZLIB_SHARED  -MMD -MF crypto/asn1/a_strex.d.tmp -MT crypto/asn1/a_strex.o -c 
-o crypto/asn1/a_strex.o crypto/asn1/a_strex.c
In file included from crypto/include/internal/evp_int.h:11:0,
 from crypto/asn1/a_sign.c:22:
include/internal/refcount.h:21:25: fatal error: stdatomic.h: No such file 
or directory
 #  include 
 ^
compilation terminated.
make[1]: *** [crypto/asn1/a_sign.o] Error 1
make[1]: *** Waiting for unfinished jobs

This is the compiler used:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man 
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla 
--enable-bootstrap --enable-shared --enable-threads=posix 
--enable-checking=release --with-system-zlib --enable-__cxa_atexit 
--disable-libunwind-exceptions --enable-gnu-unique-object 
--enable-linker-build-id --with-linker-hash-style=gnu 
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin 
--enable-initfini-array --disable-libgcj 
--with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install
 
--with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install
 --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC) 
$

External flags:
$ env | grep FLAGS
CXXFLAGS=-std=gnu++11 -O3 -march=native
CFLAGS=-std=gnu11 -O3 -march=native
$

Finally, output of "perl configdata.pm -d":

Command line (with current working directory = .):

/usr/bin/perl ./Configure linux-x86_64 
--prefix=/home/ur20980/openssl-1.1 --debug 
--openssldir=/home/ur20980/openssl-1.1/etc --with-rand-seed=rdcpu enable-aria 
enable-ec_nistp_64_gcc_128 enable-md2 enable-rc5 enable-weak-ssl-ciphers 
enable-zlib-dynamic shared threads enable-rfc3779 enable-ssl-trace

Perl information:

/usr/bin/perl
5.16.3 for x86_64-linux-thread-multi

Enabled features:

aria
asm
async
autoalginit
autoerrinit
autoload-config
bf
blake2
buildtest-c\+\+
camellia
capieng
cast
chacha
cmac
cms
comp
ct
deprecated
des
dgram
dh
dsa
dtls
dynamic-engine
ec
ec2m
ecdh
ecdsa
ec_nistp_64_gcc_128
engine
err
filenames
gost
hw(-.+)?
idea
makedepend
md2
md4
mdc2
multiblock
nextprotoneg
pinshared
ocb
ocsp
pic
poly1305
posix-io
psk
rc2
rc4
rc5
rdrand
rfc3779
rmd160
scrypt
seed
shared
siphash
sm2
sm3
sm4
sock
srp
srtp
sse2
ssl
ssl-trace
static-engine
stdio
tests
thread

Re: Errors building 1.1.1 on RHEL 7

[Blumenthal, Uri - 0553 - MITLL]

I'm getting a somewhat different error trying to build OpenSSL_1_1_1-stable on 
CentOS 7 (similar to RHEL 7).

Configuration:

./config --prefix=$HOME/openssl-1.1 --debug --openssldir=$HOME/openssl-1.1/etc 
--with-rand-seed=rdcpu enable-aria enable-ec_nistp_64_gcc_128 enable-md2 
enable-rc5 enable-weak-ssl-ciphers enable-zlib-dynamic shared threads 
enable-rfc3779 enable-ssl-trace

Followed by 

  make depend && make clean && make -j 2 all && make test && make install

I'm appending the output of "perl configdata.pm -d" at the end.

Here's the problem:

. . . . .
gcc  -I. -Icrypto/include -Iinclude -fPIC -pthread -m64 -Wa,--noexecstack 
-std=gnu11 -O3 -march=native -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC 
-DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT 
-DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM 
-DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM 
-DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM 
-DOPENSSLDIR="\"/home/ur20980/openssl-1.1/etc\"" 
-DENGINESDIR="\"/home/ur20980/openssl-1.1/lib/engines-1.1\"" -DZLIB 
-DZLIB_SHARED  -MMD -MF crypto/asn1/a_strex.d.tmp -MT crypto/asn1/a_strex.o -c 
-o crypto/asn1/a_strex.o crypto/asn1/a_strex.c
In file included from crypto/include/internal/evp_int.h:11:0,
 from crypto/asn1/a_sign.c:22:
include/internal/refcount.h:21:25: fatal error: stdatomic.h: No such file or 
directory
 #  include 
 ^
compilation terminated.
make[1]: *** [crypto/asn1/a_sign.o] Error 1
make[1]: *** Waiting for unfinished jobs

This is the compiler used:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man 
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla 
--enable-bootstrap --enable-shared --enable-threads=posix 
--enable-checking=release --with-system-zlib --enable-__cxa_atexit 
--disable-libunwind-exceptions --enable-gnu-unique-object 
--enable-linker-build-id --with-linker-hash-style=gnu 
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin 
--enable-initfini-array --disable-libgcj 
--with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install
 
--with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install
 --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC) 
$

External flags:
$ env | grep FLAGS
CXXFLAGS=-std=gnu++11 -O3 -march=native
CFLAGS=-std=gnu11 -O3 -march=native
$

Finally, output of "perl configdata.pm -d":

Command line (with current working directory = .):

/usr/bin/perl ./Configure linux-x86_64 --prefix=/home/ur20980/openssl-1.1 
--debug --openssldir=/home/ur20980/openssl-1.1/etc --with-rand-seed=rdcpu 
enable-aria enable-ec_nistp_64_gcc_128 enable-md2 enable-rc5 
enable-weak-ssl-ciphers enable-zlib-dynamic shared threads enable-rfc3779 
enable-ssl-trace

Perl information:

/usr/bin/perl
5.16.3 for x86_64-linux-thread-multi

Enabled features:

aria
asm
async
autoalginit
autoerrinit
autoload-config
bf
blake2
buildtest-c\+\+
camellia
capieng
cast
chacha
cmac
cms
comp
ct
deprecated
des
dgram
dh
dsa
dtls
dynamic-engine
ec
ec2m
ecdh
ecdsa
ec_nistp_64_gcc_128
engine
err
filenames
gost
hw(-.+)?
idea
makedepend
md2
md4
mdc2
multiblock
nextprotoneg
pinshared
ocb
ocsp
pic
poly1305
posix-io
psk
rc2
rc4
rc5
rdrand
rfc3779
rmd160
scrypt
seed
shared
siphash
sm2
sm3
sm4
sock
srp
srtp
sse2
ssl
ssl-trace
static-engine
stdio
tests
threads
tls
ts
ui-console
whirlpool
weak-ssl-ciphers
zlib
zlib-dynamic
tls1
tls1-method
tls1_1
tls1_1-method
tls1_2
tls1_2-method
tls1_3
dtls1
dtls1-method
dtls1_2
dtls1_2-method

Disabled features:

afalgeng[too-old-kernel] 
asan[default]OPENSSL_NO_ASAN
crypto-mdebug   [default]OPENSSL_NO_CRYPTO_MDEBUG
crypto-mdebug-backtrace [default]OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
devcryptoeng[default]OPENSSL_NO_DEVCRYPTOENG
egd [default]OPENSSL_NO_EGD
external-tests  [default]OPENSSL_NO_EXTERNAL_TESTS
fuzz-libfuzzer  [default]OPENSSL_NO_FUZZ_LIBFUZZER
fuzz-afl[default]OPENSSL_NO_FUZZ_AFL
heartbeats  [default]OPENSSL_NO_HEARTBEATS
msan

Current master breaks EC tests

[Blumenthal, Uri - 0553 - MITLL]

You probably noticed, but the current master keeps breaking EC tests for the 
last week or so. This is on Mac:

 

 

../test/recipes/15-test_ec.t ... Dubious, test returned 1 
(wstat 256, 0x100)

Failed 1/5 subtests 

 

 

Test Summary Report

---

../test/recipes/15-test_ec.t (Wstat: 256 Tests: 5 Failed: 1)

  Failed test:  2

  Non-zero exit status: 1

Files=172, Tests=1656, 156 wallclock secs ( 1.28 usr  0.36 sys + 118.03 cusr 
31.74 csys = 151.41 CPU)

Result: FAIL

 

This is the config string, and the build command:

 

CFLAGS="-Os -Ofast -g -std=gnu17 -march=native"

 

make distclean || true

 

./config --prefix=$HOME/openssl-1.1 --debug --openssldir=$HOME/openssl-1.1/etc 
--with-rand-seed=rdcpu enable-aria enable-ec_nistp_64_gcc_128 enable-md2 
enable-rc5 enable-weak-ssl-ciphers enable-zlib-dynamic enable-ssl-trace

 

Make depend && make clean && make -j 2 all && make test

 

 

-- 

Regards,

Uri



smime.p7s
Description: S/MIME cryptographic signature

Re: how to set flags in X509_NAME_ENTRY in OpenSSL 1.1.1

[Blumenthal, Uri - 0553 - MITLL]

> > For now the ASN.1 string is not an opaque structure.
> 
> Considering how OpenSSL design evolved, I suspect that the time may come
> when this string would become opaque. Therefore, I suggest that
> getter/setter functions should be added.

Any thoughts about the interface?

Alas, since I don't have any experience actually using these flags, I don't 
consider myself competent suggesting the API here.

Some flag bits look internal, and not necessarily ideal for applications to 
modify directly, so
while these might do:

long ASN1_STRING_get_flags(ASN1_STRING *);
void ASN1_STRING_set_flags(ASN1_STRING *, long);

This makes sense. Also, if there are flags that users are likely to need - 
perhaps explicit getter/setter calls for those individual flags? This would 
lower the likelihood of erroneously affecting unintended flags by a 
"ricochet"...

Perhaps all that's needed is:

int ASN1_BIT_STRING_set_unused(ASN1_STRING *, int);

which sets the unused bit count, checking that the ASN1_STRING type
is V_ASN1_BIT_STRING and the count is in the range [0,7].

That I don't know. I can't figure how or why I would use ..._set_unused()... 
But as I said, my competence in this particular thing is low.


smime.p7s
Description: S/MIME cryptographic signature

Re: how to set flags in X509_NAME_ENTRY in OpenSSL 1.1.1

[Blumenthal, Uri - 0553 - MITLL]

On 6/18/19, 5:44 PM, "openssl-users on behalf of Viktor Dukhovni" 
 
wrote:

We should
perhaps provide getter/setter functions for the flags, or perhaps
even a specific function for indicating the value is a bitstring,
and how many bits it holds.  For now the ASN.1 string is not an
opaque structure.

Considering how OpenSSL design evolved, I suspect that the time may come when 
this string would become opaque. Therefore, I suggest that getter/setter 
functions should be added.


smime.p7s
Description: S/MIME cryptographic signature

Re: why does RAND_add() take "randomness" as a "double"?

[Blumenthal, Uri - 0553 - MITLL]

I can understand why you may not want to break existing API. Why not add 
another similar interface done the right way?

On 5/22/19, 1:11 PM, "openssl-users on behalf of Dr. Matthias St. Pierre" 
 
wrote:

I think nobody of us needs to be convinced anymore that making it a 
'double' was a bad idea.
But the RAND api is very ancient and changing the argument type would be a 
breaking change. 
That's why we didn't dare to touch it when we overhauled the RNG 
implementation for 1.1.1,
because we tried very hard not to add unnecessary breaking changes to the 
ones made in 1.1.0.

Matthias




smime.p7s
Description: S/MIME cryptographic signature

Re: why does RAND_add() take "randomness" as a "double"?

[Blumenthal, Uri - 0553 - MITLL]

On 5/21/19, 10:45 AM, "openssl-users on behalf of Salz, Rich via openssl-users" 
 
wrote:

When I overhauled the RAND mechanism, I tried to deprecate this use of 
floating point, 
in favor of just a number from 0 to 100 but was voted down.

If it's a sarcasm, I'm missing the point.

It *is* stupid.

In general, yes, it is.

Luckily, on a modern system with system-provided randomness to seed the 
RNG, you never need this call.

Respectfully disagree. 

There are use cases when one wants to mix/add extra randomness from, e.g., an 
external source (that, for whatever reasons, is trusted more than what's 
provided by the system).





smime.p7s
Description: S/MIME cryptographic signature

Re: i2d_X509_REQ() -> d2i_X509_REQ() = asn1 encoding routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287

[Blumenthal, Uri - 0553 - MITLL]

Hmm... Registering an OID dedicated to express this case should be feasible, 
and perfectly within the ASN.1 rules. One question - where in the OID tree 
would it live, as offhand I don't have any idea. It can't be too deep down, and 
also, it better be fairly short.  

>From the ASN.1 point of view - there's nothing dumb in this idea. There's 
>plenty of MIB objects expressing/representing all kinds of things - might as 
>well add this.



On 3/22/19, 12:34, "openssl-users on behalf of Michael Wojcik" 
 
wrote:

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf 
Of
> Viktor Dukhovni
> Sent: Thursday, March 21, 2019 14:07
> To: openssl-users@openssl.org
>
> > On Mar 21, 2019, at 1:57 PM, Viktor Dukhovni 

> wrote:
> >
> >2.  Emit a "harmless" default OID (such as 0.0), returning to
> > the behaviour prior to 1.0.1i

What about registering a new OID for "missing required object"? Then at 
least there'd be a standard way to represent this case, and other parsers could 
decide to accommodate it however they prefer.

I'm by no means an ASN.1 expert, so this may be a dumb idea.

--
Michael Wojcik
Distinguished Engineer, Micro Focus






smime.p7s
Description: S/MIME cryptographic signature

Re: i2d_X509_REQ() -> d2i_X509_REQ() = asn1 encoding routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287

[Blumenthal, Uri - 0553 - MITLL]

First, let me prefix that while I don't want to badmouth anybody, even 
incompetence cannot excuse deliberately generating bad/unparsable encoding. 
That's one of the cases when the cure is clearly worse than the disease.

On 3/21/19, 13:58, "openssl-users on behalf of Viktor Dukhovni" 
 
wrote:
> > On the OpenSSL side, having found that we emit dubious encodings
> > of structures with an (unspecified) null OID element, I am considering
> > whether it would make sense to encode them as a zero-length (invalid,
> > but faithful) ASN.1 OBJECT:
> > 
> >06 00
> > 
> > *and* decode these back to a zero length NID_undef object.

After discussing this idea with a friend, I am less enthusiastic
about this option.  His point is that if OpenSSL starts emitting
invalid empty OIDs as a way to support encoding incompletely
initialized structures, this could contaminate the ecosystem with
subsequent new downstream work-arounds in other implementations.

I don't see how it is worse than what's there now.

His order of "preference" is:

1.  Return failure from i2d_ASN_OBJECT(), which then percolates
up to failure to encode the containing structure.

That would be the correct but strict behavior: OID is required, therefore no 
OID -> no encoding. Just fail (hopefully with an explanatory error code, and 
documented!)

2.  Emit a "harmless" default OID (such as 0.0), returning to
the behaviour prior to 1.0.1i

I'm OK with that, and it's probably more acceptable than (1), though OID "0.0" 
is not the same as "no-OID". I wonder if there's ever a case when OID "0.0" can 
appear in this construct? If so, then (2) is unacceptable, otherwise I don't 
know.

But the original "fix" (can't call it that but in quotes and with big 
tongue-in-cheek) was there for a reason, however misguided the actual change 
turned out to be. What was the reason for changing this (original) behavior? 
Just desire for "purity" (), or something more tangible/reasonable?

3.  Emit the invalid empty OID (06 00) in the expectation that
this would not be something that other decoders would have
to support.  That is, it would only be used, as in this case,
to serialize and deserialize objects *within* an application,
and there would be no pressure on other implementations to
follow suit.

I'm OK with (3) too. In fact, this would probably be my first preference - and 
yes, implementations that care to support use cases with no-OID would have to 
support this. But at least they won't have a broken parser on their hands.

Failing in i2d_ASN1_OBJECT() is unlikely to do harm, because the
current invalid output is not better, and we've not seen any
complaints until now in ~5 years of OpenSSL 1.0.2 deployment.
So use of i2d on partially created objects looks rather rare,
and perhaps explicit failure is better than any ad-hoc output?

Failing in i2d_ASN1_OBJECT() would be my second preference. My first preference 
would be your (3). I can live with (2), but I don't like it much because 
substituting a valid OID for a no-OID is "slippery".
 


smime.p7s
Description: S/MIME cryptographic signature

Re: i2d_X509_REQ() -> d2i_X509_REQ() = asn1 encoding routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287

[Blumenthal, Uri - 0553 - MITLL]

+1 to Viktor's points.

Regards,
Uri

Sent from my iPhone

> On Mar 21, 2019, at 12:52, Viktor Dukhovni  wrote:
> 
> On Thu, Mar 21, 2019 at 01:00:14PM +, Salz, Rich via openssl-users wrote:
> 
>>>   This software however is 7 years old, we’re not in a position to drop 
>>> everything and rewrite it.
>> 
>> Then don't upgrade?  If it's for a CA you don't need TLS 1.3 for example.
>> 
>> Or take the existing OpenSSL code that works and jam it into the current 
>> release.
> 
> Perhaps the OP is not an end-user, but rather maintains these modules
> for a user community, in which case "don't upgrade" is not generally
> an option.  In any case, it seems a bit premature to close the
> conversation.
> 
> While the original decision to use incomplete (and thus invalid)
> CSRs, is unfortunate, and not OpenSSL's fault, we can still continue
> to discuss meaningful options.  On the DER padding front, the minimal
> working suffix is 7 bytes:
> 
>30 03-- Length 3 sequence
>06 01 00 -- OBJECT ID: 0.0
>03 01 00 -- empty BIT STRING
> 
> One then also prepends a prefix (typically 4 bytes):
> 
>30 82 xx xx -- a sequence of 256 to 65535 bytes
>30 81 xx-- a sequence of 128 to 255 bytes
>30 xx   -- a sequence of up to 127 bytes
> 
> The "xx" length is the DER length of the CRI + 7 bytes for the
> suffix.
> 
> On the OpenSSL side, having found that we emit dubious encodings
> of structures with an (unspecified) null OID element, I am considering
> whether it would make sense to encode them as a zero-length (invalid,
> but faithful) ASN.1 OBJECT:
> 
>06 00
> 
> *and* decode these back to a zero length NID_undef object.  While
> these are likely to not interoperate with many other ASN.1 decoder
> implementations, just interoperating with the same version of OpenSSL
> would make it possible to encode/decode partially initialized
> structures in which some "objects" are as yet unspecified.
> 
> The reason I'm considering changes is that it now appears that the
> original commmit that stopped encoding single element OIDs, is not
> fully baked.  Just skipping required components of structures is
> not a good outcome.
> 
> -- 
>Viktor.


smime.p7s
Description: S/MIME cryptographic signature

Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

[Blumenthal, Uri - 0553 - MITLL]

Since OpenSSL is more than just a TLS implementation, I agree with Michael and 
support relaxing these checks when appropriate.

Regards,
Uri

Sent from my iPhone

On Mar 6, 2019, at 10:22, Michael Wojcik  wrote:

>> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
>> Richard Levitte
>> Sent: Wednesday, March 06, 2019 03:07
>> 
>> On Wed, 06 Mar 2019 10:52:44 +0100,
>> Jan Just Keijser wrote:
>>> as a follow-up:  Richard's analysis/suspicion was spot on.
>>> However, it was the *server* side certificate that was causing the
>>> error, and the server certificate does indeed contain a poorly
>>> formatted date:
>>> 
>>> $ openssl asn1parse -in server.crt | grep UTC
>>>   157:d=3  hl=2 l=  13 prim: UTCTIME   :091022132829Z
>>>   172:d=3  hl=2 l=  17 prim: UTCTIME   :370308132808+
>> 
>> I'm glad I could help find the answer.
>> 
>>> OpenSSL 1.0.x groks this, 1.1+ does not.
>> 
>> Yup, 1.1+ is stricter regarding these things.
> 
> I would have expected 1.0.2p and later to have rejected this as well, since 
> the RFC 5280 restrictions on validity date attributes were included in that 
> release. There was some discussion about it on the OpenSSL lists, with some 
> people suggesting that a change to insist on the letter of the standard which 
> broke compatibility with certificates generated by some other implementations 
> was not a great idea. (I am sympathetic to this argument myself, and feel 
> there should at least be an option to relax these restrictions.)
> 
> See for example: 
> https://mta.openssl.org/pipermail/openssl-project/2018-August/000984.html
> 
> It's interesting to note that back in 2009 when GeneralizedTime support for 
> X.509 dates was added to OpenSSL, Erwann Abalea pointed out that RFC 5280 is 
> only a profile of X.509, and X.509 itself allows timezone offsets and 
> fracttional seconds, and so arguably OpenSSL ought to allow them too 
> (presumably for use by non-TLS X.509 applications). (See e.g. 
> http://openssl.6102.n7.nabble.com/openssl-org-1854-GeneralizedTime-support-in-openssl-ca-td38848.html.)
>  Personally, I find that argument persuasive too, and think that it would be 
> appropriate to have a mechanism to disable the 5280 checks.
> 
> Maybe I'll put together a PR, though I don't know if it has much chance of 
> being accepted.
> 
> -- 
> Michael Wojcik 
> Distinguished Engineer, Micro Focus 
> 
> 
> 


smime.p7s
Description: S/MIME cryptographic signature

Re: [openssl-users] Smartcard cert used for encrypt\decrypt

[Blumenthal, Uri - 0553 - MITLL]

On 1/31/19, 09:19, "openssl-users on behalf of Antonio Iacono" 
 wrote:

 

    > Does anybody know how to use the smartcard to encrypt and decrypt files?

 

Smartcard performs public-key crypto operations, which aren't suitable for bulk 
processing, such as file encryption/decryption. In general, you'd need a hybrid 
scheme - generate a random symmetric key, encrypt the file with that symmetric 
key, and encrypt this symmetric key itself with an appropriate public key from 
the smartcard. Decryption would be the reverse: with the smartcard (using the 
private key) decrypt the symmetric key, and pass that symmetric key to OpenSSL 
to decrypt the file. 

 

Here's an example, which I hope would be useful, as it shows how to use OpenSSL 
to encrypt and decrypt data (like symmetric keys – short). It uses OpenSC as 
PKCS#11 library, libp11 as PKCS#11 engine/interface to OpenSSL, p11-kit to 
allow URI for objects on the smartcard, and OpenSSL itself:

 

#!/bin/bash

 

# Settings for US DoD CAC smartcard

MANUFACTURER="manufacturer=Common%20Access%20Card;"

PRK="pkcs11:${MANUFACTURER}id=%00%03;type=private"

PUBK="pkcs11:${MANUFACTURER}id=%00%03;type=public"

 

# Generate a random text file

openssl -out textfile.txt -hex 600

TEXTFILE="textfile.txt"

 

# Generate random symmetric key

KEY=`openssl rand -hex 32`

# Generate random IV for file encryption

IV=`openssl rand  -hex 16`

 

# Encrypt symmetric key to token RSA KEY MAN Key

Echo $KEY | xxd -r -p 200 | openssl pkeyutl -engine pkcs11 -keyform engine 
-encrypt -pubin -inkey "${PUBK}" -pkeyopt rsa_padding_mode:oaep -out 
encrypted.key.enc

# Encrypt file with above symmetric key and IV

openssl enc -aes-256-cfb -a -e -in ${TEXTFILE} -out ${TEXTFILE}.enc -K ${KEY} 
-iv ${IV}

 

# Decrypt symmetric key on the token

KEY2=`openssl pkeyutl -engine pkcs11 -keyform engine -decrypt -inkey "${PRK}" 
-pkeyopt rsa_padding_mode:oaep -in ${TMP}.key.enc | xxd -p -c 200`

# Decrypt the file

openssl enc -aes-256-cfb -a -d -in ${TEXTFILE}.enc -out ${TEXTFILE}.dec -K 
${KEY2} -iv ${IV}

 

 

 

 

    

Hi Boyd,

    

there are many ways to encrypt/decrypto with smartcard but since you

    wrote to the list of OpenSSL I answer you how to do with OpenSSL.

    In the meantime you need two other software, in addition to openssl,

    the engine and the pkcs11 library.

    A step-by-step guide can be found here:

    https://github.com/OpenSC/OpenSC/wiki/Quick-Start-with-OpenSC

    

Antonio

    -- 

openssl-users mailing list

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

    



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

Re: [openssl-users] openssl 1.1.1 manuals

[Blumenthal, Uri - 0553 - MITLL]

The docs site is screwed up. 

CMS_sign is indeed documented for 1.1.1 - but you have to go there via
https://www.openssl.org/docs/man1.1.1 -> Libraries -> CMS_sign.html, which 
would bring you to https://www.openssl.org/docs/man1.1.1/man3/CMS_sign.html 

On 12/27/18, 14:00, "openssl-users on behalf of Michael Richardson" 
 wrote:

J. J. Farrell  wrote:
> man1.1.1 looks OK to me, the pages all appear to be there. What is
> missing is a link to 1.1.1 in the little Manpages list of links on the
> right hand side of the page

https://www.openssl.org/docs/man1.1.0/crypto/CMS_sign.html exists, but
https://www.openssl.org/docs/man1.1.1/crypto/CMS_sign.html does not.

There are other examples which I have come across.

> On 27/12/2018 16:31, Michael Richardson wrote:

> If manual pages for 1.1.1 aren't going to be posted/generated:
> could https://www.openssl.org/docs/man1.1.1 redirect to
> https://www.openssl.org/docs/man1.1.0?

> (I think that 1.1.1 ought to be generated)


> --
> J. J. Farrell Not speaking for Oracle


> 
> Alternatives:

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



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

Re: [openssl-users] FW: Dgst sigopt parameters?

[Blumenthal, Uri - 0553 - MITLL]

Viktor,

Thank you! So, I should expect the format of the sigopt parameters to be the 
same as of pkeyopt? That's very good to know.

I wish the man page mentioned this. ;-)

Regards,
Uri

Sent from my iPhone

On Dec 13, 2018, at 17:08, Viktor Dukhovni  wrote:

>> On Dec 13, 2018, at 2:23 PM, Blumenthal, Uri - 0553 - MITLL 
>>  wrote:
>> 
>> I still would like to know where all the acceptable "dgst -sigopt" 
>> parameters are described for RSA and ECDSA.
>> 
>> Google search and scouring openssl.org manual pages did not bring me 
>> anything.
> 
> Take a look at the "-pkeyopt" option of pkeyutl(1).  I believe these are the
> same options.
> 
> If we ignore key generation parameters, all I'm finding is:
> 
>   dh: dh_pad
>  rsa: rsa_padding_mode
>  rsa: rsa_pss_saltlen
>  rsa: rsa_mgf1_md
>  rsa: rsa_oaep_md
>  rsa: rsa_oaep_label
> 
> And "dh_pad" many not be applicable to dgst(1).
> 
> -- 
>Viktor.
> 
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


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

[openssl-users] FW: Dgst sigopt parameters?

[Blumenthal, Uri - 0553 - MITLL]

I still would like to know where all the acceptable "dgst -sigopt" parameters 
are described for RSA and ECDSA.

 Google search and scouring openssl.org manual pages did not bring me anything.

On 8/24/17, 5:42 PM, "Blumenthal, Uri - 0553 - MITLL"  wrote:

OpenSSL dgst manual page only days that sigopt value are 
algorithm-specific. Where are they described for ECDSA and RSA PSS? 

Thanks!

Regards,
Uri





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

Re: [openssl-users] Question on necessity of SSL_CTX_set_client_CA_list

[Blumenthal, Uri - 0553 - MITLL]

If there's a non-EV CA that would give you a cert for DNS name amazon.com - I'd 
like to make sure it's in my list and marked Not Trusted.

Regards,
Uri

Sent from my iPhone

> On Dec 7, 2018, at 17:02, Kyle Hamilton  wrote:
> 
> CAs *do* verify the attributes they certify.  That they're not presented as 
> such is not the fault of the CAs, but rather of the browsers who insist on 
> not changing or improving their UI.
> 
> The thing is, if I run a website with a forum that I don't ask for money on 
> and don't want any transactions happening on, why should I have to pay for 
> the same level of certainty of my identity that a company like Amazon needs?
> 
> (Why does Amazon need that much certainty? Well, I could set up wireless 
> access points around coffee shops in December, point the DNS provided at 
> those WAPs to my own server and run a fake amazon.com site to capture account 
> credentials and credit cards. Without EV, that's a plausible attack. 
> Especially with SSL being not-by-default, someone could type amazon.com and 
> it can be intercepted without showing any certificate warning -- which then 
> allows a redirect to a lookalike amazon.com name that could get certified by 
> something like LetsEncrypt.)
> 
> Plus, clouds have had a protocol available for doing queries to certs and 
> keys held by other parties for several years. Cloudflare developed this 
> protocol for banks, for whom loss of control of the certificate key is a 
> reportable event, but who also often need DDoS protection. There's no reason 
> it can't be extended to other clouds and sites -- unless Cloudflare patented 
> it and wants royalties, in which case their rent-seeking is destroying the 
> security of the web by convincing cloud salesmen to say that EV is too much 
> trouble to deal with and thus should be killed off in the marketplace.
> 
> Demanding that EV be perfect and dropping support for it if it has any found 
> vulnerability falls into a class of human behavior known as "letting the 
> perfect be the enemy of the good", which is also known as "cutting off the 
> nose to spite the face".  It still cuts down on a huge number of potential 
> attacks, and doing away with it allows those attacks to flourish again. 
> (Which, by the way, is what organized crime would prefer to permit.)
> 
> -Kyle H
> 
> 
>> On Thu, Dec 6, 2018, 14:07 Blumenthal, Uri - 0553 - MITLL > wrote:
>> >> Quoting from Peter Gutmann's "Engineering Security",
>> >> section "EV Certificates: PKI-me-Harder"
>> >>
>> >>  Indeed, cynics would say that this was exactly the problem that
>> >>  certificates and CAs were supposed to solve in the first place, 
>> > and
>> >>  that “high-assurance” certificates are just a way of charging a
>> >>  second time for an existing service.
>> >
>> >Peter Gutman, for all his talents, dislikes PKI with a vengeance.
>> > EV is a standard for OV certificates done right.  Which involves more
>> >thorough identity checks, stricter rules for the CAs to follow etc.
>> >  
>> > The real point of EV certificates is to separate CAs that do a good
>> >job from those that do a more sloppy job, without completely distrusting
>> >the mediocre CA operations.
>> 
>> So, a CA that's supposed to validate its customer before issuing a 
>> certificate, may do a "more sloppy job" if he doesn't cough up some extra 
>> money.
>> 
>> I think Peter is exactly right here. CA either do their job, or they don't. 
>> If they agree to certify a set of attributes, they ought to verify each one 
>> of them.
>> 
>> 
>> -- 
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>> 
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


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

Re: [openssl-users] Question on necessity of SSL_CTX_set_client_CA_list

[Blumenthal, Uri - 0553 - MITLL]

>> Quoting from Peter Gutmann's "Engineering Security",
>> section "EV Certificates: PKI-me-Harder"
>>
>>  Indeed, cynics would say that this was exactly the problem that
>>  certificates and CAs were supposed to solve in the first place, and
>>  that “high-assurance” certificates are just a way of charging a
>>  second time for an existing service.
>
>Peter Gutman, for all his talents, dislikes PKI with a vengeance.
> EV is a standard for OV certificates done right.  Which involves more
>thorough identity checks, stricter rules for the CAs to follow etc.
>  
> The real point of EV certificates is to separate CAs that do a good
>job from those that do a more sloppy job, without completely distrusting
>the mediocre CA operations.
  
So, a CA that's supposed to validate its customer before issuing a certificate, 
may do a "more sloppy job" if he doesn't cough up some extra money.

I think Peter is exactly right here. CA either do their job, or they don't. If 
they agree to certify a set of attributes, they ought to verify each one of 
them.




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

Re: [openssl-users] [EXTERNAL] Re: Self-signed error when using SSL_CTX_load_verify_locations CApath

[Blumenthal, Uri - 0553 - MITLL]

> "Provided chain ends with unknown self-signed certificate".

I like this. 

IMHO "unrecognized" would be more confusing.

I hope the team makes up their mind quickly.

On 12/4/18, 6:17 PM, "openssl-users on behalf of Michael Wojcik" 
 
wrote:

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Jakob Bohm via openssl-users
> Sent: Tuesday, December 04, 2018 08:15
> > Care to create a PR against the "master" branch?  Something
> > along the lines of:
> >
> >  "Provided chain ends with untrusted self-signed certificate"
> >
> > or better.  Here "untrusted" might mean not trusted for the requested
> > purpose, but more precise is not always more clear.
> >
> Perhaps s/untrusted/unknown/ as in
>
> "Provided chain ends with unknown self-signed certificate".

Yes, that might be better. Or maybe "unrecognized". Of course there's scope 
for someone to misinterpret regardless of which term is used. I can suggest 
various alternatives in the PR and let the team decide.

> Or even better, two different error codes:
>
>   - "Only self-signed end certificate provided"
>
>   - "Provided chain ends with unknown root certificate"
>
> (Deciding which one keeps the old error code is left as
>   an exercise).

I can raise that as a possibility too, in the PR. Obviously it's a bit more 
work than simply changing the existing text.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



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



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

Re: [openssl-users] Question on implementing the ameth ctrl ASN1_PKEY_CTRL_DEFAULT_MD_NID

[Blumenthal, Uri - 0553 - MITLL]

The way I understand the ECDSA standard, it is supposed to truncate the 
provided hash - which is why it is possible to have ECDSA-over-P256-SHA384.

One possibility would be for you to truncate the SHA2 output yourself, IMHO.

On 11/30/18, 12:36 PM, "openssl-users on behalf of Fuchs, Andreas" 
 wrote:

The problem is as follows:
The digest parameter of the TPM2_Sign command is checked against the hash 
algorithms supported by the TPM.
If the TPM only supports SHA256, then the maximum size for the digest 
parameter is 32 bytes.
So you cannot pass in a SHA512 hash, even though the TPM does not even 
perform a hash operation.
Kind of stupid, I know, but thats how it goes.
For RSA, I could "emulate" signing by using the TPM2_RSA_Decrypt command. 
For ECDSA however there is no equivalent.
Thus the tpm2-tss-engine will only support up to SHA384 (since that's what 
most TPMs support).

Therefore, the engine needs to communicate to OpenSSL's TLS not to 
negotiate SHA512.

That was apparently added für 1.0.1 and 1.1.1 recently as the 
ASN1_PKEY_CTRL_DEFAULT_MD_NID ameth ctrl.

I just don't know enough about OpenSSL as to where to start with this.

Anyone have any hints please ?


From: William Roberts [bill.c.robe...@gmail.com]
Sent: Friday, November 30, 2018 15:55
To: openssl-users@openssl.org
Cc: Fuchs, Andreas
Subject: Re: [openssl-users] Question on implementing the ameth ctrl 
ASN1_PKEY_CTRL_DEFAULT_MD_NID

On Wed, Nov 28, 2018 at 1:22 AM Fuchs, Andreas
 wrote:
>
> Hi all,
>
> I'm currently implementing a TPM2 engine for OpenSSL over at 
https://github.com/tpm2-software/tpm2-tss-engine
> The problem I'm facing is that OpenSSL's TLS negotiation will request 
ECDSA from my engine with any hash alg, even though the TPM's keys are 
restricted to just one specific hash alg.

What about when keys aren't restricted to one specific signing scheme
and support raw encrypt/decrypt?
You could just synthesize it by building up the signature structure on
the client side
and using the raw primitives to encrypt the signing structure directly.

>
> Most recently, David Woodhouse pointed out the possibility to require a 
certain hash-alg from the key to TLS via the ameth 
ASN1_PKEY_CTRL_DEFAULT_MD_NID at 
https://github.com/tpm2-software/tpm2-tss-engine/issues/31
>
> Since I'm not that familiar with OpenSSL, I wanted to confirm that I'm 
following the right path for implementing this.
> Thus: Is the following approach correct ?
>
> So, at 
https://github.com/tpm2-software/tpm2-tss-engine/blob/master/src/tpm2-tss-engine-ecc.c#L328:
> - I need to call "const EVP_PKEY_ASN1_METHOD *EVP_PKEY_get0_asn1(const 
EVP_PKEY *pkey)" to get the ameth ?
> - I need to call EVP_PKEY_asn1_set_ctrl(EVP_PKEY_ASN1_METHOD *ameth, 
(*pkey_ctrl)) to some pkey_ctrl for ECC keys of mine ?
> - That pkey_ctrl is a int (*pkey_ctrl) (EVP_PKEY *pkey, int op, long 
arg1, void *arg2)) that implements the op ASN1_PKEY_CTRL_DEFAULT_MD_NID ?
> - That pkey_ctrl()'s ASN1_PKEY_CTRL_DEFAULT_MD_NID looks up the hash for 
the provided pkey's ecc key from the tpm2data and returns it via *(int *)arg2 = 
NID_sha1 or NID_sha256 or etc and then returns 1 or 2 or something ?
> - Which one of the return codes (1 or 2) makes it mandatory rather than 
recommended ?
>
> Thanks a lot for any advice,
> Andreas
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



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

Re: [openssl-users] What to do with deprecation errors

[Blumenthal, Uri - 0553 - MITLL]

On 10/20/2018, 21:41, "openssl-users on behalf of Skip Carter" 
 wrote:
Yes, that works just fine for me too.  But if I include ssl.h I have
the problem.  The various DEPRECATED.. macros don't get pre-compiled
and get handed to the compiler.  I think I improperly installed the
headers.

I think so too, because adding ssl.h doesn't break compilation/run for me:

$ cat ttt.c
#include 
#include 
#include 

int main(void)
{
  printf("OPENSSL_VERSION_NUMBER %lx\n",OPENSSL_VERSION_NUMBER);
  return 0;
}
$ gcc -o ttt -I$HOME/openssl-1.1/include ttt.c -L$HOME/openssl-1.1/lib -lcrypto
$ ./ttt
OPENSSL_VERSION_NUMBER 10101010
$ gcc -o ttt ttt.c -lcrypto
$ ./ttt
OPENSSL_VERSION_NUMBER 1000210f
$


On Sun, 2018-10-21 at 00:36 +0000, Blumenthal, Uri - 0553 - MITLL
wrote:
> I'm not sure I understand what you're doing, but:
> 
> $ cat ttt.c
> #include 
> #include 
> 
> int main(void)
> {
>   printf("OPENSSL_VERSION_NUMBER %lx\n",OPENSSL_VERSION_NUMBER);
>   return 0;
> }
> $ gcc -o ttt ttt.c -lcrypto
> $ ./ttt
> OPENSSL_VERSION_NUMBER 1000210f
> $ gcc -o ttt -I$HOME/openssl-1.1/include ttt.c -L$HOME/openssl-
> 1.1/lib -lcrypto
> $ ./ttt
> OPENSSL_VERSION_NUMBER 10101010
> $
> 
> --
> Regards,
> Uri 
> 
> 


-- 
Skip Carter
Taygeta Scientific Inc.

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



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

Re: [openssl-users] What to do with deprecation errors

[Blumenthal, Uri - 0553 - MITLL]

I'm not sure I understand what you're doing, but:

$ cat ttt.c
#include 
#include 

int main(void)
{
  printf("OPENSSL_VERSION_NUMBER %lx\n",OPENSSL_VERSION_NUMBER);
  return 0;
}
$ gcc -o ttt ttt.c -lcrypto
$ ./ttt
OPENSSL_VERSION_NUMBER 1000210f
$ gcc -o ttt -I$HOME/openssl-1.1/include ttt.c -L$HOME/openssl-1.1/lib -lcrypto
$ ./ttt
OPENSSL_VERSION_NUMBER 10101010
$

--
Regards,
Uri 

On 10/20/2018, 15:36, "openssl-users on behalf of Skip Carter" 
 wrote:

All,

I am thinking that the DEPRECATED... macros are not expanded by the
pre-parser so the compiler sees them as a weirdly formed function and
doesn't like it.

I "installed" the header files with 'cp' was there a make command that
I was supposed to use ?

 
On Fri, 2018-10-19 at 16:54 -0700, Skip Carter wrote:
> On Fri, 2018-10-19 at 22:54 +0100, Matt Caswell wrote:
> > 
> > 
> > It looks like its not picking up the definition of the
> > DEPRECATEDIN_1_2_0 macro for some reason.
> > 
> > That macro should be defined in opensslconf.h (which is included
> > from
> > ec.h), and looks like this:
> > 
> > /*
> >  * Do not deprecate things to be deprecated in version 1.2.0 before
> > the
> >  * OpenSSL version number matches.
> >  */
> > #if OPENSSL_VERSION_NUMBER < 0x1020L
> > # define DEPRECATEDIN_1_2_0(f)   f;
> > #elif OPENSSL_API_COMPAT < 0x1020L
> > # define DEPRECATEDIN_1_2_0(f)   DECLARE_DEPRECATED(f)
> > #else
> > # define DEPRECATEDIN_1_2_0(f)
> > #endif
> > 
> > And where OPENSSL_VERSION_NUMBER is declared in opensslv.h (which
> > is
> > included from opensslconf.h). Since 1.1.1 is less than 1.2.0, the
> > first
> > definition of DEPRECATEDIN_1_2_0 should apply, i.e. this macro
> > should
> > effectively be ignored and the parameter should be processed just
> > like
> > any other function declaration.
> > 
> > So do you have an opensslconf.h? And does it have that macro
> > defined
> > in
> > it? My theory is that somehow or other you are picking up an old
> > version
> > of that header (maybe the system version) which doesn't have the
> > macro
> > defined.
> > 
> > Matt
> > 
> 
> I found:
> 
> opensslv.h:# define OPENSSL_VERSION_NUMBER  0x1010100fL
> 
> Also to be sure my compilation environment isn't doing anything
> funky:
> 
> #include 
> 
> #include 
> 
> int main(void)
> {
>   
>   printf("OPENSSL_VERSION_NUMBER %lx\n",OPENSSL_VERSION_NUMBER);
>   
>   return 0;
> }
> 
> gave me the same thing.
> 
> 
> 
> -- 
> Skip Carter
> Taygeta Scientific Inc.
-- 
Skip Carter
Taygeta Scientific Inc.

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



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

Re: [openssl-users] Softhsm + engine_pkcs11 + openssl with EC keys fail.

[Blumenthal, Uri - 0553 - MITLL]

Note that the key to reproducing this issue is compiling SoftHSMv2 with 1.1.1.  
When compiled with 1.0.2p, everything else can be compiled against 1.1.1 and it 
works ok.

Regards,
Uri

Sent from my iPhone

> On Sep 21, 2018, at 02:09, Paras Shah (parashah) via openssl-users 
>  wrote:
> 
> I opened the issue https://github.com/openssl/openssl/issues/7258
> Also, opened issue https://github.com/OpenSC/libp11/issues/249
> and https://github.com/opendnssec/SoftHSMv2/issues/417
>  
> Found the root cause to be the openssl version 1.1.1 that was used to compile 
> the engine_pkcs11 and SoftHSM.
> When I recompiled with openssl-1.0.2p, it worked fine. See 
> https://github.com/OpenSC/libp11/issues/249 for details.
>  
> From: "Paras Shah (parashah)" 
> Date: Tuesday, September 18, 2018 at 10:06 AM
> To: Nicola , "openssl-users@openssl.org" 
> 
> Subject: Re: [openssl-users] Softhsm + engine_pkcs11 + openssl with EC keys 
> fail.
>  
> Sure. I will open the issue.
>  
> From: Nicola 
> Date: Monday, September 17, 2018 at 10:05 PM
> To: "Paras Shah (parashah)" , "openssl-users@openssl.org" 
> 
> Subject: Re: [openssl-users] Softhsm + engine_pkcs11 + openssl with EC keys 
> fail.
>  
> Would it be possible for you to open this as an issue on Github and include 
> there your first email and the full logs?
>  
> Thanks,
>  
> Nicola Tuveri
>  
> On Tue, 18 Sep 2018 at 01:15, Paras Shah (parashah) via openssl-users 
>  wrote:
> That is not it. It results in the same error for the EC key.
> 
>  
> 
> It is not the URL or the ID. Because for a RSA key in the softhsm with id = 
> , it works fine with url containing id=%33%33
> 
>  
> 
> $ openssl pkey -in 
> "pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=6a160d52b750862f;token=token%202.5.0-rc1;id=%33%33;object=rsa%20key;type=private"
>  -engine pkcs11 -inform ENGINE
> 
> engine "pkcs11" set.
> 
> Enter PKCS#11 token PIN for token 2.5.0-rc1:
> 
> -BEGIN PRIVATE KEY-
> 
> MIIBJwIBADANBgkqhkiG9w0BAQEFAASCAREwggENAgEAAoIBAQDD3378F1XbXJvP
> 
> WP2GtZry0u6sL3eNYktQwJfhDMz5evDG+PahVjCMszV5CZvG+Kvap40xPBJoonqi
> 
> oMAQsoLu7/fTx82aEL3TbdjXNLFnQ2KKYmfG9ymx80sLHMmdmDXpNNE+bEKJz1dp
> 
> t1Q0cVduwmqSfB8JyIE6Udz7JX7HCXaVmxoK7z4Njh3dyHsqhdqKIx0dBuK0hCaq
> 
> 4zPzGP/sORA3G9ZPxxpEvF3gvE/zsXj7ifihqbqr2eIFOpB/lQqAehsgQT5/6Iq+
> 
> 9pAX2LCxNkaUHYYZpMkM8Oi37jzg8PX/FnHdm9HQU2IBqYhoqo7/VsNdUDln2QHN
> 
> dGAUprcbAgMBAAE=
> 
> -END PRIVATE KEY-
> 
>  
> 
> Coming back to EC key, looking at the error logs emitted, it does seem to 
> recognize it to be EC (the logs contain EC_routines) somehow but then fails.
> 
>  
> 
> On 9/17/18, 2:22 PM, "openssl-users on behalf of Richard Levitte" 
>  wrote:
> 
>  
> 
> In message <4ac69fc3-bec7-46f6-882a-671196fc0...@contoso.com> on Mon, 17 
> Sep 2018 20:59:59 +, "Paras Shah (parashah)"  said:
> 
>
> 
> > 4. Import the key into softhsm
> 
> >
> 
> > []:~$ softhsm2-util --import ~/tmp/secp256k1-key.pem.pkcs8 --label "ec 
> key" --id  --token
> 
> > "token 2.5.0-rc1"
> 
>
> 
> Ok, so here, the ID is ""
> 
>
> 
> > 5. Get the pkcs11 url for the private key
> 
> >
> 
> > []:~$ p11tool --login --provider=/usr/local/lib/softhsm/libsofthsm2.so 
> --set-pin= --list-all
> 
> >
> 
> > Object 0:
> 
> >
> 
> > URL:
> 
> > 
> pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=6a160d52b750862f;token=token%202.5.0-rc1;id=%11%11;object=ec%20key;type=private
> 
>
> 
> But here, the ID is "%11%11", and since those get percent decoded,
> 
> that's actually two vertical tabs, or with C vector syntax,
> 
> { 0x0b, 0x0b }
> 
>
> 
> I'm not sure what engine-pkcs11 asks of you otherwise, but one guess
> 
> could be to change 'id=%11%11' to 'id=' in that URL and try again.
> 
>
> 
> Cheers,
> 
> Richard
> 
>
> 
> --
> 
> Richard Levitte levi...@openssl.org
> 
> OpenSSL Project http://www.openssl.org/~levitte/
> 
> --
> 
> openssl-users mailing list
> 
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> 
>
> 
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


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

Re: [openssl-users] updating openssl on MacOS

[Blumenthal, Uri - 0553 - MITLL]

On 9/20/18, 4:39 PM, "openssl-users on behalf of Viktor Dukhovni" 
 
wrote:

Despite (IMHO) its increasing obsolescence and irrelevance, the LibreSSL
fork of OpenSSL 1.0.2 also supports ECDSA.

Yep.

> so openssl 1.1.0 or newer, and his Mac is infested with
> 0.98letter.

That sounds like a Mac that's running a dated copy of the OS.

The latest released (High Sierra) MacOS has LibreSSL 2.2.7 - pretty dated (but 
no worries - it doesn't include .h files or linkable libraries for LibreSSL, as 
far as I could tell ;). The previous versions included 0.98letter.

Anybody who needs a "real" OpenSSL on MacOS either builds it himself (like what 
I'm doing with the master ;), or installs stable via Macports (ends up in 
/opt/local) or Brew (AFAIK, ends up in /usr/local/ssl).


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

Re: [openssl-users] updating openssl on MacOS

[Blumenthal, Uri - 0553 - MITLL]

Macports team is working on upgrading OpenSSL to 1.1.1. It takes time because 
they plan to move all the ports that depend on OpenSSL to that level. I assume 
that once that is done, 1.0.2 won't be supported/available on Macports anymore.

Installation - as Dominyk said: "sudo port install openssl" (possibly with 
parameters, check for them via "port info openssl"), and Macports would do the 
right thing. ;-)

I'm not aware of any efforts by Macports to support 1.1.0. 

Thanks!
— 
Regards,
Uri

On 9/20/18, 4:04 PM, "openssl-users on behalf of Dominyk Tiller" 
 wrote:

FWIW on macOS:

If you use Homebrew and want/need OpenSSL 1.1.1 then `brew install
openssl@1.1`. If you want the 1.0.2x series `brew install openssl`
currently is & will likely remain attached to 1.0.2x for the foreseeable.

If you use MacPorts and want OpenSSL 1.0.2x then `sudo port install
openssl`. As far as I'm aware MacPorts does not currently offer a port
for either 1.1.0x or 1.1.1x.

If you use Nix and want OpenSSL 1.1.1 then `nix-env -i openssl-1.1.1`
(I'm unsure if this has made it into a stable release of Nix yet) and if
you want OpenSSL 1.0.2x then `nix-env -i openssl-1.0.2p`. You can get
nix to spit out a list of OpenSSL versions available via `nix-env -qa
openssl`.

Hope this helps some. I'm not sure what the situation is with fink or
pkgsrc, or any newer package managers for the platform I'm unaware of.

Dom
===
Sent from macOS.

On 20/09/2018 20:53, Salz, Rich via openssl-users wrote:
> It's hard enough for the openssl team to document the basic config/build 
things, let alone all the operating systems and vendor-supplied stuff.
> 
> Perhaps a wiki page, that the community could help maintain?
>  
> 
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



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

Re: [openssl-users] Engines on Mac OS X

[Blumenthal, Uri - 0553 - MITLL]

Ouch... Spelling Corrector doing is best. The text below should've been:

"... spitting out a pile of error..."

Oh well. Hard to admit, but sometimes automatic correctors are even more 
eloquent than me, and seem freeer in their choice of words too. ;-)

Regards,
Uri

Sent from my iPhone

> On Sep 3, 2018, at 14:31, Blumenthal, Uri - 0553 - MITLL  
> wrote:
> 
> If it builds a dummy engine - then shouldn't a dummy engine respond 
> gracefully to requests with something like "sorry I can't do anything 
> useful", instead of spitting outa puke of error messages in response to 
> "openssl engine -t capi"?
> 
> Regards,
> Uri
> 
> Sent from my iPhone
> 
>> On Sep 3, 2018, at 12:27, Richard Levitte  wrote:
>> 
>> In message <62b8aa9b-d6d2-4f33-94c5-7bfe11e46...@akamai.com> on Mon, 3 Sep 
>> 2018 13:56:41 +, "Salz, Rich"  said:
>> 
>>>> Gotcha. In that case why does it get built on Mac? I.e., why
>>>> doesn’t the build process exclude it automatically?
>>> 
>>> Beats me. It ends up being a zero-length object file, more or
>>> less. Perhaps Richard Levitte knows.
>> 
>> We've made it conditional in the source file rather than the build
>> configuration, so on non-MSWindows platforms, it becomes a minimal
>> shared object with an entry point that fails unconditionally.
>> 
>> We should obviously rethink that strategy...
>> 
>> Cheers,
>> Richard
>> 
>> -- 
>> Richard Levitte levi...@openssl.org
>> OpenSSL Project http://www.openssl.org/~levitte/
>> -- 
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


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

Re: [openssl-users] Engines on Mac OS X

[Blumenthal, Uri - 0553 - MITLL]

If it builds a dummy engine - then shouldn't a dummy engine respond gracefully 
to requests with something like "sorry I can't do anything useful", instead of 
spitting outa puke of error messages in response to "openssl engine -t capi"?

Regards,
Uri

Sent from my iPhone

> On Sep 3, 2018, at 12:27, Richard Levitte  wrote:
> 
> In message <62b8aa9b-d6d2-4f33-94c5-7bfe11e46...@akamai.com> on Mon, 3 Sep 
> 2018 13:56:41 +, "Salz, Rich"  said:
> 
>>> Gotcha. In that case why does it get built on Mac? I.e., why
>>> doesn’t the build process exclude it automatically?
>> 
>> Beats me. It ends up being a zero-length object file, more or
>> less. Perhaps Richard Levitte knows.
> 
> We've made it conditional in the source file rather than the build
> configuration, so on non-MSWindows platforms, it becomes a minimal
> shared object with an entry point that fails unconditionally.
> 
> We should obviously rethink that strategy...
> 
> Cheers,
> Richard
> 
> -- 
> Richard Levitte levi...@openssl.org
> OpenSSL Project http://www.openssl.org/~levitte/
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


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

Re: [openssl-users] OpenSSL version 1.1.1 pre release 9 published

[Blumenthal, Uri - 0553 - MITLL]

Since this example would show how to generate certificates that people may not 
have a lot of experience dealing with - I think it would make a lot of sense to 
document as much as possible.

In short: yes please do include the examples of both what the certs should look 
like, and how to generate them.

On 8/27/18, 2:34 PM, "openssl-users on behalf of Hubert Kario" 
 wrote:

On Thursday, 23 August 2018 16:35:01 CEST Robert Moskowitz wrote:
> On 08/23/2018 09:00 AM, Tomas Mraz wrote:
> > On Wed, 2018-08-22 at 20:08 -0400, Robert Moskowitz wrote:
> >> On 08/22/2018 11:48 AM, Matt Caswell wrote:
> >>> On 22/08/18 00:53, Robert Moskowitz wrote:
>  On 08/21/2018 06:31 PM, Matt Caswell wrote:
> > On 21/08/18 16:24, Robert Moskowitz wrote:
> >> Thanks!
> >> 
> >> Once Fedora beta picks this up, I will run my scripts against
> >> it and see
> >> if all cases of hash with ED25519 are fixed.
> > 
> > Unfortunately the command line usability changes for this
> > didn't make it
> > into the beta. They should still be in the final release.
>  
>  Sigh.  That means you will get it right.  Right?  :)
>  
>  Change seems simple enough.
> >>> 
> >>> The relevant change has now been merged to master.
> >> 
> >> Fedora had already built pre9.1.  But on the off chance, I will look
> >> at
> >> it with tomorrow's build.
> > 
> > I'm sorry but no, I am not updating Fedora with current git tree
> > checkout. You'll have to wait for the next prerelease or the final
> > version if there are no further prereleases.
> 
> Tomas,
> 
> Thanks for responding here.
> 
> I have been preparing an Internet Draft on how to build an ED25519 pki. 
> I know have the choice of:
> 
> building my own 1.1.1 pre9 for testing.
> Wait to push the draft out until 1.1.1 is fully released.
> Fudge the draft by adding yet another caveat (yes there is a caveat
> section that I developed in creating the ECDSA pki draft) that the
> commands are for how it is suppose to work in production 1.1.1, not what
> I had to do in the prerelease.
> 
> Decisions decisions.  Thing is I want the draft out so I can push for
> EDDSA support in IEEE 802.1AR with the next meeting early Sept.

I'm not sure if providing command line examples for one particular tool are 
a 
good idea...

Example certificates, sure, but not commands to generate them...

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

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

Re: [openssl-users] openssl-1.1.0-stable-SNAP-20180802 issue

[Blumenthal, Uri - 0553 - MITLL]

Same problem on Linux. 

Regards,
Uri

Sent from my iPhone

> On Aug 2, 2018, at 07:47, The Doctor  wrote:
> 
> While compiling today's openssl 1.1.0 snap on FreeBSD 11.2 
> 
> I got
> 
> /usr/bin/cc  -I. -Icrypto/include -Iinclude -DZLIB -DZLIB_SHARED -DDSO_DLFCN 
> -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE 
> -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT 
> -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM 
> -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM 
> -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM -DPOLY1305_ASM 
> -DOPENSSLDIR="\"/usr/local/ssl\"" 
> -DENGINESDIR="\"/usr/local/lib/engines-1.1\"" -DL_ENDIAN -Wall -O3 -pthread 
> -D_THREAD_SAFE -D_REENTRANT  -rdynamic -fPIC -MMD -MF 
> crypto/asn1/tasn_utl.d.tmp -MT crypto/asn1/tasn_utl.o -c -o 
> crypto/asn1/tasn_utl.o crypto/asn1/tasn_utl.c
> cc: warning: argument unused during compilation: '-rdynamic' 
> [-Wunused-command-line-argument]
> crypto/asn1/tasn_utl.c:60:5: error: use of undeclared identifier
>  'CRYPTO_REF_COUNT'
>  CRYPTO_REF_COUNT *lck;
>  ^
> crypto/asn1/tasn_utl.c:60:23: error: use of undeclared identifier 'lck'
>  CRYPTO_REF_COUNT *lck;
>^
> crypto/asn1/tasn_utl.c:70:5: error: use of undeclared identifier 'lck'; did 
> you
>  mean 'lock'?
>  lck = offset2ptr(*pval, aux->ref_offset);
>  ^~~
>  lock
> crypto/asn1/tasn_utl.c:61:21: note: 'lock' declared here
>CRYPTO_RWLOCK **lock;
>  ^
> crypto/asn1/tasn_utl.c:75:10: error: use of undeclared identifier 'lck'; did 
> you
>mean 'lock'?
>*lck = ret = 1;
> ^~~
> lock
> crypto/asn1/tasn_utl.c:61:21: note: 'lock' declared here
>   CRYPTO_RWLOCK **lock;
>  ^
> crypto/asn1/tasn_utl.c:75:14: warning: incompatible integer to pointer
>conversion assigning to 'CRYPTO_RWLOCK *' (aka 'void *') from 'int'
>  [-Wint-conversion]
>  *lck = ret = 1;
>   ^ ~~~
> crypto/asn1/tasn_utl.c:83:14: warning: implicit declaration of function
>   'CRYPTO_UP_REF' is invalid in C99 [-Wimplicit-function-declaration]
> if (!CRYPTO_UP_REF(lck, , *lock))
>  ^
> crypto/asn1/tasn_utl.c:83:28: error: use of undeclared identifier 'lck'; did 
> you
> mean 'lock'?
>if (!CRYPTO_UP_REF(lck, , *lock))
>   ^~~
>   lock
> crypto/asn1/tasn_utl.c:61:21: note: 'lock' declared here
>CRYPTO_RWLOCK **lock;
>  ^
> crypto/asn1/tasn_utl.c:87:14: warning: implicit declaration of function
>  'CRYPTO_DOWN_REF' is invalid in C99 [-Wimplicit-function-declaration]
>if (!CRYPTO_DOWN_REF(lck, , *lock))
> ^
> crypto/asn1/tasn_utl.c:87:30: error: use of undeclared identifier 'lck'; did 
> you
>   mean 'lock'?
>   if (!CRYPTO_DOWN_REF(lck, , *lock))
>^~~
>  lock
> crypto/asn1/tasn_utl.c:61:21: note: 'lock' declared here
> CRYPTO_RWLOCK **lock;
>   ^
> 3 warnings and 6 errors generated.
> *** Error code 1
> 
> Stop.
> make[1]: stopped in /usr/source/openssl-1.1.0-stable-SNAP-20180802
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/source/openssl-1.1.0-stable-SNAP-20180802
> 
> 
> Please fix.
> 
> -- 
> Member - Liberal International This is doctor@@nl2k.ab.ca Ici 
> doctor@@nl2k.ab.ca
> Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist 
> rising!
> https://www.empire.kred/ROOTNK?t=94a1f39b  Look at Psalms 14 and 53 on Atheism
> A problem is a chance for you to do your best.  -Duke Ellington
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


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

Re: [openssl-users] Java Snippet output is not equal to command line openssl command output , Why ?

[Blumenthal, Uri - 0553 - MITLL]

Actually, it all works just fine. Viktor's point about adding terminating "\n" 
to the input text helped.

-BEGIN PRIVATE KEY-
MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDGlXflMDDD8kOP
TP5y06tSXe1g8G3uJAoGHT8NewYANIONuJEZveXnfL8+bJRIu8FDzeCc4SWsCISK
WMmX/VY+IzZxLvUlOzRaKmO3Su7A9ABSc/AtcEVcrXhr9qV3axZDMXRXsWTxFnhO
/lRK8RpfGoGIhgCKkuNswy/DUjka0x03HymD7HwWhaNgsuvon+zWlSNTIV3t/WU4
093DlykKgDwEPym3UXHIgAecEAsYvm/YeYtM8NsHF2tzr40dKxA460lO/P8Vr7rL
df+AF9sNyfNFR81KBtPp2aqvZVXabHQrIZEpoZLrkz6uCObmyPiFx2m59Y3nXQV2
Fac8DuATAgEDAoIBAQCEY6VDdXXX9te03f73N8eMPp5AoElJbVwEE39eUgQAIwJe
ewtmfplE/dTUSGLbJ9YtM+sTQMPIBa2xkIZlU47UF3mgyfjDfM2RcZfPh0nV+AA2
9/VzoC49yPrypG5PnLmCIPg6dkNLZFA0qY2HS2bqEauwWVWxt0JIgh/XjCYR4OYZ
y7unFj5XnW93cAfL9U8CZPonO6iHCB14unk/UyiIHNrR41at0+qwVJYXdTFx+m0C
3KiWAwleRdVy2LBj3Fq1R3/pW3tnYTadgOInRYF4hQuF+ttIzEiuimhd6blUdMlR
WWbw8xp2A8buS4DQUKz0u1OAAhDvsqfEDsWLIAq7AoGBAPHwbdW8aLN85Y3W1pYf
2ELIlV1422sH+MrKv/jqQFf9LVmiXzq2+EZiYQcSxUFp5/1OvnRIHfY2hiBtq4Ww
VBq9/0u/D8Rv9bKPOvpLxYZP9FIOo8/BaLp5VV3Vz4pxVort0xHr+DfWFWH7t0cC
m/3LtfC1Y7j0TKyL/soyDWzXAoGBANIf/7pM4msWM+5WtEoW17OKaE6fbHYbeG44
/C76WhRBJ5onCuz7m0tdoB9mGv+D3s8FcBojzlbDKIrZvv7XDG1rAL2x5AGKqDZP
+bH5ahKJDg/tq7Sba6xqtLBMtzVqZrtDSGTUPLNkeDJM4F6rs/dK+HvEjruLhF1E
ALS5UWMlAoGBAKFK8+PS8HeomQk55GQVOtcwY5Ol55yv+zHcf/tG1Y/+HjvBlNHP
UC7sQK9h2NZGmqjfKaLavqQkWWrzx651jWcpVN0qCoL1TncKJ1GH2QQ1TYwJwoqA
8HxQ45Pj37Gg5FyejLadUCU5Y5anz4SsZ/6HzqB47SX4Mx2yqdwhXkiPAoGBAIwV
VSbd7EdkIp7keDFkj80G8DRqSE68+vQl/XSm5rgrb7waB0invNzpFWpEEf+tPzSu
SrwX3uSCGwc71KnksvOcqykhQquxxXmKpnamRrcGCV/zx8288nLxzcrdz3jxmdIs
2u3i0yJC+swzQD8dIqTcpafYXyeyWD4tVc3Q4OzDAoGBAML1gJ2slF0egQmxKSJK
YktcRX4IP1rWlYClgcJ9OLAxZBFWPwW8+hsTfCDoa5WEk4+CFHZ37PyibzjGuASC
UQmOZj6tVnaRkB62ExArgjzyyIMEUAbfFw4vKHe8cyF8MFC6JbTYj0EDlQtkhK65
HE0xeJjwo/swhpkBItsH0cYJ
-END PRIVATE KEY-

-BEGIN PUBLIC KEY-
MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAxpV35TAww/JDj0z+ctOr
Ul3tYPBt7iQKBh0/DXsGADSDjbiRGb3l53y/PmyUSLvBQ83gnOElrAiEiljJl/1W
PiM2cS71JTs0Wipjt0ruwPQAUnPwLXBFXK14a/ald2sWQzF0V7Fk8RZ4Tv5USvEa
XxqBiIYAipLjbMMvw1I5GtMdNx8pg+x8FoWjYLLr6J/s1pUjUyFd7f1lONPdw5cp
CoA8BD8pt1FxyIAHnBALGL5v2HmLTPDbBxdrc6+NHSsQOOtJTvz/Fa+6y3X/gBfb
DcnzRUfNSgbT6dmqr2VV2mx0KyGRKaGS65M+rgjm5sj4hcdpufWN510FdhWnPA7g
EwIBAw==
-END PUBLIC KEY-

$ cat rsa_tst1.java 
import java.security.KeyFactory;
import java.security.Signature;
import java.security.spec.PKCS8EncodedKeySpec;
import java.util.Base64;

public class rsa_tst1
{

public static void main(String[] args) throws Exception 
{
String input = "sample input\n";

final String strPk = 
"-BEGIN PRIVATE KEY-\n"
+ 
"MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDGlXflMDDD8kOP\n"
+ 
"TP5y06tSXe1g8G3uJAoGHT8NewYANIONuJEZveXnfL8+bJRIu8FDzeCc4SWsCISK\n"
+ 
"WMmX/VY+IzZxLvUlOzRaKmO3Su7A9ABSc/AtcEVcrXhr9qV3axZDMXRXsWTxFnhO\n"
+ 
"/lRK8RpfGoGIhgCKkuNswy/DUjka0x03HymD7HwWhaNgsuvon+zWlSNTIV3t/WU4\n"
+ 
"093DlykKgDwEPym3UXHIgAecEAsYvm/YeYtM8NsHF2tzr40dKxA460lO/P8Vr7rL\n"
+ 
"df+AF9sNyfNFR81KBtPp2aqvZVXabHQrIZEpoZLrkz6uCObmyPiFx2m59Y3nXQV2\n"
+ 
"Fac8DuATAgEDAoIBAQCEY6VDdXXX9te03f73N8eMPp5AoElJbVwEE39eUgQAIwJe\n"
+ 
"ewtmfplE/dTUSGLbJ9YtM+sTQMPIBa2xkIZlU47UF3mgyfjDfM2RcZfPh0nV+AA2\n"
+ 
"9/VzoC49yPrypG5PnLmCIPg6dkNLZFA0qY2HS2bqEauwWVWxt0JIgh/XjCYR4OYZ\n"
+ 
"y7unFj5XnW93cAfL9U8CZPonO6iHCB14unk/UyiIHNrR41at0+qwVJYXdTFx+m0C\n"
+ 
"3KiWAwleRdVy2LBj3Fq1R3/pW3tnYTadgOInRYF4hQuF+ttIzEiuimhd6blUdMlR\n"
+ 
"WWbw8xp2A8buS4DQUKz0u1OAAhDvsqfEDsWLIAq7AoGBAPHwbdW8aLN85Y3W1pYf\n"
+ 
"2ELIlV1422sH+MrKv/jqQFf9LVmiXzq2+EZiYQcSxUFp5/1OvnRIHfY2hiBtq4Ww\n"
+ 
"VBq9/0u/D8Rv9bKPOvpLxYZP9FIOo8/BaLp5VV3Vz4pxVort0xHr+DfWFWH7t0cC\n"
+ 
"m/3LtfC1Y7j0TKyL/soyDWzXAoGBANIf/7pM4msWM+5WtEoW17OKaE6fbHYbeG44\n"
+ 
"/C76WhRBJ5onCuz7m0tdoB9mGv+D3s8FcBojzlbDKIrZvv7XDG1rAL2x5AGKqDZP\n"
+ 
"+bH5ahKJDg/tq7Sba6xqtLBMtzVqZrtDSGTUPLNkeDJM4F6rs/dK+HvEjruLhF1E\n"
+ 
"ALS5UWMlAoGBAKFK8+PS8HeomQk55GQVOtcwY5Ol55yv+zHcf/tG1Y/+HjvBlNHP\n"
+ 
"UC7sQK9h2NZGmqjfKaLavqQkWWrzx651jWcpVN0qCoL1TncKJ1GH2QQ1TYwJwoqA\n"
+ 
"8HxQ45Pj37Gg5FyejLadUCU5Y5anz4SsZ/6HzqB47SX4Mx2yqdwhXkiPAoGBAIwV\n"
+ 
"VSbd7EdkIp7keDFkj80G8DRqSE68+vQl/XSm5rgrb7waB0invNzpFWpEEf+tPzSu\n"
+ 
"SrwX3uSCGwc71KnksvOcqykhQquxxXmKpnamRrcGCV/zx8288nLxzcrdz3jxmdIs\n"
+ 
"2u3i0yJC+swzQD8dIqTcpafYXyeyWD4tVc3Q4OzDAoGBAML1gJ2slF0egQmxKSJK\n"
+ 
"YktcRX4IP1rWlYClgcJ9OLAxZBFWPwW8+hsTfCDoa5WEk4+CFHZ37PyibzjGuASC\n"
+ 
"UQmOZj6tVnaRkB62ExArgjzyyIMEUAbfFw4vKHe8cyF8MFC6JbTYj0EDlQtkhK65\n"
+ "HE0xeJjwo/swhpkBItsH0cYJ\n"
+ "-END PRIVATE KEY-\n";

String base64Signature = signSHA256RSA(input,strPk);
  

Re: [openssl-users] stunnel 5.46 released

[Blumenthal, Uri - 0553 - MITLL]

FWIW, I'm with Viktor in this argument. From cryptography point of view he's 
right. I suspect he's right from the practical point of view as well.

P.S. Those concerned that a nation-state would attack them, are advised to 
change the default config anyway.
--
Regards,
Uri Blumenthal

On 5/31/18, 14:01, "openssl-users on behalf of Viktor Dukhovni" 
 
wrote:



> On May 31, 2018, at 12:37 PM, Tomas Mraz  wrote:
> 
> I would not say that weak DH parameters are fully rejected by OpenSSL.
> The 1024 bit DH parameters could be in theory attacked by state
> agencies by precomputation of the discrete logarithm table.

That's speculative.  If the idea is to prefer kECDHE over kDHE,
OpenSSL already does that.  In practice ECDHE is negotiated
when available.  The issue at hand is whether kDHE is worse
than kRSA.  Which is more likely later key compromise or
a brute force attack on 1024-bit DHE likely costing 10's to
100's of millions of dollars per key...

> And openssl
> still accepts 1024 bit DH by default if I am not mistaken.

Yes, but unless you're another nation-state with secrets
worth attacking at all costs, it seems rather unlikely
that this is a concern.

-- 
Viktor.

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



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

Re: [openssl-users] error (openssl-1.1.0g)

[Blumenthal, Uri - 0553 - MITLL]

Thanks for your feedback.  

 

You’re welcome.

 

You think it might be something like "BUG"??  

 

Probably yes – but the question is whether it’s with the new OpenSSL test 
infrastructure, or something with how one of my machines is configured. I do 
not know.

 

Anyway, you are also waiting for the answers right?

 

Yes I certainly am.

 

2018-02-15 6:57 GMT+09:00 Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu>:

Funny. I have the same problem with the current master on one of my two MacOS 
High Sierra machines. Surprisingly, the other machine builds and runs the 
current master just fine. Configuration and build scripts are automated and 
exactly the same between the two. 

 

The “bad” machine runs a bunch of compliance-related software, but it did not 
seem to interfere with the previous OpenSSL code drops.

--

Regards,

Uri Blumenthal

From: openssl-users <openssl-users-boun...@openssl.org> on behalf of "Sakuma, 
Koshiro" <bravo.echo@gmail.com>
Reply-To: "openssl-users@openssl.org" <openssl-users@openssl.org>
Date: Wednesday, February 14, 2018 at 16:33
To: "openssl-users@openssl.org" <openssl-users@openssl.org>
Subject: [openssl-users] error (openssl-1.1.0g)

 

Hi, Team, 

 

I'm trying to install openssl-1.1.0g on my CentOS7, but I've gotten error 
during do the "make test" phase.  The error I've gotten is as follows.

 

-

./test/recipes/40-test_rehash.t ... Dubious, test returned 1 (wstat 
256, 0x100)

Failed 1/5 subtests

 

Test Summary Report

---

../test/recipes/40-test_rehash.t (Wstat: 256 Tests: 5 Failed: 1)

  Failed test:  4

  Non-zero exit status: 1

Files=95, Tests=554, 34 wallclock secs ( 0.32 usr  0.09 sys + 25.56 cusr  9.26 
csys = 35.23 CPU)

Result: FAIL

make[1]: *** [_tests] Error 1

make[1]: Leaving directory `/usr/local/src/openssl-1.1.0g

make[1]:***[tests] error 2

-

 

The command I tried to do was like "config --prefix=/usr/local/openssl shared 
zlib OR config shared OR config.

 

The OS version is CentOS Linux release 7.4.1708 (Core).

 

I am not sure if I can ignore this error and move forward to do "make". 

 

Thank you so much for your support.

 

Regards,

 


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

 



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

Re: [openssl-users] error (openssl-1.1.0g)

[Blumenthal, Uri - 0553 - MITLL]

Funny. I have the same problem with the current master on one of my two MacOS 
High Sierra machines. Surprisingly, the other machine builds and runs the 
current master just fine. Configuration and build scripts are automated and 
exactly the same between the two. 

 

The “bad” machine runs a bunch of compliance-related software, but it did not 
seem to interfere with the previous OpenSSL code drops.

--

Regards,

Uri Blumenthal

From: openssl-users  on behalf of "Sakuma, 
Koshiro" 
Reply-To: "openssl-users@openssl.org" 
Date: Wednesday, February 14, 2018 at 16:33
To: "openssl-users@openssl.org" 
Subject: [openssl-users] error (openssl-1.1.0g)

 

Hi, Team, 

 

I'm trying to install openssl-1.1.0g on my CentOS7, but I've gotten error 
during do the "make test" phase.  The error I've gotten is as follows.

 

-

./test/recipes/40-test_rehash.t ... Dubious, test returned 1 (wstat 
256, 0x100)

Failed 1/5 subtests

 

Test Summary Report

---

../test/recipes/40-test_rehash.t (Wstat: 256 Tests: 5 Failed: 1)

  Failed test:  4

  Non-zero exit status: 1

Files=95, Tests=554, 34 wallclock secs ( 0.32 usr  0.09 sys + 25.56 cusr  9.26 
csys = 35.23 CPU)

Result: FAIL

make[1]: *** [_tests] Error 1

make[1]: Leaving directory `/usr/local/src/openssl-1.1.0g

make[1]:***[tests] error 2

-

 

The command I tried to do was like "config --prefix=/usr/local/openssl shared 
zlib OR config shared OR config.

 

The OS version is CentOS Linux release 7.4.1708 (Core).

 

I am not sure if I can ignore this error and move forward to do "make". 

 

Thank you so much for your support.

 

Regards,

 



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

Re: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed

[Blumenthal, Uri - 0553 - MITLL]

> Here's the standards OpenSSL claims to implement:
> https://www.openssl.org/docs/standards.html.

So do many others, and yet when the RFC is impractical, a more practical
alternative is implemented.

I did not see RFC 5280 in the list of the implemented/supported standards. (Yes 
I know, theoretically 5280 obsoletes and supersedes 3280 and 4630, but support 
of it isn’t claimed…)


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

Re: [openssl-users] OpenSSL on side

[Blumenthal, Uri - 0553 - MITLL]

The only thing I can think of is making sure that inside the setup.py CFLAGS 
are set properly, including appropriate -I/opt/local/include and whatever 
else...

Regards,
Uri

Sent from my iPhone

> On Oct 11, 2017, at 12:03, Matěj Cepl <mc...@cepl.eu> wrote:
> 
>> On 2017-10-11, 12:11 GMT, Blumenthal, Uri - 0553 - MITLL wrote:
>> Unfortunately, not quite. Being pip-installable means to the 
>> majority of users that the package in question can be 
>> installed via, e.g.,
>> 
>>   pip install M2Crypto
> 
> I understand that, my question was whether you know how to make 
> package with working python setup.py build to be 
> pip-installable.
> 
> Thanks,
> 
> Matěj
> -- 
> http://matej.ceplovi.cz/blog/, Jabber: mceplceplovi.cz
> GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
> 
> I love deadlines. I like the whooshing sound they make as they
> fly by.
>  -- Douglas Adams, The Salmon of Doubt
> 
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


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

Re: [openssl-users] OpenSSL on side

[Blumenthal, Uri - 0553 - MITLL]

Unfortunately, not quite. Being pip-installable means to the majority of users 
that the package in question can be installed via, e.g.,

   pip install M2Crypto

Regards,
Uri

Sent from my iPhone

> On Oct 11, 2017, at 08:01, Matěj Cepl <mc...@cepl.eu> wrote:
> 
>> On 2017-10-11, 11:35 GMT, Blumenthal, Uri - 0553 - MITLL wrote:
>> And it is not installable via PIP, though to me being placed 
>> on pypi site suggested that it should be (that's how I tried 
>> to install it).
> 
> What’s needed for package to be pip installable? I would think 
> that if
> 
>python setup.py build install
> 
> works (and it should), then pip should do somehow the right 
> thing?
> 
> Best,
> 
> Matěj
> -- 
> http://matej.ceplovi.cz/blog/, Jabber: mceplceplovi.cz
> GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
> 
> If we rise from prayer better persons, our prayers have been
> answered.
>  -- a Jewish prayer book
> 
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


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

Re: [openssl-users] OpenSSL on side

[Blumenthal, Uri - 0553 - MITLL]

And it is not installable via PIP, though to me being placed on pypi site 
suggested that it should be (that's how I tried to install it).

Regards,
Uri

Sent from my iPhone

> On Oct 11, 2017, at 06:55, Richard Levitte <levi...@openssl.org> wrote:
> 
> I got curious and decided to take a look, and well, it appears
> setup.py has issues.  I posted an issue in gitlab about it:
> 
> https://gitlab.com/m2crypto/m2crypto/issues/184
> 
> In message <slrnotrdim.lq.mc...@mitmanek.ceplovi.cz> on Wed, 11 Oct 2017 
> 08:12:38 +0200, Matěj Cepl <mc...@cepl.eu> said:
> 
> mcepl> On 2017-10-10, 21:17 GMT, Blumenthal, Uri - 0553 - MITLL wrote:
> mcepl> > I have to report that this M2Crypto release is broken, as it 
> mcepl> > cannot find OpenSSL installed in /opt/local (apologies for 
> mcepl> > spamming multiple lists and people):
> mcepl> 
> mcepl> Feel free to file a ticket on 
> mcepl> https://gitlab.com/m2crypto/m2crypto/issues , no need to use 
> mcepl> mailing lists for issue tracker, when we have a proper one.  
> mcepl> I work on M2Crypto right now, so I see them immediately.
> mcepl> 
> mcepl> To your real problem: does --openssl set to /opt/local help? If 
> mcepl> you run
> mcepl> 
> mcepl> python setup.py clean build --openssl /opt/local
> mcepl> 
> mcepl> what happens? What is the generated swig line (which version you 
> mcepl> use?), and what are the two compiler lines (one for compilation, 
> mcepl> other for linking)?
> mcepl> 
> mcepl> > /usr/bin/clang -fno-strict-aliasing -fno-common -dynamic -pipe 
> mcepl> 
> mcepl> I have made so far all my testing with GCC (on Linux, there are 
> mcepl> some users on Mac OS X, so I guess CLang should work as well, 
> mcepl> but I have never tested it myself).
> mcepl> 
> mcepl> > -Os -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes 
> mcepl> > 
> -I/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7
>  
> mcepl> > -I/private/tmp/pip-build-lqb2R6/M2Crypto/SWIG -c 
> mcepl> > SWIG/_m2crypto_wrap.c -o 
> mcepl> > build/temp.macosx-10.12-x86_64-2.7/SWIG/_m2crypto_wrap.o 
> mcepl> > -Wno-deprecated-declarations
> mcepl> > SWIG/_m2crypto_wrap.c:2894:9: warning: variable 'res' is used 
> uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
> mcepl> > if (PyType_Ready(tp) < 0)
> mcepl> > ^~~~
> mcepl> > SWIG/_m2crypto_wrap.c:2918:10: note: uninitialized use occurs 
> here
> mcepl> >   return res;
> mcepl> >  ^~~
> mcepl> > SWIG/_m2crypto_wrap.c:2894:5: note: remove the 'if' if its 
> condition is always false
> mcepl> > if (PyType_Ready(tp) < 0)
> mcepl> > ^
> mcepl> > SWIG/_m2crypto_wrap.c:2875:10: note: initialize the variable 
> 'res' to silence this warning
> mcepl> >   int res;
> mcepl> >  ^
> mcepl> >   = 0
> mcepl> 
> mcepl> Just to note that this particular piece of code is generated 
> mcepl> completely by swig, I have nothing to do with it.
> mcepl> 
> mcepl> > SWIG/_m2crypto_wrap.c:3554:10: fatal error: 'openssl/err.h' file 
> not found
> mcepl> > #include 
> mcepl> >  ^~~
> mcepl> > 1 warning and 1 error generated.
> mcepl> > error: command '/usr/bin/clang' failed with exit status 1
> mcepl> 
> mcepl> Where do you actually have err.h? Manually settings CFLAGS and 
> mcepl> LDFLAGS should be followed by seutp.py, it can help as 
> mcepl> a workaround, but my dream is that plain settings of --openssl 
> mcepl> parameter should be sufficient.
> mcepl> 
> mcepl> Feel free to continue here, on on the issue tracker.
> mcepl> 
> mcepl> Best,
> mcepl> 
> mcepl> Matěj Cepl
> mcepl> -- 
> mcepl> http://matej.ceplovi.cz/blog/, Jabber: mceplceplovi.cz
> mcepl> GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
> mcepl>  
> mcepl> Love doesn't just sit there, like a stone; it has to be made,
> mcepl> like bread, remade all the time, made new.
> mcepl>   -- Ursula K. LeGuin
> mcepl> 
> mcepl> 
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


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

Re: [openssl-users] [ANN] M2Crypto 0.27.0

[Blumenthal, Uri - 0553 - MITLL]

I have to report that this M2Crypto release is broken, as it cannot find 
OpenSSL installed in /opt/local (apologies for spamming multiple lists and 
people):

/usr/bin/clang -fno-strict-aliasing -fno-common -dynamic -pipe -Os -DNDEBUG -g 
-fwrapv -O3 -Wall -Wstrict-prototypes 
-I/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 
-I/private/tmp/pip-build-lqb2R6/M2Crypto/SWIG -c SWIG/_m2crypto_wrap.c -o 
build/temp.macosx-10.12-x86_64-2.7/SWIG/_m2crypto_wrap.o 
-Wno-deprecated-declarations
SWIG/_m2crypto_wrap.c:2894:9: warning: variable 'res' is used uninitialized 
whenever 'if' condition is true [-Wsometimes-uninitialized]
if (PyType_Ready(tp) < 0)
^~~~
SWIG/_m2crypto_wrap.c:2918:10: note: uninitialized use occurs here
  return res;
 ^~~
SWIG/_m2crypto_wrap.c:2894:5: note: remove the 'if' if its condition is 
always false
if (PyType_Ready(tp) < 0)
^
SWIG/_m2crypto_wrap.c:2875:10: note: initialize the variable 'res' to 
silence this warning
  int res;
 ^
  = 0
SWIG/_m2crypto_wrap.c:3554:10: fatal error: 'openssl/err.h' file not found
#include 
 ^~~
1 warning and 1 error generated.
error: command '/usr/bin/clang' failed with exit status 1


Command 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
 -u -c "import setuptools, 
tokenize;__file__='/private/tmp/pip-build-lqb2R6/M2Crypto/setup.py';f=getattr(tokenize,
 'open', open)(__file__);code=f.read().replace('\r\n', 
'\n');f.close();exec(compile(code, __file__, 'exec'))" install --record 
/tmp/pip-VYOp3p-record/install-record.txt --single-version-externally-managed 
--compile" failed with error code 1 in /private/tmp/pip-build-lqb2R6/M2Crypto/

--
Regards,
Uri Blumenthal

On 10/5/17, 18:06, "openssl-users on behalf of Matěj Cepl" 
 wrote:

M2Crypto is the most complete Python wrapper for OpenSSL
featuring RSA, DSA, DH, EC, HMACs, message digests, symmetric
ciphers; SSL functionality to implement clients and servers;
HTTPS extensions to Python’s httplib, urllib, and xmlrpclib;
unforgeable HMAC’ing AuthCookies for web session management;
FTP/TLS client and server; S/MIME. M2Crypto can also be used to
provide SSL for Twisted. Smartcards supported through the Engine
interface.

This is another less earth-shattering release (after 0.26.2 which
brought us OpenSSL 1.1.0 compatbility), one more step towards
Python 3 compatibility nirvana, still more cleanups and
accumulated bug fixes, which could be resolved before the big
python3 branch is merged.

The release is available on
https://pypi.python.org/pypi/M2Crypto/ and all communication with
the maintainer (that’s me) should go to
https://gitlab.com/m2crypto/m2crypto.

Talking about the python3 branch, ALL TESTS PASS on all Pythons
from 2.6, 2.7, 3.3 to 3.6!!!

Now is the time to test, help with review, and complain about
whatever is wrong! I will still keep API stable, but changes are
relatively large, so this is your opportunity to suggest whatever
substantial thing you don't like with M2Crypto. I may not make it
happen in 0.28 (which I expect to be Py3k-compatible release),
but for settling the dust down and cleanup I prepare already
0.29, which should include yet more acummulated merge requests
and bugfixes, this time ones which should be better served with
python 3 layer already happening.

Happy hacking!

Matěj

-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
  
Quod fuimus, estis; quod sumus, vos eritis.



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

Re: [openssl-users] Missing EVP_PKEY method to set engine?

[Blumenthal, Uri - 0553 - MITLL]

Thank you! 

I observe that in 1.1.x everything's fine - the structure evp_pkey_methods_st 
is opaque, but both getters and setters are defined and available. 

In 1.0.2 the structure is already opaque, the setters are present, but some 
getters are absent. Which makes it quite hard to work with members of this 
structure.

I think this is a bug, and two possible remedies INHO are: add getter functions 
for the members, or add/move this structure from evp-int.h to evp.h (so it's no 
longer opaque).

What is your opinion? 

Thanks!

Regards,
Uri

Sent from my iPhone

> On Oct 1, 2017, at 18:54, Dr. Stephen Henson <st...@openssl.org> wrote:
> 
>> On Fri, Sep 29, 2017, Blumenthal, Uri - 0553 - MITLL wrote:
>> 
>> Apologies in advance for cross-posting ??? but I???m not sure which of the 
>> two mailing lists this belongs to.
>> 
>> A key (say, private key) is loaded from the pkcs11 engine via privkey = 
>> ENGINE_load_private_key(engine, ); and this operation 
>> succeeds.
>> 
>> However the resulting key handle has its engine == NULL. I looked for a 
>> method or a macro to explicitly set that value to the pointer to the engine 
>> that this key is bound to, but couldn???t find any. I define new methods 
>> such as pkcs11_pkey_rsa_decrypt(), and  try to make OpenSSL aware of them 
>> via:
>> 
>> EVP_PKEY_METHOD *orig_pmeth = EVP_PKEY_meth_find(EVP_PKEY_RSA);
>> 
>>EVP_PKEY_METHOD *pmeth = EVP_PKEY_meth_new(EVP_PKEY_RSA, 
>> EVP_PKEY_FLAG_AUTOARGLEN);
>> 
>>EVP_PKEY_meth_copy(pmeth, orig_pmeth);
>> 
>>EVP_PKEY_meth_get_decrypt(orig_pmeth, _init, );
>> 
>>EVP_PKEY_meth_set_decrypt(pmeth, pdecr_init, pkcs11_pkey_rsa_decrypt);
>> 
> 
> There doesn't seem to be any easy way to do that for an existing method. If
> the ENGINE has its own ASN.1 method things become easier.
> 
> A workaround might be to use a copy of an existing A workaround might be to
> create a copy of an existing ASN.1 method but I've not tried that.
> 
>> 
>> In ENGINE_set_pkey_meths(engine, pkey_meths) what should pkey_meths() 
>> actually be? Is it documented? 
>> 
>> 
> 
> Not currently but it similar to the cipher/digest functions but handles
> EVP_PKEY_METHOD instead.
> 
> 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


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

[openssl-users] Missing EVP_PKEY method to set engine?

[Blumenthal, Uri - 0553 - MITLL]

Apologies in advance for cross-posting – but I’m not sure which of the two 
mailing lists this belongs to.

 

A key (say, private key) is loaded from the pkcs11 engine via privkey = 
ENGINE_load_private_key(engine, ); and this operation succeeds.

 

However the resulting key handle has its engine == NULL. I looked for a method 
or a macro to explicitly set that value to the pointer to the engine that this 
key is bound to, but couldn’t find any. I define new methods such as 
pkcs11_pkey_rsa_decrypt(), and  try to make OpenSSL aware of them via:

   

EVP_PKEY_METHOD *orig_pmeth = EVP_PKEY_meth_find(EVP_PKEY_RSA);

   EVP_PKEY_METHOD *pmeth = EVP_PKEY_meth_new(EVP_PKEY_RSA, 
EVP_PKEY_FLAG_AUTOARGLEN);

   EVP_PKEY_meth_copy(pmeth, orig_pmeth);

 

   EVP_PKEY_meth_get_decrypt(orig_pmeth, _init, );

   EVP_PKEY_meth_set_decrypt(pmeth, pdecr_init, pkcs11_pkey_rsa_decrypt);

  

And then there’s a function PKCS11_pkey_meths(ENGINE *e, EVP_PKEY_METHOD 
**pmethods, const int **nids, int nid) that assigns the above pmeth to 
*pmethods.  

 

Is the above correct/sufficient? Somehow it seems to never invoke 
pkcs11_pkey_rsa_decrypt()  when it should be used.

 

How can one set the EVP_PKEY->engine field in 1.1+?

 

In ENGINE_set_pkey_meths(engine, pkey_meths) what should pkey_meths() actually 
be? Is it documented? 

 

When does libcrypto use ENGINE->pkey_meths methods instead of  
ENGINE->rsa_meth?  

 

Who/what entity is supposed to invoke ENGINE->pkey_meths to retrieve the RSA 
methods block? 

 

Is it normal if on a key (EVP_PKEY *) loaded by an engine, engine ptr is NULL? 
And if not – who/how should set those pointers to the correct value?

--

Regards,

Uri Blumenthal



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

Re: [openssl-users] Storing private key on tokens

[Blumenthal, Uri - 0553 - MITLL]

AFAIK, at this point pkcs11 engine doesn't support key generation. 

The only viable options AFAIK are OpenSC (pkcs11-tool) and vendor-specific 
applications like yubico-piv-tool.

Regards,
Uri

Sent from my iPhone

> On Sep 27, 2017, at 08:23, Dmitry Belyavsky  wrote:
> 
> Hello,
> 
> What is the most natural way to generate private keys using openssl but store 
> them on a specific hardware tokens? Reading/writing is implemented via engine 
> mechanism.
> 
> I suppose that it should be added support of -outform ENGINE to the genpkey 
> command, but do not understatnd how to deal with it after that. 
> 
> Thank you!
> 
> -- 
> SY, Dmitry Belyavsky
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


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

[openssl-users] How to load the right engine?

[Blumenthal, Uri - 0553 - MITLL]

I’m debugging programmatic access to a (modified) pkcs11 engine. My system has 
several OpenSSL installations: Apple-provided OpenSSL-0.9.8 (kept as that came 
with the OS :), Macports-installed OpenSSL-1.0.2l (the main one installed to 
/opt/local, used by everything Macports builds, and what I use mostly for my 
software), and a couple of OpenSSL-1.1.x installations mostly used for 
debugging.

 

Libp11 is installed in /opt/local/lib/engines, and that version is built 
for/compatible with OpenSSL-1.0.2.

 

There’s an installation of OpenSSL-1.1.0-stable in ~/openssl-1.1. libp11 built 
for 1.1 is installed in ~/openssl-1.1/lib/engines-1.1 directory. So far so good.

 

The problem I’m having now is – my application appears to be getting the wrong 
pkcs11 engine (the one for 1.0.2), based on the error message I get on 
decrypting, which is indicative of the unmodified libp11 version (not the one 
I’m working with for 1.1).

 

Question: how do I ensure/verify that the right pkcs11 library is loaded?

 

Tail of openssl.cnf:

 

[pkcs11_section]

   engine_id = pkcs11

   dynamic_path = /Users/ur20980/openssl-1.1/lib/engines-1.1/pkcs11.dylib

   MODULE_PATH = /usr/local/lib/yubihsm_pkcs11.dylib

   init = 0

 

 

Thanks!

--

Regards,

Uri Blumenthal



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

[openssl-users] How to emulate EVP_PKEY_meth_get_sign() on OpenSSL-1.0.2?

[Blumenthal, Uri - 0553 - MITLL]

An engine works with OpenSSL-1.1.0+. It needs to hook some methods, and it 
accesses them via EVP_PKEY_meth_get_sign(), EVP_PKEY_meth_get_decrypt(), and 
EVP_PKEY_meth_get_encrypt(). And the corresponding set() calls.

 

I’d like to backport this engine to OpenSSL-1.0.2. But 1.0.2 does not provide 
these calls.

 

Is there a way to emulate the above calls, and achieve similar result on 
OpenSSL-1.0.2? 

 

Thanks!

--

Regards,

Uri Blumenthal



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

[openssl-users] -pkeyopt parameters?

[Blumenthal, Uri - 0553 - MITLL]

I seem unable to figure how to configure RSA-OAEP parameters (hash and MGF 
functions) for “opensl pkeyutl” command.

 

The man page seems to say that only thing I can do is tell openssl CLI that I 
want OAEP padding, and nothing more. 

 

File “apps/pkeyutl.c” was of no help. Where can I find all the pkeyopt 
parameters?

 

Thanks!

--

Regards,

Uri 



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

Re: [openssl-users] Internet Draft Guide to creating an EDSA PKI

[Blumenthal, Uri - 0553 - MITLL]

On 9/1/17, 16:26, "openssl-users on behalf of Michael Wojcik" 
 
wrote:

>Bob, I just want to say thanks for producing this. Even if it never makes 
> it out of I-D stage, there's a lot of useful information here.
>
>It would probably make a good addition to the OpenSSL wiki, too.

+1 on both. 


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