Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <CAOtvUMcwLtwgigFE2mx7LVjhhEgcZsSS4WyR_SQ2gixTZxyBfg@mail.gmail.com>
 <28236835.Fk5ARk2Leh@tauon.chronox.de> <CAOtvUMchWrNsvmLJ2D-qiGOAAgbr_yxtt3h81yOHesa7C6ifZQ@mail.gmail.com>
 <6968686.FA8oO0t0Vk@tauon.chronox.de>
In-Reply-To: <6968686.FA8oO0t0Vk@tauon.chronox.de>
From:   Gilad Ben-Yossef <gilad@benyossef.com>
Date:   Sun, 9 Feb 2020 10:04:55 +0200
Message-ID: <CAOtvUMcqod8ubo_Y9_czM__+U9pWge4s6bLZoZ8YBa-WJTTWNg@mail.gmail.com>
Subject: Re: Possible issue with new inauthentic AEAD in extended crypto tests
To:     Stephan Mueller <smueller@chronox.de>
Cc:     Eric Biggers <ebiggers@kernel.org>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
        Geert Uytterhoeven <geert@linux-m68k.org>,
        David Miller <davem@davemloft.net>,
        Ofir Drang <Ofir.Drang@arm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

On Fri, Feb 7, 2020 at 2:30 PM Stephan Mueller <smueller@chronox.de> 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 whi=
ch
> > case passing different IV should fail in a predictable manner OR we sho=
uld
> > define the operation is taking two IV like structures - one as the IV a=
nd
> > 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 on=
e
> user of the RFC4106 implementation: IPSec. Providing the IV/AAD is effici=
ent
> as the rfc4106 template intents to require the data in a format that requ=
ires
> 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.
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.

Again, I am *not* suggesting or discussing changing the API.

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

--=20
Gilad Ben-Yossef
Chief Coffee Drinker

values of =CE=B2 will give rise to dom!