Re: [tor-dev] Safe Alternative Uses of Onion Service Keys

[Matthew Finkel <sysrqb@xxxxxxxxxxxxxx>]

On Mon, Aug 10, 2020 at 09:00:32AM -0400, Nick Mathewson wrote:
> On Wed, Jul 29, 2020 at 1:15 AM Matthew Finkel <sysrqb@xxxxxxxxxxxxxx> wrote:
> >
> > Hello everyone,
> 
> Hi, Matt!
> 
> There's a part of this that I'm still trying to figure out:
> 
> > The safest usage of the long-term keys for alternative purposes I see
> > appears to be by deriving a (fixed/deterministic) blinded key pair using
> > the same scheme that Tor uses, and signing/verification simply follow
> > the same process as Tor, except the derived keys need not rotate
> > periodically (is this true?). The derived key should be used for
> > certifying a freshly generated ed25519 key, which is used in the
> > application protocol. For example, if I want to use a key for code
> > signing such that it is bound to my onion service key, then I could
> > derive a certifying key by following Tor's derivation scheme, by
> > substituting:
> >
> >   BLIND_STRING = "Derive temporary signing key" | INT_1(0)
> >   N = "key-blind" | INT_8(period-number) | INT_8(period_length)
> >
> > with
> >
> >   BLIND_STRING = "Derive code signing key" | INT_1(0)
> >   N = "code-sigining-key-blind" | "v0" | "YYYY-MM-DD" |  INT_8(validity_period)
> 
> In the case of v3 onion services, 'period-number' comes from the
> current time, and 'period-length' comes from the consensus, so it's
> easy for the client to know what parameters to use when deriving the
> key.
> 
> But how is the party that relies on the derived key supposed to know
> what values were used for "YYYY-MM-DD" and "validity period" in this
> case?  It seems like those two values would need to be shipped along
> with the key, which could make for logistical issues.

I was imagining "just serialize it in the public key". The public key
would grow by a few more characters, but not too much. In this case,
we'd probably want a defined (extensible) structure for the public key
rather than each application defining their own arbitrary format, but I
didn't get that far in thinking about it.
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev