Synopsis: softraid crypto performance regression
Category: system
Environment:
System : OpenBSD 6.1
Details : OpenBSD 6.1-current (GENERIC.MP) #51: Sat May 6 12:01:40
MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile
On 8 May 2017 at 01:04, wrote:
> Synopsis: softraid crypto performance regression
>> Category: system
>> Environment:
>>
> System : OpenBSD 6.1
> Details : OpenBSD 6.1-current (GENERIC.MP) #51: Sat May 6
> 12:01:40 MDT 2017
&
On 2017-05-07 19:30, Mike Belopuhov wrote:
On 8 May 2017 at 01:04, wrote:
Synopsis: softraid crypto performance regression
Category: system
Environment:
System : OpenBSD 6.1
Details : OpenBSD 6.1-current (GENERIC.MP) #51: Sat May 6
12:01:40 MDT 2017
On Sun, May 07, 2017 at 08:06:56PM -0400, m.r...@excitingdomainname.com wrote:
> On 2017-05-07 19:30, Mike Belopuhov wrote:
> > You observe a decrease in performance because we've switched to
> > a constant time machine independent AES implementation which is
> > inherently slower than the T-table
Stefan Sperling wrote:
> I also have some machines which are affected by this, and I am
> not sure what to about it. I cannot judge the advantages of
> either AES implementation.
There's very little advantage to a constant time implementation for disk
encryption. The threat model doesn't really in
> There's very little advantage to a constant time implementation for disk
> encryption.
100% agree
But this has been shoved into the tree, only considering IPSEC performance,
and zero assessment of the impact it has upon other consumers.
It was done wrong. It was commited before we were t
On Wed, May 17, 2017 at 12:42 -0400, Ted Unangst wrote:
> Stefan Sperling wrote:
> > I also have some machines which are affected by this, and I am
> > not sure what to about it. I cannot judge the advantages of
> > either AES implementation.
>
> There's very little advantage to a constant time im
> This is simply not true if you have local users on the same box.
> http://www.cs.tau.ac.il/~tromer/papers/cache.pdf
don't need to worry about that attack anymore, because you made it
so slow noone can use the functionality anymore.
prevously this software functionality was generally used in sin
On Wed, May 17, 2017 at 18:23 +0200, Stefan Sperling wrote:
> On Sun, May 07, 2017 at 08:06:56PM -0400, m.r...@excitingdomainname.com wrote:
> > On 2017-05-07 19:30, Mike Belopuhov wrote:
> > > You observe a decrease in performance because we've switched to
> > > a constant time machine independent
On Wed, May 17, 2017 at 07:17:56PM +0200, Mike Belopuhov wrote:
> There are ways to improve perfomance but more work is required
> to get there. In the meantime if the consensus is that XTS
> performance is unacceptable we can roll it back to T-tables.
>
> Please test the diff below.
Works for m
Mike Belopuhov wrote:
> On Wed, May 17, 2017 at 12:42 -0400, Ted Unangst wrote:
> > Stefan Sperling wrote:
> > > I also have some machines which are affected by this, and I am
> > > not sure what to about it. I cannot judge the advantages of
> > > either AES implementation.
> >
> > There's very li
On Thu, 18 May 2017 16:56:57 -0400, "Ted Unangst" wrote:
> Another very popular use case doesn't even involve a threat. It's
> very easy to repurpose a machine/disk that uses full disk encryption.
> Change the key, and you've instantly wiped the disk. Personally,
> this is the main reason I use an
12 matches
Mail list logo
