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

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

I managed to get the UDF draft through the HTML version of the Internet
Draft tools:

https://www.ietf.org/id/draft-hallambaker-mesh-udf-08.html

I am not proposing CFRG do the whole daft. Rather I would propose removing
all the URI and SIN naming components, the motivation sections, etc etc.

On Mon, Jan 6, 2020 at 12:42 AM Phillip Hallam-Baker <[e-mail]>
wrote:

> 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.
>
>