[EXTERNAL] Re: AES in ECB mode

[anupama m]

Hi,

I am working on upgrading openssl to the latest version parallely.

So, my requirement is to be able to send multiple connection data by
encrypting them using a single SSL object. I am making sure I am feeding
the SSL object only one frame at a time both while encrypting and
decrypting. This works fine under less load.

But under load, with CBC cipher, I saw an issue where the packet reordering
caused decryption to fail since the previous block doesn't match the one
that was used while encrypting. In order to fix this - Tried the NULL
option for encryption like you suggested hoping this problem won't be seen,
but I am still facing the same issue.

Is there some setting that I am missing?

Thanks,
Anupama M


On Thu, Nov 16, 2023 at 4:44 PM Martin Bonner <Martin.Bonner at entrust.com>
wrote:

> Sorry, I have no idea.
>
>
>
> Also, you do know openssl-1.1.1 is out of support unless you have an
> Enterprise Support contract - in which case you should be talking to your
> support contact.
>
>
>
> Martin Bonner
>
>
>
>
>
> *From:* anupama m <anuavnd at gmail.com>
> *Sent:* Thursday, November 16, 2023 10:41 AM
> *To:* Martin Bonner <Martin.Bonner at entrust.com>
> *Cc:* openssl-users at openssl.org
> *Subject:* [EXTERNAL] Re: AES in ECB mode
>
>
>
> Hi Martin, Thanks for your reply. Let me explore the NULL option.
> Furthermore I found this in the mailing list - https: //marc.
> info/?l=openssl-users&m=133242427913068 where the user has added support
> for some specific ciphersuites in openssl.
>
> Hi Martin,
>
>
>
> Thanks for your reply. Let me explore the NULL option.
>
>
>
> Furthermore I found this in the mailing list -
> https://marc.info/?l=openssl-users&m=133242427913068
> <https://urldefense.com/v3/__https:/marc.info/?l=openssl-users&m=133242427913068__;!!FJ-Y8qCqXTj2!alBnPUtmQp_ykE4zQVaBPNtCWR3lJcyh4zDfaFw7q8WE-C614CzGqjZWoXvD8W7p5RjOgs2THm_OmOzxRw$>
> where the user has added support for some specific ciphersuites in openssl.
> Is it possible for me to define a custom ciphersuite with this method which
> can do - "Kx -DH, Au - None, Enc=AESECB, Mac=SHA256" that can serve my
> purpose. Will the openssl-1.1.1 version be able to support this?
>
>
>
> Thanks,
>
> Anupama M
>
>
>
>
>
> On Thu, Nov 16, 2023 at 2:09 PM Martin Bonner via openssl-users <
> openssl-users at openssl.org> wrote:
>
> > I am aware that ECB mode is insecure and not recommended but I still want
> > to use it for internal test purposes.
>
> > Is there any way I can use AES in ECB mode in any of these below ciphers
> > (Anonymous ciphers):
>
> > ADH-AES256-GCM-SHA384   TLSv1.2 Kx=DH Au=None Enc=AESGCM(256) Mac=AEAD
> > ADH-AES128-GCM-SHA256   TLSv1.2 Kx=DH Au=None Enc=AESGCM(128) Mac=AEAD
> > ADH-AES256-SHA256       TLSv1.2 Kx=DH Au=None Enc=AES(256)  Mac=SHA256
> > ADH-CAMELLIA256-SHA256  TLSv1.2 Kx=DH Au=None Enc=Camellia(256)
> Mac=SHA256
> > ADH-AES128-SHA256       TLSv1.2 Kx=DH Au=None Enc=AES(128)  Mac=SHA256
> > ADH-CAMELLIA128-SHA256  TLSv1.2 Kx=DH Au=None Enc=Camellia(128)
> Mac=SHA256
>
> I'm afraid not.  These are ciphers defined as part of the TLS standard,
> and were all intended to be secure at the time they were defined.
> If you want an insecure cipher, there is the NULL cipher.
>
> The GCM ones obviously can't do ECB because GCM is a different mode to ECB.
>
> The non-GCM ones still can't do ECB because they are actually defined to
> use CBC (which again, is a different mode).
>
> Also, the Camellia ones are defined to not use AES at all - they use the
> Camellia block cipher instead.
>
> --
> Martin Bonner
> Any email and files/attachments transmitted with it are intended solely
> for the use of the individual or entity to whom they are addressed. If this
> message has been sent to you in error, you must not copy, distribute or
> disclose of the information it contains. Please notify Entrust immediately
> and delete the message from your system.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20231117/24e3e624/attachment.htm>