On Fri, Jan 04, 2019 at 07:07:48PM -0800, Eric Biggers wrote:
>
> Herbert, why was CFB accepted without any test vectors in the first place?
That was an oversight. Longer term we should restructure how
the test vectors are stored by moving them in with the generic
implementation. That should als
On Fri, Jan 04, 2019 at 09:03:10PM +, Sasha Levin wrote:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a "Fixes:" tag,
> fixing commit: a7d85e06ed80 crypto: cfb - add support for Cipher FeedBack
> mode.
>
> The bot has tested the following tre
Eric Biggers wrote:
> It makes it clearer what's going on, especially since some modes update the
> 'iv' pointer after each block (delaying the copy to 'walk.iv' until the end)
> but others can't do that. The 'const' is helpful to further distinguish
> these two cases, which were confused in bot
On Fri, Jan 04, 2019 at 09:57:13AM +, David Howells wrote:
> Eric Biggers wrote:
>
> > - u8 *iv = walk->iv;
> > + u8 * const iv = walk->iv;
>
> Does adding this const actually gain anything? (this is done twice)
>
> David
It makes it clearer what's going on, especially since some mode
On 1/4/2019 5:17 PM, Horia Geanta wrote:
> On 12/21/2018 10:07 AM, Christophe Leroy wrote:
> [snip]
>> IV cannot be on stack when CONFIG_VMAP_STACK is selected because the stack
>> cannot be DMA mapped anymore.
>> This looks better, thanks.
>
>> This patch copies the IV into the extended descripto
On 12/21/2018 10:07 AM, Christophe Leroy wrote:
[snip]
> IV cannot be on stack when CONFIG_VMAP_STACK is selected because the stack
> cannot be DMA mapped anymore.
> This looks better, thanks.
> This patch copies the IV into the extended descriptor when iv is not
> a valid linear address.
>
Thoug
On Fri, Jan 4, 2019 at 1:02 PM Sumit Garg wrote:
>
> On Fri, 4 Jan 2019 at 16:31, Jens Wiklander wrote:
> >
> > On Fri, Jan 4, 2019 at 7:39 AM Sumit Garg wrote:
> > >
> > > On Thu, 3 Jan 2019 at 22:44, Daniel Thompson
> > > wrote:
> > > >
> > > > On Fri, Dec 28, 2018 at 02:41:01PM +0530, Sumit
On Fri, 4 Jan 2019 at 16:31, Jens Wiklander wrote:
>
> On Fri, Jan 4, 2019 at 7:39 AM Sumit Garg wrote:
> >
> > On Thu, 3 Jan 2019 at 22:44, Daniel Thompson
> > wrote:
> > >
> > > On Fri, Dec 28, 2018 at 02:41:01PM +0530, Sumit Garg wrote:
> > > > On Thu, 27 Dec 2018 at 19:10, Ard Biesheuvel
>
On Fri, Jan 4, 2019 at 7:39 AM Sumit Garg wrote:
>
> On Thu, 3 Jan 2019 at 22:44, Daniel Thompson
> wrote:
> >
> > On Fri, Dec 28, 2018 at 02:41:01PM +0530, Sumit Garg wrote:
> > > On Thu, 27 Dec 2018 at 19:10, Ard Biesheuvel
> > > wrote:
> > > >
> > > > On Thu, 27 Dec 2018 at 12:08, Sumit Gar
On Thu, Dec 13, 2018 at 06:12:33PM +0800, Herbert Xu wrote:
> Vitaly Chikunov wrote:
> > Current akcipher .verify() just decrypts signature to uncover message
> > hash, which is then verified in upper level public_key_verify_signature
> > by memcmp with the expected signature value, which is never
Eric Biggers wrote:
> - u8 *iv = walk->iv;
> + u8 * const iv = walk->iv;
Does adding this const actually gain anything? (this is done twice)
David
On Thu, Jan 03, 2019 at 04:16:56PM +0530, Harsh Jain wrote:
>
> On 02-01-2019 18:21, Herbert Xu wrote:
> > Does this occur if you use software crypto on the receiving end
> > while keeping the sending end unchanged?
>
> I tried with "authencesn(hmac(sha1-ssse3),cbc(aes-asm))" on both sides.
>
>
12 matches
Mail list logo
