From: Tobias Brunner <tobias@strongswan.org>
Date: Thu, 28 Mar 2024 10:51:15 +0000 (+0100)
Subject: sha3: Fix Keccak when compiled with GCC 13.x
X-Git-Tag: android-2.5.2~35
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=56f4b2096aecda21b3e0afcc279702eb42f5026e;p=thirdparty%2Fstrongswan.git

sha3: Fix Keccak when compiled with GCC 13.x

With GCC 13, the compiler apparently applies new aliasing optimizations
when compiled with -O2 and without -fno-strict-aliasing.  This caused
the application of the second padding bit, where the state was accessed
via uint8_t[], to be moved before the loop that absorbs the buffer into
the state, where the state is accessed via uint64_t[], resulting in
incorrect output.  By only accessing the state via uint64_t[] here the
compiler won't reorder the instructions.
---

diff --git a/src/libstrongswan/plugins/sha3/sha3_keccak.c b/src/libstrongswan/plugins/sha3/sha3_keccak.c
index e56df01105..69df057d33 100644
--- a/src/libstrongswan/plugins/sha3/sha3_keccak.c
+++ b/src/libstrongswan/plugins/sha3/sha3_keccak.c
@@ -372,7 +372,6 @@ METHOD(sha3_keccak_t, reset, void,
 	this->rate_index = 0;
 }
 
-
 METHOD(sha3_keccak_t, absorb, void,
 	private_sha3_keccak_t *this, chunk_t data)
 {
@@ -431,8 +430,12 @@ METHOD(sha3_keccak_t, finalize, void,
 		state_lanes[i] ^= buffer_lanes[i];
 	}
 
-	/* Add the second bit of padding */
-	this->state[this->rate - 1] ^= 0x80;
+	/* Add the second bit of padding, do this consistently via state_lanes[] and
+	 * not state[] to avoid that the compiler reorders this due to aliasing
+	 * optimizations */
+	rate_lanes = (this->rate - 1) / sizeof(uint64_t);
+	remainder = (this->rate - 1) % sizeof(uint64_t);
+	state_lanes[rate_lanes] ^= (0x80ULL << remainder * 8);
 
 	/* Switch to the squeezing phase */
 	keccak_f1600_state_permute(this->state);