Date: Wed, 8 May 2019 16:20:18 -0700 From: John Baldwin <jhb@FreeBSD.org> To: Benjamin Kaduk <kaduk@mit.edu> Cc: arch@freebsd.org Subject: Re: Deprecating crypto algorithms in the kernel Message-ID: <41d11a3a-463c-941a-e66f-035a6e3fc7b3@FreeBSD.org> In-Reply-To: <20190507170115.GI19509@kduck.mit.edu> References: <41ed59c2-f06c-710b-0e77-3b78add85ca3@FreeBSD.org> <245B376C-F79C-4615-8021-6692EE58CE60@gid.co.uk> <20190507170115.GI19509@kduck.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5/7/19 10:01 AM, Benjamin Kaduk wrote:
>>> On 7 May 2019, at 02:13, John Baldwin <jhb@freebsd.org> wrote:
>>>
>>> commit 28ee9a2b109251829e940660b53a3551e70b720b
>>> Author: John Baldwin <jhb@FreeBSD.org>
>>> Date: Mon May 6 15:48:24 2019 -0700
>>>
>>> Add deprecation warnings for IPsec algorithms deprecated in RFC 8221.
>>>
>>> All of these algorithms are either explicitly marked MUST NOT, or they are
>>> implicitly MUST NOTs by virtue of not being included in IETF's list of
>>> protocols at all despite having assignments from IANA.
>
> [see below]
>
>>> Specifically, this adds warnings for the following ciphers:
>>> - des-cbc
>>> - blowfish-cbc
>>> - cast128-cbc
>>> - des-deriv
>>> - des-32iv
>>> - camellia-cbc
>
> AFAIK Camellia is not bad per se, just not implemented/used much outside of
> Japan.
>
> For IETF protocols, it mostly got specified via Informational documents and
> not Standards-Track ones, since many people thought AES/etc. were fine.
Yes, I chose to not deprecate Camellia and ripemd160 in geli since it did
seem to just be less popular rather than "new use actively discouraged".
Do you think it might be worth letting it remain in IPsec? Similarly for
ripemd160?
>>> commit dcd2c0a4a4e5a82f7cec2fc7e77e9356c1125765
>>> Author: John Baldwin <jhb@FreeBSD.org>
>>> Date: Mon May 6 17:39:56 2019 -0700
>>>
>>> Add deprecation warnings for weaker algorithms to geli(4).
>>>
>>> - Triple DES has been formally deprecated in Kerberos (RFC 8429)
>>> and is soon to be deprecated in IPsec (RFC 8221). It is generally
>>> considered a weak cipher.
>
> Nitpicking the wording: it's not so much that it's weak per se (even
> single-DES is just falling to the 56-bit brute-force attack, and I think
> triple-DES still basically holds the expected 112-bit strength), but it's
> quite slow and has a 64-bit block size, which increases the risk of
> birthday collisions. I'm all for replacing/removing it, but mostly not
> because I think it's "weak".
Ok, I will drop that sentence.
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41d11a3a-463c-941a-e66f-035a6e3fc7b3>