Hi Tudor -
On Mon, 2 Oct 2017, Tudor Ambarus wrote:
Hi, all,
On 08/10/2017 09:39 AM, Stephan Müller wrote:
Hi,
This patch set adds the AF_ALG user space API to externalize the
asymmetric cipher API recently added to the kernel crypto API.
Do we have enough pros and cons so we can decide w
Hi, all,
On 08/10/2017 09:39 AM, Stephan Müller wrote:
Hi,
This patch set adds the AF_ALG user space API to externalize the
asymmetric cipher API recently added to the kernel crypto API.
Do we have enough pros and cons so we can decide which interface to use
for exporting akcipher/kpp to user
Hi Tudor,
>> you still need to get the public key out of the kernel if you want to use it
>> from user space. Or feed the remote public key if you plan to use some sort
>> of key derivation function.
>
> The crypto hardware that I'm working on, generates the private key
> internally within the
Hi, Marcel,
On 08/30/2017 10:21 AM, Marcel Holtmann wrote:
you still need to get the public key out of the kernel if you want to use it
from user space. Or feed the remote public key if you plan to use some sort of
key derivation function.
The crypto hardware that I'm working on, generates
Hi Tudor,
> akcipher can work with its own internal keys, now that we have crypto
> accelerators that can generate keys that never leave the hardware. Going
> through the kernel's key subsystem seems superfluous in this case.
>
> I also understand the need of going through the kernel's key subsys
Hi, Herbert, all,
akcipher can work with its own internal keys, now that we have crypto
accelerators that can generate keys that never leave the hardware. Going
through the kernel's key subsystem seems superfluous in this case.
I also understand the need of going through the kernel's key subsyst
Hi, all,
On 08/11/2017 07: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
socket for a
Hi Stephan,
>>> The first part is clearly where AF_ALG fits and keyctl does not. This is
>>> provided with the current patch set. As the keyctl API only handles, well,
>>> keys, access to the raw ciphers may not be possible through this API. And
>>> let us face it, a lot of user space code shall s
Am Montag, 14. August 2017, 08:26:22 CEST schrieb Marcel Holtmann:
Hi Marcel,
> > The first part is clearly where AF_ALG fits and keyctl does not. This is
> > provided with the current patch set. As the keyctl API only handles, well,
> > keys, access to the raw ciphers may not be possible through
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)
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
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
>
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 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
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
On Fri, 11 Aug 2017, Andrew Zaborowski wrote:
HI,
On 11 August 2017 at 02:48, Mat Martineau
wrote:
The last round of reviews for AF_ALG akcipher left off at an impasse around
a year ago: the consensus was that hardware key support was needed, but that
requirement was in conflict with the "al
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
>> socket for a brief time to do one verify or encrypt operatio
Hi Stephan,
>>> The last round of reviews for AF_ALG akcipher left off at an impasse
>>> around a year ago: the consensus was that hardware key support was
>>> needed, but that requirement was in conflict with the "always have a
>>> software fallback" rule for the crypto subsystem. For example, a
HI,
On 11 August 2017 at 02:48, Mat Martineau
wrote:
> The last round of reviews for AF_ALG akcipher left off at an impasse around
> a year ago: the consensus was that hardware key support was needed, but that
> requirement was in conflict with the "always have a software fallback" rule
> for the
Am Freitag, 11. August 2017, 02:48:37 CEST schrieb Mat Martineau:
Hi Mat,
>
> 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
Am Freitag, 11. August 2017, 07:13:30 CEST schrieb Marcel Holtmann:
Hi Marcel,
> >
> > The last round of reviews for AF_ALG akcipher left off at an impasse
> > around a year ago: the consensus was that hardware key support was
> > needed, but that requirement was in conflict with the "always hav
Hi Mat,
>> This patch set adds the AF_ALG user space API to externalize the
>> asymmetric cipher API recently added to the kernel crypto API.
>
> ...
>
>> Changes v8:
>> * port to kernel 4.13
>> * port to consolidated AF_ALG code
>>
>> Stephan Mueller (4):
>> crypto: AF_ALG -- add sign/verify A
Hi Stephan,
On Thu, 10 Aug 2017, Stephan Müller wrote:
Hi,
This patch set adds the AF_ALG user space API to externalize the
asymmetric cipher API recently added to the kernel crypto API.
...
Changes v8:
* port to kernel 4.13
* port to consolidated AF_ALG code
Stephan Mueller (4):
crypto
23 matches
Mail list logo