linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephan Mueller <smueller@chronox.de>
To: Gilad Ben-Yossef <gilad@benyossef.com>
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>
Subject: Re: Possible issue with new inauthentic AEAD in extended crypto tests
Date: Fri, 07 Feb 2020 13:29:47 +0100	[thread overview]
Message-ID: <6968686.FA8oO0t0Vk@tauon.chronox.de> (raw)
In-Reply-To: <CAOtvUMchWrNsvmLJ2D-qiGOAAgbr_yxtt3h81yOHesa7C6ifZQ@mail.gmail.com>

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.

On the other hand, the cipher implementation should just do the operation 
regardless of where the data comes from or whether the AAD buffer overlaps 
with the IV buffer. I.e. the cipher should try to interpret the data but just 
do the work.

So, where is it inefficient? Maybe the API for RFC4106 could be a bit nicer, 
but it needs to fit into the overall AEAD API as a specific RFC4106-API seems 
to be overkill.

Ciao
Stephan



  reply	other threads:[~2020-02-07 12:30 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-27  8:04 Possible issue with new inauthentic AEAD in extended crypto tests Gilad Ben-Yossef
2020-01-28  2:34 ` Eric Biggers
2020-01-28  3:15   ` Stephan Mueller
2020-01-28  3:38   ` Herbert Xu
2020-01-28  7:24     ` Gilad Ben-Yossef
2020-01-28 21:12       ` Eric Biggers
2020-01-29 11:28         ` Gilad Ben-Yossef
     [not found]         ` <2f3e874fae2242d99f4e4095ae42eb75@MN2PR20MB2973.namprd20.prod.outlook.com>
2020-01-29 13:28           ` Van Leeuwen, Pascal
2020-02-05 14:48         ` Gilad Ben-Yossef
2020-02-07  7:27           ` Eric Biggers
2020-02-07  7:56             ` Stephan Mueller
2020-02-07 11:50               ` Gilad Ben-Yossef
2020-02-07 12:29                 ` Stephan Mueller [this message]
2020-02-09  8:04                   ` Gilad Ben-Yossef
     [not found]                   ` <7f68982502574b03931e7caad965e76f@MN2PR20MB2973.namprd20.prod.outlook.com>
2020-02-10  8:03                     ` Van Leeuwen, Pascal
     [not found]               ` <3b65754206a049e596efeb76619eef5c@MN2PR20MB2973.namprd20.prod.outlook.com>
2020-02-07 14:30                 ` Van Leeuwen, Pascal
     [not found]             ` <70156395ce424f41949feb13fd9f978b@MN2PR20MB2973.namprd20.prod.outlook.com>
2020-02-07 14:07               ` Van Leeuwen, Pascal
2020-02-07 14:29                 ` Stephan Mueller
2020-02-07 15:36                   ` Van Leeuwen, Pascal
     [not found]                   ` <0795c353d60547539d23cd6db805f579@MN2PR20MB2973.namprd20.prod.outlook.com>
2020-02-07 15:50                     ` Van Leeuwen, Pascal
2020-02-09  8:09                 ` Gilad Ben-Yossef
2020-02-10  8:05                   ` Van Leeuwen, Pascal
2020-02-10 11:04             ` Herbert Xu
     [not found]       ` <b5a529fd1abd46ea881b18c387fcd4dc@MN2PR20MB2973.namprd20.prod.outlook.com>
2020-01-29  0:18         ` Van Leeuwen, Pascal
2020-01-29  1:26           ` Stephan Mueller
     [not found]           ` <11489dad16d64075939db69181b5ecbb@MN2PR20MB2973.namprd20.prod.outlook.com>
2020-01-29  8:40             ` Van Leeuwen, Pascal
2020-01-29 12:54               ` Stephan Mueller
2020-01-29 13:42                 ` Van Leeuwen, Pascal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6968686.FA8oO0t0Vk@tauon.chronox.de \
    --to=smueller@chronox.de \
    --cc=Ofir.Drang@arm.com \
    --cc=davem@davemloft.net \
    --cc=ebiggers@kernel.org \
    --cc=geert@linux-m68k.org \
    --cc=gilad@benyossef.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).