Constant-time vs. variable-time AES

[mkannwischer]

Hello everyone,

for pqm4 and also the brand new pqm3, we would like to allow implementations to choose from a constant-time AES (e.g., bitsliced) and a potentially variable time AES (e.g., t-table) because t-table implementations are faster for our platforms.

Schemes can then make use of the faster implementation for public inputs (e.g. expanding the matrix A in Kyber), and the constant-time implementation for secret inputs (e.g., Expand in NTRULPRime).

Should this extension of the AES API also go to PQClean? Any opinions on this?

[cryptojedi]

"Matthias J. Kannwischer" <notifications@github.com> wrote:

Hello everyone,

Hello Matthias, hello everyone.

for [pqm4](https://github.com/mupq/pqm4) and also the brand new [pqm3](https://github.com/mupq/pqm3), we would like to allow implementations to choose from a constant-time AES (e.g., bitsliced) and a potentially variable time AES (e.g., t-table) because t-table implementations are faster for our platforms. Schemes can then make use of the faster implementation for public inputs (e.g. expanding the matrix A in Kyber), and the constant-time implementation for secret inputs (e.g., Expand in NTRULPRime). Should this extension of the AES API also go to PQClean? Any opinions on this?

My problem is that I have two contradicting opinions, I'll call them the "real-world" and the "ideal-world" opinion: - Ideally, nobody would be using AES with a non-secret key. Consequently, libraries should also not have to deal with this distinction and not encourage the use of AES with non-secret keys for anything. - Realistically, various schemes in the NIST PQC project *are* using AES with non-secret keys and on some architectures can benefit from faster non-constant-time implementations. A framework offering AES should at least allow these implementations to distinguish the two different uses of AES. As a compromise for now: How about allowing implementations to distinguish AES with secret and non-secret keys, but, at least for the moment, map those to the same constant-time implementation through a #define? All the best, Peter