On Wed, Dec 28, 2016 at 07:50:44PM +, Ard Biesheuvel wrote:
>
> So about this chunksize, is it ever expected to assume other values
> than 1 (for stream ciphers) or the block size (for block ciphers)?
> Having block size, IV size *and* chunk size fields may be confusing to
> some already, so i
On 28 December 2016 at 09:23, Herbert Xu wrote:
> On Wed, Dec 28, 2016 at 09:19:32AM +, Ard Biesheuvel wrote:
>>
>> Ok, so that implies a field in the skcipher algo struct then, rather than
>> some definition internal to the driver?
>
> Oh yes it should definitely be visible to other crypto A
Hi,
The patch set that can be downloaded at [1] provides a different approach to /
dev/random which I call Linux Random Number Generator (LRNG) to collect
entropy within the Linux kernel. The main improvements compared to the legacy
/dev/random is to provide sufficient entropy during boot time a
Am Mittwoch, 28. Dezember 2016, 18:28:26 CET schrieb Herbert Xu:
Hi Herbert,
> On Wed, Dec 28, 2016 at 11:00:51AM +0100, Stephan Müller wrote:
> > When I configure AES-NI as module, it works. When compiling it statically,
> > the allocation returns an -ENOENT.
> >
> > Now, when I diff both confi
On Thu, Dec 22, 2016 at 03:00:51PM +, Giovanni Cabiddu wrote:
> Initialize dh.base.cra_flags before registering the dh algorithm.
> Without this fix, the registration of the dh algorithm might fail
> if the qat driver is restarted.
>
> Signed-off-by: Sushil Kumar
> Signed-off-by: Giovanni Cab
On Wed, Dec 28, 2016 at 11:00:51AM +0100, Stephan Müller wrote:
>
> When I configure AES-NI as module, it works. When compiling it statically,
> the
> allocation returns an -ENOENT.
>
> Now, when I diff both config files after a simple toggle from AES-NI=y to =m
> I
> see (linux-4.10.config c
Hannes Frederic Sowa wrote:
> We call extract_crng when we run out of batched entropy and reseed. How
> often we call down to extract_crng depends on how much entropy we
> extracted by calls to get_random_int/long, so the number of calls into
> those functions matter.
>
> In extract_crng we have a
Am Mittwoch, 28. Dezember 2016, 16:59:38 CET schrieb Herbert Xu:
Hi Herbert,
> > With 4.10-rc1, I also do not get the AES-NI implementations to work. do
> > you
> > have any ideas what may be the issue?
>
> I'm having problems reproducing this. Does it work for you if you
> build them as module
On Wed, Dec 28, 2016 at 09:19:32AM +, Ard Biesheuvel wrote:
>
> Ok, so that implies a field in the skcipher algo struct then, rather than
> some definition internal to the driver?
Oh yes it should definitely be visible to other crypto API drivers
and algorithms. It's just that we don't want
> On 28 Dec 2016, at 09:18, Herbert Xu wrote:
>
>> On Tue, Dec 27, 2016 at 06:04:52PM +0800, Herbert Xu wrote:
>>> On Fri, Dec 09, 2016 at 02:33:51PM +, Ard Biesheuvel wrote:
>>> This converts the ChaCha20 code from a blkcipher to a skcipher, which
>>> is now the preferred way to implement
On Wed, Dec 28, 2016 at 09:37:04AM +0100, Stephan Müller wrote:
> Am Donnerstag, 8. Dezember 2016, 19:40:38 CET schrieb Stephan Müller:
>
> Hi Herbert,
>
> > Am Donnerstag, 8. Dezember 2016, 19:32:03 CET schrieb Stephan Müller:
> >
> > Hi Herbert,
> >
> > > Hi Herbert,
> > >
> > > with the add
On Wed, Dec 28, 2016 at 09:23:07AM +, Ard Biesheuvel wrote:
>
> Ehm, could you keep this one and revert the other two instead please? This
> patch will not change in the respin, and the other two are blkciphers rather
> than skciphers (and in the arm64 version, I optimized the asm code as we
> On 28 Dec 2016, at 09:10, Herbert Xu wrote:
>
>> On Tue, Dec 27, 2016 at 06:35:46PM +, Ard Biesheuvel wrote:
>>
>> OK, I will try to hack something up.
>>
>> One thing to keep in mind though is that stacked chaining modes should
>> present the data with the same granularity for optimal p
On Wed, Dec 28, 2016 at 05:18:01PM +0800, Herbert Xu wrote:
> On Tue, Dec 27, 2016 at 06:04:52PM +0800, Herbert Xu wrote:
> > On Fri, Dec 09, 2016 at 02:33:51PM +, Ard Biesheuvel wrote:
> > > This converts the ChaCha20 code from a blkcipher to a skcipher, which
> > > is now the preferred way to
On Tue, Dec 27, 2016 at 06:04:52PM +0800, Herbert Xu wrote:
> On Fri, Dec 09, 2016 at 02:33:51PM +, Ard Biesheuvel wrote:
> > This converts the ChaCha20 code from a blkcipher to a skcipher, which
> > is now the preferred way to implement symmetric block and stream ciphers.
> >
> > This ports t
On Wed, Dec 28, 2016 at 09:11:03AM +, Ard Biesheuvel wrote:
>
> > On 28 Dec 2016, at 09:03, Herbert Xu wrote:
> >
> >> On Tue, Dec 27, 2016 at 02:26:35PM +, Ard Biesheuvel wrote:
> >>
> >> You just nacked the v2 of this series (due to the chunksize/walksize) and
> >> i rewrote them as
> On 28 Dec 2016, at 09:03, Herbert Xu wrote:
>
>> On Tue, Dec 27, 2016 at 02:26:35PM +, Ard Biesheuvel wrote:
>>
>> You just nacked the v2 of this series (due to the chunksize/walksize) and i
>> rewrote them as skciphers as well
>
> Sorry. Would you like me to revert or just send a new
On Tue, Dec 27, 2016 at 06:35:46PM +, Ard Biesheuvel wrote:
>
> OK, I will try to hack something up.
>
> One thing to keep in mind though is that stacked chaining modes should
> present the data with the same granularity for optimal performance.
> E.g., xts(ecb(aes)) should pass 8 blocks at a
On Tue, Dec 27, 2016 at 02:26:35PM +, Ard Biesheuvel wrote:
>
> You just nacked the v2 of this series (due to the chunksize/walksize) and i
> rewrote them as skciphers as well
Sorry. Would you like me to revert or just send a new series
on top of this?
Thanks,
--
Email: Herbert Xu
Home Pa
On Tue, Dec 27, 2016 at 11:39:21AM +, Challa, Mahipal wrote:
>
> Mahipal: One major issue is, the kernel use cases to validate the Cavium
> ThunderX ZIP driver are "ZSWAP" and "IPComp" which are not yet supported with
> scomp-acomp framework.
OK I'll look into converting IPcomp.
Thanks,
--
On Fri, Dec 09, 2016 at 07:02:25AM +0100, Stephan Müller wrote:
> Hi Herbert,
>
> while testing the current cryptodev-2.6 tree, I noticed that instead of the
> driver name of xts(aes-asm) (which used to be there), I now see xts(ecb(aes-
> asm)).
>
> Is that intentional?
Yes this is a result of
Am Donnerstag, 8. Dezember 2016, 19:40:38 CET schrieb Stephan Müller:
Hi Herbert,
> Am Donnerstag, 8. Dezember 2016, 19:32:03 CET schrieb Stephan Müller:
>
> Hi Herbert,
>
> > Hi Herbert,
> >
> > with the addition of the simd cipher change I seem to be unable to use the
> > AESNI ciphers. My .
22 matches
Mail list logo
