Re: [PATCH 0/5] Add KDF implementations to crypto API
On Wed, Jan 06, 2021 at 10:59:24PM -0800, Eric Biggers wrote: > On Thu, Jan 07, 2021 at 07:37:05AM +0100, Stephan Mueller wrote: > > Am Montag, dem 04.01.2021 um 14:20 -0800 schrieb Eric Biggers: > > > On Mon, Jan 04, 2021 at 10:45:57PM +0100, Stephan Müller wrote: > > > > The HKDF addition is used to replace the implementation in the > > > > filesystem > > > > crypto extension. This code was tested by using an EXT4 encrypted file > > > > system that was created and contains files written to by the current > > > > implementation. Using the new implementation a successful read of the > > > > existing files was possible and new files / directories were created > > > > and read successfully. These newly added file system objects could be > > > > successfully read using the current code. Yet if there is a test suite > > > > to validate whether the invokcation of the HKDF calculates the same > > > > result as the existing implementation, I would be happy to validate > > > > the implementation accordingly. > > > > > > See https://www.kernel.org/doc/html/latest/filesystems/fscrypt.html#tests > > > for how to run the fscrypt tests. 'kvm-xfstests -c ext4 generic/582' > > > should > > > be > > > enough for this, though you could run all the tests if you want. > > > > I ran the $(kvm-xfstests -c encrypt -g auto) on 5.11-rc2 with and without my > > HKDF changes. I.e. the testing shows the same results for both kernels which > > seems to imply that my HKDF changes do not change the behavior. > > > > I get the following errors in both occasions - let me know if I should dig a > > bit more. > > The command you ran runs almost all xfstests with the test_dummy_encryption > mount option enabled, which is different from running the encryption tests -- > and in fact it skips the real encryption tests, so it doesn't test the > correctness of HKDF at all. It looks like you saw some unrelated test > failures. > Sorry if I wasn't clear -- by "all tests" I meant all encryption tests, i.e. > 'kvm-xfstests -c ext4 -g encrypt'. Also, even the single test generic/582 > should be sufficient to test HKDF, as I mentioned. > I just did it myself and the tests pass. - Eric
Re: [PATCH 0/5] Add KDF implementations to crypto API
On Thu, Jan 07, 2021 at 07:37:05AM +0100, Stephan Mueller wrote: > Am Montag, dem 04.01.2021 um 14:20 -0800 schrieb Eric Biggers: > > On Mon, Jan 04, 2021 at 10:45:57PM +0100, Stephan Müller wrote: > > > The HKDF addition is used to replace the implementation in the filesystem > > > crypto extension. This code was tested by using an EXT4 encrypted file > > > system that was created and contains files written to by the current > > > implementation. Using the new implementation a successful read of the > > > existing files was possible and new files / directories were created > > > and read successfully. These newly added file system objects could be > > > successfully read using the current code. Yet if there is a test suite > > > to validate whether the invokcation of the HKDF calculates the same > > > result as the existing implementation, I would be happy to validate > > > the implementation accordingly. > > > > See https://www.kernel.org/doc/html/latest/filesystems/fscrypt.html#tests > > for how to run the fscrypt tests. 'kvm-xfstests -c ext4 generic/582' should > > be > > enough for this, though you could run all the tests if you want. > > I ran the $(kvm-xfstests -c encrypt -g auto) on 5.11-rc2 with and without my > HKDF changes. I.e. the testing shows the same results for both kernels which > seems to imply that my HKDF changes do not change the behavior. > > I get the following errors in both occasions - let me know if I should dig a > bit more. The command you ran runs almost all xfstests with the test_dummy_encryption mount option enabled, which is different from running the encryption tests -- and in fact it skips the real encryption tests, so it doesn't test the correctness of HKDF at all. It looks like you saw some unrelated test failures. Sorry if I wasn't clear -- by "all tests" I meant all encryption tests, i.e. 'kvm-xfstests -c ext4 -g encrypt'. Also, even the single test generic/582 should be sufficient to test HKDF, as I mentioned. - Eric
Re: [PATCH 0/5] Add KDF implementations to crypto API
Am Montag, dem 04.01.2021 um 14:20 -0800 schrieb Eric Biggers: > On Mon, Jan 04, 2021 at 10:45:57PM +0100, Stephan Müller wrote: > > The HKDF addition is used to replace the implementation in the filesystem > > crypto extension. This code was tested by using an EXT4 encrypted file > > system that was created and contains files written to by the current > > implementation. Using the new implementation a successful read of the > > existing files was possible and new files / directories were created > > and read successfully. These newly added file system objects could be > > successfully read using the current code. Yet if there is a test suite > > to validate whether the invokcation of the HKDF calculates the same > > result as the existing implementation, I would be happy to validate > > the implementation accordingly. > > See https://www.kernel.org/doc/html/latest/filesystems/fscrypt.html#tests > for how to run the fscrypt tests. 'kvm-xfstests -c ext4 generic/582' should > be > enough for this, though you could run all the tests if you want. I ran the $(kvm-xfstests -c encrypt -g auto) on 5.11-rc2 with and without my HKDF changes. I.e. the testing shows the same results for both kernels which seems to imply that my HKDF changes do not change the behavior. I get the following errors in both occasions - let me know if I should dig a bit more. [failed, exit status 1] [06:19:21]- output mismatch (see /results/ext4/results-encrypt/ext4/023.out.bad) --- tests/ext4/023.out 2020-03-20 02:31:32.0 + +++ /results/ext4/results-encrypt/ext4/023.out.bad 2021-01-07 06:19:21.292339438 + @@ -1,3 +1,2 @@ QA output created by 023 Format and populate -Mount ... (Run 'diff -u /root/xfstests/tests/ext4/023.out /results/ext4/results- encrypt/ext4/023.out.bad' to see the entire ) [failed, exit status 1] [06:19:28]- output mismatch (see /results/ext4/results-encrypt/ext4/028.out.bad) --- tests/ext4/028.out 2020-03-20 02:31:32.0 + +++ /results/ext4/results-encrypt/ext4/028.out.bad 2021-01-07 06:19:28.762339424 + @@ -1,3 +1,2 @@ QA output created by 028 Format and mount -Compare fsmap ... (Run 'diff -u /root/xfstests/tests/ext4/028.out /results/ext4/results- encrypt/ext4/028.out.bad' to see the entire ) [failed, exit status 1] [06:21:02]- output mismatch (see /results/ext4/results-encrypt/ext4/044.out.bad) --- tests/ext4/044.out 2020-03-20 02:31:32.0 + +++ /results/ext4/results-encrypt/ext4/044.out.bad 2021-01-07 06:21:02.215672727 + @@ -1,2 +1,5 @@ QA output created by 044 Silence is golden +mount: /vdc: wrong fs type, bad option, bad superblock on /dev/vdc, missing codepage or helper program, or other e. +ext3 mount failed +(see /results/ext4/results-encrypt/ext4/044.full for details) ... (Run 'diff -u /root/xfstests/tests/ext4/044.out /results/ext4/results- encrypt/ext4/044.out.bad' to see the entire ) generic/085 [06:32:40][ 849.654788] run fstests generic/085 at 2021-01-07 06:32:40 [ 849.903286] EXT4-fs (vdd): Test dummy encryption mode enabled [ 849.915355] EXT4-fs (vdd): mounted filesystem with ordered data mode. Opts: acl,user_xattr,block_validity,test_dummy. [ 850.267282] dm-0: detected capacity change from 524288 to 0 [ 850.369101] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none. [ 850.370106] ext4 filesystem being mounted at /vdc supports timestamps until 2038 (0x7fff) [ 850.479981] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none. [ 850.480782] ext4 filesystem being mounted at /vdc supports timestamps until 2038 (0x7fff) [ 850.530734] BUG: kernel NULL pointer dereference, address: 0058 [ 850.531241] #PF: supervisor read access in kernel mode [ 850.531613] #PF: error_code(0x) - not-present page [ 850.532020] PGD 2a496067 P4D 2a496067 PUD 0 [ 850.532336] Oops: [#1] SMP NOPTI [ 850.532604] CPU: 1 PID: 19542 Comm: dmsetup Not tainted 5.11.0-rc2-xfstests #8 [ 850.533156] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014 [ 850.533780] RIP: 0010:thaw_bdev+0x47/0x90 [ 850.534106] Code: 8b 83 d8 04 00 00 85 c0 74 57 83 e8 01 45 31 e4 85 c0 89 83 d8 04 00 00 7f 2d 48 8b bb 80 05 00 007 [ 850.535447] RSP: 0018:b97586c2bcd8 EFLAGS: 00010286 [ 850.535822] RAX: RBX: 9df4a2e74240 RCX: b97586c2bbdc [ 850.536361] RDX: 9df4fdc17e80 RSI: 9df4a2e74790 RDI: 9df48b0bf000 [ 850.536864] RBP: 9df4a2e74720 R08: R09: 00040216 [ 850.537410] R10: R11: R12: [ 850.537950] R13: R14: 0006 R15: 0001 [ 850.538455] FS: () GS:9df4fdc0(0063) knlGS:f7a487c0 [ 850.539063] CS: 0010 DS: 002b ES:
Re: [PATCH 0/5] Add KDF implementations to crypto API
On Mon, Jan 04, 2021 at 10:45:57PM +0100, Stephan Müller wrote: > The HKDF addition is used to replace the implementation in the filesystem > crypto extension. This code was tested by using an EXT4 encrypted file > system that was created and contains files written to by the current > implementation. Using the new implementation a successful read of the > existing files was possible and new files / directories were created > and read successfully. These newly added file system objects could be > successfully read using the current code. Yet if there is a test suite > to validate whether the invokcation of the HKDF calculates the same > result as the existing implementation, I would be happy to validate > the implementation accordingly. See https://www.kernel.org/doc/html/latest/filesystems/fscrypt.html#tests for how to run the fscrypt tests. 'kvm-xfstests -c ext4 generic/582' should be enough for this, though you could run all the tests if you want. - Eric
[PATCH 0/5] Add KDF implementations to crypto API
Hi, The key derviation functions are considered to be a cryptographic operation. As cryptographic operations are provided via the kernel crypto API, this patch set consolidates the KDF implementations into the crypto API. The KDF implementations are provided as service functions. Yet, the interface to the two provided KDFs are identical with the goal to allow them to be transformed into a crypto API template eventually. The KDFs execute a power-on self test with test vectors from commonly known sources. Tbe SP800-108 KDF implementation is used to replace the implementation in the keys subsystem. The implementation was verified using the keyutils command line test code provided in tests/keyctl/dh_compute/valid. All tests show that the expected values are calculated with the new code. The HKDF addition is used to replace the implementation in the filesystem crypto extension. This code was tested by using an EXT4 encrypted file system that was created and contains files written to by the current implementation. Using the new implementation a successful read of the existing files was possible and new files / directories were created and read successfully. These newly added file system objects could be successfully read using the current code. Yet if there is a test suite to validate whether the invokcation of the HKDF calculates the same result as the existing implementation, I would be happy to validate the implementation accordingly. Stephan Mueller (5): crypto: Add key derivation self-test support code crypto: add SP800-108 counter key derivation function crypto: add RFC5869 HKDF security: DH - use KDF implementation from crypto API fs: use HKDF implementation from kernel crypto API crypto/Kconfig | 14 ++ crypto/Makefile| 6 + crypto/hkdf.c | 226 + crypto/kdf_sp800108.c | 149 fs/crypto/Kconfig | 2 +- fs/crypto/fscrypt_private.h| 4 +- fs/crypto/hkdf.c | 108 +++- include/crypto/hkdf.h | 48 ++ include/crypto/internal/kdf_selftest.h | 68 include/crypto/kdf_sp800108.h | 59 +++ security/keys/Kconfig | 2 +- security/keys/dh.c | 118 ++--- 12 files changed, 617 insertions(+), 187 deletions(-) create mode 100644 crypto/hkdf.c create mode 100644 crypto/kdf_sp800108.c create mode 100644 include/crypto/hkdf.h create mode 100644 include/crypto/internal/kdf_selftest.h create mode 100644 include/crypto/kdf_sp800108.h -- 2.26.2