Re: [Cfrg] [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement

[Robert Ransom <[e-mail]>]

On 1/12/14, Daniel Kahn Gillmor <[e-mail]> wrote:
> On 01/12/2014 07:57 AM, Alyssa Rowan wrote:
>>     · Fast hardware performance is a negative in a PBKDF or a Hashcash,
>>       which we actually want to be slow to measure out workfactor of
>>       brute-force.
>>     · But it's a positive in a signature scheme, as long as the hash is
>>       strong enough to resist any plausible second-preimage attack.
>>     · And it [keccak] is.
>>     · A collision would not suffice here.
>
> What makes you say that a collision attack isn't relevant against a
> signature scheme?  The classic collision attack against a signature
> scheme is:
>
>  * attacker generates A, B, such that H(A) = H(B)
>  * attacker asks victim to sign A
>  * victim signs A over digest H
>  * attacker applies signature to B
>
> This is how the hashclash/rogue-CA project did its work [0], and it's a
> conceivable attack against anything from OpenPGP certifications to
> document signatures to revision control [1].
>
> Or am i misunderstanding the context in which you're saying that a
> collision would not suffice?

In the specific case of an EdDSA-like Schnorr signature scheme, the
*beginning* of the input to the message hash function would be
unpredictable to the attacker (thus achieving ‘randomized hashing’ for
free).  This makes collision attacks harder with any reasonable hash
function.

(Note that Schnorr's original signature scheme put R at the *end* of
the hash input; that would not mitigate collision attacks.)


Robert Ransom