Re: [CFRG] compact representation and HPKE

[denis bider <[e-mail]>]

I really dislike this sort of idealism, it's like purporting that proper
communism simply hasn't been tried yet.

In theory, a cryptographic library would implement a high-level interface
that (1) covers the way an algorithm is used in the protocol you're
implementing, (2) covers all the niche cases of use in that protocol.

In practice, the cryptographic (1) has some well-intended high-level
interfaces, which happen to not support the exact way the algorithm is used
in the protocol you're implementing, or (2) it doesn't cover all the niche
cases of use in that protocol.

So, as is the case with most abstractions, eventually you realize that you
have to bypass the abstraction and go to the nuts and bolts. Your life is
made much easier that way.

Cases in point:

- Windows CNG implements nice abstractions for DH and ECDH, and since these
abstractions are so nice and safe, there is no way provided to access the
agreed value. Instead you have a bunch of computations you can apply to the
agreed value, which works for protocols like TLS.

But none of those functions work for SSH. So how do you get the agreed
value for SSH? Trade secret that involves accessing internal Windows CNG
structures which have changed multiple times as Windows is auto-updated,
requiring the software to be updated as well.

- In the case of OpenSSL, the easiest way I've found to initialize an
ECDSA/secp256k1 public key from its SSH encoding is by
calling EC_KEY_set_public_key_affine_coordinates, which involves BN_bin2bn
to convert x and y.

There may be a more "kosher" way, but this works and fits my usage.

So. I really dislike "but the proper way to use it is our well-meant
high-level abstraction", cause it boils down to a design for hypothetical
theory instead of for useful practice.

denis


On Tue, Feb 16, 2021 at 12:40 AM Billy Brumley <[e-mail]> wrote:

> > I think Karthik is on the right track here.  While the compact
> representation undoubtedly has its benefits, it seems like there is no
> disagreement that it is not widely supported in either standards or crypto
> libraries.  So there is a sizable community for whom a requirement to use
> the compact format would render HPKE unusable.
>
> In the case of OpenSSL, I disagree.
>
> If you (=application developer) are dealing with points directly in
> OpenSSL, you are probably already doing it wrong.
>
> Using the correct abstractions in OpenSSL, whether a "point" has 1, 2,
> 3, or 42 coordinates shouldn't matter. In fact when using the correct
> abstraction in OpenSSL, you shouldn't know it's a point at all. Just a
> byte string.
>
> So I support this one, in the spirit of forward thinking, rather than
> propagating ideas from two decades old standards
>
> > (1) A technically superior approach (x-coordinate only)
>
> I would suggest soliciting an opinion from the OpenSSL OTC before
> making any decision based on perceived API difficulties.
>
> My 2c, having never even read the HPKE draft.
>
> BBB
>
> _______________________________________________
> CFRG mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg
>