mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

updated design

Browse source 
more details on using tor and pairing
This commit is contained in:
Joey Hess 2016-11-14 12:10:09 -04:00
parent 989520a104
commit a7fd200440
No known key found for this signature in database
GPG key ID: C910D9222512E3C7
1 changed files with 54 additions and 48 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

102
doc/design/assistant/telehash.mdwn
View file

@ -46,9 +46,13 @@ or [cjdns](https://github.com/cjdelisle/cjdns) or tor or i2p or [magic wormhole]
* Awesome. * Awesome.
* Easy to install, use; very well known. * Easy to install, use; very well known.
* May need root to set up a hidden service.
* There's been some [haskell packages developed recently](http://www.leonmergen.com/haskell/privacy/2015/05/30/on-anonymous-networking-in-haskell-announcing-tor-and-i2p-for-haskell.html) * There's been some [haskell packages developed recently](http://www.leonmergen.com/haskell/privacy/2015/05/30/on-anonymous-networking-in-haskell-announcing-tor-and-i2p-for-haskell.html)
to communicate with tor and set up onion addresses for a service. to communicate with tor and set up onion addresses for a service.
Could be used to make git-annex run as a hidden service. Could be used to make git-annex run as a hidden service.
However, that relies on tor being configured with a ControlPort,
without authentication. The normal tor configuration does not enable a
ControlPort.
## i2p status ## i2p status
@ -60,71 +64,73 @@ or [cjdns](https://github.com/cjdelisle/cjdns) or tor or i2p or [magic wormhole]
* doesn't require a running daemon * doesn't require a running daemon
* can transfer arbitrary blobs (strings, directories, files) * can transfer arbitrary blobs (strings, directories, files)
## implementation basics ## general design
* Add a telehash.log that maps between uuid and telehash address. * Make address.log that contains (uuid, transport, address, Maybe authtoken)
Or let's generalize it a bit; since things like snow work close enough * The authtoken is an additional guard, to protect against transports
to the same. Make it address.log and map between uuid and (networktype, address) where the address might be able to be guessed, or observed by the rest of
* On startup, assistant creates a new telehash keypair if not already the network.
present; stores this locally and generates a telehash address from it, * Some addresses can be used with only the provided authtoken
stored in address.log. from the address.log. Remotes can be auto-enabled for these.
(Or, if using snow, uses dns to look up the encryption public key address * Other addresses have Nothing povided for the authtoken, and one
of the local snow server, and stores that in address.log.) has to instead be provided during manual enabling of the remote.
* Use telehash for notifications of changes to the repository * The remotedaemon runs, and/or communicates with the program implementing
* Do git push over telehash. (Pretty easy, may need rate limiting in the network transport. For example for tor, the remotedaemon runs
situations involving relays.) the hidden service, and also connects to the tor hidden services of
* Remove git push over XMPP (which has several problems including other nodes.
XMPP being an unreliable transport, requiring a separate XMPP account per * The remotedaemon handles both sides of git push over the transport.
repo, and XMPP not being end-to-end encrypted) * The remotedaemon may also support sending objects over the transport,
depending on the transport.
## address discovery ## address discovery
The address is a public key, so won't want to type that in. Need discovery. The address is a public key, and the authtoken is some large chunk of data,
so won't want to type that in. Need discovery.
* Easy way is any set of repos that are already connected can communicate * Easy way is any set of repos that are already connected can communicate
them via address.log. them via address.log.
* Local pairing can be used for address discovery. Could be made * Address and authtoken can be communicated out of band (eg,
to work without ssh (with content transfer over telehash discussed via an OTR session or gpg encrypted mail or phone call),
below). and pasted into the webapp.
* XMPP pairing can also be used for address discovery. (Note that * Use eg, electrum-mnemonic to encode the address+authtoken so that
MITM attacks are possible.) Is it worth keeping XMPP in git-annex just it can be read over the phone.
for this? * Users may not have a way to communicate with perfect forward secrecy.
* Addresses of repositories can be communicated out of band (eg, So it would be good to have a address+authtoken that can only be used
via an OTR session or gpg signed mail), and pasted into the webapp to one time during pairing:
initiate a repository pairing that then proceeds entirely over telehash.
Once both sides do this, the pairing can proceed automatically.
## content transfer over telehash 1. Alice uses the webapp to generate a one-time address+authtoken,
and sends it into a message to Bob.
2. Bob enters it into his webapp.
3. Bob's assistant contacts Alice's over the transport, presents the
one-time authtoken. (Alice's assistant accepts it, and marks it as
used so it cannot be used again.)
4. Alice's webapp shows that it's ready to finish pairing; so does Bob's.
Both wait for their users to confirm before proceeding.
5. Alice's assistant generates a new, permanant use authtoken, sends it
to Bob's assistant, which stores it and enables a remote using it.
6. Bob's assistant generates a new, permanant use authtoken, sends it to
Alice's assistant, which stores it and enables a remote using it.
7. Alice and Bob's assistants are now paired.
* In some circumstances, it would be ok to do annexed content transfer Note that this exchange can be actively MITMed. If Eve can intercept
over telehash. Alice's message to Bob, then Eve can pair with Alice. Or, if Eve can
Need to check if there are MTU problems with large data bodies in forge a message from Alice to Bob, Eve can trick Bob into pairing with
telehash messages. her.
Probably not when a bridge is being used, due to required rate
limiting in bridging over telehash. Cloud transfer remotes still needed for
those situations.
(And it should be fine to do it over snow, maybe more so.)
* On a LAN, telehash can be used to determine the current local IP address
of another computer on the LAN. The 2 could then determine if either uses
ssh and if so use regular git-annex-shell for transfers. Or could do
annexed content transfer directly over telehash.
(Snow does not provide this feature AFAIK.)
## generic git-remote-telehash If they make a phone call, it's much harder for Eve to MITM it.
Eve would need to listen to Alice reading the authtoken and enter it
before Bob does, so pairing with Alice. But as long as Alice waits
for Bob to confirm he's ready to finish pairing, this will fail,
because Bob won't get to that point if the authtoken is intercepted.
This might turn out to be easy to split off from git-annex, so `git pull` ## remotedaemon
and `git push` can be used at the command line to access telehash remotes.
Allows using general git entirely decentralized and with end-to-end
encryption.
## separate daemon?
See [[git-remote-daemon]] for its design. See [[git-remote-daemon]] for its design.
Advantages: Advantages:
* `git annex sync` could also use the running daemon * `git annex sync` could also use the running daemon
* `git-remote-telehash` could use the running daemon * `git-remote-$transport` could use the running daemon
* c-telehash might end up linked to openssl, which has licence combination * c-telehash might end up linked to openssl, which has licence combination
problems with git-annex. A separate process not using git-annex's code problems with git-annex. A separate process not using git-annex's code
would avoid this. would avoid this.