Score:1

Using Chaskey as a stream cipher

cz flag

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.

Score:0
in flag

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.

cz flag
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?
kelalaka avatar
in flag
It needs an analysis. It is always better o generate two from one with a KDF like [HKDF](https://crypto.stackexchange.com/a/76589/18298) and expand will be enough for you if you have a uniform random-key.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.