kmac: Towards an implementation about macs HOT 4 OPEN

This is a great synopsis of the issue and a lot of great feedback on trait design.

My high-level suggestion is to implement the existing traits and then we can separately work towards ones that are a better fit for KMAC.

from macs.

I agree that we probably should start with the fixed output size traits and work on improving our traits after that.

As for API design, XofMac as a convenience wrapper around ExtendableOutput + MacMarker and something like KeyCustomInit look good to me. KeyIvInit would be a bad fit here, not only because of the name, but also because customization strings are usually byte slices, not fixed size arrays. We probably should also introduce something similar to CtVariableCoreWrapper, but for ExtendableOutput.

@tarcieri
Maybe it's worth to move this issue to the traits repo?

from macs.

Because impl_cshake! in sha3 builds exclusively over extendable-output traits, I found the XOF aspect of the problem more accessible for my next iteration.

Using crypto-common v0.2.0-pre as a base, I first defined a KeyCustomInit trait.

Using digest v0.11.0-pre as a base, I implemented KeyCustomInit for CoreWrapper<T> and added MacXof.

I then updated sha3 for v0.11.0-pre of digest (link) uneventfully.

With all the ingredients in place, I arrived at a compiling KMACXOF implementation.

Now, for what’s missing…

The six test vectors include explicitly requested output lengths. Because I coded only KMACXOF (and thus the right-encoded output length is not incorporated when finalizing the reader) none of the tests pass. But by hard-coding an output length of 256 and 512 bits, I can get the KMAC128 and KMAC256 tests passing, respectively. This makes me more confident that the remainder of the implementation is working as expected.

The tests could be made to pass if I had FixedOutputCore and were able to leverage a finalize_into() method. I need OutputSizeUser, of course. My understanding is that the output size, being arbitrary in the context of SHAKE, is a run-time parameter that can’t be represented by compile-time type information (hence the absence of any OutputSizeUser-based constructs for the CSHAKE types). I can’t implement such a finalize_into() for KmacCore either because CoreWrapper obfuscates type methods in client code. This is my top blocker.

I didn’t introduce any verification methods to MacXof because I’m unsure whether it’s possible to guarantee constant-time equality checks for arbitrarily long byte sequences. In the post-quantum literature, there’s discussion of constant-time implementations of lattice cryptography schemes that build over SHAKE. Whether the same strategies are applicable here is beyond my current understanding.

Finally, I have to import KeyCustomInit explicitly in the tests. I speculate that this is because there’s (currently) no possible blanket implementation of this trait for KmacCore.

Thank you for your patience, @tarcieri and @newpavlov.

from macs.

Thank you both for your valuable feedback. You can now find a proof-of-concept implementation for Kmac128 at ok-ryoko/RustCrypto-MACs. I'm open to any and all changes.

Implementations for the following traits are fully generic and deemed complete:

• MacMarker
• BufferKindUser
• BlockSize
• UpdateCore
• Reset

On the other hand, the following traits are implemented by hand for only KmacCore<CShake128>:

• KeySizeUser
• OutputSizeUser
• KeyInit
• AlgorithmName
• Debug

By fixing KeySizeUser and OutputSizeUser to U32, I was able to satisfy the conditions of the first test vector and write a passing unit test that leverages Mac.

Aside: I duplicated left_encode from sha3 and mentioned the original author (@jvdsn) in the license files.

from macs.