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

Wed Apr 7 18:50:24 UTC 2021

*sigh* Minor correction in line.

On 4/7/2021 2:49 PM, Michael StJohns wrote:
> On 4/7/2021 1:28 PM, Greg Rubin wrote:
>> Mike,
>>
>> Yes, this was in response to your comment.
>>
>> I'm aware that the IV really serves more as an integrity check and 
>> mode signalling mechanism than anything else. My concern is that in 
>> the past few years I've seen various issues related to "in band 
>> signalling" where something about the ciphertext (or directly 
>> associated metadata) changes how the data is decrypted and 
>> authenticated. This has reached the level where several cryptographic 
>> forums I participate in are starting to consider it a full anti-pattern.
>>
>> The proposed "AutoPadding" mode is an example of in-band signalling 
>> in which an externally provided ciphertext changes how it is 
>> interpreted. While I cannot personally think of a specific risk in 
>> this case, I would be inclined not to include this mode unless there 
>> is a strong driving need from our users. While I have definitely seen 
>> people not knowing if their data was encrypted with KW or KW+PKCS5/7, 
>> I haven't personally seen uncertainty between KW and KWP. (I also 
>> haven't worked with all possible HSMs, just a few of them.)  So, from 
>> a position of caution, I'd avoid "AutoPadding", but this is a 
>> preference based on current best-practice rather than a strong 
>> objection based on specific concerns or risks.
>
>
> I sent a note off to the original mode inventor - Russ Housley:
>
>> Can you think of any reason why there might be an issue with 
>> providing an autopadding mode for KW/KWP (e.g. select which to use 
>> based on the input data for encrypt and determine which was used 
>> after running the unwrap function but before removing the initial 
>> block and any padding)?
>
> I got back:
>
>> As long as every party supports both modes, you could use KW id [sic 
>> - I think he meant "is"]

"if" not "is"

>> the inout is a multiple of 64 bits, otherwise use KWP.  Of course, 
>> the algorithm identifier needs to be set appropriately.
>
> Which sort of confirms what I thought, but added a question: Are there 
> algorithm OIDs for KW with PKCS5 padding or do people just use the KW 
> OID( 2.16.840.1.101.3.4.1.{5,25,45}?  As far as I can tell, there are 
> no OIDs for KW with PKCS5.
>
> Does there need to be an autopad OID?
>
> If it were me, I'd be avoiding implementing the PKCS5 padding mode 
> here.  I can't actually find a specification that includes it and it 
> looks like a hack that was fixed by the specification of KWP.  I'd 
> prefer not to extend the hack's lifetime, given that  RFC5649 is 10+ 
> years old.
>
> WRT to HSM uncertainty, I ran into problems especially trying to wrap 
> RSA private keys.  Turned out that some encoded as 8 byte multiples 
> and some did not.  In any event, I mentioned HSMs, but I really care 
> about the general model for the JCE. I'd *really* like to avoid having 
> to have to first figure out the private key encoding length (which may 
> be difficult as a provider may not choose to export an unwrapped 
> private key even if its a software provider) before choosing the 
> wrapping algorithm.   Doing it that way just fits the JCE model better.
>
> At some point, there needs to be an RFC written that specifies the 
> default encodings for keys wrapped by this algorithm.
>
> Later, Mike
>
>
>>
>> Thank you,
>> Greg
>>
>> On Sat, Apr 3, 2021 at 4:38 PM Michael StJohns <mstjohns at comcast.net 
>> <mailto:mstjohns at comcast.net>> wrote:
>>
>>     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
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20210407/4a0fa3fe/attachment.htm>