From patchwork Fri Mar 2 19:56:10 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Biggers X-Patchwork-Id: 10255655 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 3ADD6603ED for ; Fri, 2 Mar 2018 19:58:13 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2B52D28473 for ; Fri, 2 Mar 2018 19:58:13 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 1F19A28471; Fri, 2 Mar 2018 19:58:13 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 8B2A328470 for ; Fri, 2 Mar 2018 19:58:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932504AbeCBT6L (ORCPT ); Fri, 2 Mar 2018 14:58:11 -0500 Received: from mail-io0-f176.google.com ([209.85.223.176]:39179 "EHLO mail-io0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932394AbeCBT6K (ORCPT ); Fri, 2 Mar 2018 14:58:10 -0500 Received: by mail-io0-f176.google.com with SMTP id b34so11800936ioj.6 for ; Fri, 02 Mar 2018 11:58:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=qYET+9Nq53YEjXlRzr+LvNIevEcxyxgSNhZsjOkSkgM=; b=s3XvGDSyKIWeke9bF1BWW9shCG/NqiIAuu6wXyj/u5Z6carpTk3bdj6yw5Tg1vCUGM ti1JoOK6OiCifpbWD1VtctfxcoQ245GIXxog+8HagrChS95pQnYMiloXMlBYZ/c3Gbji xYYqS6jKmeXwgNdUjZfLgS01lFGqDdQ7obmSp2rFDChw+8kZSaO4978OMW5ryXgmesNI AeoHmRdNKNYYfh3QFKFv+l93Qcwi9GEcvsrtJ9yvXB0w6DUodCaUFetpFhPoxOjZ8VVy DKMmG7L9HD/mFd1wsl56DXg6AwZS39P0yilKpLonaHQ1IEDi/GkYauGp2BXklOsBF4+n lztg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=qYET+9Nq53YEjXlRzr+LvNIevEcxyxgSNhZsjOkSkgM=; b=c7MbkOYTzNPr4dvaD0709SSacKbNYDba+C2sGf6KTdaI7i6WlaDgBTYsX21uhAQHGa WqGIfdkMDvPGXDH7/8//DUuJ69ROceiwDMQVedqvn/uiz8K1RrFURLuUxddvFAtOff5v ckovM0BYYRfutswsCreseD4orAMIDiUrETZ9lgSpS2Gao8i6/PhYoannsgwp+FBDQ4Fi viIV6W9xdjjXTp/USBragXKQdjHuX3Ssks19e8V8b7RHYGZGQAh3hN6vs/xuoGC251WP J6wfp7tQBzvDA9bMbRynGiZXG4O1Y9hRxvna0rbJOn1GyY7lJ9PYUgy/wLsWDpBe1PZ5 yUrw== X-Gm-Message-State: AElRT7GK2AKF8aC9w7WYsO/Rg0LczkOZ+IHntYYhKA62jpUUOpdAfRgG ++Yncdyt2oEsHipH8haR/DkBG+nHP4s= X-Google-Smtp-Source: AG47ELtuFDXtmUnsG/+IWaG2Ghbg9XqbHUFjJ/r/xtEEoXR72PejJ/bFTr87BvT6wC6lh8Jqa+5WWQ== X-Received: by 10.107.129.8 with SMTP id c8mr7966267iod.218.1520020688438; Fri, 02 Mar 2018 11:58:08 -0800 (PST) Received: from ebiggers-linuxstation.kir.corp.google.com ([2620:15c:17:3:dc28:5c82:b905:e8a8]) by smtp.gmail.com with ESMTPSA id p192sm1079816itc.29.2018.03.02.11.58.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Mar 2018 11:58:07 -0800 (PST) From: Eric Biggers To: linux-fscrypt@vger.kernel.org, Theodore Ts'o Cc: linux-crypto@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-mtd@lists.infradead.org, Richard Weinberger , David Gstir , Jaegeuk Kim , Paul Crowley , Patrik Torstensson , Greg Kaiser , Michael Halcrow , Eric Biggers Subject: [PATCH] fscrypt: add Speck128/256 support Date: Fri, 2 Mar 2018 11:56:10 -0800 Message-Id: <20180302195610.153581-1-ebiggers@google.com> X-Mailer: git-send-email 2.16.2.395.g2e18187dfd-goog Sender: linux-fscrypt-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fscrypt@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hello, here's a patch which adds Speck128/256 support to fscrypt, for ext4/f2fs/ubifs encryption. Note that this can be applied independently of the patches that added Speck to the crypto API since there is no hard dependency, but the crypto API support is needed for Speck-encrypted files to work. The crypto API patches can be found in linux-next via cryptodev/master. Commit da7a0ab5b4ba ("crypto: speck - add support for the Speck block cipher") with CONFIG_CRYPTO_SPECK enabled is sufficient for basic testing, but for testing on ARM the NEON-accelerated version should be applied and enabled as well. -----8<----- fscrypt currently only supports AES encryption. However, many low-end mobile devices have older CPUs that don't have AES instructions, e.g. the ARMv8 Cryptography Extensions. Currently, user data on such devices is not being encrypted because AES is not fast enough, even when the NEON bit-sliced implementation of AES is used. Therefore, this patch provides an alternative to AES by updating fscrypt to support the Speck block cipher. Separate patches added Speck to the crypto API; more details about the choice of Speck can be found in those patches. Note in particular that we can't use ChaCha20 as previously proposed, since it would, in general, be insecure to use a stream cipher in this context. The generic Speck implementation is not especially fast, but Speck can be greatly accelerated using general-purpose vector instructions, e.g. ARM NEON. As an example, on a device with an ARMv7 processor, the NEON-accelerated Speck128/256-XTS was 108 MB/s for both encryption and decryption, while AES-256-XTS (with the NEON bit-sliced implementation) was only 41 MB/s encryption and 37 MB/s decryption. There are multiple variants of Speck. This patch only adds support for Speck128/256, which is the variant with a 128-bit block size and 256-bit key size -- the same as AES-256. This is believed to be the most secure variant of Speck, and it's only about 6% slower than Speck128/128. Speck64/128 is also a contender, since it's at least 20% faster than Speck128/256 (having 20% fewer rounds), and can be even faster on CPUs that can't efficiently do the 64-bit operations needed for Speck128. But, ARM NEON supports the needed 64-bit operations even on 32-bit CPUs, and Speck128/256 appears to be fast enough for our targeted use cases. So, it makes sense to support Speck128/256 in fscrypt anyway, even if there's a possibility that Speck64/128 support would be added later. The chosen modes of operation are XTS for contents and CTS-CBC for filenames. These are the same modes recommended for AES currently. This patch intentionally does *not* make CONFIG_FS_ENCRYPTION select CONFIG_CRYPTO_SPECK. Thus, people will have to enable Speck support themselves if needed. This is firstly because we shouldn't bloat the FS_ENCRYPTION dependencies with every new cipher, especially ones that aren't recommended for most users. It's also because CRYPTO_SPECK just refers to the generic implementation, which won't be fast enough for many users; in practice, they'll need to enable a vectorized implementation such as CRYPTO_SPECK_NEON to get acceptable performance. Signed-off-by: Eric Biggers --- Documentation/filesystems/fscrypt.rst | 10 ++++++++++ fs/crypto/fscrypt_private.h | 4 ++++ fs/crypto/keyinfo.c | 2 ++ include/uapi/linux/fs.h | 2 ++ 4 files changed, 18 insertions(+) diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst index cfbc18f0d9c9..c99465965512 100644 --- a/Documentation/filesystems/fscrypt.rst +++ b/Documentation/filesystems/fscrypt.rst @@ -191,11 +191,21 @@ Currently, the following pairs of encryption modes are supported: - AES-256-XTS for contents and AES-256-CTS-CBC for filenames - AES-128-CBC for contents and AES-128-CTS-CBC for filenames +- Speck128/256-XTS for contents and Speck128/256-CTS-CBC for filenames It is strongly recommended to use AES-256-XTS for contents encryption. AES-128-CBC was added only for low-powered embedded devices with crypto accelerators such as CAAM or CESA that do not support XTS. +Similarly, Speck128/256 support was only added for older or low-end +CPUs which cannot do AES fast enough -- especially ARM CPUs which have +NEON instructions but not the Cryptography Extensions. It is not +recommended to use Speck on CPUs that have AES instructions. +Nevertheless, to use Speck, CONFIG_CRYPTO_SPECK must be enabled. It +is strongly recommended to enable any available architecture-specific +implementations of Speck as well, e.g. CONFIG_CRYPTO_SPECK_NEON for +ARM, since they can be much faster than the generic implementation. + New encryption modes can be added relatively easily, without changes to individual filesystems. However, authenticated encryption (AE) modes are not currently supported because of the difficulty of dealing diff --git a/fs/crypto/fscrypt_private.h b/fs/crypto/fscrypt_private.h index fb96e493167b..bf0bbba783f8 100644 --- a/fs/crypto/fscrypt_private.h +++ b/fs/crypto/fscrypt_private.h @@ -91,6 +91,10 @@ static inline bool fscrypt_valid_enc_modes(u32 contents_mode, filenames_mode == FS_ENCRYPTION_MODE_AES_256_CTS) return true; + if (contents_mode == FS_ENCRYPTION_MODE_SPECK128_256_XTS && + filenames_mode == FS_ENCRYPTION_MODE_SPECK128_256_CTS) + return true; + return false; } diff --git a/fs/crypto/keyinfo.c b/fs/crypto/keyinfo.c index 05f5ee1f0705..96a1eae9e51d 100644 --- a/fs/crypto/keyinfo.c +++ b/fs/crypto/keyinfo.c @@ -135,6 +135,8 @@ static const struct { FS_AES_128_CBC_KEY_SIZE }, [FS_ENCRYPTION_MODE_AES_128_CTS] = { "cts(cbc(aes))", FS_AES_128_CTS_KEY_SIZE }, + [FS_ENCRYPTION_MODE_SPECK128_256_XTS] = { "xts(speck128)", 64 }, + [FS_ENCRYPTION_MODE_SPECK128_256_CTS] = { "cts(cbc(speck128))", 32 }, }; static int determine_cipher_type(struct fscrypt_info *ci, struct inode *inode, diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h index d2a8313fabd7..0b6e07ee63a6 100644 --- a/include/uapi/linux/fs.h +++ b/include/uapi/linux/fs.h @@ -275,6 +275,8 @@ struct fsxattr { #define FS_ENCRYPTION_MODE_AES_256_CTS 4 #define FS_ENCRYPTION_MODE_AES_128_CBC 5 #define FS_ENCRYPTION_MODE_AES_128_CTS 6 +#define FS_ENCRYPTION_MODE_SPECK128_256_XTS 7 +#define FS_ENCRYPTION_MODE_SPECK128_256_CTS 8 struct fscrypt_policy { __u8 version;