Incremental Keccak API

[baentsch]

When building a library containing both dilithium and kyber, the symbols in the namespace pqcrystals_fips202_ref are the same and thus, permit linking. However, it seems the functionalities in some functions (e.g., keccak_absorb) seem to be different (incremental vs. always-zeroing). (Accordingly?) arbitrary crashes occur in the "mixed library".

If you agree that libraries containing both kyber and dilithium --possibly sharing as much code as possible (see Dilithium issue #21 )-- are sensible, I see two alternatives immediately:

• separate out the incremental API with explicit naming of the functions (and add some testing to ensure the 'common' code in kyber and dilithium is "common" indeed, so others building on this don't fall in the same "trap").
• separate the name spacing of pqcrystals_fips202_ref into a kyber and a dilithium version (causing some code bloat, though).

Further alternatives would be welcome. For the time being/as a workaround, I apply sed to separate the namespaces to allow kyber and dilithium to co-exist in a direct import to liboqs. I'd be glad to see a better approach (again, ideally minimising the code footprint, i.e., maximising the amount of shared/common code).

[gregorseiler]

The fips202 implementations in the round 3 code of Kyber and Dilithium are compatible now.