Date: Mon, 27 Feb 2017 21:07:38 +0000 From: Colin Percival <cperciva@tarsnap.com> To: Ed Schouten <ed@nuxi.nl>, Andriy Gapon <avg@freebsd.org> Cc: src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-stable@freebsd.org, svn-src-stable-10@freebsd.org Subject: Re: svn commit: r314335 - stable/10/sys/crypto/sha2 Message-ID: <0100015a816670c6-5cea53f5-32f4-43d0-9fe5-18ca7a241430-000000@email.amazonses.com> In-Reply-To: <CABh_MK==nm1rpy0STaECBVF-fT%2B5C5BapDWjkOOqAEeszOBknw@mail.gmail.com> References: <201702271305.v1RD5HOi077424@repo.freebsd.org> <CABh_MK==nm1rpy0STaECBVF-fT%2B5C5BapDWjkOOqAEeszOBknw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 02/27/17 06:01, Ed Schouten wrote:
> Something interesting that I noticed some time ago when comparing the
> various SHA-{256,512} implementations: there is no need to store the
> entire extended message in W. During every iteration of this loop,
> RNDr() and MSCH() never go more than 16 elements back.
>
> Say, if you were to modify MSCH() to something like this:
>
>> +#define MSCH(W, ii) \
>> + W[ii] += s1(W[(ii + 14) % 16]) + W[(ii + 9) % 16] + s0(W[(ii + 1)) % 16])
>
> Then it will compute the next chunk of the extended message in-place.
> RNDr() must then be adjusted to use W[i] instead of W[i + ii], of
> course. W then only needs to hold 16 elements instead of 64 or 80.
I tried this, and it was slower. The larger array avoids write-after-read
accesses and results in better code being emitted due to more flexible
instruction scheduling.
--
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0100015a816670c6-5cea53f5-32f4-43d0-9fe5-18ca7a241430-000000>