Incremental Keccak API
baentsch opened this issue · 1 comments
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
anddilithium
is "common" indeed, so others building on this don't fall in the same "trap"). - separate the name spacing of
pqcrystals_fips202_ref
into akyber
and adilithium
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).
The fips202 implementations in the round 3 code of Kyber and Dilithium are compatible now.