Re: [openssl-users] CVE-2016-2177

[Jakob Bohm]

Just to clarify for anyone searching the archives in the future:

Is that commit included in release 1.0.1t or not?

(I could probably dig it up myself, but I am not an authoritative
source on the matter, so not good enough for future readers).

On 12/08/2016 21:20, Salz, Rich wrote:


Commit 6f35f6deb5ca7daebe289f86477e061ce3ee5f46 in 1.0.1

*From:*Scott Neugroschl [mailto:scot...@xypro.com]
*Sent:* Friday, August 12, 2016 3:11 PM
*To:* openssl-users@openssl.org
*Subject:* [openssl-users] CVE-2016-2177

CVE 2016-2177 notes that it applies to all versions up to 1.0.2h.   
Does this mean that the fix is not applied to the 1.0.1 series (in 
particular 1.0.1t)?



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

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

Re: [openssl-users] EVP_SealInit question

[Jakob Bohm]

There are (generally) 3 kinds of asymmetric cryptographic algorithms:

1. Signature algorithms, such as DSS, ECDSS, Ed255, and 3 modes of the 
RSA algorithm.


2. Key exchange/generation algorithms such as DH, ECDH and SRP.

3. Key encryption algorithms, such as 2 other modes of the RSA algorithm.

EVP_SealInit() is a function to invoke key encryption algorithms with a 
brand new random key.


On 16/08/2016 02:38, Norm Green wrote:

Sorry, I'm still not quite getting it.

It sounds like you're saying that only RSA supports encrypting with a 
public key.  But can't any asymmetric encryption algorithm encrypt 
using the public key?  Why is RSA special in this regard?


Norm Green

On 8/15/2016 5:31 PM, Dr. Stephen Henson wrote:

On Mon, Aug 15, 2016, Norm Green wrote:


Ok, thanks.

What I don't understand is what key transport has to do with
EV_SealInit() ?  Why is key transport important here ?

Because EVP_SealInit() generates a random symmetric key and encrypts 
it using
one or more public keys. For this to work the public key algorithm 
has to
support encryption of the symmetric key using a public key aka key 
transport.


Of the public key algorithms OpenSSL currently implements only RSA 
has that

operation.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

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

Re: [openssl-users] EVP_SealInit question

[Norm Green]

Sorry, I'm still not quite getting it.

It sounds like you're saying that only RSA supports encrypting with a 
public key.  But can't any asymmetric encryption algorithm encrypt using 
the public key?  Why is RSA special in this regard?


Norm Green

On 8/15/2016 5:31 PM, Dr. Stephen Henson wrote:

On Mon, Aug 15, 2016, Norm Green wrote:


Ok, thanks.

What I don't understand is what key transport has to do with
EV_SealInit() ?  Why is key transport important here ?


Because EVP_SealInit() generates a random symmetric key and encrypts it using
one or more public keys. For this to work the public key algorithm has to
support encryption of the symmetric key using a public key aka key transport.

Of the public key algorithms OpenSSL currently implements only RSA has that
operation.

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

Re: [openssl-users] EVP_SealInit question

[Dr. Stephen Henson]

On Mon, Aug 15, 2016, Norm Green wrote:

> Ok, thanks.
> 
> What I don't understand is what key transport has to do with
> EV_SealInit() ?  Why is key transport important here ?
> 

Because EVP_SealInit() generates a random symmetric key and encrypts it using
one or more public keys. For this to work the public key algorithm has to
support encryption of the symmetric key using a public key aka key transport.

Of the public key algorithms OpenSSL currently implements only RSA has that
operation.

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

Re: [openssl-users] EVP_SealInit question

[Norm Green]

Ok, thanks.

What I don't understand is what key transport has to do with 
EV_SealInit() ?  Why is key transport important here ?


Norm Green

On 8/15/2016 2:38 PM, Dr. Stephen Henson wrote:

On Mon, Aug 15, 2016, Norm Green wrote:


The man page for EVP_SealInit says:

"The public key must be RSA because it is the only OpenSSL public
key algorithm that supports key transport."

1 ) Is this still true?

Yes: the only algorithm we currently support which handles key transport is
RSA.


2) Will this restriction change now that RSA key transport is being
dropped from TLS 1.3 (or so I've read...)?


Don't undertand. The algorithm limitation has nothing to do with TLS
restrictions.

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

Re: [openssl-users] EVP_SealInit question

[Dr. Stephen Henson]

On Mon, Aug 15, 2016, Norm Green wrote:

> The man page for EVP_SealInit says:
> 
> "The public key must be RSA because it is the only OpenSSL public
> key algorithm that supports key transport."
> 
> 1 ) Is this still true?

Yes: the only algorithm we currently support which handles key transport is
RSA.

> 2) Will this restriction change now that RSA key transport is being
> dropped from TLS 1.3 (or so I've read...)?
> 

Don't undertand. The algorithm limitation has nothing to do with TLS
restrictions.

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

[openssl-users] AUTO: Marcus Daniel is out of the office (Rückkehr am 17.08.2016)

[Marcus . Daniel]

Ich kehre zurück am 17.08.2016.




Hinweis: Dies ist eine automatische Antwort auf Ihre Nachricht
"[openssl-users] EVP_SealInit question" gesendet am 15.08.2016 21:03:59.

Diese ist die einzige Benachrichtigung, die Sie empfangen werden, während
diese Person abwesend ist.

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

[openssl-users] EVP_SealInit question

[Norm Green]

The man page for EVP_SealInit says:

"The public key must be RSA because it is the only OpenSSL public key 
algorithm that supports key transport."


1 ) Is this still true?
2) Will this restriction change now that RSA key transport is being 
dropped from TLS 1.3 (or so I've read...)?


Norm Green

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

Re: [openssl-users] additional data (MAC'ed only) over TLS connection?

[Dr. Stephen Henson]

On Mon, Aug 15, 2016, Thomas Knauth wrote:

> Hi list,
> 
> the EVP_EncryptUpdate function has the option to pass data that is
> only MAC'ed but not encrypted. Is there some similar provision in the
> BIO interface? I have a use case, where I'd like to "inject"
> pre-encrypted/pre-mac'ed data into a TLS stream. Any suggestion on a
> low-effort way to do this?
> 

In the BIO interface as such, no.

However you can retrieve the EVP_CIPHER_CTX associated with the BIO and handle
things that way.

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

Re: [openssl-users] additional data (MAC'ed only) over TLS connection?

[Salz, Rich]

> the EVP_EncryptUpdate function has the option to pass data that is only
> MAC'ed but not encrypted. Is there some similar provision in the BIO
> interface? I have a use case, where I'd like to "inject"
> pre-encrypted/pre-mac'ed data into a TLS stream. Any suggestion on a low-
> effort way to do this?

You mean you have an SSL BIO, and you want to avoid the SSL 
encryption/record-layer/etc for part of it?

Not possible.

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

Re: [openssl-users] Migration from AES_ctr128_encrypt to EVP

[Vladimir A. Petrov]

Hello Steve,

I was solved. Actually we had a bit old version of the OpenSSL library in
our repository which didn't contain CTR support. Upgrade resolved the
problem. BTW, e.g. this page https://www.openssl.org/docs/manmaster/crypto/
does not have a reference on EVP_aes_128_ctr.

Thanks,
Vladimir.

On Aug 8, 2016 11:08 PM, "Dr. Stephen Henson"  wrote:

> On Mon, Aug 08, 2016, Vladimir A. Petrov wrote:
>
> > Hello,
> >
> > I need to migrate some code from the old style software implemented
> > AES_ctr128_encrypt to the EVP interface. I spent pretty much time reading
> > OpenSSL manual pages and Wiki as well as googling. Unfortunately, I still
> > can't get an idea how to migrate from these AES_* functions to the API
> > provided by EVP. The closest info that I found is the proposal made by Dr
> > Stephen N. Henson (
> > https://mta.openssl.org/pipermail/openssl-users/2015-March/000776.html)
> to
> > switch to EVP_aes_128_ctr, but there is no such 'ctr' mode in EVP for
> AES.
> >
> >
>
> I'm not sure what you mean by "but there is no such 'ctr' mode in EVP for
> AES": can you clarify?
>
> 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
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] additional data (MAC'ed only) over TLS connection?

[Thomas Knauth]

Hi list,

the EVP_EncryptUpdate function has the option to pass data that is
only MAC'ed but not encrypted. Is there some similar provision in the
BIO interface? I have a use case, where I'd like to "inject"
pre-encrypted/pre-mac'ed data into a TLS stream. Any suggestion on a
low-effort way to do this?

Kind regards,
Thomas.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users