On Fri, Aug 11, 2017 at 7:05 PM, Marcel Holtmann wrote:
> Hi Stephan,
>
>>> AF_ALG is best suited for crypto use cases where a socket is set up once
>>> and there are lots of reads and writes to justify the setup cost. With
>>> asymmetric crypto, the setup cost is high when you might only use the
platform_device_id are not supposed to change at runtime. All functions
working with platform_device_id provided by
work with const platform_device_id. So mark the non-const structs as
const.
Signed-off-by: Arvind Yadav
---
drivers/crypto/sahara.c | 2 +-
1 file changed, 1 insertion(+), 1 delet
Showing only the key parts of the message:
> From: John Gilmore
An exceedingly knowledgeable guy, one we should probably take seriously.
https://en.wikipedia.org/wiki/John_Gilmore_(activist)
> Most hardware crypto accelerators are useless, ...
> ... you might as well have
> just computed the an
Am Sonntag, 13. August 2017, 10:52:00 CEST schrieb Gilad Ben-Yossef:
Hi Gilad,
> While I don't have anything to contribute to the choice between
> keyctl() vs ALG_IF as interfaces for asymmetric cryptography, I would
> like to point out that there is both interest and HW support for
> private sy
Am Freitag, 11. August 2017, 21:43:15 CEST schrieb Mat Martineau:
Hi Mat,
>
> I also would like to have more of those algorithms exposed to userspace,
> and I'd like to make sure the API is a good fit. There was extensive
> discussion of AF_ALG akcipher last year. v8 of the patch set updates the
Am Freitag, 11. August 2017, 18:02:55 CEST schrieb Marcel Holtmann:
Hi Marcel,
> > Thanks for the reminder. I have looked at that but I am unsure about
> > whether this one covers asym crypto appropriately, too.
> >
> > The issue is that some hardware may only offer accelerators without a full
>
Hi Stephan,
>> I also would like to have more of those algorithms exposed to userspace,
>> and I'd like to make sure the API is a good fit. There was extensive
>> discussion of AF_ALG akcipher last year. v8 of the patch set updates the
>> implementation but doesn't address the API concerns that ke
Hi Stephan,
>>> Thanks for the reminder. I have looked at that but I am unsure about
>>> whether this one covers asym crypto appropriately, too.
>>>
>>> The issue is that some hardware may only offer accelerators without a full
>>> blown RSA siggen/ver logic (that pulls in PKCS or OAEP or others)
