Opened 5 years ago

Closed 12 months ago

#1240 closed task (fixed)

Investigate alternate DH implementations

Reported by: str4d Owned by: zzz
Priority: minor Milestone: 0.9.36
Component: router/transport Version: 0.9.12
Keywords: security performance ntcp ssu Cc:
Parent Tickets: #856, #1112, #2199

Description (last modified by str4d)

tl;dr:

We should examine our current DH protocol and compare it to the ntor and Ace protocols for security and efficiency. We should also look at Tor's overall handshake process, and determine how ntor and Ace might support handshake obfuscation.

The end goal is to decide on the DH protocol that will be used in the next versions of our transports, starting with NTCP2. If we can benefit from the existing 1W-AKE research, we should.


Both NTCP and SSU use a "traditional" Diffie-Hellman key negotiation, combined with a system of hashes, signatures and encrypted blocks to provide authentication and (partial) obfuscation. Ticket #1112 documents progress on fixing a long-present entropy loss bug, along with fully obfuscating the handshake.

But there are other DH protocols available, some of which are probably more efficient and provably more secure. Recently, Tor researchers defined the concept of one-way authenticated key exchange (1W-AKE) between an anonymous client and an authenticated server, and presented the provably secure 1W-AKE protocol ntor.

The original Tor Authentication Protocol (TAP) encrypted the first DH message g^x with the public key of the server. The current ntor protocol uses a DH protocol enhanced with a long-term key of the server g^b, and the session key is H(g^xy, g^xb).

There is another 1W-AKE protocol, Ace, that theoretically computationally faster than ntor (but requires sending twice as many bytes in the first message - g^x1, g^x2). The Ace paper has a good overview of the efficiencies of the various protocols above (compared to insecure unauthenticated DH).

Tor are also looking to make the ntor handshake faster, using various techniques that would probably also apply to Ace.

Subtickets

Change History (8)

comment:1 Changed 5 years ago by str4d

  • Description modified (diff)

comment:2 Changed 5 years ago by zzz

  • Priority changed from major to minor

comment:3 Changed 4 years ago by str4d

<Yawning> " determine how ntor and Ace might support handshake obfuscation"
<Yawning> look at obfs4
<Yawning> which uses obfuscated ntor
<kernelcorn> I don't think they know what NTor is
<Yawning> the ticket is reasonable
<Yawning> and elligator2 isn't that hard to implement
<Yawning> If I were changing the wire crypto for i2p I'd use poly1305/chacha20
<Yawning> but that's just me

comment:4 Changed 4 years ago by str4d

  • Keywords security performance ntcp ssu added

comment:5 Changed 3 years ago by zzz

  • Parent Tickets changed from 856 to 856, 1112

comment:6 Changed 3 years ago by str4d

  • Status changed from new to open

comment:7 Changed 14 months ago by zzz

  • Parent Tickets changed from 856, 1112 to 856, 1112, 2199

comment:8 Changed 12 months ago by zzz

  • Milestone set to 0.9.36
  • Resolution set to fixed
  • Status changed from open to closed

NTCP2 will use X25519 with AES obfuscation. See #2199 and proposal 111.

Note: See TracTickets for help on using tickets.