Re: Limit the number of AES-GCM keys allowed in TLS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I wasn’t aware of other national standards requiring a similar check.

 

I made the change in the AES-GCM code because FIPS demands the check be inside the FIPS boundary.  I’d have preferred to make it in the TLS layer, but that mustn’t be inside the FIPS boundary.  My understanding is that TLS catches this case earlier and thus the test can never pass.

 

I don’t think dropping the check down into the algorithm implementations makes sense.  A more generic mechanism at the EVP would.

 

 

 

Pauli

--

Oracle

Dr Paul Dale | Cryptographer | Network Security & Encryption

Phone +61 7 3031 7217

Oracle Australia

 

From: Dmitry Belyavsky [mailto:beldmit@xxxxxxxxx]
Sent: Wednesday, 12 September 2018 7:02 PM
To: openssl-users@xxxxxxxxxxx
Subject: Limit the number of AES-GCM keys allowed in TLS

 

Hello,

 

The issue https://github.com/openssl/openssl/pull/7129 has introduced a possibility to limit the amount of TLS records processed without key changing as required by FIPS.

 

We in Russia have limitations with the same semantics applicable to Russian GOST TLS ciphersuites (https://datatracker.ietf.org/doc/draft-smyshlyaev-tls12-gost-suites/) so I think that this mechanism is very useful. 

 

The current implementation is done at EVP level, and it seems suboptimal because of the following reasons:

- If the AES implementation is provided via engine, not by OpenSSL itself, the limitation can be avoided

- the limitation has been made too generic

- the implementation seems to be AEAD-specific. 

 

So does not it make sense to provide this limitation at least at the ciphersuite level? It can provide more straightforward way to manage such limitations.


Thank you!

 

--

SY, Dmitry Belyavsky

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux