Opened 3 years ago

Last modified 2 years ago

#18638 assigned task

Write a proposal for PK handshake that uses more client resources than server.

Reported by: nickm Owned by: yawning
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-dos, tor-dos-designs, research-program
Cc: Actual Points:
Parent ID: Points: 3
Reviewer: Sponsor: SponsorU-can

Description

Our current handshakes (TLS, TAP, ntor, and ) all have resource asymmetries: a client can send junk with very little effort, and thereby cause a server to spend more CPU. We could instead look for ways to make sure that a client cannot force servers to spend X resources without themselves spending something in vicinity of X resources.

Child Tickets

Change History (18)

comment:1 Changed 3 years ago by nickm

Parent ID: #17280

These tickets are could-do for #17280.

comment:2 Changed 3 years ago by yawning

(Do we care about TAP given that we will kill it in the medium term and it's de-prioritised?)

For ntor, perhaps something like:

Client generates X,x as usual, and additionally calculates k = EXP(B,x).
In addition to the current values, client also sends SHA3-256(tweak | k | NODE_ID | KEY_ID | CLIENT_PK).

The server needs to calculate EXP(X,b) as part of the full ntor handshake, so this only adds a SHA3 call and a compare server side, and gives the server the opportunity to abort the handshake early if the client is sending garbage keys (cuts out 1 scalar basepoint multiply, 1 scalar multiply, and 3 HMAC calls).

(Replace SHA3-256 with HMAC-SHA256 if appropriate)

comment:3 Changed 3 years ago by nickm

A good start! (No, let's say we don't care about TAP.)

There is still a DoS force multiplier in this design, though, to the extent that computing Xb is slower for the server than sending a fake X is for the client.

I wonder if we can raise the cost somehow.

comment:4 Changed 3 years ago by nickm

Owner: set to nickm
Status: newaccepted

comment:5 Changed 3 years ago by mikeperry

Keywords: tor-dos added; dos removed

Canonicalize dos tag to tor-dos

comment:6 Changed 3 years ago by nickm

Keywords: tor-dos-designs added

comment:7 Changed 3 years ago by isabela

Points: medium/large4.5

comment:8 Changed 3 years ago by nickm

Points: 4.53

comment:9 Changed 3 years ago by nickm

Owner: nickm deleted
Status: acceptedassigned

by no means sure that I can get to these.

comment:10 Changed 3 years ago by nickm

Status: assignednew

Put all unowned "assigned" tickets back into "new".

comment:11 Changed 3 years ago by yawning

Owner: set to yawning
Status: newassigned

Taking this for 0.2.9, though I'm not sure I can come up with much better than what I sketched out, that doesn't involve the phrase "proof of work".

comment:12 Changed 3 years ago by nickm

Keywords: nickm-deferred-20160905 added
Milestone: Tor: 0.2.9.x-finalTor: 0.2.???

Hi, Yawning! I'm deferring these tickets assigned to you from 0.2.9 to 0.2.???, since you're going to be out for September. But if you wind up wanting to do any of them for 0.2.9 anyway, please feel free to move them back.

(This is my ticket-deferring afternoon)

comment:13 Changed 3 years ago by nickm

Parent ID: #17280

Unparenting, to close parent.

comment:14 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:15 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:16 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:17 Changed 2 years ago by nickm

Keywords: nickm-deferred-20160905 removed

comment:18 Changed 2 years ago by nickm

Keywords: research-program added
Note: See TracTickets for help on using tickets.