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]
Message-Id: <274D6476-E37F-4110-BAA5-5B5CE0B63BE9@bytedance.com>
Date:   Thu, 30 Jun 2022 20:44:18 +0800
From:   Lei He <helei.sig11@...edance.com>
To:     Herbert Xu <herbert@...dor.apana.org.au>
Cc:     Lei He <helei.sig11@...edance.com>, davem@...emloft.net,
        dhowells@...hat.com, "Michael S. Tsirkin" <mst@...hat.com>,
        linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
        "Daniel P . Berrangé" <berrange@...hat.com>,
        zhenwei pi <pizhenwei@...edance.com>
Subject: Re:  [PATCH v2 0/4] virtio-crypto: support ECDSA algorithm

On Jun 30, 2022, at 5:07 PM, Herbert Xu <herbert@...dor.apana.org.au> wrote:

> 
> On Thu, Jun 30, 2022 at 04:30:39PM +0800, Lei He wrote:
>> 
>> I have explained above why we need a driver that supports ECDSA, and this patch
>> enables virtio-crypto to support ECDSA. I think this is a good time to support ECDSA
>> in the kernel crypto framework, and there will be more drivers supporting ECDSA in the 
>> future.
>> Looking forward to your opinion :-).
> 
> Until there are drivers in the kernel it's pointless to implement
> this.
> 

I guess you mean that if there are no drivers in the linux kernel source tree that supports the 
ECDSA, then there is no way under linux to offload ECDSA to other devices, so even if the
virtio-crypto can get the akcipher request, it can’t do better, right? I have some different opinions
 on this:
1. There does exist hardware for offloading ECDSA calculations, for example, IBM PCIe
Cryptographic Coprocessor, Intel QAT, etc, and those chips are already on the market now.
Of course, they also provided corresponding drivers to access these devices, but for some reason,
these drivers have not been submitted to the kernel source tree now.
2. With this patch, when we use QEMU to create a virtual machine, people can directly access the 
virtio-crypto device without caring about where these akcipher requests are executed, and no need
to update drivers(and other stuff) for guest kernel when the  co-processor is updated. 
3.  I will communicate with the Intel QAT team about their plans to provide ECDSA support and ECDH 
support.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ