request for TLBleed information / non-constant-time vulnerabilities

[NIIBE Yutaka]

Hello,

I should have answered earlier.  I was joining Debconf18 in Hsinchu and
was busy to distribute 5x5 LED Matrix board.

The paper is great, it shows us coarse-grained leak like the one through
TLB (the shared resource) is still important.

But... from the libgcrypt developer(s) view, it's somewhat confusing, I
have to say.  I don't know if it's intentional, if not, I wish
improvement for their clarification.

Please note that they have not reported to us.  If had, I would have
complained. :-)


"Michael R. Hines" <mrhines at digitalocean.com> wrote:
> Our team is trying to get an accurate understanding of whether or not 
> the most recent version of libgcrypt does or does not remain vulnerable
> to the timing attack document here: 
> https://www.vusec.net/wp-content/uploads/2018/07/tlbleed-author-preprint.pdf

For an attack to libgcrypt EdDSA described in the paper, it is
irrelevant to _any_ versions of libgcrypt, if "signing" refers the use
of the function _gcry_ecc_eddsa_sign.

I mean, the scenario never occurs in real use case of
_gcry_ecc_eddsa_sign.  In the paper, it says, "We use the non-
constant-time version in this work.", in the second paragraph in section
8 "Temporal Analysis".  I interpret that they changed the code so that
their attack can work for that path.  It is artificial, from my
viewpoint.

In _gcry_ecc_eddsa_sign, the scalar A is allocated in secure memory.
So, it always goes another path, which always call
_gcry_mpi_ec_add_points.

They would have targeted the call of point_set function in the old
version of 1.6.3.  This was fixed in 2015, to use point_swap_cond,
unconditionally.  Version 1.7.0, 1.8.0 or later has this fix.


For an attack to libgcrypt RSA, it is also not the real use case,
but artificial (for 1.6, 1.7 and 1.8).

We keep the old and simple implementation of _gcry_mpi_powm, which can
be enabled with the macro USE_ALGORITHM_SIMPLE_EXPONENTIATION.  Their
target is this code, which is not used since 1.6.0.

Well, in 1.8.0, I modified this implementation too.  So, if they attack
the one in 1.8.0, it won't work.


> In addition to that, more generally, as a cloud provider we are also 
> looking for input and guidance on whether or not there are other 
> locations that should be of concern within libgcrypt from the 
> perspective of TLBleed.

Although their current version of "attacks" are pretty artificial (for
me), their points make sense; There are more possibility of side channel
leaks, along with improvements of signal analysis and reverse
engineering of lower architecture.

We need to remove any non-constant time code.
--