http://blog.gmane.org/gmane.network.freenet.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.network.freenet.devel/29387 <pre>Hi developers, i read on this mailinglist, that maybe tunneling is a feature that will be realized next (If i understood that correctly). If freenet goes in the direction of tunneling, would it make sense to combine freenet with another technologies like tor or i2p? i2p is java and there is also a java implementation for tor (silvertunnel). maybe every freenet user should have an onion-identifier. freenet could then connect to all neighbour freenet-nodes like tor does (using circuits). and it will be compatible to tor, so the tor users could create some noise on freenet nodes, which would be good for diversity of freenet and for the performance of tor. better performance of tor is also important. not only freenet. the big picture is most important. It is just an idea and i don't know if this would be feasible or appropriate. </pre> Zwiebelcode 2013-05-22T22:06:35 http://comments.gmane.org/gmane.network.freenet.devel/29386 <pre> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi freenet developers, Opennet is still alive and people want it. The theory behind darknet is, that you can trust your friends (or at least you know, that your friends are not automated bots) and add them in freenet. In opennet you dont have to know people in real life. In opennet, an attacker can start multiple nodes and try to observe the users. I am sure, this can be solved. I am working on open-ident, which will be a software, which users can use to identify each other. Normally, users identify each other with gpg-keys, passwords or whatever. But i want to create a identification system that could be used like a passport. People then can have electronic *unique* identities. This can be done without trusting a central organisation or server. In the "normal" world, people use the governments passports to create unique identities. But the past has shown, that the bad guys are able to fake passwords. So we need a more secure identify-system. I suggest open-ident. Open-Ident could be useful for securing up opennet. Opennet can use open-ident to make sure, that all opennet users are really different real-life-persons. When you then add tunnelling, then you have very very strong security!!! This is a shortened description how open-ident will work: A users connects to an untrusted central server and requests for an assurer-contact. The user physically goes to several (randomly assigned) assurers and gives his fingerprint- and/or iris-scan to them. Then the fingerprint-data is signed and send back to the server. After that, the user gets a certificate, which proves, that his public key is a unique real-life-person on that server. Currently, i try to implement this with the use of opentransactions. But i am still not 100% sure if this is the best way. Maybe a stanalone app would be better... It initially looked so easy because of their ready-to-use blinded-token-coins which i could use in later steps to anonymize the hole thing... Open-ident will not only be interesting for anonymizing systems, but also for market platforms similar to ebay,... Because people can not login twice on one market Comments? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJRnT9PAAoJEFCTkZ2uNzgr7I8H/3NLWqPus3wDTtq0vyTtiyrG JgfmHYXlMt3us1vLsR4G1DJ+YeAjv2x1CGvX/synL5sd7q3mq8bSynw1sAoiRsej 1NQITuhEQ7Uh1FJLnJbrHOV5q95e9BVrhoVBYIJZ3ZfstT/uPZAE0+0FD9y74mRf g1nXiCi9fZsRlvByKunJoJ91R+EGJDLGdtG5vViitkV5J1ScdCA2HgYLAsFh+OP3 u4HXvjex1OudpU57efl+hBvfil+eTGt4X0g2qhdgyeBArZmty89p1BJsKtZpIqGK BMoV6RIonk/BKjd5+vjmTedeOoIMwhDIx4ZfQru5O9WjsVfRh8bP1bRQ3EWKTf8= =1Rjx -----END PGP SIGNATURE----- _______________________________________________ Devl mailing list Devl-RdDMkVZAZeuJnvDnx1genB2eb7JE58TQ&lt; at &gt;public.gmane.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl</pre> Zwiebelcode 2013-05-22T21:57:36 http://comments.gmane.org/gmane.network.freenet.devel/29379 <pre> 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. (=&gt; 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. _______________________________________________ Devl mailing list Devl-RdDMkVZAZeuJnvDnx1genB2eb7JE58TQ&lt; at &gt;public.gmane.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl</pre> Matthew Toseland 2013-05-21T16:23:48 http://comments.gmane.org/gmane.network.freenet.devel/29375 <pre> Hi infinity0, My proposal to GSoC13 is highly related to your code (Library).  First, do you have any extra documentation on the code that you think it could be useful for me to understand the most important parts, such the SkeletonBTreeMap? Second, I have some questions: 1. You disabled the "boolean internal_entries" inside the classSkeletonBTreeMap and use option 2. I don't understand what do you mean about a dummy serialiser that copies task.data to task.meta. What contains task.data?   2. What means deflate/inflate the node? 3. What is a GhostNode? I understood is a not desirable structure used to contain some metadata or sth related with the serializer and needs to be removed. If you can elaborate more about Library, besides the documentation already published in the wiki, it will be of great help. Thanks in advance, leuchtkaefer_______________________________________________ Devl mailing list Devl-RdDMkVZAZeuJnvDnx1genB2eb7JE58TQ&lt; at &gt;public.gmane.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl</pre> leuchtkaefer 2013-05-20T21:36:32 http://comments.gmane.org/gmane.network.freenet.devel/29374 <pre>We have 2 students who have mentors, and 3 promising students that I may end up mentoring. One is on filesharing, one is on android and one is on transport layer improvements (not transport plugins, lower level stuff re the current UDP protocol e.g. congestion control, MTUs etc). If anyone is interested, please sign up *right now*, as deduping happens in two days and all students must have a mentor by 07:00 UTC on Friday. _______________________________________________ Devl mailing list Devl-RdDMkVZAZeuJnvDnx1genB2eb7JE58TQ&lt; at &gt;public.gmane.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl</pre> Matthew Toseland 2013-05-20T18:40:21 http://comments.gmane.org/gmane.network.freenet.devel/29372 <pre>I will be able to work full time on Freenet for four months after my exams are over. After that, it's iffy. Obviously the first priority has to be to make sure that other people can do releases. Beyond that, IMHO I should focus primarily on sorting out darknet. Darknet should be easy, fast, and secure. It should coexist with opennet, and automatically detect when opennet is unnecessary. And then we can implement tunnels, probably based on Pisces. This is a fairly limited amount of time, and IMHO darknet is *the key issue* for Freenet. The fact is, right now using Freenet in darknet mode is slow, insecure and above all inconvenient. Using Freenet in opennet mode is slow to bootstrap (darknet invites would actually solve this problem), and even more insecure. IMHO the major police support agencies probably already have tools to trace opennet users, they just avoid showing them in court. The academic literature shows tunneling makes much more sense on darknet than on opennet; peer selection for DHTs is an unsolved problem. Our key selling point is anonymity, as evidenced by the frequent requests for accessing Freenet over Tor. People tend to assume Freenet has good security; they're wrong, and sooner or later this will become obvious. Our first-time wizard tries to make this clear and probably puts off a lot of people as a result. Major benefits of sorting out darknet: - Hard to block. - Strong security for small inserts with reasonable performance. This applies to chat posts, but also to top blocks for e.g. freesites and files where the attacker is assumed to be initially distant. - Optional strong security for even large inserts (e.g. reinserts) and requests, at a significant performance cost. - Fast performance out of the box from an invite, via your friend who invited you, and his friends. No more waiting for opennet to bootstrap. - You can customise the bookmarks you give to your friend in the invite. - Fix published attacks on darknet, notably Pitch Black. - Can use published academic work on tunnels on darknet, e.g. Pisces. Note that darknet is a much better bet for tunneling than opennet; various opennet DHT tunnel setup algorithms have severe flaws. - Much easier viral growth. - Darknet infrastructure supports even stronger protection (e.g. non-real time tunnels for inserts) in the longer term. I'd like to hear opinions on this. Others may want me to focus on getting rid of db4o, or load management, or lots of other things. There are lots of important things to do, but not enough time to do everything. Thoughts? Obviously I hope other people will be working on other things; this is a question of how to use paid project resources. _______________________________________________ Devl mailing list Devl-RdDMkVZAZeuJnvDnx1genB2eb7JE58TQ&lt; at &gt;public.gmane.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl</pre> Matthew Toseland 2013-05-19T19:13:11 http://comments.gmane.org/gmane.network.freenet.devel/29369 <pre> Hello everybody, I am planning to implement file sharing/search improvements/new features. As an initial step I immersed myself in all different sources of info about Freenet to understand better all part of the projects related to the distributed search. I more or less read lot of stuff listed in a guide that I started writing in case someone is in the same situation as me in the near future. I can uploaded my guide to the list if somebody is interested on it. HOWEVER it is still difficult for a newbie in Freenet to understand the basic implemented data structures. It is also somehow confusing know what things have been done but are not in the official deployment. For instance, I really need to understand: According to doc in source Library an INDEX has metadata and two BTree.Index  |-- metadata  |-- ttab: BTreeMap&lt;String, BTreeSet&lt;TermEntry&gt;&gt;  |-- utab: BTreeMap&lt;URIKey, BTreeMap&lt;FreenetURI, URIEntry&gt;&gt; Does each p2p node construct one index? It is this index the actual structure in official Freenet? I also don't understand why the root of the index is stored under a SSK splitfile. I thought and SSK splitfile is used to store normal user's file. THanks for help in advance!_______________________________________________ Devl mailing list Devl-RdDMkVZAZeuJnvDnx1genB2eb7JE58TQ&lt; at &gt;public.gmane.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl</pre> leuchtkaefer 2013-05-16T16:47:14 http://comments.gmane.org/gmane.network.freenet.devel/29367 <pre>Freenet 0.7.5 build 1442 is now available. Please let me know if you have any trouble upgrading; your Freenet node should update itself automatically. This build will be mandatory on the 21st of May. Major changes: - Process connection setup messages on a separate thread to the one that handles packets from already connected peers. This should make connections more stable, especially on seednodes, ARM nodes and when there are CPU usage problems. - Increase the maximum number of locations that a peer can tell us about to 110. This does NOT actually increase the maximum number of opennet peers yet, that will be in 1443. - Update update.sh and update.cmd via the auto-updater. - Minor optimisations in auto-update. - Write a backup of the old main jar to freenet.jar.bak when updating on Linux (on Windows, we alternate between freenet.jar and freenet.jar.new). - Paranoid code to try to prevent the problems in 1439 from happening again. - Increase the startup timeout for waiting for entropy to 1 hour, explain the situation a bit better. - Support missing the ; at the end of CSS styles (e.g. in HTML). - Fix changing the bindTo address for fproxy breaking the web interface completely when bad addresses are entered (same for FCP too) - bug #5674. - Refactoring, mostly in client layer, also some logging stuff in crypto code. - Trivial optimisations, cleanups, remove old probe messages, comments in the code etc. _______________________________________________ Devl mailing list Devl-RdDMkVZAZeuJnvDnx1genB2eb7JE58TQ&lt; at &gt;public.gmane.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl</pre> Matthew Toseland 2013-05-14T19:00:03 http://comments.gmane.org/gmane.network.freenet.devel/29360 <pre>Freenet 0.7.5 build 1441 is now available. Please upgrade, the changes are minimal but include a critical security fix for FlogHelper. If you have used FlogHelper and have published flogs with the "safe backups" option enabled, your hostname is visible to anyone who downloads flog.db4o. Sorry about this, we should have been more careful (it's an information leak inside db4o...). A more detailed warning will show up if you use it. Note that this may not affect you even if you do have a FlogHelper flog with backups turned on, if it hasn't been updated recently and the backup file is large enough not to be in the main container (in which case it may have fallen out). Changes: - Update the SSL certificate for the last resort update scripts. - Catch more db4o errors on startup. - Library v27. - FlogHelper v29. - Fix an NPE in non-persistent USK inserts. ANONYMITY BREACH: Your flog "${title}" has leaked your hostname "${hostname}" for your WoT identity ${author}, in the backup file "flog.db4o". That means all your flogs, Sone posts, Freetalk posts, Freemail and anything else using that identity can be connected to "${hostname}". You could keep using this identity but bear in mind that it may be compromised, or you could delete the identity. Files on Freenet cannot be deleted, but if you upload a new version the old one may eventually become inaccessible, although somebody may have downloaded it already. You can delete the identity or create a new one on the Community menu under "Own anonymous identities". In case of any questions please contact us securely on Freenet Messaging System (FMS) board Freenet. _______________________________________________ Devl mailing list Devl-RdDMkVZAZeuJnvDnx1genB2eb7JE58TQ&lt; at &gt;public.gmane.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl</pre> Matthew Toseland 2013-05-08T15:02:28 http://comments.gmane.org/gmane.network.freenet.devel/29357 <pre>Hey Toad, I can simply directly call getMTU() inside Node.getMinimumMTU or I can replace the pluginDetectedIP.mtu with getMTU() calls in NodeIPDetector.processDetectedIPs. Could you please tell me which one do you think is the better/cleaner/more harmonious way to do it? Thanks, Vmon </pre> vmonmoonshine-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org 2013-05-07T09:32:55 http://comments.gmane.org/gmane.network.freenet.devel/29356 <pre> FYI. http://www.wired.com/wiredscience/2013/05/vint-cerf-interplanetary-internet/ Apart from the "cell phone" analogy, seems like much of the "web" could be used across planets using freenet. -- Robert Hailey _______________________________________________ Devl mailing list Devl-RdDMkVZAZeuJnvDnx1genB2eb7JE58TQ&lt; at &gt;public.gmane.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl</pre> Robert Hailey 2013-05-06T17:06:39 http://comments.gmane.org/gmane.network.freenet.devel/29351 <pre>From FMS: Re: maxpeers setting adilson_lanpo&lt; at &gt;8AEGotJKXJ4ABJy1gKjls4SrrzpshQNoEMAbu0IFA94 wrote: Basically the worry is that the network could become over-reliant on a moderate number of nodes with lots of connections each. I.e. it becomes a "scale free" network, where all requests are routed through a centralised cabal of nodes, rather than a more homogenous "small world" network. The problem with such a situation is if you take out the "big" nodes, the rest of the network will be severely damaged and take some time to adapt. However, there are a lot of problems with opennet, so maybe this is less of an issue than we have assumed? I don't know how to quantify this. Arguably you can get a cabal just by fast (high capacity) nodes linking to other fast (high capacity) nodes, without violating the peer limits. To some degree this happens automatically on opennet (as it's a bit meritocratic), but the fact that fast nodes still see relatively low transfer rates shows it doesn't happen *that much*. So maybe there's no problem with raising the limit to say 100 peers on opennet. On darknet somebody with a lot of connections might well have 100 peers, especially if we have FOAF links. Opennet is vulnerable with or without high peer limits, and the main worries with centralisation are somewhat independent of peer limits. We could limit "aristocracy" by e.g. limiting connections not by number but by capacity. I.e. you can have 20 high capacity peers or 40 low capacity peers. This is a bit hand-wavy at this point... _______________________________________________ Devl mailing list Devl-RdDMkVZAZeuJnvDnx1genB2eb7JE58TQ&lt; at &gt;public.gmane.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl</pre> Matthew Toseland 2013-05-05T12:59:24 http://comments.gmane.org/gmane.network.freenet.devel/29339 <pre>Does the 32-bit JVM auto-update itself on 64-bit Windows? _______________________________________________ Devl mailing list Devl-RdDMkVZAZeuJnvDnx1genB2eb7JE58TQ&lt; at &gt;public.gmane.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl</pre> Matthew Toseland 2013-05-01T22:26:38 http://comments.gmane.org/gmane.network.freenet.devel/29338 <pre>Do we want to have an "official" bounty system for Freenet? Advantages: - It's essential to get buy in from the people who do the merging. Unofficial bounty systems have been tried, and failed, partly because of different views between users, donors and the people who do the merging. We don't want stuff to be paid for and implemented but never deployed. - BTC bounties are possible. Even paying developers anonymously. - Can use casual contractors, hire people when we have the money, not rely on having enough income to justify full time staff. - Agreeing a detailed technical spec in advance is probably a good thing, though there will of course be problems in practice. - There is far more work to do on Freenet than there are resources to do it right now! Disadvantages: - Agreeing a price in advance may mean paying over the odds, even if we pay in BTC for something some of them may want to do. - Depending on how "official" it is, paying devs anonymously may be legally iffy. Long term we probably want the core devs to be anonymous anyway, and have a multiple sign off system for releases... "Official" here means getting buy-in from core devs before the project starts to fundraise. - We still have the possibility of paid staff; I should be full time from June 24th to October, and may be available in summer vacations after that. - Merging code, reviewing code, escrowing it, and so on may drain resources of core devs in much the same way as GSoC admin, if the devs are poor. - There needs to be sufficient trust on both sides. Who's going to control the escrow exactly? - Possibly over-dependant on Bitcoin. Ideally we'd like to start with a small "step" in a larger project, that can be individually funded. Obviously this is intended as a way to raise funds rather than to distribute them, though maybe it'd be worth spending some of the BTC we've accumulated to get it started. Some possible projects: - Update "streams", and other stuff related to distributing development over Freenet. - Content filter work. - Update the wrapper, in a 100% back compatible way. (C-heavy project) - BTCFN. This has already been started. What happened to it? Was it escrowed? IIRC the funds were raised but nothing has been heard since, at least not on the FMS board? - Rewrite the client layer: The splitfile code needs to be rewritten to use a robust on-disk flat-file structure per download. I can give a precise spec for this. The rest of the client layer should be stripped of db4o cruft and simply use serialisation (with backups). - Ambitious project: ECC-based SSKs/PSKs and advanced forums: </pre> Matthew Toseland 2013-05-01T13:18:51 http://comments.gmane.org/gmane.network.freenet.devel/29337 <pre>Currently we use 256-bit AES (more or less) to encrypt packets, and 2048-bit DSA and secp256r1 for Diffie-Hellman/STS/JFK for creating those keys. This is of course ridiculous, as you can see below, and is also slow and oversized. We need to decide on what keys we want to use before we implement the next stage of crypto changes. http://www.keylength.com/en/3/ I propose that we use: - 128-bit AES for packet encryption. - secp256k1 for DSA (signing the connection setup, to prove that the node is not being spoofed) - secp256k1 for Diffie-Hellman (generating the private key) Advantages: - We can use JCA for packet crypto (once we switch to 128-bit block size): 128-bit AES is exportable. Of course the paranoid would say the reason it's exportable is the NSA can crack it. But it's gonna be a long time before we have any hope against them - and it's pretty much certain that nobody else can crack it. Anyway, this makes the code easier / cleaner / more standard. - 128-bit AES uses about 40% less CPU than 256-bit AES. - The above is consistent, it's listed as "Long-term protection" on the standard linked above. - secp256k1 should be just as secure as secp256r1, but it's much faster. Note that Bitcoin uses secp256k1 to protect sometimes large amounts of money. - Diffie-Hellman (ECDH) doesn't need very strong security. We rekey every hour, so cracking an exchange will only allow you to decrypt one hour's worth of data. - Signing the connection setup doesn't need very strong security either. Ideally we'd like to be able to change the key, say once a year. But again, borrowing a supercomputer to impersonate one node isn't very realistic, even on darknet, or on a seednode; it'd be easier just to add a bunch of evil seednodes, although some schemes to secure opennet might be interesting. - I don't think it's worthwhile to go for an even smaller key size, simply because secp256k1 is likely to be fast enough. Obviously this is more than sufficient for opennet, given our higher level attacks. IMHO it is probably sufficient for darknet too. Having said that, on darknet, cracking a node's identity gives you a lot more than it does on opennet. Also in future we will have an option to do tunneling on darknet, and the tunnels will only be as strong as the nodes' darknet identities - even if we had a stronger key for encrypting the tunnel, stealing the node's connection setup identity would probably let you steal it, but the above is probably still strong enough. The second question is what to use for SSK keypairs? Some keys are more important than others. E.g. the auto-update key. However it is possible to change them - in particular the auto-update key has been changed several times, it's a hassle but it's possible. It will need to be changed again when we move to ECC-based SSKs. Our options are: - Use secp256k1 for everything. Probably ideal. - Allow smaller keys if wanted, or even force them for small blocks. - Allow larger keys. The problem with allowing larger keys is that above 256-bit ECC (128-bit effective), there are no -k curves, they are all purely random. Meaning they are much much slower. So if we were to be really paranoid and support secp384r1 or even secp521r1, verifying the SSK on each hop might cause significant CPU usage. So I'm inclined to just go for secp256k1 for everything... Another possibility: There is actually another set of standard curves, sect*. These use a different kind of arithmetic (binary fields rather than prime fields). Do we want to look at these? Are they less safe than prime fields? The relevant bug is here: https://bugs.freenetproject.org/view.php?id=5690 _______________________________________________ Devl mailing list Devl-RdDMkVZAZeuJnvDnx1genB2eb7JE58TQ&lt; at &gt;public.gmane.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl</pre> Matthew Toseland 2013-04-30T18:22:20 http://comments.gmane.org/gmane.network.freenet.devel/29332 <pre>Hey Chetan, I started to implement a packet transport plugin that convert the data portion of the packet before sending it off and before processing it after it is received, as a part of "if I know coding" quiz. I have few questions regarding this and I thought you might be able to help me with them. 1) From the point of view of a coder who wants to implement such a transport, it is natural to inherit from UdpSocketHandler. However, my understanding is that the transport plugins should be "pluggable" like other plugins on freenet, i.e. user be able to easily enable and disable them, to reach this goal, is there another class that needs to be implemented/modified or should I give the name of my new Class (UdpBase64SocketHandler) to some sort of function to be added as new plugin? 2) What's the role of the tracker object? Why both _socket and the tracker should be sending the packets? 3) What is the different between destination in Peer type and destination in PluginAddress type? 4) My understanding is that byte[] data part of the packet only contains the data part of the packet (and not the header) so the max packet size does not need assumes that the header is also in Base64 encoding. Is that correct? My implementation up to now is here: https://github.com/vmon/fred-staging/commit/d1830950737fa5ec0c13238d7309bef6ddaf750a Hopefully it'll become more realistic after I get the answer. Now that I'm back home, I think my nights should have some intersection with your days, I'll try to be reliably on irc at nights. If you think it is more constructive to chat on irc, we can schedule a meeting on irc anytime between 9:30am-4:30pm your time. If nothing in this interval works for you, I'll find another every-day spot based on your alternative suggestion. In any case it's good to use Google Calendar in order not to get confused with zones and miss each other. Meanwhile, I'm working also on writing down the proposal based on my previous discussion with you and toad and will share it with you guys soon when the initial version is out. Should I include "completing the merge and testing of chetan-transport branch" also into the proposal or you think you'll have a chance to get over that before May 22 in case the proposal will be accepted? Thank you very much for your help, Vmon </pre> vmonmoonshine-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org 2013-04-25T09:23:05 http://comments.gmane.org/gmane.network.freenet.devel/29320 <pre>Respected Sir/Madam, I am a sophomore from Indian Institute of Technology Delhi. I am quite interested in P2p and would like to work for the development of P2p. Since Wi-Fi Direct is relatively new, its potential is largely unexplored.. By using Wi-Fi Direct, we could have a local P2p sharing between android mobiles. Now a days, we are having smart TV sets and smart cameras that have Wi-Fi-direct functionality. I feel this could be a revolutionary technology and would be available on latest and upcoming devices. For example, one can look and share files with anybody who is having an Android device and is close by. This way without using internet/data connectivity data can be shared. Sharing without internet connection --&gt; Censorship impossible Now data that is shared at local level could move to other people when these people visit different places.. Now using Bacon number kind of notation, it would take no more than 10 hops for the data to reach from me to you without internet/data connectivity!!! My Strengths: Android Development - Both Native and using SDK Programming and Data Structures - Developed small multiplayer games (connecto , tic tac toe etc) Signal and Image Processing (If that could be of any use) Sensors Please reply if you find this an interesting project for GSOC. Also, you could give suggestions to improve my idea. Thanking You, Sincerely, G. Nitesh Bharadwaj. _______________________________________________ Devl mailing list Devl-RdDMkVZAZeuJnvDnx1genB2eb7JE58TQ&lt; at &gt;public.gmane.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl</pre> Nitesh Bharadwaj 2013-04-20T06:51:37 http://comments.gmane.org/gmane.network.freenet.devel/29317 <pre>OCB mode[1] is a CCA-secure[2] mode of encryption which means that it's secure against active attackers, which pretty much applies to anything on the internet. By contrast, non-authenticated encryption (anything without a MAC, e.g. AES-CBC, AES-CTR) is only CPA-secure[3] and breaks under an active attacker. You can build CCA-secure schemes by combining Enc() and Mac() operations (with different keys!). Enc(M)||Mac(Enc(M)) is generally secure; Enc(M||Mac(M)) and Enc(M)||Mac(M) can have security problems, the latter being more likely to be insecure. However, OCB is apparently faster than schemes that do authentication/encryption separately. It used to be patent-encumbered, but as of January 2013, the creator is giving an exception to open source projects.[4] I'm not sure if any of this was taken into consideration by whoever originally did the crypto for Freenet, and I haven't looked into the implementation in great detail to see if we are doing Enc_k1(M)||Mac_k2(Enc(M)) everywhere, as opposed to one of the other less secure options. Hopefully someone who did the crypto for freenet can comment further. X [1] http://en.wikipedia.org/wiki/OCB_mode [2] http://en.wikipedia.org/wiki/Chosen-ciphertext_attack [3] http://en.wikipedia.org/wiki/Chosen-plaintext_attack [4] http://www.cs.ucdavis.edu/~rogaway/ocb/license.htm </pre> Ximin Luo 2013-04-17T22:59:16 http://comments.gmane.org/gmane.network.freenet.devel/29316 <pre>2013/4/17 Matthew Toseland &lt;toad-EI5O+8PHWbJeeLb3ft/vUmD2FQJk+8+b&lt; at &gt;public.gmane.org&gt; The most straightforward and naive way to do it would be the negotiation about MTU for the connection at the beginning of conversation. It's most major disadvantages are: 1) It's a great overhead in case of send-and-forget and other transient handshakes, where the start-up cost of such detection could easily exceed the amount of useful data sent. 2) Path MTU could vary over time, so we can end up blocking ourselves up if the packets suddenly start being routed over weaker hosts. A bit more advanced path would be to determine the actual MTU as the conversation goes on. We could keep useful connection stats for nodes that we've recently heard from and use it as the indicator for current choice of MTU. E.g. if we receive acks for 90% of requests, why not to try broadening the route? The amount of each reduce/increase can be based on previous MTU values for the node, e.g. a bit mutated dichotomy if we could assume that MTU is more or less stable in borders of single connection. This solves both of stated above problems, but introduces a new one: - Generally, it's a bad idea to keep track of all nodes that we've talked to in decentralized p2p applications; and I'm still not sure about it's significance in FreeNet context. There are many ways to reduce the amount of stored information (forget about inactive for long time nodes, etc.), but they depend heavily on the aims and tendencies of the network that I'm not familiar with right now. 2013/4/17 Matthew Toseland &lt;toad-EI5O+8PHWbJeeLb3ft/vUmD2FQJk+8+b&lt; at &gt;public.gmane.org&gt; Yep, I thought about it this way. Transport plugins are awesome concept but the base should be as effective and usable as it could be. _______________________________________________ Devl mailing list Devl-RdDMkVZAZeuJnvDnx1genB2eb7JE58TQ&lt; at &gt;public.gmane.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl</pre> Vladislav Sterzhanov 2013-04-17T20:59:53 http://comments.gmane.org/gmane.network.freenet.devel/29312 <pre>Hi there, FreeNet people. I am a student from a Belarusian State University and I'd like to participate in this year's Summer of Code by improving the Free Network. Generally, I wish to enhance the survivability of slow and dying connections, while boosting the broad ones. Some key points that I see after viewing Ideas page and searching the bug tracker: - providing the ability for dynamic detection of the currently available MTU size along the path to the node, making it possible to forecast nearly exact suitable packet size for the connection. (issues 0000976&lt;https://bugs.freenetproject.org/view.php?id=976&gt; , 0005294 &lt;https://bugs.freenetproject.org/view.php?id=5294&gt;) - dealing with the low-bandwidth and high-latency links by more precise control over them - splitting packets to get them through, estimating the appropriate wait-timeout, etc. (0002123&lt;https://bugs.freenetproject.org/view.php?id=2123&gt; and, partly 0005630 &lt;https://bugs.freenetproject.org/view.php?id=5630&gt;) This two could be significantly improved by tracking the connection stats (sent packets / retransmits / acks) for the nodes that we're currently connected to. Provided with such information and making some empirical assumptions we could additionally adjust estimations needed and determine the reliability of the connection. - auto-adjusting the acknowledge method for a connection based on available information (priority for poor connection is to send and receive at least something, whereas for low-latency one additional savings provided by cumulative zero-ack would be a good idea). - some more high-level control also seems feasible: e.g. mentioned idle-priority chunks can reduce the additional load on network at rush-hours. Perhaps I got something wrong, moreover, I bet that there is much more work to do that I've already found out, so I need to know what do you think about it? </pre> Vladislav Sterzhanov 2013-04-16T15:38:28 http://comments.gmane.org/gmane.network.freenet.devel/29309 <pre>Mentors should sign up. Students can sign up in 2 weeks time. _______________________________________________ Devl mailing list Devl-RdDMkVZAZeuJnvDnx1genB2eb7JE58TQ&lt; at &gt;public.gmane.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl</pre> Matthew Toseland 2013-04-08T21:23:46 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.network.freenet.devel