2

AES-SIV is a very robust and safe algorithm but performance isn't great. AES-PMAC-SIV, should provide a great parallelization, increasing performance and ensuring the same robustness. Indications of this can be found on the GitHub pages of Miscreant and on the IETF mailing list.

How does it compare to the other authenticated encryption (AE) algorithms? Does it have the technical potential to become a popular algorithm and overcome the other AE algorithms, that is, is it technically (security properties / performance) superior in (many?) aspects to other currently (somewhat) widely used AE schemes?

SEJPM
  • 45,967
  • 7
  • 99
  • 205
Leonardo
  • 35
  • 5
  • No complaints for AES-PMAC-SIV. It is faster than AES-CMAC-SIV because parallel vs sequential. It is simpler and faster without additional less standard GHASH acceleration than AES-GCM-SIV. Need something faster? AES-VMAC-SIV would be a nice addition to miscreant, but is that good? I think so but I haven't done the analysis. – cypherfox May 09 '18 at 08:56
  • @cypherfox It isn't RFC certified. In your opinion, can it be used anyway? – Leonardo May 09 '18 at 10:35
  • AES-PMAC-SIV is certainly good to use. AFAIK AES-VMAC-SIV is good to be used - but no implementation exists. – cypherfox May 09 '18 at 11:07
  • 2
    Maybe a better question is: What is the security reduction for AES-PMAC-SIV? What security contract does it provide? What usage limits do cryptographers advise on it? How does this compare to alternatives with similar security contracts? This is not a matter of conjecture or opinion: there is presumably a theorem about bounds on advantage of distinguishing AES-PMAC-SIV from an idealized whatever in terms of bounds on the advantage of distinguishing AES from a pseudorandom permutation family. – Squeamish Ossifrage May 09 '18 at 19:30
  • @SqueamishOssifrage But this isn't just about security but also about performance and parallel computation, which makes it pretty broad. – Maarten Bodewes May 09 '18 at 20:57

1 Answers1

3

I don't think it will become popular. AES-SIV has a main usage as key wrapping mechanism for its deterministic encryption properties. But keys are generally pretty small; parallel computation is certainly not required for minimal amounts of data.

With regards of performance: yes it can be parallelized. But on a modern machine you may need a lot of enhancements to beat AES in CTR mode + AES CMAC on a single thread that uses hardware acceleration. Intel's AES-NI + GCM acceleration can get throughput of 2 Gbps (that bits, mind you) on a single core of a Westmere chip (that's an old chip doing 2.4 GHz) - and that's within an actual IPSEC tunnel. You may want to go faster, but it might be that other components of your system cannot keep up. For server components that can have any amount of connections: if you have a 8 core chip (and 8 connections) you may easily saturate a 10 Gbps network card.

AES-PMAC still requires a single AES block encrypt per plaintext block. So even though it can be parallelized it will be outperformed by special MAC constructs such as GMAC or Poly1305 that do not require block cipher calls for each block of plaintext. You'd need at least another thread to make up for the difference in performance, and they you'd still need to manage the multi-threading.

I presume that the authentication tag is relatively secure, even if only the first x bytes are used for authentication tag. That's maybe nice for embedded platforms, but those commonly don't go for multi-threading / parallel computation. It's certainly an advantage over other MAC constructs that do not have this property, but not over others such as AES-SIV, AES-EAX or AES-CCM.

The one good reason why it may get popular is when the cryptographic community decides to switch from authenticated encryption to encryption that is largely impervious to nonce reuse (nonce misuse resistance).

But note that GMAC, as used in GCM mode, may actually performed in parallel as well; putting the parts together requires some additional calculations displayed here. So GCM-SIV may also be executed in parallel, using a less computationally expensive MAC calculation. GCM in SIV mode sidesteps the issues with the nonce that makes it extremely sensitive to nonce reuse. MAC calculations that use a block cipher are simply not that efficient.

Maarten Bodewes
  • 92,551
  • 13
  • 161
  • 313
  • Speaking of misuse resistance, there are other robust properties not covered by AES-PMAC-SIV that are covered by others. I.e. A RUPAE-secure function will return random garbage if the authenticator "would fail". But this has few applications, it is great for mixing/onion routing where you may not be able to verify the ciphertext at the relays but a full-text avalanche occurs to eliminate crypto-tagging. – cypherfox May 10 '18 at 02:52