<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">*sigh* Minor correction in line.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 4/7/2021 2:49 PM, Michael StJohns
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:91c7929d-0592-8947-d065-7f6180df86cc@comcast.net">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="moz-cite-prefix">On 4/7/2021 1:28 PM, Greg Rubin
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAE26cs6pGJYdM6joF_TOSROL_r5XVtEHqFkVFiKPU5ct=4qg_g@mail.gmail.com">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<div dir="ltr">Mike,
<div><br>
</div>
<div>Yes, this was in response to your comment.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
</div>
</blockquote>
<p><br>
</p>
<p>I sent a note off to the original mode inventor - Russ Housley:</p>
<p> </p>
<blockquote type="cite">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)?</blockquote>
<p>I got back:</p>
<p> </p>
<blockquote type="cite">As long as every party supports both
modes, you could use KW id [sic - I think he meant "is"]</blockquote>
</blockquote>
<p>"if" not "is"</p>
<blockquote type="cite"
cite="mid:91c7929d-0592-8947-d065-7f6180df86cc@comcast.net">
<blockquote type="cite"> the inout is a multiple of 64 bits,
otherwise use KWP. Of course, the algorithm identifier needs to
be set appropriately.</blockquote>
<p>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. <br>
</p>
<p>Does there need to be an autopad OID? <br>
</p>
<p>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.</p>
<p>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.<br>
</p>
<p>At some point, there needs to be an RFC written that specifies
the default encodings for keys wrapped by this algorithm.<br>
</p>
<p>Later, Mike</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAE26cs6pGJYdM6joF_TOSROL_r5XVtEHqFkVFiKPU5ct=4qg_g@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>Thank you,</div>
<div>Greg</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sat, Apr 3, 2021 at 4:38
PM Michael StJohns <<a href="mailto:mstjohns@comcast.net"
moz-do-not-send="true">mstjohns@comcast.net</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">On 4/3/2021 11:35 AM,
Greg Rubin wrote:<br>
> 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?<br>
><br>
> 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.<br>
<br>
I think this is in response to my comment?<br>
<br>
The wrap function can take a Key as an input and can have
the unwrap <br>
method produce a Key as an output - indeed it should be used
primarily <br>
for this rather than the more general encrypt/decrypt
functions. The <br>
problem is that the encoding of the key may not be known
prior to the <br>
attempt to wrap it - hence it's not known whether or not
padding need be <br>
applied. This is especially problematic with HSMs.
Providing an <br>
AutoPadding mode would allow the wrapping algorithm to
decide whether to <br>
use either of the RFC 3394 (AKA KW) Integrity Check Value
(ICV) or the <br>
RFC5649 (aka KWP) value and padding length.<br>
<br>
The key thing to remember here is that the IV (initial value
- RFC <br>
language) /ICV (integrity check value - NIST
language)actually isn't an <br>
IV(initialization vector) in the ordinary meaning, it's a
flag, padding <br>
and integrity indicator and will be fixed for all keys of
the same <br>
length that use the specified values. E.g. unlike other
modes that <br>
require an initialization vector, you don't need to know the
ICV to <br>
decrypt the underlying key stream, but you can (and for
that matter <br>
MUST) easily test the recovered first block against the
expected ICV to <br>
determine whether the output needs padding removed or not.<br>
<br>
FWIW, the actual cryptographic operations between padded
data and <br>
non-padded data (of the right multiple length) are
identical. It's only <br>
the pre or post processing that's looking for different
data.<br>
<br>
Obviously, this doesn't work if someone provides their own
IV - but <br>
that's fairly unlikely. CF CCM and its non-normative
example formatting <br>
function appendix A - each and every implementation I've
seen uses that <br>
formatting function, even though it isn't actually required
by the <br>
standard. I'd be surprised if anyone decided to use a
different set of <br>
non-standard IV values.<br>
<br>
If an AutoPadding mode were implemented, I'd throw
exceptions if someone <br>
tried to set the IV.<br>
<br>
Later, Mike<br>
<br>
<br>
</blockquote>
</div>
</blockquote>
<p><br>
</p>
</blockquote>
<p><br>
</p>
</body>
</html>