Create 1A-tor-address-encoding-and-encrypted-peer-info.md

[Zolmeister]

Tor Address Encoding and Encrypted PeerInfo

Lifecycle Stage	Maturity	Status	Latest Revision
1A	Working Draft	Active	DRAFT, 2019-05-31

Authors: @Zolmeister

Interest Group: @yusefnapora, others TBD

See the lifecycle document for context about maturity level
and spec status.

Context:

IPNS addresses are encoded as:

peer_id = base58(Multihash_SHA256(protobuf(RSA_PUBLIC_KEY)
# e.g. QmNUhKfcGJyQJnZu3AKn8NoiomDwDCRBicgqPt1YRqJBCz

And added to the DHT like so (~ I think):

PUT(peer_id, PeerInfo, signature)
GET(peer_id) -> PeerInfo, signature

The proposal is to encode IPNS addresses as Tor rend-spec-v3 onion addresses:

peer_id = base32(PUBKEY | CHECKSUM | VERSION)
CHECKSUM = SHA3("peerid checksum" | PUBKEY | VERSION)[:2]

where:
  - PUBKEY is the 32 bytes ed25519 public key
  - VERSION is a 1-byte version field (default value '\x03')
  - "peerid checksum" is a constant string
  - CHECKSUM is truncated to two bytes

# e.g. pg6mmjiyjmcrsslvykfwnntlaru7p5svn6y2ymmju6nubxndf4pscryd

And added to the DHT like so:

PUT(BlindKey, Encrypt(PeerInfo, DeriveKey(peer_id)), signature)
GET(BlindKey) -> EncryptedPeerInfo, signature

Where BlindKey is derived from the ed25519 keypair using Tors derivation scheme, except without key rotation

Note that BlindKey derivation only works for ed25519 keypairs

Encrypt and DeriveKey follow Tors hidden service descriptor encryption key derivation (again without shared random)

Motivation

Adversaries can:

• discover all services by walking the DHT
• monitor changes to PeerInfo of all services
• monitor PeerInfo requests of other members in the network

Scope and Rationale

IPNS address calculation, IPNS DHT read/write and validation

Goals

Significantly improve the privacy of IPNS services

Expected Feature Set: a summary/enumeration of features the spec provides.

Encrypted PeerInfo records and base32 IPNS addressing with inlined signing keys

Tentative Technical Directions

Add a ney KeyType to the public key protobuf

Address Tradeoffs

• base32 for DNS
  • always, ux consistency. no multibase
• version byte at end
  • using a common prefix (Qm) makes it much harder for people to distinguish addresses
  • better vanity addresses
• has checksum
• fixed signing key type
  • public key is always inline
  • changing signing algorithm requires version byte increment, forces consistency within PeerID versions

Additional Notes

• Original writeup: Proposal to migrate PeerIDs to match Tor v3 addresses #139
• All of this is heavily based on Tor rend-spec-v3 which contains much of the implementation details
• PUT(Hash(PeerID), Encrypt(PeerInfo, PeerID)) (proposed elsewhere)
  • cannot be signed, because signature verification would require revealing PeerID to parties before inserting into the DHT
• Unlike Tor, BlindKeys are not rotated daily using a shared random value
  • The consquences of this have not been explored thorougly
    • One point though is that the position within the DHT does not change over time (so certain network nodes could be targeted for DOS)
• Tor additionally supports a second encryption layer for records for access control (a 'password' to access the service after querying the DHT)
• Tor additionally pads their descriptors with NUL bytes to 10k, and 'stubs' extra fields to shield access controlled descriptors (which are longer)
• I would have liked to have added the shared random BlindKey rotation, but could not find a suitable generation scheme
  • Tor uses a voting consensus system among their special HSDir servers
  • Algorand does some neat tricks with VRF, but relies on crypto-assets

[raulk]

@yusefnapora would you mind taking the lead in adjusting this doc to the new header format, and in identifying the appropriate members of the Interest Group?

[yusefnapora]

Definitely. Thanks for making this @Zolmeister, we should definitely get an Interest Group formed up around this. @Stebalien @jhiesey @bigs, would any of you be interested?

To summarize a bit, it sounds like the end goal of this proposal is a more privacy-preserving IPNS, in which peers publish DHT records whose keys are a blind key (derived from their primary ed25519 identity) and whose values are encrypted peer info.

@Zolmeister I wasn't quite clear on why this requires a new KeyType. Are the derived keys a different type than ed25519?

[Zolmeister]

@yusefnapora I'm not sure it does, but it seemed like a way to avoid a similar situation as #138, #111

[yusefnapora]

I see, that makes sense. The inlining of keys is a bit of a problem at the moment.

I have a question for the group at large - are IPNS addresses required to also be peer ids? Or could this proposed encoding be considered a valid IPNS address, but not necessarily a peer id? That would let @Zolmeister define an encoding with as much metadata as necessary, and with the ed25519 key type restriction, which doesn't feel to me like it makes sense as part of the peer id definition.

Anyway, this sounds like an interesting direction to explore.

I'll be a bit delayed in my responses next week, as I'll be moving to a new house a few states away. But please @ me if there's something I can help with.

[Zolmeister]

Ping @vyzo @jamesray1 @daviddias @ivilata @richardschneider @lgierth @marten-seemann @dryajov
I would appreciate some feedback here

[vyzo]

How will this work in practice? It breaks compatibility with the existing system completely.

[Zolmeister]

@vyzo Yes, these changes will not be backwards compatible with existing nodes.
Necessarily, because PeerInfo privacy is the feature being added.
Support for the KeyType will be added, and then at a later point can be made the default (once enough of the network has updated).