Re: [Cfrg] Handling invalid points

[Natanael <[e-mail]>]

Den 22 nov 2014 01:57 skrev "Michael Hamburg" <[e-mail]>:

> 3)
>
> Another form of “attack” would be to cause two implementations to produce
> different results for a supposedly deterministic computation, eg a
signature
> check.  For example, in the Ed25519 paper, you specify:

[...]

> In both these systems, implementations are allowed to differ when given
inputs
> that are wrong by a small-order amount.  There are more ways to specify
this
> sort of laxness with cofactored curves, though behavior should be
testable by
> vectors if the specification goes one way or the other.
>
> Again, it’s not clear that this constitutes an attack, but it is
something to
> consider when deploying such a system.

The type of attacks that come to mind are consensus breaking attacks,
rather than pure cryptographic attacks.

Making some people believe everybody had received a valid order while some
will believe they were sent a bogus one which they reject (insider
sabotage?) over some broadcast medium. Would be detectable after the fact,
but could cause enough damage to be worth it for the attacker before then.

In the worst case scenario you could frame somebody this way if you know
the implementation they use right now will respond in one way but will soon
be updated/replaced to behave in the other way, and in which his superiors
already use the latter method. This provides for a very slim attack window,
but the risk is real.
You can make the verification fail, which he later would be unable to prove
after the change when he is asked why he didn't follow orders.
Or vice versa, make him follow an order that the software used by the
superiors will reject the signature on. Again, a claim he can't prove after
the change.

Also, for cryptocurrencies you could cause a fork between clients using
different signature verification implementations, making one side believe
the blockchain with a certain transaction to be invalid while the other
side doesn't.