Re: [Cfrg] Hardware requirements for elliptic curves

[Dirk Feldhusen <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
Am 15.09.2014 14:50, schrieb Alyssa Rowan:
> On 15 September 2014 11:53:28 BST, "Lochter, Manfred" <[e-mail]> wrote:
> > you are right when you assume that Brainpool users can live with what
> > they
> > have, if Brainpool-like curves will be mandatory to implement for TLS
> > 1.3.
>
> The question of what should be MTI in TLS 1.3 and why is plainly a
matter for the upstream TLS list to debate, not CFRG.
>
> If people want random primes, Brainpool already gives you those -
that's Watson's point. I don't think that's what upstream are looking
for, though. If people wanted that, they'd be using it already: yet UTA
actually removed Brainpool from their draft recommendations recently due
to its rarity and performance.
>
> It just doesn't look like the pendulum's swinging that way, and I can
see why: the relatively poor performance of Brainpool-class random
primes in software; the difficulty of securing generic elliptic curve
software routines against timing side-channels; and the sheer
cost-multiplication potential of a proposal to mandate the option of
using relatively-inefficient crypto near-universally across the web -
including at CDN scale!? I think personally you'd face a massive uphill
struggle arguing for random curve support to ever be anything better
than MAY. But that's something I reckon you should take over to those
lists if you *really* want to raise it? (I'll bring marshmallows! <g>)

I don't understand why securing generic elliptic curve implementation
should be harder. Regularised scalar multiplication methods are
quite standard in security implementations. But (nearly) time constant
modular multiplication or LIM routines for fixed bit length I've seen up
to now only in hardware. Contrariwise for software implementations, see
the for instance bunch of publications on RSA timing attacks. Why there
are no time dependencies on the arguments for  modular multiplication
with special primes?
Even when the algorithm is time constant in theory there could be
properties of the hardware which could complicate the situation, for
instance the bug attacks (Crypto 2008) or cache timing attacks on the AES.
Side channel resistance is a property of the software together with the
underlying hardware.

Cheers,
Dirk

(where are the marshmallows?)


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
 
iEYEARECAAYFAlQW+OAACgkQQ9KtQ4ejsgyxOgCfTiU3dYWL5GHOSeLS1HH5hItw
YB0AoMc3X2eq8FMnZkoXRy1nbtRxJ6iE
=f3v7
-----END PGP SIGNATURE-----