linux-kernel - RE: [PATCH 19/22] crypto: inside-secure - add check for xts input length equal to zero

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 10 Aug 2020 21:37:50 +0000
From:   "Van Leeuwen, Pascal" <pvanleeuwen@...bus.com>
To:     Horia Geantă <horia.geanta@....com>,
        Herbert Xu <herbert@...dor.apana.org.au>
CC:     "Andrei Botila (OSS)" <andrei.botila@....nxp.com>,
        "David S. Miller" <davem@...emloft.net>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
        "linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "linux-arm-kernel@...s.com" <linux-arm-kernel@...s.com>,
        Andrei Botila <andrei.botila@....com>,
        Antoine Tenart <antoine.tenart@...tlin.com>
Subject: RE: [PATCH 19/22] crypto: inside-secure - add check for xts input
 length equal to zero

> -----Original Message-----
> From: Horia Geantă <horia.geanta@....com>
> Sent: Monday, August 10, 2020 4:34 PM
> To: Herbert Xu <herbert@...dor.apana.org.au>; Van Leeuwen, Pascal <pvanleeuwen@...bus.com>
> Cc: Andrei Botila (OSS) <andrei.botila@....nxp.com>; David S. Miller <davem@...emloft.net>; linux-crypto@...r.kernel.org; linux-
> arm-kernel@...ts.infradead.org; linux-kernel@...r.kernel.org; linuxppc-dev@...ts.ozlabs.org; linux-s390@...r.kernel.org;
> x86@...nel.org; linux-arm-kernel@...s.com; Andrei Botila <andrei.botila@....com>; Antoine Tenart <antoine.tenart@...tlin.com>
> Subject: Re: [PATCH 19/22] crypto: inside-secure - add check for xts input length equal to zero
>
> <<< External Email >>>
> On 8/10/2020 4:45 PM, Herbert Xu wrote:
> > On Mon, Aug 10, 2020 at 10:20:20AM +0000, Van Leeuwen, Pascal wrote:
> >>
> >> With all due respect, but this makes no sense.
> >
> > I agree.  This is a lot of churn for no gain.
> >
> I would say the gain is that all skcipher algorithms would behave the same
> when input length equals zero - i.e. treat the request as a no-op.
>
XTS already behaves differently because it can accept any byte amount as long
as it is not in the range 0 -16. So far, you got an EINVAL error for lengths < 16.
The special exception on top of that for length 0 does not improve anything.

Treating a request of length 0 as a no-op is not a useful feature here, as there
is no use case where that would make sense. XTS encrypts blocks (usually disk
sectors), and cannot be chained. So an attempt to encrypt a zero length block
is most certainly some kind of error (e.g. trying to use XTS for something it
was not designed to do - big security mistake!).

> We can't say "no input" has any meaning to the other skcipher algorithms,
> but the convention is to accept this case and just return 0.
> I don't see why XTS has to be handled differently.
>
I don't see why you would blindly follow some historical convention ...
unless maybe there was some existing real use case that would benefit?

BTW: for generic ciphers I could think of some use cases where the zero
length request being a no-op makes sense if the application does not
bother to check how much data it has gathered to process (which may be
nothing), but I can't see how this could apply to XTS, being block-based.

> Thanks,
> Horia

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>