r.freeman@9o6kYYB8Xk8DAHMfYdxm2MX7T~WbJzdECeiFEeFRyD8 wrote: > toad-notrust@h2RzPS4fEzP0zU43GAfEgxqK2Y55~kEUNR01cWvYApI 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. > > Good idea. What is the status, implemented? Or would be done as my > project.
It's on a branch. It should be merged soon, deployed, made mandatory, and then in a future build we will enable it for noderefs displayed on the web interface. And also use it to move PluginStore to a non-db4o file per plugin. > >> 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. > > I calculated it for you in my proposal. > Find "year" in the document. > 20 characters is absolutely safe for ever. > 16 chars for one-time codes. Okay fair enough. Is this enough shorter than a CHK to be worthwhile? These are hexadecimal letters? > > Well until some big democracy will love freedom of speech so much they > will build dozen of quantum-computers, AND hash algorithm is broken (by > developing QC method to collide/reverse hash) - but in that case all > crypto we use, and banks use, and everyone uses would be useless so it > would be smallest of worries. > >> 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. > > Hm? I'm not following. KSK insert of long key is safe as long as inserter > does not publish the key, right? Right. The length of the KSK is primarily to prevent an offline attack to guess the key and thus decrypt the reference. > >> 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. :( > > Which leads me to proposing this solution :) > > Oh. > > By the way, I might implement freenet-pastebin, while doing this project: > > Just a nicer user interface around insert-a-file. > You paste a text into big text-area aaaaaaand done. You get address > instantly, post to where ever you need. > random KSK by default, SSK option too. > High priority insert, instantly show key. > Warn about security implications. That's been done already. > >> 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). > > Uh? > What is use case here, again? > > Mine is: > - new guy downloads freenet (from website, or tor when we're blocked) > - guy connects to opennet > - guy gets more connections using my comfortable method > > Therefore we obtained new guy in freenet, that didn't took us 15 minutes > of explaining that is now our darknet friend (better for us) and who is > less sorrounded on opennet (better for him). What if they don't have a secure way to download Freenet? What if they're not connected to opennet? Both of these are plausible in hostile environments or with paranoid users. > > If you want the darknet-only use case, then ok. > Then created code would be > CODE = ABSG-FFGS-DHAF-CKAAS-GXZK > > The GXZ being encoded 4 octets our IP address + port. > When friend enter this address, his node connects to us: > sends UDP packets to us, that will include: > salt, hash(salt+CODE+hisIp+myIp+time), public-key > > When we see a valid UDP in this format, we reply with our reference > encrypted to his public-key, our-public-key. Next he will send his > reference encoded to our-public-key. > > The crypto would be what ever is easiest. It could be using some SSL/HTTPS > libs sure. > > The problem is that this loses the no-logging-of-ip-port part. > But that would be a separate code. Not logging IP address is bogus. Which means your four round KSK system (which will be slowish) is pointless. Any mechanism where you can be eavesdropped on will give away your IP address anyway, so there's no point worrying about it. What you do need to worry about is a man-in-the-middle attack. The easiest way to deal with this is to verify out-of-band, i.e. exchange either a password for password-based auth, or a fingerprint, over the phone (which is hard to intercept in real time). > > "Create ip-Onetime-Code LESS SECURE code, for friends that have 0 peers > and want to be pure darknet. Warning: this code gives out your IP and PORT > number, keep it confidential, do not post over eavesdropped channels like > facebook chat, IM etc. Exchange in person on paper, best." Anyone watching your IM's already has your IP address and that of the person you are talking to. The more serious problem is that, especially if you exchange in person, your IP address may have changed. One way to achieve this is to use a friend's IP:port rather than yours if you have poor connectivity or your IP is likely to change. If we have a lot of data (e.g. a QR code, a file), we could provide multiple IP:port's. There are various proposals... > >> 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. > > Unless democracies that allow censorship and other violence > will keep improving on available technology :) > But that would out of scope of what we can do as freenet developers. > > I agree, voice is best we have now. > > And napkin (harder to record video then to listen in with mic.) > >> 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. > > As above, put our IP to CODE, and use CODE for preshared-secret exchange > of references directly as node-node UDP conversation. As I said, it's not that easy. > >> 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 think custom route looks fine, but maybe Freemail v0.1 too. > But how about spam resistance in there? > This exchange is trivial because it's just 1-1 message. IMHO it's pointless, for reasons I've explained above. > >> 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. > > The problem could be that some ministry of Love gets too much money from > working masses tax and decides to browse YEARS of archives. And start mass > arrests. The IPs are right there! This is true even with your scheme. As long as they can detect an exchange, they can arrest the people involved, even if they don't have a full noderef. > > Didn't anonymous just released some data on African whistle blowers? > Ask them if they mind their (and friends) are IPs are associated now with > activism. > > The ones that will be still alive... > > >> 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. > > Yeap. So my One-time code, and permanent code. > >> 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. > > Are we really at this level of popularity? > This if for bitcoin payments, maybe. > > But why so much work over this? IMHO this is important because it could be dramatically easier to use, and reasonably secure. > > With the code, just taka a picture of it. > > The purpose of short code (20 char) is that you can enter it in any way > possible, even with 1990's cellphone SMS or twitter. > > A 4 member family could publish this code on registration plates of their > cars if they wanted :) > > You can put it into bitcoin blockchain. > > Etc. etc. Every way imaginable will work. > > > <snip> > >> 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). > > </snip> > > This is, imo, mission creep. > Just make the codes. We need to be able to get hold of the software. > > Other people invented ways to exchange 20 character long texts, > like mr. Morse. > our main mission is not to improve on that... :) > > > >> 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. > > > ^---- this is what I like. Yes, this one is important. But it's harder than it sounds. > > >> 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. > > Why? Just grab installer.jar + .sig and put there your code.txt and .zip > it. Simple. > > Or again, just give the installer any way (email, ftp, whatever) and call > with code. Unfortunately life is not this easy. I agree that's the basic principle but IMHO we need to include rather more than that: We need the noderefs not only of the node but also of its public friends, for reasons of connectivity; we need a one-time code that is broadcast to them that allows the other side to connect and add itself; we need the installer to recognise the code file and use it; we need it to ask different questions as a result. This stuff is hard. :( > >> HTTPS url and out-of-band password. >> - Download the installer bundle. >> - Only sending a url in one direction. >> - Same malware/signing issue as above.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
