[Cfrg] Proposal: Threshold cryptography for CFRG curves + UDF

[Phillip Hallam-Baker <[e-mail]>]

All,

I have just submitted two new drafts:

https://www.ietf.org/id/draft-hallambaker-threshold-00.html
https://www.ietf.org/id/draft-hallambaker-threshold-sigs-00.html

I wish to (in due course) propose these as CFRG work items together with
the existing draft:

https://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html

(should have a proper HTML version of above soon, stress test on the tools.)

These are of course work that is motivated by my work on the Mathematical
Mesh. And since the obvious question for the IESG to ask is whether CFRG
has looked at the crypto, it probably makes sense to begin by discussing
the crypto here.

But more importantly, the Mesh is merely a vehicle to try to persuade the
field to start using some post 1990s crypto. So it isn't a problem for me
if the outcome is we end up putting threshold decryption into legacy CRM
schemes rather than deploying my new one.


The first draft describes the addition of three new capabilities to the
X25519 / X448 / Ed25519 / Ed448 repertoire:

1) Threshold Decryption (n, n)
2) Threshold Key Generation
3) Side channel disclosure resistance

The implementation of threshold signature is described in a separate draft.
Two schemes are described for Ed25519/Ed448

1) Unanimous threshold i.e. (n, n)
2) Quorate threshold, i.e. (n, t)

The third document describes the presentation of certain types of
cryptographic material that it is necessary for people to interact with
under certain circumstances. This began as a very tightly constrained piece
of work to 'do digest fingerprints right'. It has since grown in response
to requests and now has some capabilities that I think really need some
CFRG input:

1) Deterministic functions for generating ECDH and RSA keys from a
specified key via a KDF
2) Shamir secret sharing for escrow of encrypted keying material
3) Shamir secret sharing for escrow of seed used to generate key pairs

As previously discussed on the list, the threshold signatures are not
aggregate signatures. They are however compatible with the existing RFC7748
and RFC8032 curves and algorithms and that is my overarching goal. I am
aware of the BLS work but I don't see it as overlapping. There are numerous
references and citations missing including to previous IETF/IRTF proposals.
I am more than willing to share authorship. The key thing is to move the
work ahead.

Many thanks to all those who have helped on or off the list. Will be
following up to ask folk who helped me offlist if they want their names
mentioned in the acknowledgements. Also need to chase down the references
to source.

Security considerations are intentionally left blank as I think it better
to start this only after the scope is understood or things get missed.


Questions:

1) Should CFRG look at any/all of this work?

2) Is (n,k) quorum Threshold decryption worth adding?

3) UDF provides two escrow models at present, do we need to add in direct
escrow of the private keys?

4) If threshold signature is worth doing, should there be one threshold
spec for the  RFC7748 and RFC8032 curves or keep these as two?

5) I was planning to kill OID UDFs, they were originally added as a way to
allow QR code transmission of private keys and then Michael Richardson gave
me a better idea.

I understand that UDF might be a little on the 'lite' side and not so
suited to CFRG. But I would like people to take a look at the deterministic
key gen because it solves a very important problem a lot of sysadmins face
today: how to keep SSH keys in sync across machines. Some of the
instructions given on the net on how to do this are pitiful.

This technique is not as simple or easy to use as the Mesh of course, but
it does support 'offline' and 'paper' pretty well.