pastebin needs PANDA-like interface for exchanging onions

Alice and Bob should be able to sit next to each other and exchange files over Tor hidden services... however it is cumbersome to dictate and transcribe Tor onion addresses. A PAKE system should therefore be utilized for this purpose... this requires Alice and Bob to both connect to the same PAKE server... of course.

I think the first step might be to create a Twisted cred plugin for Brian Warner's pure python JPAKE implementation:

https://github.com/warner/python-jpake

I have looked at this a little bit, and am writing down the results of that plus discussion with @david415 since my initial understanding was different:

1. there exists some JPAKE-understanding server
2. Alice starts pastebin, and puts the resulting .onion URI into 1. with some password
3. Bob gets the password "somehow" and uses it via 1 to retrieve the .onion URI
4. Bob uses the .onion URI to retrieve the content from Alice's pastebin instance

I have started a Twisted Cred based thing that "does" JPAKE (using python-jpake as referenced above).

Excellent! I look forward to reviewing your code and collaborating on this...

hmm actually it looks like JPAKE isn't designed to use a server like PANDA is. here this is perhaps a good intro to PANDA: https://github.com/agl/pond/blob/master/papers/panda/panda.tex

Perhaps we can use Warner's pure python JPAKE as inspiration to implement a python PANDA implementation... which by the way... could and should be compatible with the existing Pond PANDA server; meaning we can simply use the that PANDA server for the purpose of exchanging secret Tor Hidden Service onion addresses instead of a Pond key exchange.

I'm still trying to imagine how to do JPAKE via HTTP. Ideally without a special client. Unfortunately, it still seems like you'd need a two-step process:

1. client contacts server; it send the step-one message in a header; the client sents the step-one reply in a header (e.g. basic-auth or a set-cookie).
2. "somehow" communicate the step-two message
3. "somehow" client communicates step-two answer

Both parties now have the same key, only-if they had the same password to start. So we encrypt the onion addess with the key and send it to the client. They decrypt (with their derived key) and visit the resulting .onion, ideally retrieving the content they desired.

I agree JPAKE doesn't meet your goal of "not transcribing an onion URI" :) So, changing this enhancement to PANDA.

Even crazier idea (and probably already covered before by others' ideas around petnames): what if we provided a petname-style mapping from "words" -> ".onion". The publickey hash is 80 bits. 5 words from ~70k-word corpus is also about 80 bits (my /etc/dictionaries-common/words is 99k).

So, you wouldn't end up with a way to exchange the .onion, but you'd end up with an "easier to transcribe and/or remember" thing for humans that can derive the .onion. So "pastebin" could spit out both the 'real' URI (the .onion) and the "nice" name (e.g. "bide expunges cleopatra whenever rambles").

Yes! Excellent idea! Let's do it... I'd love to collaborate with you to get get this done soon. Essentially this is a "killer app" idea that would fundamentally increase the useability of Tor hidden services.

Yes to your idea AND I'm now wondering if it is useful to use JPAKE with onion-petnames to authenticate the connection. In this way there can be two word-salads:

1. the onion-petname
2. the JPAKE shared secret

If I understand correctly this means that Alice and Bob can verbally exchange one of these word salads in the presents of untrusted people... and the other word salad can be exchanged via a confidential channel such as whispering directly into the receiving ear.

Why is this better than just an onion-petname? The Tor hidden service onions can be discovered by bad acting Tor relays... allowing attackers to connect to the service and possibly attack it. This of course can be mitigated by using Authenticated Tor Hidden Services... AND maybe instead of using JPAKE we can simply create a petname system for the authentication token?

Did you push your Twisted JPAKE implementation to github yet? Can you think of any uses for JPAKE?

PANDA seems more useful than JPAKE... but then again I'm not sure I've thought clearly about all of this enough to come to that conclusion.

I did not push the JPAKE thing anywhere yet, sorry and thanks for the reminder.

I believe we could use your above "2" to derive a "stealth" hidden-service authentication key, but that's off the top of my head (and I'm not sure if JPAKE can derive the correct sized key?). So then unless you know both word-salads, you can't even learn if the hidden-service is there or not.

See the basic vs. stealth authentication stuff in tor's manpage.

Yes... what I was saying is:

• using JPAKE with hidden services seems almost equivalent to a stealth hidden service which is what I meant by authenticated hidden service... therefore I don't see any benefit to using JPAKE.

But there is benefit in having petnames for onions and "stealth authentication tokens".

What I was getting at was: maybe it's possible to have JPAKE derive a key that can be used straight-up as a stealth authentication. That is, independent from the onion pet-name, we could (potentially) make it so that instead of the client providing a complete stealth-auth key, they derive that key via JPAKE? However, I guess JPAKE needs a server to interact with, so in practice might not be that useful for this :/

More thinking required :)

Using http://magic-wormhole.io for this seems like a good candidate...