Hi Ard,
I love your patch! Yet something to improve:
[auto build test ERROR on cryptodev/master]
[also build test ERROR on v5.2-rc4 next-20190614]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
From: Eric Biggers
[ Upstream commit 7829a0c1cb9c80debfb4fdb49b4d90019f2ea1ac ]
When I added the sanity check of 'descsize', I missed that the child
hash tfm needs to be freed if the sanity check fails. Of course this
should never happen, hence the use of WARN_ON(), but it should be fixed.
Fix
On Fri, Jun 14, 2019 at 8:44 AM Jason Baron wrote:
>
>
>
>
> The inconsistencies coming from kernel version skew with some servers
> being on the old hash and some on the newer one? Or is there another
> source for the inconsistency you are referring to?
>
The servers still using the old crypto h
On 6/14/19 11:34 AM, Eric Dumazet wrote:
> On Fri, Jun 14, 2019 at 7:01 AM Ard Biesheuvel
> wrote:
>>
>> Using a bare block cipher in non-crypto code is almost always a bad idea,
>> not only for security reasons (and we've seen some examples of this in
>> the kernel in the past), but also for p
On Fri, Jun 14, 2019 at 7:01 AM Ard Biesheuvel
wrote:
>
> Using a bare block cipher in non-crypto code is almost always a bad idea,
> not only for security reasons (and we've seen some examples of this in
> the kernel in the past), but also for performance reasons.
>
> In the TCP fastopen case, we
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Also, there is no need to store the individual debugfs file names,
especially as the whole directiry is deleted at o
Using a bare block cipher in non-crypto code is almost always a bad idea,
not only for security reasons (and we've seen some examples of this in
the kernel in the past), but also for performance reasons.
In the TCP fastopen case, we call into the bare AES block cipher one or
two times (depending o
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Also, there is no need to store the individual debugfs file names,
especially as the whole directiry is deleted at o
From: Ard Biesheuvel
> Sent: 14 June 2019 12:15
> (fix Eric's email address)
>
> On Fri, 14 Jun 2019 at 13:14, Ard Biesheuvel
> wrote:
> >
> > Using a bare block cipher in non-crypto code is almost always a bad idea,
> > not only for security reasons (and we've seen some examples of this in
> >
On Fri, Jun 14, 2019 at 4:14 AM Ard Biesheuvel
wrote:
>
> Using a bare block cipher in non-crypto code is almost always a bad idea,
> not only for security reasons (and we've seen some examples of this in
> the kernel in the past), but also for performance reasons.
>
> In the TCP fastopen case, we
On 6/13/2019 3:48 PM, Christophe Leroy wrote:
> @@ -336,15 +336,18 @@ static void flush_channel(struct device *dev, int ch,
> int error, int reset_ch)
> tail = priv->chan[ch].tail;
> while (priv->chan[ch].fifo[tail].desc) {
> __be32 hdr;
> + struct talitos_ede
(fix Eric's email address)
On Fri, 14 Jun 2019 at 13:14, Ard Biesheuvel wrote:
>
> Using a bare block cipher in non-crypto code is almost always a bad idea,
> not only for security reasons (and we've seen some examples of this in
> the kernel in the past), but also for performance reasons.
>
> In
Using a bare block cipher in non-crypto code is almost always a bad idea,
not only for security reasons (and we've seen some examples of this in
the kernel in the past), but also for performance reasons.
In the TCP fastopen case, we call into the bare AES block cipher one or
two times (depending o
On Fri, 14 Jun 2019 at 12:05, Greg KH wrote:
>
> On Fri, Jun 14, 2019 at 11:43:53AM +0200, Ard Biesheuvel wrote:
> > The wusb code takes a very peculiar approach at implementing CBC-MAC,
> > by using plain CBC into a scratch buffer, and taking the output IV
> > as the MAC.
> >
> > We can clean up
On Fri, Jun 14, 2019 at 11:43:53AM +0200, Ard Biesheuvel wrote:
> The wusb code takes a very peculiar approach at implementing CBC-MAC,
> by using plain CBC into a scratch buffer, and taking the output IV
> as the MAC.
>
> We can clean up this code substantially by switching to the cbcmac
> shash,
On Fri, 14 Jun 2019 at 11:42, Ard Biesheuvel wrote:
>
> The AIRO driver applies a ctr(aes) on a buffer of considerable size
> (2400 bytes), and instead of invoking the crypto API to handle this
> in its entirety, it open codes the counter manipulation and invokes
> the AES block cipher directly.
>
The wusb code takes a very peculiar approach at implementing CBC-MAC,
by using plain CBC into a scratch buffer, and taking the output IV
as the MAC.
We can clean up this code substantially by switching to the cbcmac
shash, as exposed by the CCM template. To ensure that the module is
loaded on dema
The AIRO driver applies a ctr(aes) on a buffer of considerable size
(2400 bytes), and instead of invoking the crypto API to handle this
in its entirety, it open codes the counter manipulation and invokes
the AES block cipher directly.
Let's fix this, by switching to the sync skcipher API instead.
The AIRO driver applies a ctr(aes) on a buffer of considerable size
(2400 bytes), and instead of invoking the crypto API to handle this
in its entirety, it open codes the counter manipulation and invokes
the AES block cipher directly.
Let's fix this, by switching to the sync skcipher API instead.
Instead of open coding the CCM aead mode in the driver, and invoking
the AES block cipher block by block, use a ccm(aes) aead transform
which already encapsulates this functionality. This is a cleaner use
of the crypto API, and permits optimized implementations to be used,
which are typically much
Two different users of ESSIV (encrypted salt|sector IV) implement the
algorithm using bare shash and cipher transform. This is not a huge
deal, since the algorithm is fairly simple, but it does require us to
keep the cipher interface public. Since the cipher interface is often
used incorrectly, and
This series is presented as an RFC for a couple of reasons:
- it is only build tested
- it is unclear whether this is the right way to move away from the use of
bare ciphers in non-crypto code
- we haven't really discussed whether moving away from the use of bare ciphers
in non-crypto code is a
Instead of open coding the shash and cipher operations that make up
the ESSIV transform, switch to the new ESSIV shash template that
encapsulates all of this. Using this more abstract interface provides
more flexibility for the crypto subsystem to do refactoring, and
permits better testing.
Signed
Replace the open coded ESSIV handling with invocations into the new
ESSIV shash, created specifically for this purpose. Using this more
abstract interface allows the crypto subsystem to refactor the way
ciphers are used, and to provide better testing coverage.
Signed-off-by: Ard Biesheuvel
---
d
Le 13/06/2019 à 21:07, Horia Geanta a écrit :
On 6/13/2019 3:48 PM, Christophe Leroy wrote:
On SEC1, hash provides wrong result when performing hashing in several
steps with input data SG list has more than one element. This was
detected with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS:
[ 44.185947]
25 matches
Mail list logo
