Looking back at 2022, we further improved the bounds of differential and linear trails in Xoodoo. In the article Tighter trail bounds for Xoodoo available on the IACR Cryptology ePrint Archive, we report on the outcome of our new trail scan effort. The importance of trail bounds is not to be repeated; instead we refer to last year's news item for a discussion. As you can see in the table below, the lower bounds have been quite significantly improved.

Next to a description of the optimizations in our trail search code that allowed us to improve the bounds, in the article we also report on a set of trails that are extendable to an arbitrary number of rounds and as such provide upper bounds for the minimum weight of trails. We summarize the new lower and upper bounds for the weight of trails in the table below. The bounds are the same for differential and linear trails.

# rounds	1	2	3	4	5	6	8	10	12
Lower bounds	2	8	36	80	98	132	176	220	264
Upper bounds	2	8	36	80	120	168	288	440	624

Currently, the vast majority of symmetric-key cryptographic schemes are built as modes of block ciphers. What would cryptography look like if it was built around another primitive? In this note, we explain our approach to authentication, encryption and authenticated encryption using a primitive type that we call deck functions. For more details, we invite you to watch our presentation All on deck! at RWC 2020, read our paper Jammin' on the deck or see its presentation at Asiacrypt 2022.

What are deck functions?

A deck function stands for doubly extendable keyed cryptographic function. It is not a construction like sponge or farfalle; instead, a deck function is a primitive type, the same concept as a block cipher. A primitive type abstractly defines a functional and security interface to modes, where the latter can be specified and proven secure independent of the details of the underlying primitive.

In a nutshell, a deck function is a function that, when keyed with a secret key, is hard to distinguish from a random oracle. Instead, a block cipher is a function that, when keyed with a secret key, is hard to distinguish from a random permutation. While the latter is called (S)PRP security, the security concept for a deck function is called PRF security, i.e., taking a key and a string as input, it outputs seemingly random bits for an adversary who does not know the key.

Yet, to qualify as a deck function, it must satisfy some additional requirements. First, the data input takes the form of a sequence of binary strings instead of a single one, and the output depends on the sequence and not just the concatenation of input strings. Then, a deck function must implement efficient incrementality properties. Specifically, both the input and the output are extendable: By keeping state, appending an extra string to the input sequence costs only the processing of this extra string. Similarly, like an extendable output function (XOF), asking for more output bits should be efficient.

Do you have examples of deck functions?

A construction for building deck functions is farfalle, of which Kravatte and Xoofff are instances.

However, there is nothing that prevents from building deck function differently, in the same way that there are multiple ways to build a block cipher: A wide design space is waiting to be explored!

What can you do with deck functions?

Like for block ciphers, we can define deck function modes of use for authentication, encryption and various kinds of authenticated encryption (AE). For instance, in our paper, we describe five modes with different robustness properties. Four of these modes are variations around a Feistel network structure, with a consistent and unified approach. This Feistel network has two mandatory central rounds and two optional outer rounds. The central rounds provide AE with nonce-misuse robustness, while the optional round at the beginning reduces the ciphertext expansion and the optional round at the end adds resistance against release of unverified plaintext (RUP).

Building AE schemes with such properties is not new and can be done based on block ciphers, but in the case of deck functions, the modes become really simple and natural. Passing a sequence of input strings and supporting incremental inputs are key ingredients in this simplicity, see for instance Seth's article on modes and his recent paper Nonce-encrypting AEAD Modes with Farfalle.

Wait, aren't you just pushing the complexity down to the primitive?

It is true that with deck functions we move the burden of dealing with variable input and output lengths from the mode to the primitive. It turns out that this allows more efficient schemes. Traditionally, block cipher-based modes rely on their (S)PRP security, and achieving a solid level of (S)PRP security comes at the price of a relatively large number of rounds. On the other hand, building a variable-input-length function that targets PRF security using the same building blocks can be done more efficiently when the reductionist security argument is dropped. Think about how much faster Pelican-MAC is compared to AES-CMAC: The former needs 4 rounds per 128 bits of input when the latter needs 10!

Besides efficiency, what are other advantages of deck functions?

Their incrementality properties are particularly well suited for uses of AE that go beyond the encryption and/or authentication of individual messages. In particular, processing streams of data, with intermediate tags, and bi-directional communications benefit from simpler modes.

In this context, a session deals with the authentication of sequences of messages, preventing an attacker from reshuffling messages. Ensuring that a message is authenticated in the context of previously sent messages comes essentially for free thanks to the incrementality properties of deck functions. Another interesting use case is the transmission of long messages to low-end devices, where intermediate tags can authenticate the message in an incremental way.

Concretely, how can I start using deck functions?

It depends on what you want to do.

If you are implementing a new protocol, note that Kravatte and Xoofff are supported in the XKCP and in a few other places. Currently, Xoofff has our preference because of its efficiency on a wide range of platforms, from the low-end processors as used in embedded devices to the high-end server processors. On the ARM™ Cortex-M0 and -M3, Xoofff outperforms AES-based schemes by a factor 4 or 5, and with AVX-512 instructions it runs faster than AES-based schemes even with the dedicated AES instructions!

If you are interested in modes and in proving their security, you may want to adapt existing modes with interesting properties to deck functions and see if the deck function interface makes them simpler. If you are a cryptographic designer, maybe your favorite design approach can be applied to build a deck function. And if you are interested in cryptanalysis, you may want to have a critical look at farfalle, our schemes and possibly new deck functions.

The possibilities are endless!