Re: [Cfrg] On the use of Montgomery form curves for key agreement

[Nico Williams <[e-mail]>]

On Tue, Sep 2, 2014 at 4:58 PM, Andrey Jivsov <[e-mail]> wrote:
> On 09/02/2014 02:47 PM, Stephen Farrell wrote:
>> Can you give me an example of such an IETF protocol? Without
>> having thought much about it, I think there are always different
>> codepoints allocated for DH and signatures, and I doubt we'd
>> want the same private values shared anyway, so I'm not sure
>> if that's a real or a theoretical issue.

+1.  We generally strive for key hygiene.  We'd not use a key for
different purposes.

What is the use of using the same key for DH and signatures in the
same protocol?  I can only think of a round-trip optimization, but
what I have in mind is very handwavy and not likely to be a win
(partly because it means losing PFS).

> A few examples of dual-key use and a bit braader question of whether would
> want to add points as oppose to only do scalar multiplication.
>
> Some TLS server side fixed-base optimization will benefit from point
> addition.

Can you give some more details of what this would mean protocol-wise?

> While OpenPGP RFC 4880 has a concept of a "bundle of keys" things are easier
> when the top key can have both encryption and signing capability. There are
> products that add X.509 certs to PGP keys.

Yes, I could see this.  Though key bundles have been around for long
enough (and in widespread enough use) that it doesn't seem likely to
matter much.

> Signing a certificate request for a DH key to prove key possession.

A self-signed DH cert.  OK, this one makes some sense, but if the
price is losing PFS or paying extra CPU cycles if you want PFS, then
it seems not worthwhile.

On the other hand, if using the same key for DH and signatures is
worthwhile, then it seems likely that point form conversion won't be a
big deal.  No?

> Protocols for applications with space-saving requirements : keys on URLs or
> e-mail aliases, pre-generate keys "for everybody" to represent identities.
> Keys that are handled by humans (e.g. typed in base32 encoding), etc

Yes, this is a clear win.  But again, any point conversion penalty
seems minor for such a protocol.

Nico
--