I wonder if there's some practical way to implement ghash without table
lokups where indices are sensitive (since such lookups result in side
channel leakage).
I've tried a straight bitwise loop, which needs a precomputed table of
x^k H (mod P), but that table is accessed purely deterministically. Then
the multiplication is just a series of conditional xors. Loop would look
like this,
static void
gcm_gf_mul (union nettle_block16 *x, const union nettle_block16 *table)
{
uint64_t x0 = x->u64[0];
uint64_t x1 = x->u64[1];
uint64_t r0 = 0;
uint64_t r1 = 0;
unsigned i;
for (i = 0; i < 64; i++, x0 >>= 1, x1 >>= 1)
{
uint64_t m0 = -(x0 & 1);
uint64_t m1 = -(x1 & 1);
r0 ^= m0 & table[i].u64[0];
r1 ^= m0 & table[i].u64[1];
r0 ^= m1 & table[64+i].u64[0];
r1 ^= m1 & table[64+i].u64[1];
}
x->u64[0] = r0; x->u64[1] = r1;
}
(Untested; I haven't written any code to populate the table in the right
way).
In initial benchmarking, this loop appears to run in 4.2 cycles per
iteration on my laptop, and a slowdown by a factor of 3 compared to the
current C implementation of ghash_update. Penalty may be a bit less for
assembly implementation, but I haven't tried.
It's not an obvious tradeoff, but perhaps it would be best to accept that
performance penalty, do reduce leakage?
Another problem algorithm in terms of side-channel leakage is the C
implementation of AES. It's possible to replace sbox lookups by
bit-slicing techniques (I'm told boringssl includes an aes
implementation doing that), but I haven't look into how that works out.
Regards,
/Niels
--
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
_______________________________________________
nettle-bugs mailing list -- [email protected]
To unsubscribe send an email to [email protected]
