Re: [CFRG] HPKE and Key Wrapping

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

Well one difference is that AES-SIV can take a nonce (probabilistic mode) or
not (deterministic mode). If no nonce is provided you get DAE security as 
described in the Rogaway and Shrimpton paper. If a nonce is provided you can
get semantic security provided it is never used twice. It does provide misuse
protection, though, in the event it is. With AES-GCM-SIV, you have to pass a
nonce, it doesn't have a deterministic mode, and it provides the same guarantees
under the same nonce use/misuse as AES-SIV.

 

Yes. And you can compute the boundaries for your use case (whether you do or do not allow for nonce to repeat, how many times, etc.) for each mode.


Another difference is the key. AES-SIV uses a "doublewide" key (for AES with
a 128 bit key you pass AES-SIV a 256-bit key, AES with 256 uses a 512 bit key)
while AES-GCM-SIV uses just a single "normal" sized key. Some people seem to
think this is a problem with AES-SIV but KDFs can churn out keys of any length
and a call to get a 256-bit key is as easy as a call to get a 512-bit key.

 

>From my point of view, it’s a deficiency of AES-SIV – because it means that instead of feeding the algorithm just one 256-bit key and letting it figure out the rest, I need to create another logical piece that would intake my 256-bit key and produce pseudo-“key schedule” – aka, AES-SIV input keys. An unnecessary complication (from my point of view).



  Both of them are two pass modes (in order to achieve misuse resistance) but
AES-GCM-SIV is probably faster than AES-SIV due to the fact that it uses a
polynomial authenticator that can take advantage of the hardware support for
carryless multiply while AES-SIV uses CMAC which is considerably slower. But
that advantage would really only be seen on the wire and that is not the
use case here. This is userland/key exchange, not kernel-level packet
encryption.

 

Respectfully disagree here. Speed matters, kernel or “userland”. In all of my use cases, at least – which do encrypt packets, but not “in the kernel”.



  Yes, my draft does not discuss passing a nonce to AES-SIV in HPKE but it
would be possible to do such a thing because AES-SIV takes a vector of AAD and
the nonce can be one component of that vector-- AES-SIV doesn't require a
distinct input for a nonce. Since I'm trying to deal with using HPKE in lossy
networks, I don't really want to have to deal with a nonce unless I have to
and if I do, then I really need to export the sequence number (as indicated
in my draft) and in that case the need for a DAE cipher is not really there
and I might as well just use AES-GCM in that case. 


We’re in agreement here.

 
  The "single shot" HPKE call would not require a random nonce. It will just use
the base nonce that gets generated as part of the HPKE key schedule (since the
first and only shot will XOR a sequence number of zero onto that base nonce). 
So a trusted RNG is needed, yes, but that's necessary to achieve the security
guarantees of HPKE in the first place (see section 9.7.5 of RFC 9180), there are
no additional requirements placed on a RNG to do "single shot" key wrapping.

  That said, yes I agree: a nonce-less and misuse-resistant mode would be better. 
A DAE mode can achieve semantic security when the plaintext carries a (random) 
key-- the exact use case here-- so the principal complaint of DAE goes away. 

 

Again, yes.

 

Thanks