wrbt:促进 cjdns 对等互连的协议

  • G0_479289
  • 17.6KB
  • zip
  • 0
  • VIP专享
  • 0
  • 2022-06-14 04:26
写字 wrbt ,发音为wrabbit ,是一种促进 cjdns 节点对等互连的协议。 通过wrbt对等的两方能够通过不安全的通道安全且私密地交换凭据。 Alice 和 Bob 拥有的两个 cjdns 节点的对等互连是这样的。 Alice刚刚建立了一个新节点,需要一个peer,所以她生成了一组完全独立于她的cjdns密钥的私钥和公钥。 让我们分别称这些为wrbtSk和wrbtPk 。 Alice 通过不安全的通道向对等方发送请求。 由于频道不安全,我们不妨假设它是面向全世界的公共广播。 scheme://host/?type=peer&interface=udp&link=overlay&pk=wrbtPk&metadata=metadataOfAlice&cjdnsVersion=X&wrbtVersion=Y Bob 看到 Alice 的请求并提供给对等方。 他从他的节点为 A
  • wrbt-master
  • README.md
wrbt ==== **wrbt**, pronounced *wrabbit*, is a protocol that facilitates peering of cjdns nodes. The two parties peering through **wrbt** are able to exchange credentials securely and privately over an insecure channel. Peering of two cjdns nodes, owned by Alice and Bob, goes something like this. 1. Alice just set up a new node and is in need of a peer, so she generates a set of private and public keys that are completely independent of her cjdns keys. Let's call these `wrbtSk` and `wrbtPk`, respectively. 2. Alice sends out a request to peer via an insecure channel. Since the channel is insecure, we may as well assume it's a public broadcast to the entire world. ``` scheme://host/?type=peer&interface=udp&link=overlay&pk=wrbtPk&metadata=metadataOfAlice&cjdnsVersion=X&wrbtVersion=Y ``` 3. Bob sees Alice's request and offers to peer. From his node, he generates a new password for Alice and adds it to the list of `authorizedPasswords` in his node's **cjdroute.conf**. ``` { "name": "Alice", "password": "generatedPasswordForAlice" } ``` 4. Bob then composes the following peering credential. ``` { "externalIpOfBob:port": { "name": "Bob", "publicKey": "cjdnsPublicKeyOfBob", "password": "generatedPasswordForAlice" } } ``` 5. With that peering credential and some optional `metadata`, Bob composes the `node` JSON blob and signs it with his cjdns private key to get `signatureOfBob`. ``` { "credentials": [ { "node": { "credential": { "externalIpOfBob:port": { "name": "Bob", "publicKey": "cjdnsPublicKeyOfBob", "password": "generatedPasswordForAlice" } }, "metadata": {} }, "signature": "signatureOfBob" } ] } ``` 6. Bob encrypts the whole JSON blob with Alice's `wrbtPk` and a `generatedNonce`, resulting in `encryptedCredentialsForAlice`, then responds to Alice either synchronously with, ``` { "encryptedCredentials": "encryptedCredentialsForAlice", "nonce": "generatedNonce" } ``` or asynchronously, where `encodedMessage` is the above JSON blob URL-encoded. ``` scheme://host/?type=credentials&interface=udp&link=overlay&pk=wrbtPk&message=encodedMessage&cjdnsVersion=X&wrbtVersion=Y ``` 7. In the asynchronous case, Alice is able to know that this is a response to her earlier request based on the `scheme://host` and `wrbtPk`. The latter also ensures that only she can decrypt the `encryptedCredentialsForAlice`. Alice proceeds to decrypt the message with her `wrbtSk` and `generatedNonce`, revealing the plain text `credentials`. Alice then attempts to verify that the `credential` actually came from the cjdns node's operator, i.e. the holder of its cjdns private key. So Alice takes the `publicKey` from `credential` and hashes it with the `signature`, and verifies that it matches with the hash of the `node`. The application then proceeds to ask Alice whether she wants to peer with the following node. ``` Name: Bob Protocol: UDP via Clearnet Overlay Address: fc00:0000:0000:0000:0000:0000:0000:BBBB Verified: true ``` 8. Alice accepts the peering offer and the application adds `credential` to **cjdroute.conf** of Alice's node. Her node starts connecting to Bob's node. 9. Bob's node sees connections coming in from Alice's node `fc00:0000:0000:0000:0000:0000:0000:AAAA` and optionally pins it to the entry for Alice in `authorizedPasswords`, so that password becomes dedicated to her node only. >**IP-pinning** is optional. ## Cross-platform Peering & Platform-specific Handling One way the [Android application](https://github.com/berlinmeshnet/cjdns-android) can add peers is through the `http://findpeer.hyperboria.net` implementation of **wrbt**. When Caleb installed the Android application, he does not know anyone on Hyperboria, so he tweeted the following message generated by the Android app, in hopes that someone will offer to peer with his Android node. ``` #followTheWhiteRabbit findpeer.hyperboria.net/?type=peer... ``` The URL, shortened by Twitter, expands into something like this when clicked. ``` http://findpeer.hyperboria.net/?type=peer&interface=udp&link=overlay&pk=wrbtPk&metadata=metadataOfCaleb&cjdnsVersion=X&wrbtVersion=Y ``` Danielle, who actively monitors the **#followTheWhiteRabbit** hashtag, is on her computer when she saw the tweet. That computer is already a cjdns node, so she decides to use a **wrbt** desktop application to generate a response, offering to peer with Caleb. The desktop application takes Caleb's URL as an input, and does all the **wrbt** magic as described above, resulting in the following which Danielle replies to Caleb with via Twitter. ``` http://findpeer.hyperboria.net/?type=credentials&interface=udp&link=overlay&pk=wrbtPk&message=encodedMessage&cjdnsVersion=X&wrbtVersion=Y ``` Ed, who saw Caleb's tweet from his phone, also happens to have cjdns running on his phone with the Android application. He clicks on the link, and is asked if he wants to open the link with the cjdns application, because application advertises itself as a handler for the scheme `http` and host `findpeer.hyperboria.net`. This allows the cjdns Android app to do what the desktop app did for Danielle. Faye saw the tweet on her laptop, has no idea what this is, but clicks on the link anyways. She is directed to a welcome page, introducing her to the wonderful world of Hyperborea. Georgina, who also knows nothing about the existance of a parallel internet, clicked on the tweet from her Android phone. `findpeer.hyperboria.net` is set up in a way that redirects all Android clients to `market://details?id=cjdns.android.package.name`, which opens up the cjdns Android application download page in Google Play. ## Auto-peering & Implementation-specific Behaviour The implementation-specified `scheme://host` allows for implementation-specific behaviour. The previous example, `http://findpeer.hyperboria.net`, is only one example for an implementation. It is one where peering is asynchronous, requiring the other party to extend a delayed response after manually deciding to peer with Caleb, perhaps based on some criteria embedded in the [metadata](#optional-metadata). You can easily imagine a cjdns node that synchronously hands out unique credentials to whoever asks for it at `http://[fc00:0000:0000:0000:0000:0000:0000:XXXX]`. This, of course, requires Caleb to have an existing peer to reach it in the first place. This same server can also hand out credentials in the clearnet by having a clearnet domain. Unrestricted handing out of peering credentials is probably self-destructive, but **wrbt** does not limit one from implementing whatever self-destructive behaviour. On the other hand, it ensures that the exchange of credentials and other private information are conducted in a secure manner, and by enforcing a unique password per peer, it allows the node to break away from any particularly abusive relationship. The node can also engage in hook-ups by issuing passwords that expire, i.e. removal from `authorizedPasswords` after some fixed time. ## Privacy & Anonymity The private exchange of peering credentials is protected by `wrbtSk` and `wrbtPk`. It is important that each responding node generates a unique nonce when using `wrbtPk` to generate the `encryptedCredentials`. Aside from the peering credentials, **wrbt** aims to keep the relation between the identity of a node, i.e. its `fc00::/8` address, and its operator from becoming public information. When Alice first advertises that she needs to find a peer, she has exposed that she operates a node associated with whatever metadata embedded in that peering request. However, that request does not contain her cjdns public key or `fc00::/8` address, so her node cannot be uniquely identified based on that informa
    • dns-info:使用Node获取DNS信息
      提取DNS信息。 dnsInfo ( 'reaktor.fi' ) . then ( function ( info ) { console . log ( info ) } ) 或者 dnsInfo ( { domain : 'reaktor.fi' , server : { address : '' , port : 53 , type : 'udp...
    • TCP-UDP-DNS-Server-in-C:使用TCPUDP套接字Linux套接字编程
      网络编程 使用TCP / UDP套接字Linux套接字编程
    • UDP抓包分析和存盘.rar
    • Go-DNS-over-QUIC到UDP代理
    • LWIP-udp-DHCP-DNS
    • iOS UDP demo
      关于iOS UDP编程的一个小demo 一目了然。只试用于初学者,了解原理。
    • UDPDemo传输
    • native-dns-server:功能齐全的 UDP DNS 服务器
      本机 DNS 服务器 功能齐全的 UDP DNS 服务器,改进了提供的基本服务器实现。 文档 即将推出。 执照 麻省理工学院
    • java-dns-query:使用 Java 和 UDP 的简单 DNS 查询
      java-dns-查询 使用 Java 和 UDP 的简单 DNS 查询 如何构建 mvn package 如何使用 java -cp ./target/dnsquery-1.0-SNAPSHOT-jar-with-dependencies.jar com.company.app.Main
    • udp2tcp-开源
      udp2tcp 是一个小而通用的工具,用于通过 TCP 转发 UDP 数据报(即,通过 TCP 封装 DNS 请求)。 当您正在寻找的服务也可以侦听 TCP 并且您的防火墙丢弃 UDP 数据报时很有用。