Hi Rob,
[auto build test ERROR on cryptodev/master]
[also build test ERROR on v4.9-rc8]
[cannot apply to next-20161209]
[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/commits/Rob-Rice/crypto-brcm-DT-doc
cc: Viro because I'm talking about iov_iter.
On Sat, Dec 10, 2016 at 6:45 AM, Jason A. Donenfeld wrote:
> Hi Herbert,
>
> On Sat, Dec 10, 2016 at 6:37 AM, Herbert Xu
> wrote:
>> As for AEAD we never had a sync interface to begin with and I
>> don't think I'm going to add one.
>
> That's too bad
> There's a 32-bit secret random salt (inet_ehash_secret) which means
> that in practice, inet_ehashfn() will select 1 out of 2^32 different
> hash functions at random each time you boot the kernel; without
> knowing which one it selected, how can a local or remote attacker can
> force IPv4 connect
Hi Herbert,
On Sat, Dec 10, 2016 at 6:37 AM, Herbert Xu wrote:
> As for AEAD we never had a sync interface to begin with and I
> don't think I'm going to add one.
That's too bad to hear. I hope you'll reconsider. Modern cryptographic
design is heading more and more in the direction of using AEAD
On 9 December 2016 at 19:36, Jason A. Donenfeld wrote:
> SipHash is a 64-bit keyed hash function that is actually a
> cryptographically secure PRF, like HMAC. Except SipHash is super fast,
> and is meant to be used as a hashtable keyed lookup function.
>
> SipHash isn't just some new trendy hash f
On Fri, Dec 09, 2016 at 07:36:59PM +0100, Jason A. Donenfeld wrote:
> SipHash is a 64-bit keyed hash function that is actually a
> cryptographically secure PRF, like HMAC. Except SipHash is super fast,
> and is meant to be used as a hashtable keyed lookup function.
>
> SipHash isn't just some new
Regards,
-Gonglei
> -Original Message-
> From: linux-crypto-ow...@vger.kernel.org
> [mailto:linux-crypto-ow...@vger.kernel.org] On Behalf Of Sam Ravnborg
> Sent: Saturday, December 10, 2016 5:59 AM
> To: Gonglei (Arei)
> Cc: linux-ker...@vger.kernel.org; qemu-de...@nongnu.org;
> virti
On Sat, Dec 10, 2016 at 04:16:43PM +0800, Herbert Xu wrote:
> Why did you drop me from the CC list when you were replying to
> my email?
>
Sorry --- this thread is Cc'ed to the kernel-hardening mailing list (which was
somewhat recently revived), and I replied to the email that reached me from
the
Why did you drop me from the CC list when you were replying to
my email?
Eric Biggers wrote:
> On Sat, Dec 10, 2016 at 01:32:08PM +0800, Herbert Xu wrote:
>
>> Are you sure? Any instance of *_ON_STACK must only be used with
>> sync algorithms and most drivers under drivers/crypto declare
>> thems
Jason A. Donenfeld wrote:
> Hah, looks like I missed [1] by a couple weeks. Looks like it's been
> settled then.
>
> Is this a stable@ candidate?
Not really since it shouldn't cause any problems unless the stack
is vmalloced.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/
abed mohammad kamaluddin wrote:
>
> We are also looking for user-space access to the kernel crypto layer
> compression algorithms. I have gone through AF_ALG but couldn’t find
> support for compression ops through it. This is required for our
> hardware zip engines whose driver hooks up to the cr
On Fri, Dec 09, 2016 at 02:18:01PM +0100, Jason A. Donenfeld wrote:
> Hi Herbert,
>
> The scatterwalk_map_and_copy function copies ordinary buffers to and
> from scatterlists. These buffers can, of course, be on the stack, and
> this remains the most popular use of this function -- getting info
>
12 matches
Mail list logo
