<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/lib/crypto/sha256.c, branch v6.6.131</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.131</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.131'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2023-05-19T08:45:43+00:00</updated>
<entry>
<title>crypto: lib/sha256 - Use generic code from sha256_base</title>
<updated>2023-05-19T08:45:43+00:00</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2023-05-11T04:30:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6c19f3bfff0344cdc02e7b074062a9acd026f010'/>
<id>urn:sha1:6c19f3bfff0344cdc02e7b074062a9acd026f010</id>
<content type='text'>
Instead of duplicating the sha256 block processing code, reuse
the common code from crypto/sha256_base.h.

Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: lib/sha256 - Remove redundant and unused sha224_update</title>
<updated>2023-05-19T08:45:43+00:00</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2023-05-11T04:29:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=70d391a86317f77c30d4c0aa898b5fe0f75687b9'/>
<id>urn:sha1:70d391a86317f77c30d4c0aa898b5fe0f75687b9</id>
<content type='text'>
The function sha224_update is exactly the same as sha256_update.
Moreover it's not even used in the kernel so it can be removed.

Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: sha - split sha.h into sha1.h and sha2.h</title>
<updated>2020-11-20T03:45:33+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2020-11-13T05:20:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a24d22b225ce158651378869a6b88105c4bdb887'/>
<id>urn:sha1:a24d22b225ce158651378869a6b88105c4bdb887</id>
<content type='text'>
Currently &lt;crypto/sha.h&gt; contains declarations for both SHA-1 and SHA-2,
and &lt;crypto/sha3.h&gt; contains declarations for SHA-3.

This organization is inconsistent, but more importantly SHA-1 is no
longer considered to be cryptographically secure.  So to the extent
possible, SHA-1 shouldn't be grouped together with any of the other SHA
versions, and usage of it should be phased out.

Therefore, split &lt;crypto/sha.h&gt; into two headers &lt;crypto/sha1.h&gt; and
&lt;crypto/sha2.h&gt;, and make everyone explicitly specify whether they want
the declarations for SHA-1, SHA-2, or both.

This avoids making the SHA-1 declarations visible to files that don't
want anything to do with SHA-1.  It also prepares for potentially moving
sha1.h into a new insecure/ or dangerous/ directory.

Signed-off-by: Eric Biggers &lt;ebiggers@google.com&gt;
Acked-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Acked-by: Jason A. Donenfeld &lt;Jason@zx2c4.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: lib/sha256 - Unroll LOAD and BLEND loops</title>
<updated>2020-10-30T06:35:04+00:00</updated>
<author>
<name>Arvind Sankar</name>
<email>nivedita@alum.mit.edu</email>
</author>
<published>2020-10-25T14:31:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=18d05ca4486fe38991c3166b1f4df26b8a029665'/>
<id>urn:sha1:18d05ca4486fe38991c3166b1f4df26b8a029665</id>
<content type='text'>
Unrolling the LOAD and BLEND loops improves performance by ~8% on x86_64
(tested on Broadwell Xeon) while not increasing code size too much.

Signed-off-by: Arvind Sankar &lt;nivedita@alum.mit.edu&gt;
Reviewed-by: Eric Biggers &lt;ebiggers@google.com&gt;
Acked-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: lib/sha256 - Unroll SHA256 loop 8 times intead of 64</title>
<updated>2020-10-30T06:35:03+00:00</updated>
<author>
<name>Arvind Sankar</name>
<email>nivedita@alum.mit.edu</email>
</author>
<published>2020-10-25T14:31:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=63642d5c141f1bcbe97f7895467a724ad2e3f346'/>
<id>urn:sha1:63642d5c141f1bcbe97f7895467a724ad2e3f346</id>
<content type='text'>
This reduces code size substantially (on x86_64 with gcc-10 the size of
sha256_update() goes from 7593 bytes to 1952 bytes including the new
SHA256_K array), and on x86 is slightly faster than the full unroll
(tested on Broadwell Xeon).

Signed-off-by: Arvind Sankar &lt;nivedita@alum.mit.edu&gt;
Reviewed-by: Eric Biggers &lt;ebiggers@google.com&gt;
Acked-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: lib/sha256 - Clear W[] in sha256_update() instead of sha256_transform()</title>
<updated>2020-10-30T06:35:03+00:00</updated>
<author>
<name>Arvind Sankar</name>
<email>nivedita@alum.mit.edu</email>
</author>
<published>2020-10-25T14:31:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b8399819b2dd6f29195ed7535217b66c01b1e57d'/>
<id>urn:sha1:b8399819b2dd6f29195ed7535217b66c01b1e57d</id>
<content type='text'>
The temporary W[] array is currently zeroed out once every call to
sha256_transform(), i.e. once every 64 bytes of input data. Moving it to
sha256_update() instead so that it is cleared only once per update can
save about 2-3% of the total time taken to compute the digest, with a
reasonable memset() implementation, and considerably more (~20%) with a
bad one (eg the x86 purgatory currently uses a memset() coded in C).

Signed-off-by: Arvind Sankar &lt;nivedita@alum.mit.edu&gt;
Reviewed-by: Eric Biggers &lt;ebiggers@google.com&gt;
Acked-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: lib/sha256 - Don't clear temporary variables</title>
<updated>2020-10-30T06:35:03+00:00</updated>
<author>
<name>Arvind Sankar</name>
<email>nivedita@alum.mit.edu</email>
</author>
<published>2020-10-25T14:31:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7a4295f6c9d54e082474667e552a227606b4a085'/>
<id>urn:sha1:7a4295f6c9d54e082474667e552a227606b4a085</id>
<content type='text'>
The assignments to clear a through h and t1/t2 are optimized out by the
compiler because they are unused after the assignments.

Clearing individual scalar variables is unlikely to be useful, as they
may have been assigned to registers, and even if stack spilling was
required, there may be compiler-generated temporaries that are
impossible to clear in any case.

So drop the clearing of a through h and t1/t2.

Signed-off-by: Arvind Sankar &lt;nivedita@alum.mit.edu&gt;
Reviewed-by: Eric Biggers &lt;ebiggers@google.com&gt;
Acked-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: lib/sha256 - Use memzero_explicit() for clearing state</title>
<updated>2020-10-30T06:35:03+00:00</updated>
<author>
<name>Arvind Sankar</name>
<email>nivedita@alum.mit.edu</email>
</author>
<published>2020-10-25T14:31:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1762818f25f3f99c5083caa13d69e5e5aa2e4b6f'/>
<id>urn:sha1:1762818f25f3f99c5083caa13d69e5e5aa2e4b6f</id>
<content type='text'>
Without the barrier_data() inside memzero_explicit(), the compiler may
optimize away the state-clearing if it can tell that the state is not
used afterwards. At least in lib/crypto/sha256.c:__sha256_final(), the
function can get inlined into sha256(), in which case the memset is
optimized away.

Signed-off-by: Arvind Sankar &lt;nivedita@alum.mit.edu&gt;
Reviewed-by: Eric Biggers &lt;ebiggers@google.com&gt;
Acked-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: lib/sha256 - add sha256() function</title>
<updated>2020-07-16T11:49:05+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2020-07-08T16:39:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9ea9c58b40a441a0babef8c615acedcfb3733919'/>
<id>urn:sha1:9ea9c58b40a441a0babef8c615acedcfb3733919</id>
<content type='text'>
Add a function sha256() which computes a SHA-256 digest in one step,
combining sha256_init() + sha256_update() + sha256_final().

This is similar to how we also have blake2s().

Reviewed-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Tested-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Eric Biggers &lt;ebiggers@google.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: lib/sha256 - return void</title>
<updated>2020-05-08T05:32:12+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2020-05-01T16:42:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=13855fd8ce641e567c1b972048b5fd1451984e88'/>
<id>urn:sha1:13855fd8ce641e567c1b972048b5fd1451984e88</id>
<content type='text'>
The SHA-256 / SHA-224 library functions can't fail, so remove the
useless return value.

Also long as the declarations are being changed anyway, also fix some
parameter names in the declarations to match the definitions.

Signed-off-by: Eric Biggers &lt;ebiggers@google.com&gt;
Reviewed-by: Jason A. Donenfeld &lt;Jason@zx2c4.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
</feed>
