From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B2FA9C433E1 for ; Sat, 25 Jul 2020 07:06:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8E21F206E3 for ; Sat, 25 Jul 2020 07:06:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1595660778; bh=2CHbIxC5Kb2WtZDnEWCdd+0JKhqhPfpbvIbPs1xwH4k=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=Nv/bdsk/lz5K1iViga3rXhB084P8f5BlHSEQxa3EWSJKnV46QUwfj5+NtPApJj3Rk vRO/+7k6zhq9exekcycfEir0N3TjBcXGDp7oR3uRUlTQ+3IisgoDivb6y/XrhV3OKS z962i9YZ5Q3m64WnlHL0KDqCttxg0LF9LZ8tVErI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726945AbgGYHGS (ORCPT ); Sat, 25 Jul 2020 03:06:18 -0400 Received: from mail.kernel.org ([198.145.29.99]:46246 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725874AbgGYHGR (ORCPT ); Sat, 25 Jul 2020 03:06:17 -0400 Received: from mail-oi1-f172.google.com (mail-oi1-f172.google.com [209.85.167.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 030B5206E3; Sat, 25 Jul 2020 07:06:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1595660777; bh=2CHbIxC5Kb2WtZDnEWCdd+0JKhqhPfpbvIbPs1xwH4k=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=uwH6LviNKeZGE4LzNNRPr3R/92imSYJ2ZgeAEN7TOA44pZ/llpuI20rU+xXICJ5H7 iRnIa6vNoOk88t2s4QrIua+pndEJwCFEk40fa+C9jcg1PPzDYwO1OvKAkEcfOMT58/ 8fGrHKhJc+pnJgAy8JiVQAJdWl7suR/I2SAQsRGo= Received: by mail-oi1-f172.google.com with SMTP id k4so10004727oik.2; Sat, 25 Jul 2020 00:06:16 -0700 (PDT) X-Gm-Message-State: AOAM531RNgGdkGqdKRsLdqAQ8R6epkHCdgvLztMhWyZKeX1MEuPwOT/1 jKLPHNwzRiuRDl6+yLtBhV5ZEE31V3pVIgVAyJM= X-Google-Smtp-Source: ABdhPJzidd2j+iDxB/LYtohSgN4ly7uvOdd4MMroDSUd9hpc7Iq4dbDDtkMqbNUHllGwnfIzHzQ5G/xdxanlFrdAxEY= X-Received: by 2002:aca:5594:: with SMTP id j142mr280999oib.33.1595660776343; Sat, 25 Jul 2020 00:06:16 -0700 (PDT) MIME-Version: 1.0 References: <20200702101947.682-1-ardb@kernel.org> <20200702101947.682-5-ardb@kernel.org> <20200702175022.GA2753@sol.localdomain> In-Reply-To: From: Ard Biesheuvel Date: Sat, 25 Jul 2020 10:06:04 +0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 4/7] crypto: remove ARC4 support from the skcipher API To: Eric Biggers Cc: linux-wireless@vger.kernel.org, Marcel Holtmann , Denis Kenzior , Linux Kernel Mailing List , Herbert Xu , "David S. Miller" , Greg Kroah-Hartman , Trond Myklebust , Anna Schumaker , "J. Bruce Fields" , Chuck Lever , Linux Crypto Mailing List , "open list:BPF JIT for MIPS (32-BIT AND 64-BIT)" , devel@driverdev.osuosl.org, linux-nfs@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Sat, 18 Jul 2020 at 11:18, Ard Biesheuvel wrote: > > On Fri, 3 Jul 2020 at 02:04, Ard Biesheuvel wrote: > > > > On Thu, 2 Jul 2020 at 20:21, Ard Biesheuvel wrote: > > > > > > On Thu, 2 Jul 2020 at 19:50, Eric Biggers wrote: > > > > > > > > [+linux-wireless, Marcel Holtmann, and Denis Kenzior] > > > > > > > > On Thu, Jul 02, 2020 at 12:19:44PM +0200, Ard Biesheuvel wrote: > > > > > Remove the generic ecb(arc4) skcipher, which is slightly cumbersome from > > > > > a maintenance perspective, since it does not quite behave like other > > > > > skciphers do in terms of key vs IV lifetime. Since we are leaving the > > > > > library interface in place, which is used by the various WEP and TKIP > > > > > implementations we have in the tree, we can safely drop this code now > > > > > it no longer has any users. > > > > > > > > > > Signed-off-by: Ard Biesheuvel > > > > > > > > Last year there was a discussion where it was mentioned that iwd uses > > > > "ecb(arc4)" via AF_ALG. So can we really remove it yet? > > > > See https://lkml.kernel.org/r/97BB95F6-4A4C-4984-9EAB-6069E19B4A4F@holtmann.org > > > > Note that the code isn't in "iwd" itself but rather in "libell" which iwd > > > > depends on: https://git.kernel.org/pub/scm/libs/ell/ell.git/ > > > > > > > > Apparently it also uses md4 and ecb(des) too. > > > > > > > > > > Ah yes, I remember now :-( > > > > > > > Marcel and Denis, what's your deprecation plan for these obsolete and insecure > > > > algorithms? > > > > > > > > > > Given Denis's statement: > > > > > > It sounds to me like it was broken and should be fixed. So our vote / > > > preference is to have ARC4 fixed to follow the proper semantics. We > > > can deal with the kernel behavioral change on our end easily enough; > > > the required workarounds are the worse evil. > > > > > > I would think that an ABI break is not the end of the world for them, > > > and given how trivial it is to implement RC4 in C, the workaround > > > should be to simply implement RC4 in user space, and not even bother > > > trying to use AF_ALG to get at ecb(arc4) > > > > > > (same applies to md4 and ecb(des) btw) > > > > > > There will always be a long tail of use cases, and at some point, we > > > just have to draw the line and remove obsolete and insecure cruft, > > > especially when it impedes progress on other fronts. > > > > > > > I have ported iwd to Nettle's LGPL 2.1 implementation of ARC4, and the > > diffstat is > > > > src/crypto.c | 80 ++++++++++++-------- > > src/main.c | 8 -- > > unit/test-eapol.c | 3 +- > > 3 files changed, 51 insertions(+), 40 deletions(-) > > > > https://git.kernel.org/pub/scm/linux/kernel/git/ardb/iwd.git/log/?h=arc4-cleanup > > Marcel, Denis, > > Do you have any objections to the ecb(arc4) skcipher being dropped > from the kernel, given the fallback i proposed above (which is a much > better way of doing rc4 in user space anyway)? > > For libell, I would suggest dropping rc4 entirely, once iwd stops > relying on it, as using rc4 for tls is obsolete as well. Ping?