[openssl-users] (no subject)

[Neetish Pathak]

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


Could you please clarify where am I going wrong. Also, why is X25519 not
mentioned

in ec curve list

using openssl ecparam -list_curves


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).

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

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 it is
>>sending or receiving data that might be replayed.
>>
>>
>> >
>> > Is there any API available in OpenSSL for false start ?
>>
>> No, OpenSSL does not support false start. As an aside please note that
>> false start only applies to <= TLSv1.2.
>
>
> Thanks for your comments.
>
> I need some direction on the doing server and client side authentication
> during the handshake.
>
> *1) For certificate sent from the server side, I am using*
>
> SSL_CTX_load_verify_locations(ssl_ctx, CAFILE, NULL))   for loading
> verification file *on the client side*
>
> Where do I get a CAFILE in the above API. If the server is sending a self
> signed certificate, what will be the CA file on the client side for
> verification.
>
>
> *2) For Client side authentication*
>
> I am using SSL_CTX_use_PrivateKey_file and SSL_CTX_use_certificate file
> on the client side to load the private key and the certificate.
> I read that client side authentication will not kick off unless the server
> sends CertificateRequest. I can use SSL_CTX_set_client_cert_cb() that
> sets the client_cert_cb() callback to be called on CertificateRequest.
>
> I am not sure how I can enable the server side to send CertificateRequest.
> What is the API for that.
> Should SSL_CTX_set_verify((ssl_ctx,SSL_VERIFY_PEER, NULL)) be used on
> server side for sending the certificateRequest message. Please correct me ?
>
> *3) Certificate request Message*
> Also, what is the use of 

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

[Benjamin Kaduk via openssl-users]

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
-- 
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 different names?

[Richard Levitte]

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

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

Generally speaking, it's a bad idea.  The 1.1.0 libraries aren't ABI
backward compatible with the older versions.  Therefore, we decided
for a new naming scheme that includes the version we claim to keep
being backward compatible.

I would suggest that, rather than trying to fit things back to a
naming scheme that no longer works, you fit your building procedures
to the new scheme when building against OpenSSL 1.1.0 and on.  The
plan is that the names will be 'libcrypto-1_1.dll' and 'libssl-1_1.dll'
for 32-bit and 'libcrypto-1_1-x64.dll' and 'libssl-1_1-x64.dll' for
64-bit for all 1.1.x OpenSSL versions.
(which means that whenever 1.2.0 comes out, there will be a
'libcrypto-1_2.dll' and so on...  I expect it will take a number of
years before we get there)

Note, btw, that the import libraries on Windows are simply called
libcrypto.lib and libssl.lib from OpenSSL 1.1.0 and on.  That will
most likely not change at all for the far future.

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] How to define EVP_EncryptUpdate and EVP_EncryptFinal functions for an AES engine? (and a separate question re: padding).

[Brett R. Nicholas]

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


2. Does the EVP interface handle padding when a dynamic engine is involved? Or 
is it up to me to implement a padding structure within the engine itself? If 
the latter is the case, then I think the answer to the previous questions will 
help me figure out exactly where to implement it.



So to recap, two questions:

  1.  How can I explicitly define which operations in my engine happen when the 
EVP_[En/De]cryptInit_ex(..),EVP_[En/De]cryptUpdate(..), and 
EVP_[En/De]cryptFinal_ex(..) functions are called from a driver program?
  2.  Does my engine need to handle padding the input data upon encryption, and 
stripping the padding when decrypting? Or does the EVP API handle the padding 
for me, and I only need to worry about the core AES algorithm on the arbitrary 
input data? (for reference, I'd like to just use standard PKCS padding)

Thanks in advance,


- Brett


** I'm using the Xilinx Zynq SoC, so I can create custom hardware in the 
programmable logic, and then interact with it from software running on the 
processor through the memory map, just like any peripheraldetails irrelevant




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