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. 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 ? Cheers, Nicolas
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev