Re: Support FFDHE?

[Jakob Bohm via openssl-users]

On 2020-02-28 03:37, Salz, Rich via openssl-users wrote:


*>*Per section Supported Groups in RFC 8446 [1], FFDHE groups could be 
supported.


I was wrong, sorry for the distraction.

As others have pointed out, it will be in the next (3.0) release.


Note that the group identifiers for the hardwired DH groups were also
present in TLS 1.2, though it is generally safer to use random groups
not shared with other hosts.

The RFC that introduced these groups also added crazy rules that
signaling support for those groups should disable general FFDH
support, making implementation for TLS 1.2 inadvisable.

With the removal of general FFDH from TLS 1.3, it has now become
advisable to implement for TLS 1.3 session but ignore for TLS 1.2
and below sessions, as if not implemented for those, at least as a
default-on compatibility option.

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

Re: Stream Encription

[Dmitry Belyavsky]

Hello,

If you mean encryption/decryption only, I strongly suppose you should look
at EVP_CipherInit/Update/Final functions.

On Fri, Feb 28, 2020 at 4:53 PM Илья Юркевич (Ilya Yurkevich) via
openssl-users  wrote:

> Hello,
>
> I have a client, that sends me data, that I need to encrypt, in few steps.
> I can use such functions in PKCS11: C_EncryptInit (...), C_EncryptUpdate
> (...), C_EncryptFinal (...). It allows me add data, that will be encrypted
> at every step, using C_EncryptUpdate  function.
>
>
>
> In OpenSSL I found CMS_encrypt (...) with flag = CMS_STREAM, but I can't
> understand how I can add data as I described above or another way? I get
> data in unsigned char* every time. Any help would be appreciated. Thanks.
>


-- 
SY, Dmitry Belyavsky

Stream Encription

[Ilya Yurkevich]

Hello,
I have a client, that sends me data, that I need to encrypt, in few steps. I 
can use such functions in PKCS11: C_EncryptInit (...), C_EncryptUpdate (...), 
C_EncryptFinal (...). It allows me add data, that will be encrypted at every 
step, using C_EncryptUpdate   function.
 
In OpenSSL I found CMS_encrypt (...) with flag = CMS_STREAM, but I can't 
understand how I can add data as I described above or another way? I get data 
in unsigned char* every time. Any help would be appreciated. Thanks.

Re: aes_cbc_hmac_sha1 implementation

[Phani 2004]

OK. I understood that "AES-128-CBC-HMAC-SHA1"(aesni_cbc_hmac_sha1) always
does mte.
I am trying to implement engine implementation of combined mode cipher
aes_cbc_hmac_sha1.
So in my aes_cbc_hmac_sha1_cipher implementation should i do mte only?

If hardware engine can do both operations in a single request and save
time. Also, say there is a flag which indicates whether its mte or etm.
How should my aes_cbc_hmac_sha1 implementation look like?
Should it do only mte always? Should i have two ciphers, one for etm and
other for mte.
But how to i tell openssl to use this cipher for etm and other for mte
without changing the openssl code.

One more query i have is, how do we pass the etm option to the openssl in
conf file.

Regards
Phani

On Fri, Feb 28, 2020 at 8:53 AM Matt Caswell  wrote:

>
>
> On 27/02/2020 18:30, Phani 2004 wrote:
> > Thanks for the reply.
> >
> > In ssl_get_evp_cipher api when etm flag is enabled the
> > aesni_cbc_hmac_sha1_cipher is not used. In this cipher only it
> > implements mte. This part is not clear to me? Support I implement one
> > cipher func which needs to handle both etm as well as mte, at the cipher
> > api level how do I know if we have etm extension enabled or not.
>
> At the engine level all it knows about are ciphers and hashes. Engines
> know nothing about TLS ciphersuites or TLS extensions. Your engine will
> not know whether etm or mte is in use. libssl makes the decision about
> what cipher it is going to ask the engine for based on what has been
> negotiated.
>
> If mte is in use then it will first look to see if it has an
> implementation of "AES-128-CBC-HMAC-SHA1" (of which
> aesni_cbc_hmac_sha1_cipher is the built-in implementation).
>
> If that is not available it will look for individual implementations of
> "AES-128" and "SHA1".
>
> If etm is in use it will just look for individual implementations of
> "AES-128" and "SHA1".
>
> Matt
>
>
>
> >
> > Regards
> > Phani
> >
> > On Wed, 26 Feb, 2020, 6:03 PM Hubert Kario,  > > wrote:
> >
> > On Wednesday, 26 February 2020 08:59:01 CET, Phani 2004 wrote:
> > > Thanks for the quick response Matt.
> > >
> > > My command was :
> > > openssl s_client -connect 10.29.20.26 -cipher ECDHE-RSA-AES128-SHA
> > -tls1_2.
> > > I did not realise that "2" was not copied.
> > >
> > > I am trying to implement combined algo support on our engine.
> > > I am using the openssl s_server and s_client apps to validate my
> > > implementation.
> > > The combined algo that i am looking to implement is AES128/256 and
> > SHA1.
> > > Its clear that i should always use tls version less than 1.3
> > otherwise GCM
> > > ciphers are used.
> > >
> > > What cipher suites can i use to validate the above combination of
> > combined
> > > algo?
> >
> > OpenSSL internally treats key exchange and symmetric cipher
> > separately, so
> > all "*AES128-SHA" ciphers use the same cipher backend
> >
> > you should also test AES256-SHA, AES128-SHA256, AES256-SHA256 and
> > AES256-SHA384
> >
> > > Which tls versions support which cipher suites?
> >
> > *-SHA1 and *MD5 is supported by everything between SSL3 and TLS 1.2
> > *-SHA256 and *-SHA384 (if they are not TLS1.3 cipher suites) are
> > supported
> > by TLS 1.2 only
> >
> > > Should i be doing "encrypt-then-mac" or "mac-then-encrypt" in my
> > > implementation?
> > > Does the cipher suite decide this?
> > > If yes, what are the ciphers which do "encrypt-then-mac" and what
> > ciphers
> > > to "mac-then-encrypt"?
> >
> > etm vs mte happens based on negotiated extension, not cipher suite
> >
> > --
> > 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
> >
>