Hi Chris,
I'd rather not get into the "slow" part, but I'm sure it could be
faster. I've just posted to dev-crypto about a projective coordinates
patch that may improve things for some curves.
Timing attacks are a big topic, but I think it's fair to say in general
that if timing attacks are a concern for your particular application,
you should not use BC's EC implementation. At least not without taking
steps to mitigate any side-channel.
Having quickly read the paper referred to in the comments ("OpenSSL
timing attack you mention" -> http://eprint.iacr.org/2011/232.pdf), it
seems the particular attack is not relevant to BC. However, BC does not
implement the Montgomery ladder at all, so is vulnerable as described in
the Introduction.and in many other papers.
We are, of course, interested in improving this situation, but short on
time to do so.
Pete.
On 3/07/2013 1:43 AM, Mankowski, Chris wrote:
I'm comparing the performance of UProve using ECC groups versus Subgroups
and the consensus at the forum below is that the ECC implementation in C#
is too slow, and possibly subject to a timing attack.
Is this a valid concern?
http://security.stackexchange.com/q/38169/396
**********************************************************************
Notice: This e-mail message and any attachment to this e-mail message may
contain information that is confidential, proprietary, privileged, legally
privileged and/or exempt from disclosure under applicable law. If you are not
the intended recipient, please accept this as notice that any disclosure,
copying, distribution or use of the information contained in this transmission
is strictly prohibited. NFP reserves the right, to the extent and under
circumstances permitted by applicable law, to retain, monitor and intercept
e-mail messages to and from its systems.
Any views or opinions expressed in this e-mail are those of the sender and do
not necessarily express those of NFP. Although this transmission and any
attachment are believed to be free of any virus or other defect that might
affect any computer system into which it is received and opened, it is the
responsibility of the recipient to ensure that it is virus free and no
responsibility is accepted by NFP, its subsidiaries and affiliates, as
applicable, for any loss or damage arising in any way from its use.
If you have received this e-mail in error, please immediately contact the
sender by return e-mail or by telephone at 212-301-4000 and destroy the
material in its entirety, whether electronic or hard copy format.
