Am Donnerstag, 26. Mai 2016, 22:14:29 schrieb Theodore Ts'o:
Hi Theodore,
> On Thu, May 26, 2016 at 08:49:39PM +0200, Stephan Mueller wrote:
> > Using the kernel crypto API one can relieve the CPU of the crypto work, if
> > a hardware or assembler implementation is available. This may be of
> >
On Sun, May 29, 2016 at 09:51:59PM +0200, Stephan Mueller wrote:
>
> I personally am not sure that taking some arbitrary cipher and turning it
> into
> a DRNG by simply using a self-feeding loop based on the ideas of X9.31
> Appendix A2.4 is good. Chacha20 is a good cipher, but is it equally
Am Samstag, 28. Mai 2016, 07:28:25 schrieb Aaron Zauner:
Hi Aaron,
> Heya,
>
> > On 27 May 2016, at 01:49, Stephan Mueller wrote:
> > Then, the use of the DRBG offers users to choose between a Hash/HMAC and
> > CTR implementation to suit their needs. The DRBG code is
Heya,
> On 27 May 2016, at 01:49, Stephan Mueller wrote:
> Then, the use of the DRBG offers users to choose between a Hash/HMAC and CTR
> implementation to suit their needs. The DRBG code is agnostic of the
> underlying cipher. So, you could even use Blowfish instead of AES
> If we implement something which happens to result in a 2 minute stall
> in boot times, the danger is that a clueless engineer at Sony, or LGE,
> or Motorola, or BMW, or Toyota, etc, will "fix" the problem without
> telling anyone about what they did, and we might not notice right away
> that the
Am Donnerstag, 26. Mai 2016, 22:14:29 schrieb Theodore Ts'o:
Hi Theodore,
> On Thu, May 26, 2016 at 08:49:39PM +0200, Stephan Mueller wrote:
> > Using the kernel crypto API one can relieve the CPU of the crypto work, if
> > a hardware or assembler implementation is available. This may be of
> >
On Thu, May 26, 2016 at 08:49:39PM +0200, Stephan Mueller wrote:
>
> Using the kernel crypto API one can relieve the CPU of the crypto work, if a
> hardware or assembler implementation is available. This may be of particular
> interest for smaller systems. So, for smaller systems (where kernel
On Thu, May 26, 2016 at 2:49 PM, Stephan Mueller wrote:
> Then, the use of the DRBG offers users to choose between a Hash/HMAC and CTR
> implementation to suit their needs. The DRBG code is agnostic of the
> underlying cipher. So, you could even use Blowfish instead of AES
Am Donnerstag, 26. Mai 2016, 14:20:19 schrieb Sandy Harris:
Hi Sandy,
>
> Why are you using AES? Granted, it is a reasonable idea, but when Ted
> replaced the non-blocking pool with a DBRG, he used a different cipher
> (I think chacha, not certain) and I think chose not to use the crypto
>
Stephan Mueller wrote:
> for the DRBG and the LRNG work I am doing, I also test the speed of the DRBG.
> The DRBG can be considered as a form of block chaining mode on top of a raw
> cipher.
>
> What I am wondering is that when encrypting 256 16 byte blocks, I get a
Am Donnerstag, 26. Mai 2016, 19:30:01 schrieb Stephan Mueller:
Hi,
>
> However, the key difference to a standard speed test is that I set up a new
> key schedule quite frequently. And I would suspect that something is going
> on here...
With tcrypt, there is some interesting hint: on smaller
> What I am wondering is that when encrypting 256 16 byte blocks, I get a speed
> of about 170 MB/s with the AES-NI driver. When using the aes-generic or aes-
> asm, I get up to 180 MB/s with all else being equal. Note, that figure
> includes a copy_to_user of the generated data.
>
> ...
Am Donnerstag, 26. Mai 2016, 13:25:02 schrieb Jeffrey Walton:
Hi Jeffrey,
> > What I am wondering is that when encrypting 256 16 byte blocks, I get a
> > speed of about 170 MB/s with the AES-NI driver. When using the
> > aes-generic or aes- asm, I get up to 180 MB/s with all else being equal.
>
13 matches
Mail list logo