linux-kernel - Re: [PATCH] crypto: mark cts(cbc(aes)) as FIPS allowed

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, 5 Nov 2018 11:20:28 +0100
From:   Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:     Gilad Ben-Yossef <gilad@...yossef.com>
Cc:     Stephan Müller <smueller@...onox.de>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        David Miller <davem@...emloft.net>,
        Ofir Drang <Ofir.Drang@....com>,
        Yael Chemla <Yael.Chemla@....com>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        Linux kernel mailing list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] crypto: mark cts(cbc(aes)) as FIPS allowed

On 5 November 2018 at 10:18, Gilad Ben-Yossef <gilad@...yossef.com> wrote:
> Hi Stephan,
>
> On Mon, Nov 5, 2018 at 10:50 AM Stephan Mueller <smueller@...onox.de> wrote:
>>
>> Am Sonntag, 4. November 2018, 11:05:24 CET schrieb Gilad Ben-Yossef:
>>
>> Hi Gilad,
>>
>> > As per Sp800-38A addendum from Oct 2010[1], cts(cbc(aes)) is
>> > allowed as a FIPS mode algorithm. Mark it as such.
>> >
>> > [1] https://csrc.nist.gov/publications/detail/sp/800-38a/addendum/final
>>
>> There are several types of CTS approaches. Only three of those are listed in
>> the SP800-38A addendum. The source code only refers to some RFCs.
>>
>> Did you check whether the CTS implementation matches one or more of the types
>> listed in the addendum? If yes, may I suggest to add a small statement in the
>> code noting this fact?
>
> Yes, AFAIK the software implements CBC-CS3 as described in the document.
> You have a very good point about this not document anywhere. I will
> send a patch.
>

I agree that it makes sense to document this.

> While we're at it, does someone find it useful if I implemented the
> other two modes?
> They are part of the standard as well, although I am not sure that in
> itself is sufficient cause.
>

Nope. The linux crypto API is not a general purpose cryptography
toolkit, it should only offer what we actually use in the kernel, or
we'll either end up with bitrot or with a disproportionate maintenance
burden for stuff nobody actually uses.