On Tue, Dec 01, 2020 at 09:12:38AM +, David Howells wrote:
>
> That depends on whether the caller has passed it elsewhere for some other
> parallel purpose, but I think I'm going to have to go down that road and
> restore it afterwards.
Sure but even if you added it to the API the underlying
Herbert Xu wrote:
> Couldn't you just change the output sg to include the offset?
That depends on whether the caller has passed it elsewhere for some other
parallel purpose, but I think I'm going to have to go down that road and
restore it afterwards.
David
On Tue, Dec 01, 2020 at 08:44:33AM +, David Howells wrote:
> Btw, would it be feasible to make it so that an extra parameter can be added
> to the cipher buffer-supplying functions, e.g.:
>
> skcipher_request_set_crypt(req, input, ciphertext_sg, esize, iv);
>
> such that we can pass in
Btw, would it be feasible to make it so that an extra parameter can be added
to the cipher buffer-supplying functions, e.g.:
skcipher_request_set_crypt(req, input, ciphertext_sg, esize, iv);
such that we can pass in an offset into the output sg as well?
David
On Thu, Nov 26, 2020 at 08:19:41AM +, David Howells wrote:
>
> I haven't done that yet. Sorry, I should've been more explicit with what I
> was after. I was wanting to find out if the nfs/nfsd people are okay with
> this (and if there are any gotchas I should know about - it turns out, if I
>
Herbert Xu wrote:
> > Here's my first cut at a generic Kerberos crypto library in the kernel so
> > that I can share code between rxrpc and sunrpc (and cifs?).
>
> I can't find the bit where you are actually sharing this code with
> sunrpc, am I missing something?
I haven't done that yet. Sorr
On Thu, Nov 12, 2020 at 12:57:45PM +, David Howells wrote:
>
> Hi Herbert, Bruce,
>
> Here's my first cut at a generic Kerberos crypto library in the kernel so
> that I can share code between rxrpc and sunrpc (and cifs?).
Hi David:
I can't find the bit where you are actually sharing this co
> On Nov 12, 2020, at 4:07 PM, Bruce Fields wrote:
>
> On Thu, Nov 12, 2020 at 04:54:06PM +, David Howells wrote:
>> Chuck Lever wrote:
>>
>>> Really? My understanding of the Linux kernel SUNRPC implementation is
>>> that it uses asynchronous, even for small data items. Maybe I'm using
>
On Thu, Nov 12, 2020 at 04:54:06PM +, David Howells wrote:
> Chuck Lever wrote:
>
> > Really? My understanding of the Linux kernel SUNRPC implementation is
> > that it uses asynchronous, even for small data items. Maybe I'm using
> > the terminology incorrectly.
>
> Seems to be synchronous,
> On Nov 12, 2020, at 1:37 PM, J. Bruce Fields wrote:
>
> On Thu, Nov 12, 2020 at 12:57:45PM +, David Howells wrote:
>>
>> Hi Herbert, Bruce,
>>
>> Here's my first cut at a generic Kerberos crypto library in the kernel so
>> that I can share code between rxrpc and sunrpc (and cifs?).
>>
On Thu, Nov 12, 2020 at 12:57:45PM +, David Howells wrote:
>
> Hi Herbert, Bruce,
>
> Here's my first cut at a generic Kerberos crypto library in the kernel so
> that I can share code between rxrpc and sunrpc (and cifs?).
>
> I derived some of the parts from the sunrpc gss library and added
Chuck Lever wrote:
> Really? My understanding of the Linux kernel SUNRPC implementation is
> that it uses asynchronous, even for small data items. Maybe I'm using
> the terminology incorrectly.
Seems to be synchronous, at least in its use of skcipher:
grep -e skcipher *
gss_krb5_crypto.c:#inclu
> On Nov 12, 2020, at 10:42 AM, David Howells wrote:
>
> Chuck Lever wrote:
>
>>> There are three main interfaces to it:
>>>
>>> (*) I/O crypto: encrypt, decrypt, get_mic and verify_mic.
>>>
>>>These all do in-place crypto, using an sglist to define the buffer
>>>with the data in i
Chuck Lever wrote:
> > There are three main interfaces to it:
> >
> > (*) I/O crypto: encrypt, decrypt, get_mic and verify_mic.
> >
> > These all do in-place crypto, using an sglist to define the buffer
> > with the data in it. Is it necessary to make it able to take separate
> > i
> On Nov 12, 2020, at 7:57 AM, David Howells wrote:
>
>
> Hi Herbert, Bruce,
>
> Here's my first cut at a generic Kerberos crypto library in the kernel so
> that I can share code between rxrpc and sunrpc (and cifs?).
>
> I derived some of the parts from the sunrpc gss library and added more
Would it be possible/practical to make the skcipher encrypt functions take an
offset into the scatterlist rather than always starting at the beginning?
David
Hi Herbert, Bruce,
Here's my first cut at a generic Kerberos crypto library in the kernel so
that I can share code between rxrpc and sunrpc (and cifs?).
I derived some of the parts from the sunrpc gss library and added more
advanced AES and Camellia crypto. I haven't ported across the DES-base
17 matches
Mail list logo
