Re: [PATCH v2 3/4] crypto: ecdsa - Fix enc/dec size reported by KEYCTL_PKEY_QUERY

[Lukas Wunner <lukas@wunner.de>]

On Sun, Feb 16, 2025 at 12:19:44PM +0800, Herbert Xu wrote:
> On Mon, Feb 10, 2025 at 07:53:57PM +0100, Lukas Wunner wrote:
> > > > https://git.kernel.org/pub/scm/libs/ell/ell.git/tree/ell/key.c
> > > > https://git.kernel.org/pub/scm/network/wireless/iwd.git/tree/src/eap-tls.c
> > > 
> > > Surely this doesn't use the private key part of the API, does it?
> > 
> > It does use the private key part:
> > 
> > It takes advantage of the kernel's Key Retention Service for EAP-TLS,
> > which generally uses mutual authentication.  E.g. clients authenticate
> > against a wireless hotspot.  Hence it does invoke KEYCTL_PKEY_SIGN and
> > KEYCTL_PKEY_ENCRYPT (with private keys, obviously).
> 
> Does it really? I grepped the whole iwd git tree and the only
> use of private key functionality is to check that it matches
> the public key, IOW it encrypts a piece of text and then decrypts
> it again to check whether they match.
> 
> It doesn't make use of any other private key functionality AFAICS.

__eap_handle_request()                            [iwd src/eap.c]
  eap->method->handle_request()
    eap_tls_common_handle_request()               [iwd src/eap-tls-common.c]
      l_tls_handle_rx()                           [ell ell/tls-record.c]
        tls_handle_ciphertext()
          tls_handle_plaintext()
            tls_handle_message()                  [ell ell/tls.c]
              tls_handle_handshake()
                tls_handle_server_hello_done()
                  tls_send_certificate_verify()
                    tls->pending.cipher_suite->signature->sign
                      tls_rsa_sign()              [ell ell/tls-suites.c]
                        l_key_sign()              [ell ell/key.c]
                          eds_common()
                            kernel_key_eds()
                              syscall(__NR_keyctl, KEYCTL_PKEY_SIGN, ...)

... where tls_handle_server_hello_done() performs client authentication
per RFC 8446 sec 4.6.2:

  "When the client has sent the "post_handshake_auth" extension (see
   Section 4.2.6), a server MAY request client authentication at any
   time after the handshake has completed by sending a
   CertificateRequest message.  The client MUST respond with the
   appropriate Authentication messages (see Section 4.4).  If the client
   chooses to authenticate, it MUST send Certificate, CertificateVerify,
   and Finished."

   https://datatracker.ietf.org/doc/html/rfc8446#section-4.6.2

I think the best option at this point isn't to aim for removal
but to wait for Cloudflare to beat their out-of-tree implementation
(which apparently isn't susceptible to side channel attacks)
into shape so that it can be upstreamed.

Thanks,

Lukas