2
0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-29 23:53:55 +08:00
linux-next/fs/crypto
Eric Biggers ba47b515f5 fscrypt: align Base64 encoding with RFC 4648 base64url
fscrypt uses a Base64 encoding to encode no-key filenames (the filenames
that are presented to userspace when a directory is listed without its
encryption key).  There are many variants of Base64, but the most common
ones are specified by RFC 4648.  fscrypt can't use the regular RFC 4648
"base64" variant because "base64" uses the '/' character, which isn't
allowed in filenames.  However, RFC 4648 also specifies a "base64url"
variant for use in URLs and filenames.  "base64url" is less common than
"base64", but it's still implemented in many programming libraries.

Unfortunately, what fscrypt actually uses is a custom Base64 variant
that differs from "base64url" in several ways:

- The binary data is divided into 6-bit chunks differently.

- Values 62 and 63 are encoded with '+' and ',' instead of '-' and '_'.

- '='-padding isn't used.  This isn't a problem per se, as the padding
  isn't technically necessary, and RFC 4648 doesn't strictly require it.
  But it needs to be properly documented.

There have been two attempts to copy the fscrypt Base64 code into lib/
(https://lkml.kernel.org/r/20200821182813.52570-6-jlayton@kernel.org and
https://lkml.kernel.org/r/20210716110428.9727-5-hare@suse.de), and both
have been caught up by the fscrypt Base64 variant being nonstandard and
not properly documented.  Also, the planned use of the fscrypt Base64
code in the CephFS storage back-end will prevent it from being changed
later (whereas currently it can still be changed), so we need to choose
an encoding that we're happy with before it's too late.

Therefore, switch the fscrypt Base64 variant to base64url, in order to
align more closely with RFC 4648 and other implementations and uses of
Base64.  However, I opted not to implement '='-padding, as '='-padding
adds complexity, is unnecessary, and isn't required by the RFC.

Link: https://lore.kernel.org/r/20210718000125.59701-1-ebiggers@kernel.org
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Eric Biggers <ebiggers@google.com>
2021-07-25 20:47:05 -07:00
..
bio.c block: rename BIO_MAX_PAGES to BIO_MAX_VECS 2021-03-11 07:47:48 -07:00
crypto.c fscrypt: adjust logging for in-creation inodes 2020-09-22 06:48:38 -07:00
fname.c fscrypt: align Base64 encoding with RFC 4648 base64url 2021-07-25 20:47:05 -07:00
fscrypt_private.h f2fs-for-5.11-rc1 2020-12-17 11:18:00 -08:00
hkdf.c crypto: sha - split sha.h into sha1.h and sha2.h 2020-11-20 14:45:33 +11:00
hooks.c fscrypt: add fscrypt_symlink_getattr() for computing st_size 2021-07-25 20:01:06 -07:00
inline_crypt.c fscrypt: fix inline encryption not used on new files 2020-11-11 20:59:07 -08:00
Kconfig fscrypt: relax Kconfig dependencies for crypto API algorithms 2021-04-22 17:31:32 +10:00
keyring.c fscrypt: simplify master key locking 2020-11-24 15:29:47 -08:00
keysetup_v1.c fscrypt: stop pretending that key setup is nofs-safe 2020-09-22 06:48:42 -07:00
keysetup.c fscrypt: fix derivation of SipHash keys on big endian CPUs 2021-06-05 00:52:52 -07:00
Makefile fscrypt: add inline encryption support 2020-07-08 10:29:30 -07:00
policy.c inode: make init and permission helpers idmapped mount aware 2021-01-24 14:27:16 +01:00