[tor-dev] Tor with collective signatures

[Tim Wilson-Brown - teor]

> On 6 May 2016, at 19:07, Nicolas Gailly <nicolas.gailly at epfl.ch> wrote:
> 
> Hi,
> 
> First, thanks a lot both of you for your in-depth comments, I know it takes time,
> but they've been very helpful!
> 
> Then I mean to ask you about what you said regarding the fallback
> directory keys. So keys are not embedded but only hashes, OK. As you
> pointed out, CoSi would need to download full descriptors in order to
> safely get the private keys of all the witnesses.
> This solution would need to clearly be defined as you said in order to
> be correct. However, there exists another solution and I'd like to know
> if it looks reasonable in the context of Tor .
> 
> => Considering the two roles of Fallback directory mirrors are different
> (serving the consensus document to Tor /  collectively signing on it),
> we thought it would make sense to create new keys for this role and
> embed those into the Tor source code. These keys would have to be
> ed25519 keys (same size as the ID), so the size overhead
> is minimal (32 bytes * 100 = 3.2KB vs 1.5MB). The only reason I can
> think of why Tor includes hashes instead of public keys is because of
> local storage: How does Tor consider an increase of storage need by 3.2KB ? Is
> it acceptable or not ?
> 
> That would :
> 
> * Bring down the need for exchanging the descriptors between the
> fallbacks / no more bandwidth /
> 
> * No complex scenario such as "fallback key download mechanism"
> 
> * Simplify the verification on the client side also (no need to get the
> keys if you already have them).
> 
> * Add an additional steps for the relays operators where they would need
> to create that key and inform the Tor people about their public key.

This already happens in Tor 0.2.7.6 with ed25519 keys, but we generally have a principle of different keys for different purposes.
So a distinct co-signing key would be a good idea.
However, that key could be placed in relay descriptors for transparency.

> Maybe you thought of this solution and there's a reason why you did not
> mention it, or maybe you did not, then what do you think of it ?

I didn't think through the implications of the small size of ed25519 keys.
Seems like a great design, and I doubt the extra bytes will be an issue.
And I think having a completely separate list is wise for all sorts of reasons.

One request: please don't call this new list "fallback directory mirrors".
Relay operators who consented to being fallback directory mirrors did not consent to other uses for their relay.
So while we could use a similar process to select co-signers, it's a distinct list, and we should give it a distinct name to avoid confusion.

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B
ricochet:ekmygaiu4rzgsk6n



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160506/ea483fab/attachment-0001.sig>