Did the in-kernel Camellia or CMAC crypto implementation break?

Did the in-kernel Camellia or CMAC crypto implementation break?

[David Howells]

Hi Chuck, Herbert,

I was trying to bring my krb5 crypto lib patches up to date, but noticed that
the Camellia encryption selftests are failing (the key derivation tests work,
but the crypto tests failed).

After some investigation that didn't get anywhere, I tried the sunrpc kunit
tests that Chuck added - and those fail similarly (dmesg attached below).  I
tried the hardware accelerated version also and that has the same failure.

Note that Chuck and I implemented the kerberos Camellia routines
independently.

David
---
    KTAP version 1
    # Subtest: RFC 6803 suite
    1..3
        KTAP version 1
        # Subtest: RFC 6803 key derivation
        ok 1 Derive Kc subkey for camellia128-cts-cmac
        ok 2 Derive Ke subkey for camellia128-cts-cmac
        ok 3 Derive Ki subkey for camellia128-cts-cmac
        ok 4 Derive Kc subkey for camellia256-cts-cmac
        ok 5 Derive Ke subkey for camellia256-cts-cmac
        ok 6 Derive Ki subkey for camellia256-cts-cmac
    # RFC 6803 key derivation: pass:6 fail:0 skip:0 total:6
    ok 1 RFC 6803 key derivation
        KTAP version 1
        # Subtest: RFC 6803 checksum
        ok 1 camellia128-cts-cmac checksum test 1
        ok 2 camellia128-cts-cmac checksum test 2
        ok 3 camellia256-cts-cmac checksum test 3
        ok 4 camellia256-cts-cmac checksum test 4
    # RFC 6803 checksum: pass:4 fail:0 skip:0 total:4
    ok 2 RFC 6803 checksum
        KTAP version 1
        # Subtest: RFC 6803 encryption
    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1389
    Expected memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 0, but
        memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 135 (0x87)

encrypted result mismatch
    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1393
    Expected memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 0, but
        memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == -108 (0xffffffffffffff94)

HMAC mismatch
        not ok 1 Encrypt empty plaintext with camellia128-cts-cmac
    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1389
    Expected memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 0, but
        memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == -49 (0xffffffffffffffcf)

encrypted result mismatch
    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1393
    Expected memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 0, but
        memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == -3 (0xfffffffffffffffd)

HMAC mismatch
        not ok 2 Encrypt 1 byte with camellia128-cts-cmac
    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1389
    Expected memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 0, but
        memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == -36 (0xffffffffffffffdc)

encrypted result mismatch
    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1393
    Expected memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 0, but
        memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 44 (0x2c)

HMAC mismatch
        not ok 3 Encrypt 9 bytes with camellia128-cts-cmac
    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1389
    Expected memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 0, but
        memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == -58 (0xffffffffffffffc6)

encrypted result mismatch
    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1393
    Expected memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 0, but
        memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == -103 (0xffffffffffffff99)

HMAC mismatch
        not ok 4 Encrypt 13 bytes with camellia128-cts-cmac
    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1389
    Expected memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 0, but
        memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 160 (0xa0)

encrypted result mismatch
    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1393
    Expected memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 0, but
        memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 95 (0x5f)

HMAC mismatch
        not ok 5 Encrypt 30 bytes with camellia128-cts-cmac
    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1389
    Expected memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 0, but
        memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == -150 (0xffffffffffffff6a)

encrypted result mismatch
    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1393
    Expected memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 0, but
        memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 48 (0x30)

HMAC mismatch
        not ok 6 Encrypt empty plaintext with camellia256-cts-cmac
    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1389
    Expected memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 0, but
        memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 24 (0x18)

encrypted result mismatch
    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1393
    Expected memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 0, but
        memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 22 (0x16)

HMAC mismatch
        not ok 7 Encrypt 1 byte with camellia256-cts-cmac
    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1389
    Expected memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 0, but
        memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 108 (0x6c)

encrypted result mismatch
    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1393
    Expected memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 0, but
        memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == -106 (0xffffffffffffff96)

HMAC mismatch
        not ok 8 Encrypt 9 bytes with camellia256-cts-cmac
    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1389
    Expected memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 0, but
        memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 64 (0x40)

encrypted result mismatch
    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1393
    Expected memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 0, but
        memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == -196 (0xffffffffffffff3c)

HMAC mismatch
        not ok 9 Encrypt 13 bytes with camellia256-cts-cmac
    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1389
    Expected memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 0, but
        memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == -238 (0xffffffffffffff12)

encrypted result mismatch
    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1393
    Expected memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 0, but
        memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 168 (0xa8)

HMAC mismatch
        not ok 10 Encrypt 30 bytes with camellia256-cts-cmac
    # RFC 6803 encryption: pass:0 fail:10 skip:0 total:10
    not ok 3 RFC 6803 encryption
# RFC 6803 suite: pass:2 fail:1 skip:0 total:3
# Totals: pass:10 fail:10 skip:0 total:20
not ok 3 RFC 6803 suite

Re: Did the in-kernel Camellia or CMAC crypto implementation break?

[Chuck Lever III]

> On Apr 12, 2023, at 11:56 AM, David Howells <dhowells@redhat.com> wrote:
> 
> Hi Chuck, Herbert,
> 
> I was trying to bring my krb5 crypto lib patches up to date, but noticed that
> the Camellia encryption selftests are failing (the key derivation tests work,
> but the crypto tests failed).
> 
> After some investigation that didn't get anywhere, I tried the sunrpc kunit
> tests that Chuck added - and those fail similarly (dmesg attached below).  I
> tried the hardware accelerated version also and that has the same failure.

Ah, I see Scott is Cc'd. Yes, Scott reported this to me yesterday.


> Note that Chuck and I implemented the kerberos Camellia routines
> independently.

Yes, but we implemented the same unit tests (from RFC 6803).


> David
> ---
>    KTAP version 1
>    # Subtest: RFC 6803 suite
>    1..3
>        KTAP version 1
>        # Subtest: RFC 6803 key derivation
>        ok 1 Derive Kc subkey for camellia128-cts-cmac
>        ok 2 Derive Ke subkey for camellia128-cts-cmac
>        ok 3 Derive Ki subkey for camellia128-cts-cmac
>        ok 4 Derive Kc subkey for camellia256-cts-cmac
>        ok 5 Derive Ke subkey for camellia256-cts-cmac
>        ok 6 Derive Ki subkey for camellia256-cts-cmac
>    # RFC 6803 key derivation: pass:6 fail:0 skip:0 total:6
>    ok 1 RFC 6803 key derivation
>        KTAP version 1
>        # Subtest: RFC 6803 checksum
>        ok 1 camellia128-cts-cmac checksum test 1
>        ok 2 camellia128-cts-cmac checksum test 2
>        ok 3 camellia256-cts-cmac checksum test 3
>        ok 4 camellia256-cts-cmac checksum test 4
>    # RFC 6803 checksum: pass:4 fail:0 skip:0 total:4
>    ok 2 RFC 6803 checksum
>        KTAP version 1
>        # Subtest: RFC 6803 encryption
>    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1389
>    Expected memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 0, but
>        memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 135 (0x87)
> 
> encrypted result mismatch
>    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1393
>    Expected memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 0, but
>        memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == -108 (0xffffffffffffff94)
> 
> HMAC mismatch
>        not ok 1 Encrypt empty plaintext with camellia128-cts-cmac
>    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1389
>    Expected memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 0, but
>        memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == -49 (0xffffffffffffffcf)
> 
> encrypted result mismatch
>    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1393
>    Expected memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 0, but
>        memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == -3 (0xfffffffffffffffd)
> 
> HMAC mismatch
>        not ok 2 Encrypt 1 byte with camellia128-cts-cmac
>    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1389
>    Expected memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 0, but
>        memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == -36 (0xffffffffffffffdc)
> 
> encrypted result mismatch
>    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1393
>    Expected memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 0, but
>        memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 44 (0x2c)
> 
> HMAC mismatch
>        not ok 3 Encrypt 9 bytes with camellia128-cts-cmac
>    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1389
>    Expected memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 0, but
>        memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == -58 (0xffffffffffffffc6)
> 
> encrypted result mismatch
>    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1393
>    Expected memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 0, but
>        memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == -103 (0xffffffffffffff99)
> 
> HMAC mismatch
>        not ok 4 Encrypt 13 bytes with camellia128-cts-cmac
>    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1389
>    Expected memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 0, but
>        memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 160 (0xa0)
> 
> encrypted result mismatch
>    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1393
>    Expected memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 0, but
>        memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 95 (0x5f)
> 
> HMAC mismatch
>        not ok 5 Encrypt 30 bytes with camellia128-cts-cmac
>    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1389
>    Expected memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 0, but
>        memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == -150 (0xffffffffffffff6a)
> 
> encrypted result mismatch
>    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1393
>    Expected memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 0, but
>        memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 48 (0x30)
> 
> HMAC mismatch
>        not ok 6 Encrypt empty plaintext with camellia256-cts-cmac
>    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1389
>    Expected memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 0, but
>        memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 24 (0x18)
> 
> encrypted result mismatch
>    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1393
>    Expected memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 0, but
>        memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 22 (0x16)
> 
> HMAC mismatch
>        not ok 7 Encrypt 1 byte with camellia256-cts-cmac
>    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1389
>    Expected memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 0, but
>        memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 108 (0x6c)
> 
> encrypted result mismatch
>    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1393
>    Expected memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 0, but
>        memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == -106 (0xffffffffffffff96)
> 
> HMAC mismatch
>        not ok 8 Encrypt 9 bytes with camellia256-cts-cmac
>    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1389
>    Expected memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 0, but
>        memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 64 (0x40)
> 
> encrypted result mismatch
>    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1393
>    Expected memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 0, but
>        memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == -196 (0xffffffffffffff3c)
> 
> HMAC mismatch
>        not ok 9 Encrypt 13 bytes with camellia256-cts-cmac
>    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1389
>    Expected memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 0, but
>        memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == -238 (0xffffffffffffff12)
> 
> encrypted result mismatch
>    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1393
>    Expected memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 0, but
>        memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 168 (0xa8)
> 
> HMAC mismatch
>        not ok 10 Encrypt 30 bytes with camellia256-cts-cmac
>    # RFC 6803 encryption: pass:0 fail:10 skip:0 total:10
>    not ok 3 RFC 6803 encryption
> # RFC 6803 suite: pass:2 fail:1 skip:0 total:3
> # Totals: pass:10 fail:10 skip:0 total:20
> not ok 3 RFC 6803 suite
> 

--
Chuck Lever

Re: Did the in-kernel Camellia or CMAC crypto implementation break?

[Scott Mayhew]

On Wed, 12 Apr 2023, Chuck Lever III wrote:

> 
> 
> > On Apr 12, 2023, at 11:56 AM, David Howells <dhowells@redhat.com> wrote:
> > 
> > Hi Chuck, Herbert,
> > 
> > I was trying to bring my krb5 crypto lib patches up to date, but noticed that
> > the Camellia encryption selftests are failing (the key derivation tests work,
> > but the crypto tests failed).
> > 
> > After some investigation that didn't get anywhere, I tried the sunrpc kunit
> > tests that Chuck added - and those fail similarly (dmesg attached below).  I
> > tried the hardware accelerated version also and that has the same failure.
> 
> Ah, I see Scott is Cc'd. Yes, Scott reported this to me yesterday.

Yes, I found that if I run the test via kunit.py it works fine.  If I
try to run it via loading the gss_krb5_test module, the checksum tests
fail.  But if I build the tests directly into the kernel, then they also
run fine.

-Scott
> 
> 
> > Note that Chuck and I implemented the kerberos Camellia routines
> > independently.
> 
> Yes, but we implemented the same unit tests (from RFC 6803).
> 
> 
> > David
> > ---
> >    KTAP version 1
> >    # Subtest: RFC 6803 suite
> >    1..3
> >        KTAP version 1
> >        # Subtest: RFC 6803 key derivation
> >        ok 1 Derive Kc subkey for camellia128-cts-cmac
> >        ok 2 Derive Ke subkey for camellia128-cts-cmac
> >        ok 3 Derive Ki subkey for camellia128-cts-cmac
> >        ok 4 Derive Kc subkey for camellia256-cts-cmac
> >        ok 5 Derive Ke subkey for camellia256-cts-cmac
> >        ok 6 Derive Ki subkey for camellia256-cts-cmac
> >    # RFC 6803 key derivation: pass:6 fail:0 skip:0 total:6
> >    ok 1 RFC 6803 key derivation
> >        KTAP version 1
> >        # Subtest: RFC 6803 checksum
> >        ok 1 camellia128-cts-cmac checksum test 1
> >        ok 2 camellia128-cts-cmac checksum test 2
> >        ok 3 camellia256-cts-cmac checksum test 3
> >        ok 4 camellia256-cts-cmac checksum test 4
> >    # RFC 6803 checksum: pass:4 fail:0 skip:0 total:4
> >    ok 2 RFC 6803 checksum
> >        KTAP version 1
> >        # Subtest: RFC 6803 encryption
> >    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1389
> >    Expected memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 0, but
> >        memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 135 (0x87)
> > 
> > encrypted result mismatch
> >    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1393
> >    Expected memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 0, but
> >        memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == -108 (0xffffffffffffff94)
> > 
> > HMAC mismatch
> >        not ok 1 Encrypt empty plaintext with camellia128-cts-cmac
> >    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1389
> >    Expected memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 0, but
> >        memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == -49 (0xffffffffffffffcf)
> > 
> > encrypted result mismatch
> >    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1393
> >    Expected memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 0, but
> >        memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == -3 (0xfffffffffffffffd)
> > 
> > HMAC mismatch
> >        not ok 2 Encrypt 1 byte with camellia128-cts-cmac
> >    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1389
> >    Expected memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 0, but
> >        memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == -36 (0xffffffffffffffdc)
> > 
> > encrypted result mismatch
> >    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1393
> >    Expected memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 0, but
> >        memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 44 (0x2c)
> > 
> > HMAC mismatch
> >        not ok 3 Encrypt 9 bytes with camellia128-cts-cmac
> >    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1389
> >    Expected memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 0, but
> >        memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == -58 (0xffffffffffffffc6)
> > 
> > encrypted result mismatch
> >    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1393
> >    Expected memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 0, but
> >        memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == -103 (0xffffffffffffff99)
> > 
> > HMAC mismatch
> >        not ok 4 Encrypt 13 bytes with camellia128-cts-cmac
> >    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1389
> >    Expected memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 0, but
> >        memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 160 (0xa0)
> > 
> > encrypted result mismatch
> >    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1393
> >    Expected memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 0, but
> >        memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 95 (0x5f)
> > 
> > HMAC mismatch
> >        not ok 5 Encrypt 30 bytes with camellia128-cts-cmac
> >    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1389
> >    Expected memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 0, but
> >        memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == -150 (0xffffffffffffff6a)
> > 
> > encrypted result mismatch
> >    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1393
> >    Expected memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 0, but
> >        memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 48 (0x30)
> > 
> > HMAC mismatch
> >        not ok 6 Encrypt empty plaintext with camellia256-cts-cmac
> >    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1389
> >    Expected memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 0, but
> >        memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 24 (0x18)
> > 
> > encrypted result mismatch
> >    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1393
> >    Expected memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 0, but
> >        memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 22 (0x16)
> > 
> > HMAC mismatch
> >        not ok 7 Encrypt 1 byte with camellia256-cts-cmac
> >    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1389
> >    Expected memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 0, but
> >        memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 108 (0x6c)
> > 
> > encrypted result mismatch
> >    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1393
> >    Expected memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 0, but
> >        memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == -106 (0xffffffffffffff96)
> > 
> > HMAC mismatch
> >        not ok 8 Encrypt 9 bytes with camellia256-cts-cmac
> >    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1389
> >    Expected memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 0, but
> >        memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 64 (0x40)
> > 
> > encrypted result mismatch
> >    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1393
> >    Expected memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 0, but
> >        memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == -196 (0xffffffffffffff3c)
> > 
> > HMAC mismatch
> >        not ok 9 Encrypt 13 bytes with camellia256-cts-cmac
> >    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1389
> >    Expected memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == 0, but
> >        memcmp(param->expected_result->data, buf.head[0].iov_base, buf.len) == -238 (0xffffffffffffff12)
> > 
> > encrypted result mismatch
> >    # RFC 6803 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:1393
> >    Expected memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 0, but
> >        memcmp(param->expected_result->data + (param->expected_result->len - checksum.len), checksum.data, checksum.len) == 168 (0xa8)
> > 
> > HMAC mismatch
> >        not ok 10 Encrypt 30 bytes with camellia256-cts-cmac
> >    # RFC 6803 encryption: pass:0 fail:10 skip:0 total:10
> >    not ok 3 RFC 6803 encryption
> > # RFC 6803 suite: pass:2 fail:1 skip:0 total:3
> > # Totals: pass:10 fail:10 skip:0 total:20
> > not ok 3 RFC 6803 suite
> > 
> 
> --
> Chuck Lever
> 
> 

Re: Did the in-kernel Camellia or CMAC crypto implementation break?

[David Howells]

Scott Mayhew <smayhew@redhat.com> wrote:

> Yes, I found that if I run the test via kunit.py it works fine.  If I
> try to run it via loading the gss_krb5_test module, the checksum tests
> fail.  But if I build the tests directly into the kernel, then they also
> run fine.

I have them built into the kernel, both in sunrpc and my krb5 lib.  Both are
failing.

David

Re: Did the in-kernel Camellia or CMAC crypto implementation break?

[Herbert Xu]

On Wed, Apr 12, 2023 at 06:50:03PM +0100, David Howells wrote:
>
> I have them built into the kernel, both in sunrpc and my krb5 lib.  Both are
> failing.

So are there Crypto API test vectors for these algorithms and if so
are they succeeding or not? If they are working but your own vectors
going through your code isn't, then I would start looking there.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Did the in-kernel Camellia or CMAC crypto implementation break?

[David Howells]

Herbert Xu <herbert@gondor.apana.org.au> wrote:

> > I have them built into the kernel, both in sunrpc and my krb5 lib.  Both are
> > failing.
> 
> So are there Crypto API test vectors for these algorithms and if so
> are they succeeding or not? If they are working but your own vectors
> going through your code isn't, then I would start looking there.

krb5: Running camellia128-cts-cmac key
alg: No test for cmac(camellia) (cmac(camellia-asm))
krb5: Running camellia128-cts-cmac enc no plain
alg: No test for cts(cbc(camellia)) (cts(cbc-camellia-asm))

I'm guessing not.

Do you know if there is "standard" test data somewhere?  rfc3713 appendix A
has three but are there more?

David

Re: Did the in-kernel Camellia or CMAC crypto implementation break?

[Herbert Xu]

On Thu, Apr 13, 2023 at 07:36:25AM +0100, David Howells wrote:
.
> krb5: Running camellia128-cts-cmac key
> alg: No test for cmac(camellia) (cmac(camellia-asm))
> krb5: Running camellia128-cts-cmac enc no plain
> alg: No test for cts(cbc(camellia)) (cts(cbc-camellia-asm))
> 
> I'm guessing not.

Oh OK.

So when did these last work for you?

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Did the in-kernel Camellia or CMAC crypto implementation break?

[David Howells]

Herbert Xu <herbert@gondor.apana.org.au> wrote:

> So when did these last work for you?

Okay, this branch works:

	https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=rxrpc-rxgk

That's based on 5.10.0-rc4.  dmesg excerpt attached below.  This was before I
extracted the krb5 stuff out into its own lib.

On the other hand, I dug back through my crypto-krb5 branch to something based
on 5.16.0 and that doesn't work.

I can try forward porting my rxrpc-rxgk branch to try and find where it stops
working.

David
---
rxrpc: Running selftests
rxrpc: Running aes128-cts-hmac-sha256-128 prf
rxrpc: Running aes256-cts-hmac-sha384-192 prf
rxrpc: Running aes128-cts-hmac-sha256-128 key
rxrpc: Running aes256-cts-hmac-sha384-192 key
rxrpc: Running camellia128-cts-cmac key
alg: No test for cmac(camellia) (cmac(camellia-asm))
rxrpc: Running camellia256-cts-cmac key
rxrpc: Running aes128-cts-hmac-sha256-128 enc no plain
rxrpc: Running aes128-cts-hmac-sha256-128 enc plain<block
rxrpc: Running aes128-cts-hmac-sha256-128 enc plain==block
rxrpc: Running aes128-cts-hmac-sha256-128 enc plain>block
rxrpc: Running aes256-cts-hmac-sha384-192 enc no plain
rxrpc: Running aes256-cts-hmac-sha384-192 enc plain<block
rxrpc: Running aes256-cts-hmac-sha384-192 enc plain==block
rxrpc: Running aes256-cts-hmac-sha384-192 enc plain>block
rxrpc: Running camellia128-cts-cmac enc no plain
alg: No test for cts(cbc(camellia)) (cts(cbc-camellia-asm))
rxrpc: Running camellia128-cts-cmac enc 1 plain
rxrpc: Running camellia128-cts-cmac enc 1 plain
rxrpc: Running camellia128-cts-cmac enc 9 plain
rxrpc: Running camellia128-cts-cmac enc 13 plain
rxrpc: Running camellia128-cts-cmac enc 30 plain
rxrpc: Running camellia256-cts-cmac enc no plain
rxrpc: Running camellia256-cts-cmac enc 1 plain
rxrpc: Running camellia256-cts-cmac enc 9 plain
rxrpc: Running camellia256-cts-cmac enc 13 plain
rxrpc: Running camellia256-cts-cmac enc 30 plain
rxrpc: Running aes128-cts-hmac-sha256-128 mic
rxrpc: Running aes256-cts-hmac-sha384-192 mic
rxrpc: Running camellia128-cts-cmac mic abc
rxrpc: Running camellia128-cts-cmac mic ABC
rxrpc: Running camellia256-cts-cmac mic 123
rxrpc: Running camellia256-cts-cmac mic !@#
rxrpc: Selftests succeeded

Re: Did the in-kernel Camellia or CMAC crypto implementation break?

[David Howells]

Chuck Lever III <chuck.lever@oracle.com> wrote:

> Ah, I see Scott is Cc'd. Yes, Scott reported this to me yesterday.

Found it (see patch sent separately).  There was an uninitialised variable in
sunrpc.

The krb5lib problem was that I'd lost the byteswapping of the usage value in
the test data when I split it out of the net/rxrpc/ directory, e.g.:

@@ -167,7 +167,7 @@ const struct krb5_enc_test krb5_enc_tests[] = {
 		.plain	= "'1",
 		.conf	= "6F2FC3C2A166FD8898967A83DE9596D9",
 		.K0	= "5027BC231D0F3A9D23333F1CA6FDBE7C",
-		.usage	= 1,
+		.usage	= htonl(1),
 		.ct	= "842D21FD950311C0DD464A3F4BE8D6DA88A56D559C9B47D3F9A85067AF661559B8",
 	}, {
 		.krb5	= &krb5_camellia128_cts_cmac,

David

Re: Did the in-kernel Camellia or CMAC crypto implementation break?

[Herbert Xu]

On Thu, Apr 13, 2023 at 02:55:38PM +0100, David Howells wrote:
> 
> Found it (see patch sent separately).  There was an uninitialised variable in
> sunrpc.

Now that you have it working, perhaps you could convert some of
your test vectors into crypto API test vectors?

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Did the in-kernel Camellia or CMAC crypto implementation break?

[David Howells]

Herbert Xu <herbert@gondor.apana.org.au> wrote:

> Now that you have it working, perhaps you could convert some of
> your test vectors into crypto API test vectors?

Actually, I was wondering about that.  I see that all the testing data seems
to be statically loaded in testmgr.[ch], even if the algorithms to be tested
are resident in modules that aren't loaded yet (so it's kind of test "on
demand").  I guess it can't be split up amongst the algorithm modules as some
of the tests require stuff from multiple modules (eg. aes + cbs + cts).

If I'm going to do that, I presume I'd need to create an API akin to the
skcipher API or the hash API, say, to do autoload/create krb5 crypto.  Maybe
loading with something like:

	struct crypto_krb5 *alg;

	alg = crypto_alloc_krb5("aes256-cts-hmac-sha384-192", 0,
				CRYPTO_ALG_ASYNC);

and split the algorithms into separate modules?  Much of the code would still
end up in a common module, though.

Note that each algorithm can be asked to do four different things and has four
different types of test:

 - PRF calculation
 - Key derivation
 - Encryption/decryption
 - Checksum generation/verification

David

Re: Did the in-kernel Camellia or CMAC crypto implementation break?

[Herbert Xu]

On Fri, Apr 14, 2023 at 09:47:37AM +0100, David Howells wrote:
>
> Actually, I was wondering about that.  I see that all the testing data seems
> to be statically loaded in testmgr.[ch], even if the algorithms to be tested
> are resident in modules that aren't loaded yet (so it's kind of test "on
> demand").  I guess it can't be split up amongst the algorithm modules as some
> of the tests require stuff from multiple modules (eg. aes + cbs + cts).

Yes I've been meaning to split this up so they're colocated with
the generic implementation.

> If I'm going to do that, I presume I'd need to create an API akin to the
> skcipher API or the hash API, say, to do autoload/create krb5 crypto.  Maybe
> loading with something like:
> 
> 	struct crypto_krb5 *alg;
> 
> 	alg = crypto_alloc_krb5("aes256-cts-hmac-sha384-192", 0,
> 				CRYPTO_ALG_ASYNC);
> 
> and split the algorithms into separate modules?  Much of the code would still
> end up in a common module, though.

Unless this code has at least two users it's probably not worth
it (but there are exceptions, e.g. we did a one-user algorithm
for dm-crypt).

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Did the in-kernel Camellia or CMAC crypto implementation break?

[David Howells]

Herbert Xu <herbert@gondor.apana.org.au> wrote:

> > Actually, I was wondering about that.  I see that all the testing data
> > seems to be statically loaded in testmgr.[ch], even if the algorithms to
> > be tested are resident in modules that aren't loaded yet (so it's kind of
> > test "on demand").  I guess it can't be split up amongst the algorithm
> > modules as some of the tests require stuff from multiple modules (eg. aes
> > + cbs + cts).
> 
> Yes I've been meaning to split this up so they're colocated with
> the generic implementation.

Might be easier if I wait to see how you do that.

> Unless this code has at least two users it's probably not worth
> it (but there are exceptions, e.g. we did a one-user algorithm
> for dm-crypt).

There would be just two users at the moment: sunrpc/nfs and rxrpc/afs.  I
don't know if cifs or ceph could make use of it.

David

Re: Did the in-kernel Camellia or CMAC crypto implementation break?

[Herbert Xu]

On Fri, Apr 14, 2023 at 11:17:10AM +0100, David Howells wrote:
>
> There would be just two users at the moment: sunrpc/nfs and rxrpc/afs.  I
> don't know if cifs or ceph could make use of it.

Interesting.  Could you outline how this new interface would work?
And have you looked whether the aead interface could fit into your
model?

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Did the in-kernel Camellia or CMAC crypto implementation break?

[David Howells]

Herbert Xu <herbert@gondor.apana.org.au> wrote:

> Interesting.  Could you outline how this new interface would work?

I'll write up an API doc for my code as I have it working and post that.

> And have you looked whether the aead interface could fit into your
> model?

Do you mean use the aead API rather than inventing my own?  Looking at aead.h,
there aren't enough bits in it as it stands:

	struct aead_alg {
		int (*setkey)(struct crypto_aead *tfm, const u8 *key,
			      unsigned int keylen);
		int (*setauthsize)(struct crypto_aead *tfm, unsigned int authsize);
		int (*encrypt)(struct aead_request *req);
		int (*decrypt)(struct aead_request *req);
		int (*init)(struct crypto_aead *tfm);
		void (*exit)(struct crypto_aead *tfm);

		unsigned int ivsize;
		unsigned int maxauthsize;
		unsigned int chunksize;

		struct crypto_alg base;
	};

In krb5, for encryption, there are two keys, not one, and no IV to be passed
in.  The code I have will insert a confounder and a checksum, which must have
space allowed for it.

David

Re: Did the in-kernel Camellia or CMAC crypto implementation break?

[Herbert Xu]

On Fri, Apr 14, 2023 at 11:34:37AM +0100, David Howells wrote:
>
> In krb5, for encryption, there are two keys, not one, and no IV to be passed
> in.  The code I have will insert a confounder and a checksum, which must have
> space allowed for it.

Two keys is not an issue.  Authenc for example supports two keys
by encoding them into a single byte-stream.  AEAD also supports
having no IVs by providing IV generators (see seqiv, eseqiv, etc.).

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Did the in-kernel Camellia or CMAC crypto implementation break?

[David Howells]

Herbert Xu <herbert@gondor.apana.org.au> wrote:

> Could you outline how this new interface would work?

Attached is documentation for the API as I currently have it.

David
---
.. SPDX-License-Identifier: GPL-2.0

===========================
Kerberos V Cryptography API
===========================

.. Contents:

  - Overview.
    - Small Buffer.
  - Encoding Type.
  - Key Derivation.
    - PRF+ Calculation.
    - Kc, Ke And Ki Derivation.
  - Crypto Functions.
    - Encryption Mode.
    - Checksum Mode.

Overview
========

This API provides Kerberos 5-style cryptography for key derivation, encryption
and checksumming for use in network filesystems and can be used to implement
the low-level crypto that's needed for GSSAPI.

The following crypto types are supported::

	KRB5_ENCTYPE_AES128_CTS_HMAC_SHA1_96
	KRB5_ENCTYPE_AES256_CTS_HMAC_SHA1_96
	KRB5_ENCTYPE_AES128_CTS_HMAC_SHA256_128
	KRB5_ENCTYPE_AES256_CTS_HMAC_SHA384_192
	KRB5_ENCTYPE_CAMELLIA128_CTS_CMAC
	KRB5_ENCTYPE_CAMELLIA256_CTS_CMAC

	KRB5_CKSUMTYPE_HMAC_SHA1_96_AES128
	KRB5_CKSUMTYPE_HMAC_SHA1_96_AES256
	KRB5_CKSUMTYPE_CMAC_CAMELLIA128
	KRB5_CKSUMTYPE_CMAC_CAMELLIA256
	KRB5_CKSUMTYPE_HMAC_SHA256_128_AES128
	KRB5_CKSUMTYPE_HMAC_SHA384_192_AES256

The API can be included by::

	#include <crypto/krb5.h>

Small Buffer
------------

To pass small pieces of data about, such as keys, a buffer structure is
defined, giving a pointer to the data and the size of that data::

	struct krb5_buffer {
		unsigned int	len;
		void		*data;
	};

Encoding Type
=============

The encoding type is defined by the following structure::

	struct krb5_enctype {
		int		etype;
		int		ctype;
		const char	*name;
		u16		key_bytes;
		u16		key_len;
		u16		Kc_len;
		u16		Ke_len;
		u16		Ki_len;
		u16		prf_len;
		u16		block_len;
		u16		conf_len;
		u16		cksum_len;
		bool		pad;
		...
	};

The fields of interest to the user of the API are as follows:

  * ``etype`` and ``ctype`` indicate the protocol number for this encoding
    type for encryption and checksumming respectively.  They hold
    ``KRB5_ENCTYPE_*`` and ``KRB5_CKSUMTYPE_*`` constants.

  * ``name`` is the formal name of the encoding.

  * ``key_len`` and ``key_bytes`` are the input key length and the derived key
    length.  (I think they only differ for DES, which isn't supported here).

  * ``Kc_len``, ``Ke_len`` and ``Ki_len`` are the sizes of the derived Kc, Ke
    and Ki keys.  Kc is used for in checksum mode; Ke and Ki are used in
    encryption mode.

  * ``prf_len`` is the size of the result from the PRF+ function calculation.

  * ``block_len``, ``conf_len`` and ``cksum_len`` are the encryption block
    length, confounder length and checksum length respectively.  All three are
    used in encryption mode, but only the checksum length is used in checksum
    mode.

The encoding type is looked up by number using the following function::

	const struct krb5_enctype *crypto_krb5_find_enctype(u32 enctype);

Key Derivation
==============

Once the application has selected an encryption type, the keys that will be
used to do the actual crypto can be derived from the transport key.

PRF+ Calculation
----------------

To aid in key derivation, a function to calculate the Kerberos GSSAPI
mechanism's PRF+ is provided::

	int crypto_krb5_calc_PRFplus(const struct krb5_enctype *krb5,
				     const struct krb5_buffer *K,
				     unsigned int L,
				     const struct krb5_buffer *S,
				     struct krb5_buffer *result,
				     gfp_t gfp);

This can be used to derive the transport key from a source key plus additional
data to limit its use.

Kc, Ke And Ki Derivation
------------------------

To do actual crypto on messages, three keys can be derived: *Kc*, used in
checksum-only mode, and *Ke* and *Ki* which are used in encryption mode for
encryption and the integrity hash.  Three functions are provided to derive
these keys from the transport key::

	int crypto_krb5_get_Kc(const struct krb5_enctype *krb5,
			       const struct krb5_buffer *TK,
			       u32 usage,
			       struct krb5_buffer *key,
			       struct crypto_shash **_shash,
			       gfp_t gfp);
	int crypto_krb5_get_Ke(const struct krb5_enctype *krb5,
			       const struct krb5_buffer *TK,
			       u32 usage,
			       struct krb5_buffer *key,
			       struct crypto_sync_skcipher **_ci,
			       gfp_t gfp);
	int crypto_krb5_get_Ki(const struct krb5_enctype *krb5,
			       const struct krb5_buffer *TK,
			       u32 usage,
			       struct krb5_buffer *key,
			       struct crypto_shash **_shash,
			       gfp_t gfp);

In all cases, ``krb5`` is the encoding type, ``TK`` is the transport key,
``usage`` indicates the use to which the keys will be put, ``key`` is the
prepared output buffer for the raw key and ``gfp`` are flags to control any
allocation performated.

For Kc and Ki, ``_shash`` points to where the prepared and keyed hash context
should be returned and for Ke, ``_ci`` points to where the prepared and keyed
cipher should be returned.  These will need to be passed into the crypto
functions.

For use with the encrypt/decrypt functions, a struct is provided to hold the
Ke skcipher and Ki shash::

	struct krb5_enc_keys {
		struct crypto_sync_skcipher	*Ke;
		struct crypto_shash		*Ki;
	};

and this can be cleaned up with::

	void crypto_krb5_free_enc_keys(struct krb5_enc_keys *e);

Crypto Functions
================

Once the keys have been derived, crypto can be performed on the data.  The
caller must leave gaps in the buffer for the storage of the confounder (if
needed) and the checksum when preparing a message for transmission.  An enum
and two functions are provided to aid in this::

	enum krb5_crypto_mode {
		KRB5_CHECKSUM_MODE,
		KRB5_ENCRYPT_MODE,
	};

	size_t crypto_krb5_how_much_buffer(const struct krb5_enctype *krb5,
					   enum krb5_crypto_mode mode, bool pad,
					   size_t data_size, size_t *_offset);

	size_t crypto_krb5_how_much_data(const struct krb5_enctype *krb5,
					 enum krb5_crypto_mode mode, bool pad,
					 size_t *_buffer_size, size_t *_offset);

Both functions take the encoding type, an indication the mode of crypto
(checksum-only or full encryption) and an indication if padding is going to be
required by the application.

The first function returns how big the buffer will need to be to house a given
amount of data; the second function returns how much data will fit in a buffer
of a particular size, and adjusts down the size of the required buffer
accordingly.  In both cases, the offset of the data within the buffer is also
returned.

When a message has been received, the location and size of the data can be
determined by calling::

	size_t crypto_krb5_where_is_the_data(const struct krb5_enctype *krb5,
					     size_t *_offset, size_t len);

This returns the size of the data (plus any padding) and the offset of the
data.  It is up to the caller to determine how much padding there is.


Encryption Mode
---------------

A pair of functions are provided to encrypt and decrypt a message::

	ssize_t crypto_krb5_encrypt(const struct krb5_enctype *krb5,
				    struct krb5_enc_keys *keys,
				    struct scatterlist *sg, unsigned int nr_sg,
				    size_t sg_len,
				    size_t data_offset, size_t data_len,
				    bool preconfounded);
	int crypto_krb5_decrypt(const struct krb5_enctype *krb5,
				struct krb5_enc_keys *keys,
				struct scatterlist *sg, unsigned int nr_sg,
				size_t *_offset, size_t *_len,
				int *_error_code);

In both cases, the input and output buffers are indicated by the same
scatterlist.

For the encryption function, the output buffer may be larger than is needed
(the amount of output generated is returned) and the location and size of the
data are indicated (which must match the encoding).  If no confounder is set,
the function will insert one.

For the decryption function, the offset and length of the message in buffer
are supplied and these are shrunk to fit the data.  If a decryption failure
occurs, a kerberos 5 error code is indicated.

Checksum Mode
-------------

A pair of function are provided to generate the checksum on a message and to
verify that checksum::

	ssize_t crypto_krb5_get_mic(const struct krb5_enctype *krb5,
				    struct crypto_shash *shash,
				    const struct krb5_buffer *metadata,
				    struct scatterlist *sg, unsigned int nr_sg,
				    size_t sg_len,
				    size_t data_offset, size_t data_len);
	int crypto_krb5_verify_mic(const struct krb5_enctype *krb5,
				   struct crypto_shash *shash,
				   const struct krb5_buffer *metadata,
				   struct scatterlist *sg, unsigned int nr_sg,
				   size_t *_offset, size_t *_len,
				   int *_error_code);

In both cases, the input and output buffers are indicated by the same
scatterlist.  Additional metadata can be passed in which will get added to the
hash before the data.

For the get_mic function, the output buffer may be larger than is needed (the
amount of output generated is returned) and the location and size of the data
are indicated (which must match the encoding).

For the verification function, the offset and length of the message in buffer
are supplied and these are shrunk to fit the data.  If a verification failure
occurs, a kerberos 5 error code is indicated.

Re: Did the in-kernel Camellia or CMAC crypto implementation break?

[David Howells]

Herbert Xu <herbert@gondor.apana.org.au> wrote:

> > Actually, I was wondering about that.  I see that all the testing data seems
> > to be statically loaded in testmgr.[ch], even if the algorithms to be tested
> > are resident in modules that aren't loaded yet (so it's kind of test "on
> > demand").  I guess it can't be split up amongst the algorithm modules as some
> > of the tests require stuff from multiple modules (eg. aes + cbs + cts).
> 
> Yes I've been meaning to split this up so they're colocated with
> the generic implementation.

I don't suppose you have anything to look at for this?  Should I leave my
testing stuff as it is for now until you've attempted this?

David