Opened 4 years ago

Closed 3 years ago

Last modified 3 years ago

#17239 closed enhancement (fixed)

Implement new key blinding scheme for proposal 224

Reported by: dgoulet Owned by:
Priority: Medium Milestone: Tor: 0.2.9.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-hs
Cc: Actual Points:
Parent ID: #12424 Points: large
Reviewer: Sponsor:

Description

For next generation hidden service, we need to implement the key blinding scheme and the use of ed25519 keys by the service.

In other word, implement the new keying scheme for hidden service.

Child Tickets

Change History (12)

comment:1 Changed 4 years ago by teor

Severity: Normal

In the current prop224, the key blinding scheme doesn't have a string prefix in its hash: H("key-blind" | ...).

But most of the other hashes do: H("store-idx" | ...), and adding a string prefix to all hashes is mentioned at the top of the document.

Should key blinding have a string prefix?

comment:2 Changed 4 years ago by nickm

I'd be fine having a prefix or customization thing on the hash.

FWIW, the main key-blinding backend routines are already implemented as:

  • ed25519_keypair_blind()
  • ed25519_public_blind()

comment:3 Changed 4 years ago by teor

We send the same blinded key to each HSDir, and use it to encrypt the payload.

This allows the HSDir to descrypt the descriptor, which seems dangerous/unnecessary.
It also allows a HSDir to work out which other HSDirs hold descriptors for the same hidden service.

If we:

  • send different blinded keys to each replica (doing this for spread leaks information), and
  • use a different blinded key for retrieval and encryption,

then the HSDir can't decrypt the descriptor or find the other descriptor replica.
It can only find the other HSDirs in the spread for this descriptor's replica, which it can do using the hash ring anyway.

See for extensive, over-the-top detail:
https://lists.torproject.org/pipermail/tor-dev/2015-November/009884.html

comment:4 in reply to:  3 Changed 4 years ago by teor

Replying to teor:

We send the same blinded key to each HSDir, and use it to encrypt the payload.

This allows the HSDir to descrypt the descriptor, which seems dangerous/unnecessary.

I made a mistake here, the HSDir actually needs the subcredential to decrypt, which is derived from the credential.

So this is what we're doing already with the separate subcredential (encryption) and blinded public key (retrieval):

  • use a different blinded key for retrieval and encryption,

But using different blinded keys per replica means that replicas can't find each other.

Also, what if replicas overlap? We could end up with just 3 HSDirs for a service.

I'll send a patch in the morning addressing these issues and those in #17242.

comment:5 Changed 4 years ago by teor

Please see my spec patch rend-ng-descriptors on https://github.com/teor2345/torspec.git

It adds mitigations for the above issues, each in their own commit, and mitigations for the issues I mentioned in #17242.

comment:6 Changed 4 years ago by teor

Fixes for the issues mentioned above were merged in #17242.

comment:7 Changed 4 years ago by nickm

Milestone: Tor: 0.2.???Tor: 0.2.8.x-final

comment:8 Changed 4 years ago by nickm

Status: newneeds_review

comment:9 Changed 4 years ago by teor

Milestone: Tor: 0.2.8.x-finalTor: 0.2.9.x-final
Status: needs_reviewnew

(Spec changes only, the implementation may not make it into 0.2.8.)

comment:10 Changed 3 years ago by dgoulet

+       [ XX/teor - is the extra load on the HSDirs worth it? ]

Not sure which load you are referencing here but replacing descriptors that have a higher revision counter is imo very cheap.

Your revision counter increment algorithm sounds good to me. The rest also looks good. Would be good to at least get asn or arma or nickm to have a look at it before merge?

comment:11 Changed 3 years ago by dgoulet

Resolution: fixed
Sponsor: None
Status: newclosed

Crypto functions for key blinding are in the tor code. And teor's fixes to the proposal are also merged. This ticket is considered fixed. Using the blinded keys will happen in #17242.

comment:12 Changed 3 years ago by nickm

Sponsor: None

These tickets had Sponsor == "None". Our convention seems to be Sponsor == "".

Note: See TracTickets for help on using tickets.