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

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

I just saw a practical use case that justifies application of threshold
cryptography in (n,t) fashion at the ECDH level rather than using release
of a static symmetric key to unlock a private key for use.

Consider the case in which a service might be compromised and the private
key extracted. We split the private key across multiple servers (e.g. 3)
put them in different data centers and we perform each private key
operation on all three. The (2,3) quorum allows for fault tolerance when
one of the servers fails or is unable to communicate.

So at this point it seems best to move the Shamir Secret Sharing scheme
into the threshold spec. But I will wait on comment on that before going
ahead.

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