Re: [openssl-users] Building libssl and libcrypto, .dlls and .libs, with (ABI compatibility)

[Richard Levitte]

In message <44064b1e7c3c4db094bf63355204f...@rnop-exci05.is.ad.igt.com> on Tue, 
27 Jun 2017 15:58:09 +, "Zarlenga.Mike"  said:

Mike.Zarlenga> In message 
<36801de60bb64636a972476419816...@rnop-exci05.is.ad.igt.com> on Mon, 26 Jun 
2017 01:18:39 +, "Zarlenga.Mike"  said:
Mike.Zarlenga> 
Mike.Zarlenga> MZ> Has anyone on this mailing list gone through the steps 
necessary to
Mike.Zarlenga> MZ> build OpenSSL 1.1.0f with the old filenames (libeay and 
ssleay)?
Mike.Zarlenga> 
Mike.Zarlenga> RL>Generally speaking, it's a bad idea.
Mike.Zarlenga> RL>The 1.1.0 libraries aren't ABI backward compatible with the 
older versions.
Mike.Zarlenga> 
Mike.Zarlenga> Hi Richard,
Mike.Zarlenga> 
Mike.Zarlenga> Thanks for replying.
Mike.Zarlenga> 
Mike.Zarlenga> Since I'm rebuilding and relinking from source code, do I need 
to be concerned
Mike.Zarlenga> with ABI backward compatibility?

Depends...

If you're also relinking all applications that use the DLLs, then
fine...  but in that case, I don't see why you bother with DLLs at
all.

What, exactly, do you intend to do with the resulting DLLs?

Mike.Zarlenga> I see that build.info builds the .libs for VMS with a 32/64 
suffix, the same naming
Mike.Zarlenga> convention that we're using for 1.0.n, and want to keep in 
1.1.n. So, maybe, our
Mike.Zarlenga> best way forward is a small change to build.info in the IF 
statement for /^VC-/ ?

Yes, the top build.info is the file to make changes in for this.
However, once again, I really do not recommend this.

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

Re: [openssl-users] Loading multiple private keys a certificates on server program

[Neetish Pathak]

Thanks
1) How can i load multiple private keys and certificates on the server side.
I need to use different keys and certificates when the client explicitly
asks for a particular cipher.
E.g The client can send the ciphersuite as

ECDHE-RSA-AES256-GCM-SHA384 for first connection
and then

ECDHE-ECDSA-AES256-GCM-SHA384 for second connection

Server should pick the right key and certificate (RSA and ECDSA certs
respectively)

I am using

SSL_CTX_use_certificate_file to load the certificate but the server always
picks just the first certificate mentioned in the file and fails for one of
the cases with no cipher shared message

What should we do to store multiple certificates and private keys at the
server side so that it picks the right one corresponding to the requested
cipher.


Should I make certificate chain ?

Should I make keystore? (PKCS12 etc)

what API should be used to load the keys and certificates. Can somebody
suggest the right way to do this.
Thanks
Best Regards,
Neetish


On Tue, Jun 27, 2017 at 12:56 AM, Matt Caswell  wrote:

>
>
> On 27/06/17 01:05, Neetish Pathak wrote:
> > Hi ,
> >
> > 1) I am working with a client and server program and want to use
> > ECDHE-ECDSA type ciphers.
> > I see that default Elliptic curve group supported is X25519. (when I
> > check client  and server logs on wireshark)
> > I wish to generate a self-signed certificate for X25519 curve. But I am
> > unable to do that the way I do for other curves like secp256r1,
> > secp521r1 etc.
> >
> > I generate a private key for secp521r1 using ecparam command and  then I
> > generate the self-signed certificate.
> >
> > openssl ecparam -name secp521r1 -genkey -param_enc named_curve -out
> > server_key.pem
> >
> > openssl req -new -x509 -key server_key.pem -out server_cert.pem -days 730
> >
> >
> > On man page for X25519,
> >
> > I found the command to generate private key
> >
> > openssl genpkey -algorithm X25519 -out xkey.pem
> >
> > But as I try to generate a self signed certificate, I am getting the
> > following error
> >
> > EVP_PKEY_sign_init:operation not supported for this keytype
>
> It is not possible to "self-sign" an X25519 certificate because X25519
> is a key-exchange algorithm only, not a digital signature algorithm. You
> would not typically create an X25519 certificate at all but an Ed25519
> one (only supported in the master branch).
>
>
> >
> >
> > Could you please clarify where am I going wrong. Also, why is X25519 not
> > mentioned
> >
> > in ec curve list
> >
> > using openssl ecparam -list_curves
>
> X25519 is different. "Standard" EC keys can be used for ECDH or ECDSA.
> X25519 keys are for X25519 only (similar to ECDH). Internally X25519 is
> treated as a standalone algorithm and not integrated into the rest of
> the EC logic.
>
> >
> >
> > Any references to clarify my understanding will be appreciated.
> >
> > 2) Also, can you direct me towards what hack is needed in Openssl to
> > support pre-generated PSK in TLS 1.3 and false start in TLS 1.2 (for my
> > study purpose).
>
> For external PSKs in TLS1.3 (again only supported in master), you need
> to use the new
> SSL_CTX_set_psk_use_session_callback()/SSL_CTX_set_psk_
> find_session_callback()
> APIs. See the man pages in master for this (for some reason I notice
> that the documentation for this has not been updated on the website -
> but it *is* in the doc/man3 folder in git).
>
> >
> > Are you planning to integrate false start in OpenSSL any time. Thanks
>
> I am not aware of anyone working on this.
>
> Matt
>
>
> >
> > Thanks
> >
> >
> > Best Regards,
> > Neetish
> >
> > On Wed, Jun 21, 2017 at 3:17 PM, Neetish Pathak  > > wrote:
> >
> >
> >
> > On Wed, Jun 21, 2017 at 3:11 AM, Matt Caswell  > > wrote:
> >
> >
> >
> > On 21/06/17 00:38, Neetish Pathak wrote:
> > > I wanted to understand the replay attack vulnerability in case
> of enable
> > > early data of TLS 1.3 while false start is secure in that
> respect as I
> > > have read from https://github.com/openssl/openssl/issues/1541
> > 
> > > So, with false start, the application data is sent from client
> after the
> > > first leg of the handshake i.e. one round trip is complete, so
> the data
> > > goes encrypted even though the handshake is not completed. In
> enable
> > > early data mode in TLS 1.3 for 0-RTT for session resumption,
> the
> > > application data is sent from the client along with the client
> hello
> > > message. Does the application data in early data mode go as
> clear text ?
> >
> > No, it is encrypted using a traffic key derived from the PSK.
> >
> > > I assume this is also encrypted using the PSK because 0-RTT is
> only
> > > applicable when PSK is available on the client side. How is it
> > 

Re: [openssl-users] X509 subject public key id-RSASSA-PSS

[Salz, Rich via openssl-users]

> Does your response mean, that RSA-PSS meanhile _is_ fully supported in 1.1.0?

I hesitate to  say fully, because there are no doubt parts that don't work.  
But RSAPSS signatures are supported.
But more importantly, 1.1.1 not 1.1.0

> Any estimations about how much work has to be done for adopting the newer 
> version?

It depends.  Almost all structures are opaque now, so you can't look inside at 
the fields direcdtly.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] X509 subject public key id-RSASSA-PSS

[weber]

Am 27.06.2017 um 14:18 schrieb Salz, Rich via openssl-users:


1.0.2 does not have full RSA-PSS support; you can’t use it.



Thanks Rich, in my case it works, because we partially do the 
verification (and algo selection) work externally.

We just need to access the public key which is rsa in both cases.

Does your response mean, that RSA-PSS meanhile _is_ fully supported in 
1.1.0?
Any estimations about how much work has to be done for adopting the 
newer version?


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

[openssl-users] OpenSSL FIPS CAVP tests throws an error iob_func while linking

[Jayalakshmi bhat]

Hi All,

I am trying to build CAVP test executable for WinCE. Most of the executable
are built except 1-2. I am facing iob_func unresolved error.

Every thing seems to be proper. Any idea or help is well appreciated.

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

Re: [openssl-users] Building libssl and libcrypto, .dlls and .libs, with (ABI compatibility)

[Zarlenga.Mike]

In message <36801de60bb64636a972476419816...@rnop-exci05.is.ad.igt.com> on Mon, 
26 Jun 2017 01:18:39 +, "Zarlenga.Mike"  said:

MZ> Has anyone on this mailing list gone through the steps necessary to
MZ> build OpenSSL 1.1.0f with the old filenames (libeay and ssleay)?

RL>Generally speaking, it's a bad idea.
RL>The 1.1.0 libraries aren't ABI backward compatible with the older versions.

Hi Richard,

Thanks for replying.

Since I'm rebuilding and relinking from source code, do I need to be concerned
with ABI backward compatibility?

I see that build.info builds the .libs for VMS with a 32/64 suffix, the same 
naming
convention that we're using for 1.0.n, and want to keep in 1.1.n. So, maybe, our
best way forward is a small change to build.info in the IF statement for /^VC-/ 
?

Regards,
M Zarlenga

CONFIDENTIALITY NOTICE: This message is the property of International Game 
Technology PLC and/or its subsidiaries and may contain proprietary, 
confidential or trade secret information. This message is intended solely for 
the use of the addressee. If you are not the intended recipient and have 
received this message in error, please delete this message from your system. 
Any unauthorized reading, distribution, copying, or other use of this message 
or its attachments is strictly prohibited.

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

Re: [openssl-users] X509 subject public key id-RSASSA-PSS

[Salz, Rich via openssl-users]

1.0.2 does not have full RSA-PSS support; you can’t use it.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] X509 subject public key id-RSASSA-PSS

[weber]

Am 26.06.2017 um 22:30 schrieb Benjamin Kaduk:

On 06/25/2017 03:06 PM, we...@infotech.de wrote:

Dear OpenSSSL users,

we recently came across a certificate with OID: id-RSASSA-PSS aka 
rsassaPss in x509 subjects public key AlgorithmIdentifier.


According to rfc4056 it is legitimate to use rsaEncryption or 
id-RSASSA-PSS as OID for the subject public key.


But when listing the certs's contents or during verification, openssl 
v1.0.2h bails out:
12392:error:0609E09C:digital envelope 
routines:PKEY_SET_TYPE:unsupported algorithm:.\crypto\evp\p_lib.c:231:
12392:error:0B07706F:x509 certificate 
routines:X509_PUBKEY_get:unsupported 
algorithm:.\crypto\asn1\x_pubkey.c:148:
which is caused by failing to assign the proper ameth structure to 
the key.


Later in x_pubkey.c, only the method pub_decode is needed, which 
seems to work for rsassa pubkeys.
So may we assign the same methods associated to rsaEncryption in this 
case or are we breaking other functionality by doing so?


It might be more interesting to just try using the current OpenSSL 
master branch (or a snapshot), which has more proper RSA-PSS support.


-Ben


It's absolutely the same with Version 1.0.2l.
Due to time limitation we avoid updating to 1.1.0 as we assume that 
there will be several adaptations neccessary ...


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

Re: [openssl-users] How to define EVP_EncryptUpdate and EVP_EncryptFinal functions for an AES engine? (and a separate question re: padding).

[Matt Caswell]

On 26/06/17 15:21, Brett R. Nicholas wrote:
> Hi there,
> 
> 
> I'm building a dynamic engine to support a custom AES hardware module
> that I've implemented in FPGA logic, but after reading all available
> documentation, and pouring over the source code, I'm still very confused
> about the following two things.
> 
> 
>  1. *How and where I should define the
> EVP_[En/De]cryptInit_ex(..),EVP_[En/De]cryptUpdate(..), and
> EVP_[En/De]cryptFinal_ex(..)
> functions in my Engine code? *
> 
> 
> Prior to this, I successfully built an engine for my sha256 accelerator,
> and now I'm trying to follow the same steps for AES. For sha256, the
> EVP_MD structure allowed me to declare pointers to my init, update, and
> final functions. This all worked flawlessly.
> 
> 
> Now, when I'm building the AES engine, I see that the EVP_CIPHER
> structure does not have these pointers (init, update, final), but
> instead has a pointer to init_key and do_cipher functions. However, the
> EVP encryption interface still has these functions defined.
> 
> 
> AFAIK (and please correct me if this is wrong)  my init_key function is
> invoked by the EVP interface when I call the EVP_[En/De]cryptInit_ex
> function, and the do_cipher function is called upon
> EVP_[En/De]cryptUpdate. But how should I handle
> the EVP_[En/De]cryptFinal functions? Should I not be implementing them
> in my engine? Or am I missing something here

The behaviour varies a little depending on whether you have set the
EVP_CIPH_FLAG_CUSTOM_CIPHER flag for your cipher.

If you have not set the EVP_CIPH_FLAG_CUSTOM_CIPHER flag:

do_cipher() will only ever be invoked where the length is a multiple of
a full block length. EVP_[En/De]cryptUpdate and EVP_[En/De]cryptFinal
will invoke do_cipher() as required. There may not be a one-to-one
correspondence between calls to those functions and calls to
do_cipher(). The EVP functions handle dealing with partial blocks and
padding the final block as required.


If you have set the EVP_CIPH_FLAG_CUSTOM_CIPHER flag:

EVP_[En/De]cryptUpdate just call do_cipher() directly. The cipher
implementation itself has to handle partial blocks etc. Similarly
EVP_[En/De]cryptFinal just calls do_cipher() directly, but will pass
NULL for the input buffer, and 0 for the input length. Your cipher
implementation will have to handle any padding etc itself.


Matt

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

Re: [openssl-users] (no subject)

[Matt Caswell]

On 27/06/17 01:05, Neetish Pathak wrote:
> Hi ,
> 
> 1) I am working with a client and server program and want to use
> ECDHE-ECDSA type ciphers.
> I see that default Elliptic curve group supported is X25519. (when I
> check client  and server logs on wireshark)
> I wish to generate a self-signed certificate for X25519 curve. But I am
> unable to do that the way I do for other curves like secp256r1,
> secp521r1 etc.
> 
> I generate a private key for secp521r1 using ecparam command and  then I
> generate the self-signed certificate.
> 
> openssl ecparam -name secp521r1 -genkey -param_enc named_curve -out
> server_key.pem
> 
> openssl req -new -x509 -key server_key.pem -out server_cert.pem -days 730
> 
> 
> On man page for X25519,
> 
> I found the command to generate private key
> 
> openssl genpkey -algorithm X25519 -out xkey.pem
> 
> But as I try to generate a self signed certificate, I am getting the
> following error
> 
> EVP_PKEY_sign_init:operation not supported for this keytype

It is not possible to "self-sign" an X25519 certificate because X25519
is a key-exchange algorithm only, not a digital signature algorithm. You
would not typically create an X25519 certificate at all but an Ed25519
one (only supported in the master branch).


> 
> 
> Could you please clarify where am I going wrong. Also, why is X25519 not
> mentioned
> 
> in ec curve list
> 
> using openssl ecparam -list_curves

X25519 is different. "Standard" EC keys can be used for ECDH or ECDSA.
X25519 keys are for X25519 only (similar to ECDH). Internally X25519 is
treated as a standalone algorithm and not integrated into the rest of
the EC logic.

> 
> 
> Any references to clarify my understanding will be appreciated.
> 
> 2) Also, can you direct me towards what hack is needed in Openssl to
> support pre-generated PSK in TLS 1.3 and false start in TLS 1.2 (for my
> study purpose).

For external PSKs in TLS1.3 (again only supported in master), you need
to use the new
SSL_CTX_set_psk_use_session_callback()/SSL_CTX_set_psk_find_session_callback()
APIs. See the man pages in master for this (for some reason I notice
that the documentation for this has not been updated on the website -
but it *is* in the doc/man3 folder in git).

> 
> Are you planning to integrate false start in OpenSSL any time. Thanks

I am not aware of anyone working on this.

Matt


> 
> Thanks
> 
> 
> Best Regards,
> Neetish
> 
> On Wed, Jun 21, 2017 at 3:17 PM, Neetish Pathak  > wrote:
> 
> 
> 
> On Wed, Jun 21, 2017 at 3:11 AM, Matt Caswell  > wrote:
> 
> 
> 
> On 21/06/17 00:38, Neetish Pathak wrote:
> > I wanted to understand the replay attack vulnerability in case of 
> enable
> > early data of TLS 1.3 while false start is secure in that respect 
> as I
> > have read from https://github.com/openssl/openssl/issues/1541
> 
> > So, with false start, the application data is sent from client 
> after the
> > first leg of the handshake i.e. one round trip is complete, so the 
> data
> > goes encrypted even though the handshake is not completed. In enable
> > early data mode in TLS 1.3 for 0-RTT for session resumption, the
> > application data is sent from the client along with the client hello
> > message. Does the application data in early data mode go as clear 
> text ?
> 
> No, it is encrypted using a traffic key derived from the PSK.
> 
> > I assume this is also encrypted using the PSK because 0-RTT is only
> > applicable when PSK is available on the client side. How is it
> > vulnerable to replay attack. Please help me understand.
> 
> The same PSK can be used multiple times. Because the traffic key
> for the
> early data is derived from the PSK, if you later re-use the PSK
> and send
> early data again then the same traffic key will be derived. This
> can be
> exploited by an attacker who can record the early data from an
> earlier
> session and replay it later. The server will think that the replayed
> data is a new connection and process the early data accordingly.
> 
> Early data (aka 0-RTT data) can be dangerous if not used
> properly. For
> this reason the current TLSv1.3 draft makes this note:
> 
>Protocols MUST NOT use 0-RTT data without a profile that
> defines its
>use.  That profile needs to identify which messages or
> interactions
>are safe to use with 0-RTT.  In addition, to avoid accidental
> misuse,
>implementations SHOULD NOT enable 0-RTT unless specifically
>requested.  Implementations SHOULD provide special functions for
>0-RTT data to ensure that an application is always aware that
>