[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOq732Lgh=Nca4_7QaN4F1ddSg-AX919_un4wSxyv5gU0PvqQw@mail.gmail.com>
Date: Fri, 17 Jun 2016 02:39:39 +0200
From: Andrew Zaborowski <balrogg@...glemail.com>
To: Stephan Mueller <smueller@...onox.de>
Cc: Mat Martineau <mathew.j.martineau@...ux.intel.com>,
Tadeusz Struk <tadeusz.struk@...el.com>,
David Howells <dhowells@...hat.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
linux-api@...r.kernel.org, Marcel Holtmann <marcel@...tmann.org>,
linux-kernel@...r.kernel.org, keyrings@...r.kernel.org,
Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
David Woodhouse <dwmw2@...radead.org>, davem@...emloft.net
Subject: Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface
Hi Stephan,
On 16 June 2016 at 17:38, Stephan Mueller <smueller@...onox.de> wrote:
>> This isn't an issue with AF_ALG, I should have changed the subject
>> line perhaps. In this case it's an inconsistency between some
>> implementations and the documentation (header comment). It affects
>> users accessing the cipher through AF_ALG but also directly.
>
> As I want to send a new version of the algif_akcipher shortly now (hoping for
> an inclusion into 4.8), is there anything you see that I should prepare for
> regarding this issue? I.e. do you forsee a potential fix that would change the
> API or ABI of algif_akcipher?
No, as far as I understand algif_akcipher will do the right thing now
if the algorithm does the right thing. It's only the two RSA drivers
that would need to align with the software RSA in what buffer length
they accept.
Best regards
Powered by blists - more mailing lists