RFR: 8248268: Support KWP in addition to KW [v4]

[Michael StJohns]

On 4/3/2021 11:35 AM, Greg Rubin wrote:
> I'd advise against the AutoPadding scheme without more careful analysis and discussion. Have we seen either KW or KWP specifications which recommend that behavior?
>
> My concern is that we've seen cases before where two different cryptographic algorithms could be selected transparently upon decryption and it lowers the security of the overall system. (A variant of in-band signalling.) The general consensus that I've been seeing in the (applied) cryptographic community is strongly away from in-band signalling and towards the decryptor fully specifying the algorithms and behavior prior to attempting decryption.

I think this is in response to my comment?

The wrap function can take a Key as an input and can have the unwrap 
method produce a Key as an output - indeed it should be used primarily 
for this rather than the more general encrypt/decrypt functions.  The 
problem is that the encoding of the key may not be known prior to the 
attempt to wrap it - hence it's not known whether or not padding need be 
applied.  This is especially problematic with HSMs.  Providing an 
AutoPadding mode would allow the wrapping algorithm to decide whether to 
use either of the RFC 3394 (AKA KW) Integrity Check Value (ICV) or the 
RFC5649 (aka KWP) value and padding length.

The key thing to remember here is that the IV (initial value - RFC 
language) /ICV (integrity check value - NIST language)actually isn't an 
IV(initialization vector) in the ordinary meaning, it's a flag, padding 
and integrity indicator and will be fixed for all keys of the same 
length that use the specified values.   E.g. unlike other modes that 
require an initialization vector, you don't need to know the ICV to 
decrypt the underlying key stream, but you can  (and for that matter 
MUST) easily test the recovered first block against the expected ICV to 
determine whether the output needs padding removed or not.

FWIW, the actual cryptographic operations between padded data and 
non-padded data (of the right multiple length) are identical. It's only 
the pre or post processing that's looking for different data.

Obviously, this doesn't work if someone provides their own IV - but 
that's fairly unlikely.  CF CCM and its non-normative example formatting 
function appendix A -  each and every implementation I've seen uses that 
formatting function, even though it isn't actually required by the 
standard.  I'd be surprised if anyone decided to use a different set of 
non-standard IV values.

If an AutoPadding mode were implemented, I'd throw exceptions if someone 
tried to set the IV.

Later, Mike