Chaskey (https://eprint.iacr.org/2014/386.pdf) is a a secure, compact and efficient MAC for embedded systems and has won many benchmarks. It is built using an Even-Mansour block cipher. This block cipher XORs a plaintext with a key, applies a public permutation function, then XORs the result with the same key to create the ciphertext. The paper unfortunately only discusses the MAC use case, and not the encryption use case. The web site (https://mouha.be/chaskey/) however mentions other use cases as well:

  1. A lightweight PRF.
  2. Can be used to cryptographically ensure message integrity (as a MAC).
  3. To authenticate users (in challenge-response protocols).
  4. To generate random numbers (in counter mode).

What I'm wondering is if it can also be used, in a secure way, for encryption, i.e. using it in counter mode to create a stream cipher. This would mean we could create an Encrypt-then-MAC algorithm using only Chaskey as primitive, which would be very efficient for embedded systems (of course in combination with a per-message nonce).

Since it can be used as a PRF and to generate random numbers in counter mode, it seems like this should indeed be feasible.


1 Answer 1


CTR mode originally is designed for PRFs.

Any PRF* can be turned into a stream cipher with CTR mode. However, it is not preferable to use a heavy function built for MAC to use as a stream cipher. Use ChaCha for stream cipher constructed from PRF or use direct stream cipher like Trivium.

If you really want to use then use the input as $$F_k(\text{nonce_block}\mathbin\|\text{counter_block})$$ as the CTR mode and encrypt as

$$c_i = m_i \oplus F_k(\text{nonce_block}\mathbin\|\text{counter_i})$$

Make sure that

  • $\text{counter_i}$ never exceed size of the $\text{counter_block}$,
  • never return to initial state if counter reaches the maximum $2^{\text{counter_block_size}}-1$
  • do not complicate with resumuing the counter for another encryption.
  • Under above, newer let an $(IV,key)$ appear again where $IV = (\text{nonce_block}\mathbin\|\text{counter_i})$

* Actually, any is not enough for cryptography, the key size and the input and output size are important. Today we prefer xChaCha20 since it enables 192-bit nonces to avoid the nonce collision under the same key and has 512-bit input/output sizes. Chaskey's 128-bit security is enough for lightweight cryptography, however, for other purposes, it is not secure enough.

  • $\begingroup$ Great! A follow up question: CCM uses the same key for both CTR encryption and for MAC by careful construct of the input to the block cipher. Can we use a similar approach here to avoid the need to have two keys? $\endgroup$
    – Emil
    Commented Jan 31, 2022 at 11:22
  • $\begingroup$ It needs an analysis. It is always better o generate two from one with a KDF like HKDF and expand will be enough for you if you have a uniform random-key. $\endgroup$
    – kelalaka
    Commented Jan 31, 2022 at 11:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.