On 01/22/2015 02:23 PM, Herbert Xu wrote:
> Yes but we should also fix this so that it's a proper aead
> algorithm.
Ok, I'll do that.
Thanks,
Tadeusz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info
On Thu, Jan 22, 2015 at 10:23:57AM -0800, Tadeusz Struk wrote:
>
> No, I thought that the agreement was that we don't want to allow user
> space to use these helpers directly, right? Am I missing something?
Yes but we should also fix this so that it's a proper aead
algorithm.
Cheers,
--
Email:
On 01/22/2015 01:20 PM, Stephan Mueller wrote:
> That would be correct. But if I understood Herbert correctly, he is
> creating a patch that disables these service ciphers for general usage.
Yes, and this should also implicitly fix the problem with user space.
Thanks,
Tadeusz
--
To unsubscribe
Am Donnerstag, 22. Januar 2015, 10:23:57 schrieb Tadeusz Struk:
Hi Tadeusz,
>On 01/20/2015 05:25 PM, Stephan Mueller wrote:
>>> Rather than adding a bogus setkey function, please fix this mess
>>> properly by moving the top-level setkey function into the __driver
>>> one where it should be.
On 01/20/2015 05:25 PM, Stephan Mueller wrote:
>> Rather than adding a bogus setkey function, please fix this mess
>> properly by moving the top-level setkey function into the __driver
>> one where it should be. Compare with how we handle it in the
>> ablk_helper which is pretty much the same
On Thu, Jan 22, 2015 at 10:23:57AM -0800, Tadeusz Struk wrote:
No, I thought that the agreement was that we don't want to allow user
space to use these helpers directly, right? Am I missing something?
Yes but we should also fix this so that it's a proper aead
algorithm.
Cheers,
--
Email:
On 01/22/2015 01:20 PM, Stephan Mueller wrote:
That would be correct. But if I understood Herbert correctly, he is
creating a patch that disables these service ciphers for general usage.
Yes, and this should also implicitly fix the problem with user space.
Thanks,
Tadeusz
--
To unsubscribe
On 01/22/2015 02:23 PM, Herbert Xu wrote:
Yes but we should also fix this so that it's a proper aead
algorithm.
Ok, I'll do that.
Thanks,
Tadeusz
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On 01/20/2015 05:25 PM, Stephan Mueller wrote:
Rather than adding a bogus setkey function, please fix this mess
properly by moving the top-level setkey function into the __driver
one where it should be. Compare with how we handle it in the
ablk_helper which is pretty much the same thing.
Am Donnerstag, 22. Januar 2015, 10:23:57 schrieb Tadeusz Struk:
Hi Tadeusz,
On 01/20/2015 05:25 PM, Stephan Mueller wrote:
Rather than adding a bogus setkey function, please fix this mess
properly by moving the top-level setkey function into the __driver
one where it should be. Compare with
Am Dienstag, 20. Januar 2015, 14:17:04 schrieb Herbert Xu:
Hi Tadeusz,
> On Sun, Jan 18, 2015 at 11:56:03PM +0100, Stephan Mueller wrote:
> > The cipher registered as __driver-gcm-aes-aesni is never intended
> > to be used directly by any caller. Instead it is a service mechanism to
> >
Am Dienstag, 20. Januar 2015, 14:17:04 schrieb Herbert Xu:
Hi Tadeusz,
On Sun, Jan 18, 2015 at 11:56:03PM +0100, Stephan Mueller wrote:
The cipher registered as __driver-gcm-aes-aesni is never intended
to be used directly by any caller. Instead it is a service mechanism to
On Tue, Jan 20, 2015 at 04:54:44AM +0100, Stephan Mueller wrote:
>
> How would the fail manifest itself? If algif_aead would be present, user
> space could use the __driver implementation regardless of a setkey or
> authsize callback by simply calling encrypt/decrypt. Would the error be
>
Am Dienstag, 20. Januar 2015, 14:37:05 schrieb Herbert Xu:
Hi Herbert,
>On Tue, Jan 20, 2015 at 04:35:41AM +0100, Stephan Mueller wrote:
>> This in turn would then turn the __driver implementation into a full
>> GCM implementation. That would mean that we should rename it from
>> __driver into
On Tue, Jan 20, 2015 at 04:35:41AM +0100, Stephan Mueller wrote:
>
> This in turn would then turn the __driver implementation into a full GCM
> implementation. That would mean that we should rename it from __driver
> into gcm(aes) / gcm-aesni.
No you shouldn't because it'll fail in interrupt
Am Dienstag, 20. Januar 2015, 14:17:04 schrieb Herbert Xu:
Hi Herbert,
>On Sun, Jan 18, 2015 at 11:56:03PM +0100, Stephan Mueller wrote:
>> The cipher registered as __driver-gcm-aes-aesni is never intended
>> to be used directly by any caller. Instead it is a service mechanism
>> to
On Sun, Jan 18, 2015 at 11:56:03PM +0100, Stephan Mueller wrote:
> The cipher registered as __driver-gcm-aes-aesni is never intended
> to be used directly by any caller. Instead it is a service mechanism to
> rfc4106-gcm-aesni.
>
> The kernel crypto API unconditionally calls the registered setkey
On 01/18/2015 02:56 PM, Stephan Mueller wrote:
> The cipher registered as __driver-gcm-aes-aesni is never intended
> to be used directly by any caller. Instead it is a service mechanism to
> rfc4106-gcm-aesni.
>
> The kernel crypto API unconditionally calls the registered setkey
> function. In
On Sun, Jan 18, 2015 at 11:56:03PM +0100, Stephan Mueller wrote:
The cipher registered as __driver-gcm-aes-aesni is never intended
to be used directly by any caller. Instead it is a service mechanism to
rfc4106-gcm-aesni.
The kernel crypto API unconditionally calls the registered setkey
On Tue, Jan 20, 2015 at 04:54:44AM +0100, Stephan Mueller wrote:
How would the fail manifest itself? If algif_aead would be present, user
space could use the __driver implementation regardless of a setkey or
authsize callback by simply calling encrypt/decrypt. Would the error be
limited to
Am Dienstag, 20. Januar 2015, 14:37:05 schrieb Herbert Xu:
Hi Herbert,
On Tue, Jan 20, 2015 at 04:35:41AM +0100, Stephan Mueller wrote:
This in turn would then turn the __driver implementation into a full
GCM implementation. That would mean that we should rename it from
__driver into gcm(aes)
On Tue, Jan 20, 2015 at 04:35:41AM +0100, Stephan Mueller wrote:
This in turn would then turn the __driver implementation into a full GCM
implementation. That would mean that we should rename it from __driver
into gcm(aes) / gcm-aesni.
No you shouldn't because it'll fail in interrupt
Am Dienstag, 20. Januar 2015, 14:17:04 schrieb Herbert Xu:
Hi Herbert,
On Sun, Jan 18, 2015 at 11:56:03PM +0100, Stephan Mueller wrote:
The cipher registered as __driver-gcm-aes-aesni is never intended
to be used directly by any caller. Instead it is a service mechanism
to rfc4106-gcm-aesni.
On 01/18/2015 02:56 PM, Stephan Mueller wrote:
The cipher registered as __driver-gcm-aes-aesni is never intended
to be used directly by any caller. Instead it is a service mechanism to
rfc4106-gcm-aesni.
The kernel crypto API unconditionally calls the registered setkey
function. In case a
The cipher registered as __driver-gcm-aes-aesni is never intended
to be used directly by any caller. Instead it is a service mechanism to
rfc4106-gcm-aesni.
The kernel crypto API unconditionally calls the registered setkey
function. In case a caller erroneously uses __driver-gcm-aes-aesni a
call
Am Sonntag, 18. Januar 2015, 23:56:03 schrieb Stephan Mueller:
Hi Tadeusz,
> The cipher registered as __driver-gcm-aes-aesni is never intended
> to be used directly by any caller. Instead it is a service mechanism to
> rfc4106-gcm-aesni.
>
> The kernel crypto API unconditionally calls the
The cipher registered as __driver-gcm-aes-aesni is never intended
to be used directly by any caller. Instead it is a service mechanism to
rfc4106-gcm-aesni.
The kernel crypto API unconditionally calls the registered setkey
function. In case a caller erroneously uses __driver-gcm-aes-aesni a
call
Am Sonntag, 18. Januar 2015, 23:56:03 schrieb Stephan Mueller:
Hi Tadeusz,
The cipher registered as __driver-gcm-aes-aesni is never intended
to be used directly by any caller. Instead it is a service mechanism to
rfc4106-gcm-aesni.
The kernel crypto API unconditionally calls the registered
28 matches
Mail list logo
