> -----Original Message----- > From: linux-crypto-owner@xxxxxxxxxxxxxxx <linux-crypto-owner@xxxxxxxxxxxxxxx> On Behalf Of Gilad Ben-Yossef > Sent: Sunday, February 9, 2020 9:05 AM > To: Stephan Mueller <smueller@xxxxxxxxxx> > Cc: Eric Biggers <ebiggers@xxxxxxxxxx>; Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>; Linux Crypto Mailing List <linux- > crypto@xxxxxxxxxxxxxxx>; Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>; David Miller <davem@xxxxxxxxxxxxx>; Ofir Drang > <Ofir.Drang@xxxxxxx> > Subject: Re: Possible issue with new inauthentic AEAD in extended crypto tests > > <<< External Email >>> > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the > sender/sender address and know the content is safe. > > > On Fri, Feb 7, 2020 at 2:30 PM Stephan Mueller <smueller@xxxxxxxxxx> wrote: > > > > Am Freitag, 7. Februar 2020, 12:50:51 CET schrieb Gilad Ben-Yossef: > > > > Hi Gilad, > > > > > > > > It is correct, but is it smart? > > > > > > Either we require the same IV to be passed twice as we do today, in which > > > case passing different IV should fail in a predictable manner OR we should > > > define the operation is taking two IV like structures - one as the IV and > > > one as bytes in the associated data and have the IPsec code use it in a > > > specific way of happen to pass the same IV in both places. > > > > > > I don't care either way - but right now the tests basically relies on > > > undefined behaviour > > > which is always a bad thing, I think. > > > > I am not sure about the motivation of this discussion: we have exactly one > > user of the RFC4106 implementation: IPSec. Providing the IV/AAD is efficient > > as the rfc4106 template intents to require the data in a format that requires > > minimal processing on the IPSec side to bring it in the right format. > > > > The motivation for this discussion is that our current test suite for > RFC4106 generates test messages where req->iv is different than the > copy in the associated data. > Interesting ... this must be a recent change then, because that's not what I remember and it's also not in the current 5.6-rc1 tree from Linus. So what would you expect then? That it takes the IV from req->iv and totally ignores the AAD data part? That would be the only behavor making sense for rfc4106 specifically. Leaves the question why you would allow the application to supply totally random data to the ciphersuite. But then what about rfc4543 where you have the same API (presumably rfc4106 was aligned with that?) but you MUST have req->iv matching that AAD data otherwise you're not compliant with that RFC. (regardless of whether that 'might be useful' - the name would be wrong then) > This is not per my interpretation of RFC 4106, this is not the API as > is described in the header files and finally it is not per the use > case of the single user of RFC 4106 in the kernel and right now these > tests > causes the ccree driver to fail these tests. > Agree > Again, I am *not* suggesting or discussing changing the API. > The API just needs some clarification in this area. It makes sense to _require_ req->iv and the IV part at the end of the AAD buffer to be _identical_ such that the driver can _assume_ this to be the case. Considering these ciphersuites are really specific to IPsec ESP. > I am asking the very practical question if it makes sense to me to > delve into understanding why this use case is failing versus fixing > the test suite to test what we actually use. > > Gilad > > -- > Gilad Ben-Yossef > Chief Coffee Drinker > > values of β will give rise to dom! Regards, Pascal van Leeuwen Silicon IP Architect Multi-Protocol Engines, Rambus Security Rambus ROTW Holding BV +31-73 6581953 Note: The Inside Secure/Verimatrix Silicon IP team was recently acquired by Rambus. Please be so kind to update your e-mail address book with my new e-mail address. ** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is confidential and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying, forwarding or saving it. Please delete the message and attachments and notify the sender immediately. ** Rambus Inc.<http://www.rambus.com>
