4

When 128-bit long data blocks are unavailable for one-time MAC:

  1. Could 64 bits be used instead?
  2. Should $q$ then be >=64 bits? E.g. $2^{64}+5$
  3. Can this be scaled even further downwards to 32, 16, … bits? (block size and $q$)

The few theory sources I found:

  1. https://www.youtube.com/watch?v=OMDDvINZNnE
  2. http://www.crypto-it.net/eng/theory/mac.html
e-sushi
  • 17,891
  • 12
  • 83
  • 229
Dadada
  • 43
  • 3

2 Answers2

1

Could 64 bits be used instead?

Yes, but it reduces the security.

Assuming that the message length is $L$ blocks, then given a valid message, tag pair, the attacker can generate a second message/tag pair that would authenticate with probability $L/q$ (assuming, of course, that $L \le q$). By reducing the value of $q$, you're increasing the probability that the attacker would succeed.

Now, you could run it several times in parallel (using distinct random values for $k_1, k_2$ for each instance; lets example how it works.

For example, if you use a single 128 bit $q$, and your message length is $\ell$ bytes (and hence we have $L = \ell/16$), that means that the attacker can succeed with probability $2^{-132} \ell$.

In contrast, if you have a 64 bit $q$, and run it twice in parallel, and your message length is $\ell$ bytes (and so $L = \ell/8$), this means that the attacker can succeed with probability $2^{-134} \ell^2$ (note, this is always larger, even with the smaller constant factor, as we assumed that $\ell$ is a multiple number of blocks, and so $\ell \ge 16$).

Because the second case reduced security as a square of the message length, it degrades significantly faster if long messages were possible. Whether it degrades too fast would depend on a) how much forgery probability is tolerable, and b) how long your messages are anyways.

Can this be scaled even further downwards to 32, 16, … bits? (block size and $q$)

Yes, but you run into even faster degradation based on message length.

poncho
  • 147,019
  • 11
  • 229
  • 360
1

I'm guessing you're talking about a typical univariate polynomial evaluation one-time MAC, like Poly1305 or GHASH. This isn't the only way to make a one-time MAC: there are variations on the theme, and other ways than polynomial evaluation in a field to construct the necessary flavor of universal hash family, the study of which is left as an exercise to the reader.

Pick a field $k$ of approximately $2^t$ elements, e.g. $k = \mathbb Z/(2^{130} - 5)\mathbb Z$ as in Poly1305. Suppose a message is up to $n$ blocks of $t$ bits; interpret it as a polynomial $m \in k[x]$ of degree $n$. Define the one-time key to be a pair of elements $r, s \in k$, and define the authenticator $a$ to be $a = m(r) + s$.

For an adversary to whom $r, s$ is unknown and uniformly distributed, the forgery probability after witnessing a single authenticated message—i.e., for any message $m' \ne m$ the probability of finding $a' = m'(r) + s$ given $(m, a)$ with $a = m(r) + s$—is bounded by about $n/2^t$. That bound becomes uncomfortably small for many reasonable message sizes if you pick $t \approx 64$, and less than useful if you pick, e.g., $t = 16$ and $n = 65536$.

For a concise mathematician's perspective, see

Daniel J. Bernstein, ‘Protecting communications against forgery’, pp. 535–549 in Algorithmic number theory: lattices, number fields, curves and cryptography, edited by Joe Buhler, Peter Stevenhagen. Cambridge University Press, 2008. ISBN 978-0521808545

Can you do arithmetic in smaller fields, say near 64 bits? If so, maybe you can use a quadratic extension of your arithmetic field—say, a quadratic extension $\mathbb F_{p^2}$ for $p = 2^{64} + 13$.* The most popular choices are large prime fields just below a power of two like $\mathbb Z/(2^{130} - 5)\mathbb Z$ and binary fields like $\operatorname{GF}(2^{128})$. It seems difficult to make an extension field that performs uniformly better on a variety of platforms than Poly1305—especially for a modulus just above a power of two, wasting nearly half your input space, rather than just below a power of two, wasting a minuscule fraction of your input space—while binary fields are particularly easy to implement in hardware like for GHASH.


* You don't want to use $2^{64} + 5$ because it's not prime! It factors into $3 \times 7 \times 29 \times 36760123 \times 823996703$, so $\mathbb Z/(2^{64} + 5)\mathbb Z$ doesn't even form a field.

Squeamish Ossifrage
  • 48,392
  • 3
  • 116
  • 223