On Tuesday 21 May 2013 17:23:48 Matthew Toseland wrote: > r.freeman@9o6kYYB8Xk8DAHMfYdxm2MX7T~WbJzdECeiFEeFRyD8 wrote: > > > > > > > 1. user A clicks “generate one-time code” tells that code to B > > 2. user B inputs that code i.e. “ABCD-7777-XYZZ-GGGG”, and done > > > > Would that be nice to have? > > > > > > Comfortable and secure (all is over freenet, except for the code that does > > not leak any information). > > > > I wanted to donate more exact description & discussion of such a system. > > If someone would be so nice and donate a bit, I could go ahead and also > > implement it. > > > > > > Read more: > > > > USK@kBVbzT27Y1awpKDvwDKYgN8YOL~2TtrCRvecSX51dYU,4VL~hjWr3rv19mAwgFEW8km8BmQYwZ6YpAZb6Wa~pvM,AQACAAE/FastRefer-Darknet/-5/ > > Re fragility, there are improvements pending: Any line including spaces and > other dangerous characters will be base64'ed and be "blah==..." rather than > "blah=...". Then we can survive stuff getting broken up into multiple lines > and so on fairly robustly. > > There is a well established plan to upload a full noderef to a CHK so that we > can just give somebody the CHK. Changing this to a KSK might make sense; as > you point out, any KSK-based scheme needs to use enough characters that you > can't brute force it. I'm not sure how many that would be, probably quite a > few. Also, a CHK is potentially more robust than a KSK, because a full > noderef won't fit in a single KSK anyway, so it would be two keys. On the > other hand, 2KB SSKs are planned, and maybe 32KB ones, and these would be far > more robust than CHKs. (KSKs are just SSKs with the keypair derived from the > keyword). > > Any passive observer can identify a KSK and fetch it. This does not solve the > "exchanging IPs in plaintext" problem. E.g. a mobile app might. > > Personally I find it absolutely amazing that exchanging one small file with > friends is so difficult. But I guess that's just how the internet has > developed. :( > > There are various related proposals, for example: > - Give your friend an HTTPS URL, which uses password-based crypto (recent > browsers support this I believe). Exchange the password out of band (e.g. by > voice phone call). Then download the installer from the friend. If the friend > is behind a NAT, we can use a friend's node, especially if the binary itself > is signed. > - IP address and port number each way (so 10 digits hex, less than an average > CD key), and password out of band (voice phone call again). > > Note that there are good protocols for authenticating with a password. This > is a useful building block. Exchanging a password by voice is IMHO an > important part of any usable protocol, precisely because it can't be > intercepted easily; voice recognition is unreliable, and you'd have to > combine it with an active man-in-the-middle attack. If we only allow a few > guesses this should make the threat minimal. > > IMHO we need a protocol that works when the invited user is *not on freenet*, > or has no peers. And we need to limit the number of options, for simplicity's > sake. > > Your protocol for one-time invites is similar to Freemail v0.1.1. I wonder if > we should just use that, with a temporary identity? Maybe it's simpler to use > something custom though... Establishing an encrypted channel before we > exchange noderefs is probably a good thing, so maybe it's worth looking at. > However, if the original KSK is sent over a channel that can be watched and > MITM'ed, IMHO we still need to exchange a password out-of-band. > > I'm not sure whether IPs being exchanged in monitorable protocols is a > problem or not. Ideally, we would exchange noderefs face to face, by using a > cellphone app, a QR code or a USB stick. On the one hand, if they are doing > that level of surveillance, they probably know who your friends are. On the > other hand, we know Microsoft Skype reports all URLs in private conversations > to its central servers; if those URLs include the above > introduction-and-download URLs, that could be a serious problem; even if it's > gone down, they have the IP of a node. So "fishing expeditions" are > potentially a serious issue. > > There have been lots of proposed solutions. Below I summarise what I see as > the main use cases, and the best solutions for each. > > Maybe there are still too many? > > SITUATIONS: > > Geeks able to exchange files securely, already have Freenet: > - Full noderefs, need to be more robust. > - CHK or KSK in both directions. > - One-way secure invite over Freenet. > > Clean smartphone, physical proximity: > - Android app. > - There is a possible GSoC candidate for this. > - Easy and secure if both sides already have the app and a node. > - App in corporate appstore: Recipient asked to install app, app caches the > invite, helps the user to install Freenet on main system (possibly without > using the website i.e. get the jar from the sender). This is at least as > secure as downloading it over HTTPS from the website anyway. > - App spreads "virally" i.e. file from the other phone: This is probably > prohibited by most user-level phones. > > USB stick exchanged in physical proximity: (or a big file exchanged securely) > - Installer bundle, with the installers, full noderef, peers' noderefs, > one-time invite. > - Optional out-of-band voice password verification for the really paranoid. > - Works fine whether or not Freenet is already installed. > > Printed one-way invite (probably as a QR code) > IF YOU HAVE FREENET WORKING: > - Freenet-based one-way invite. > - Out-of-band (voice) password check. > IF YOU DON'T HAVE FREENET WORKING: > - IP:port, fingerprint, one time token. > - Out-of-band (voice) password check. This also functions as checking that > nobody else has used the invite first. > - IP:port can be for another node, which will relay for us (fix connectivity > issues). > IF YOU CAN'T SAFELY OBTAIN FREENET: > - QR code to HTTPS url, see below. > > No physical proximity, insecure channel, out-of-band verification, both sides > have Freenet working already: > - One-way invite over Freenet. > - Out-of-band verification (password over voice comms). Essentially this is > just a key you can pronounce: Similar to QR-codes: Easily shareable codes. As > with the other cases, the objective is to ensure that the right person used > the invite, *before* we add the connection. > > No physical proximity, insecure channel, one side doesn't have Freenet: > - HTTPS url to download installer bundle as on USB stick. > - HTTPS encrypted using password, exchanged out of band. > - Installer may be signed. > - If the inviter isn't port forwarded, can use a friend. In which case they > may need the installer to be signed and a separate password verification > post-install. > - Major con: Skype etc give away IP addresses to passive surveillance. > Consider using USB stick. > > No physical proximity, insecure channel, one side has Freenet but no peers > (i.e. darknet only and no friends yet) > - Exchange IP:port in both directions and then verify out-of-band via > password. Probably should include a one-time token as well to prevent port > scanning, but can be short. > - May need to use a third party node for connectivity (give their IP:port, > need to tell them we want the invite). > > TECHNOLOGIES: > > (Big) noderef files: > - Improvements to noderef file robustness. > - Including peers' noderefs to improve connectivity and performance (with > FOAF). > > Noderef variants: > - One-time invite codes. (May be needed to connect to peers) > - Probably don't need to include full noderefs for peers. > > CHK/KSK for full noderef. (=> single line) (i.e. FastRefer permanent-code) > - Exchanged in both directions. If intercepted, includes the full IP address. > - Not usable for bootstrapping. > > Secure one-time invite exchange over Freenet. Optional out-of-band password > verification. (I.e. FastRefer onetime-code) > - Both parties already connected to Freenet. > - Original code exchanged in one direction over an insecure channel. > - See the code passively, then insert it before the target does: Can be > limited by out of band verification (voice password exchange). IMHO this > should always be done because the carrier may be compromised - how do you > know who you are talking to? > > IP:port (10 digits hex) and out-of-band password. > - IP:port needs to be sent both ways most of the time. > - Can send the whole thing out of band, or send it via an insecure channel > and then verification password by phone. > - Both sides need to have already obtained a copy of Freenet safely. > > Installer bundle: > - Big noderef file. > - Installer. > - Possible issues with malware, there are various ideas to detect this. > - Stick it on a USB stick. > - Really easy to use. > > HTTPS url and out-of-band password. > - Download the installer bundle. > - Only sending a url in one direction. > - Same malware/signing issue as above. > Okay, lets simplify:
The basic problem that r.freeman is trying to solve with his complicated 2-stage KSK exchange is a non-problem: "The noderef might be exchanged via an insecure channel. So it mustn't have an IP address in it". This is nonsense. Because any insecure channel you use to exchange it WILL BETRAY BOTH SIDES' IP ADDRESSES ANYWAY!
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
