lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 30 Jun 2022 20:43:37 +0800
From:   Lei He <helei.sig11@...edance.com>
To:     "Daniel P. Berrangé" <berrange@...hat.com>
Cc:     Lei He <helei.sig11@...edance.com>,
        Herbert Xu <herbert@...dor.apana.org.au>, davem@...emloft.net,
        dhowells@...hat.com, "Michael S. Tsirkin" <mst@...hat.com>,
        linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
        pizhenwei@...edance.com
Subject: Re: [PATCH v2 0/4] virtio-crypto: support ECDSA algorithm

On Jun 30, 2022, at 5:48 PM, Daniel P. Berrangé <berrange@...hat.com> wrote:
> 
> On Thu, Jun 30, 2022 at 03:23:39PM +0800, Lei He wrote:
>> 
>>> On Jun 30, 2022, at 2:59 PM, Herbert Xu <herbert@...dor.apana.org.au> wrote:
>>> 
>>> On Thu, Jun 23, 2022 at 03:05:46PM +0800, Lei He wrote:
>>>> From: lei he <helei.sig11@...edance.com>
>>>> 
>>>> This patch supports the ECDSA algorithm for virtio-crypto.
>>> 
>>> Why is this necessary?
>>> 
>> 
>> The main purpose of this patch is to offload ECDSA computations to virtio-crypto dev.
>> We can modify the backend of virtio-crypto to allow hardware like Intel QAT cards to 
>> perform the actual calculations, and user-space applications such as HTTPS server 
>> can access those backend in a unified way(eg, keyctl_pk_xx syscall).
>> 
>> Related works are also described in following patch series:
>> https://lwn.net/ml/linux-crypto/20220525090118.43403-1-helei.sig11@bytedance.com/
> 
> IIUC, this link refers to testing performance of the RSA impl of
> virtio-crypto with a vhost-user backend, leveraging an Intel QAT
> device on the host. What's the status of that depolyment setup ?
> Is code for it published anywhere, and does it have dependancy on
> any kernel patches that are not yet posted and/or merged ? Does it
> cover both ECDSA and RSA yet, or still only RSA ?
> 
> The QEMU backend part of the virtio-crypto support for ECDSA looks fine
> to merge, but obviously I'd like some positive sign that the kernel
> maintainers are willing to accept the guest driver side.
> 

1. We have now been able to provide offload capability for nginx’s TLS handshake in the virtual
machine(with the kctl-engine), and have achieved	about 0.8~0.9 times performance improvement. 
But as you can see, when we were testing, both authentication and key exchange only supported 
RSA at the moment. 
2. The code for the QAT offload backend is not posted now, it does not support the ECDSA, so it also does not 
depends on any other patches that have not been merged. To support ECDSA, this patch is required.
At present, I have only implemented and tested the ECDSA for the builtin backend, and the ECDSA support
for another backend that can offload is also in progress.

By the way,  the virtio part of QEMU( for support ECDSA)  is also ready,  I will post it soon.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ