[tor-dev] prop224: Ditching key blinding for shorter onion addresses

[bancfc at openmailbox.org]

On 2016-07-29 17:26, George Kadianakis wrote:
> Hello people,
> 
> this is an experimental mail meant to address legitimate usability 
> concerns
> with the size of onion addresses after proposal 224 gets implemented. 
> It's
> meant for discussion and it's far from a full blown proposal.
> 
> Anyway, after prop224 gets implemented, we will go from 16-character 
> onion
> addresses to 52-character onion addresses. See here for more details:
> 
> https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt#n395
> 
> This happens because we want the onion address to be a real public key, 
> and not
> the truncated hash of a public key as it is now. We want that so that 
> we can do
> fun cryptography with that public key. Specifically, we want to do key 
> blinding
> as specified here:
> 
> https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt#n1692
> 
> As I understand it the key blinding scheme is trying to achieve the
> following properties:
> a) Every HS has a permanent identity onion address
> b) Clients use an ephemeral address to fetch descriptors from HSDir
> c) Knowing the ephemeral address never reveals the permanent onion 
> address
> c) Descriptors are encrypted and can only be read by clients that know
> the identity onion key
> d) Descriptors are signed and verifiable by clients who know the
> identity onion key
> e) Descriptors are also verifiable in a weaker manner by HSDirs who
> know the ephemeral address
> 
> In this email I'm going to sketch a scheme that has all above
> properties except from (e).
> 
> The suggested scheme is basically the current HSDir protocol, but with 
> clients
> using ephemeral addresses for fetching HS descriptors. Also, we 
> truncate onion
> address hashes to something larger than 80bits.
> 
> Here is a sketch of the scheme:
> 
> ------
> 
> Hidden service Alice has a long-term public identity key: A
> Hidden service Alice has a long-term private identity key: a
> 
> The onion address of Alice, as in the current scheme, is a truncated 
> H(A).
> So let's say: onion_address = H(A) truncated to 128 bits.
> 
> The full public key A is contained in Alice's descriptor as it's
> currently the case.
> 
> When Alice wants to publish a descriptor she computes an ephemeral 
> address
> based on the current time period 't': ephemeral_address = H(t || 
> onion_address)
> 
> Legitimate clients who want to fetch the descriptor also do the same, 
> since
> they know both 't' and 'onion_address'.
> 
> Descriptors are encrypted using a key derived from the onion_address. 
> Hence,
> only clients that know the onion_address can decrypt it.
> 
> Descriptors are signed using the long-term private key of the hidden 
> service,
> and can be verified by clients who manage to decrypt the descriptor.
> 
> ---
> 
> Assuming the above is correct and makes sense (need more brain), it 
> should
> maintain all the security properties above except from (e).
> 
> So basically in this scheme, HSDirs won't be able to verify the 
> signatures of
> received descriptors.
> 
> The obvious question here is, is this a problem?
> 
> IIUC, having the HSDirs verify those signatures does not offer any 
> additional
> security, except from making sure that the descriptor signature was 
> actually
> created using a legitimate ed25519 key. Other than that, I don't see it
> offering much.
> 
> So, what does this additional HSDir verification offer? It seems like a 
> weak
> way to ensure that no garbage is uploaded on the HSDir hash ring. 
> However, any
> reasonable attacker will put their garbage in a descriptor and sign it 
> with a
> random ed25519 key, and it will trivially pass the HSDir validation.
> 
> So do we actually care about this property enough to introduce huge 
> onion
> addresses to the system?
> 
> Please discuss and poke holes at the above system.
> 
> Cheers!
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev


Speaking out of turn here:

Why not integrate kernelcorn's OnioNS project and keep all the current 
security properties?

OnioNS addresses are much more user friendly than even the shorter 
.onion addresses.