Hello, Sorry, I've just found similar checks in all _CGM functions.
On Fri, Sep 14, 2018 at 1:30 PM Dmitry Belyavsky <beld...@gmail.com> wrote: > Dear Paul, > > Could you please clarify? > The code seems to be related to s390 platform. Do I miss something? > > On Thu, Sep 13, 2018 at 1:55 AM Paul Dale <paul.d...@oracle.com> wrote: > >> 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:beld...@gmail.com] >> *Sent:* Wednesday, 12 September 2018 7:02 PM >> *To:* openssl-users@openssl.org >> *Subject:* [openssl-users] 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 >> > > > -- > SY, Dmitry Belyavsky > -- SY, Dmitry Belyavsky
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users