From freenet-devl at david.sowder.com Thu Nov 1 16:51:17 2007 From: freenet-devl at david.sowder.com (David Sowder) Date: Thu, 01 Nov 2007 11:51:17 -0500 Subject: [freenet-dev] Expose Crypto Stuff via FCP In-Reply-To: <1193865660.7033.17.camel@localhost> References: <1193821127.10134.48.camel@localhost> <20071031153144.GA4141@freenetproject.org> <1193852061.7033.4.camel@localhost> <4728C6C0.3040709@david.sowder.com> <20071031211154.GH4141@freenetproject.org> <1193865660.7033.17.camel@localhost> Message-ID: <472A0405.8040209@david.sowder.com> David ?Bombe? Roden wrote: > On Wed, 2007-10-31 at 22:11 +0100, Florent Daigni?re wrote: > > >> Link security is the obvious thing... DoSes are an other one. >> > > We're talking about FCP here. Where is the DoS potential? > DoS potential would be limited to the IPs allowed FCP access in the first place. This will, in general, boil down to DoS only by trojan in my thinking. >> Generally speaking, the less services the node provides, the simpler >> the protocol is... The best it is for everyone. >> > > Which is true for FNP but not necessarily for FCP. > Yes. I in my thinking, FCP's job is to encourage Freenet related apps and promote a standard method of communicating with Freenet and Freenet-related facilities in the process. >> By the way sharing our RNG with clients is probably a bad idea (most >> crypto operations involve using some randomness) and we will have to >> expose it at some point if we want clients to do some useful stuffs. >> > > You don't have to expose the RNG. The node just needs to perform a > couple of operations on behalf of the clients. You could even add the > FCP messages as an entropy source. > > > >> That's what the GenerateSSK message is for. >> > > You have no idea what I'm talking about, do you? Otherwise please tell > me how I use that key pair to encrypt data. Thank you in advance. :) > Yes, GPG-style key pairs rather than public and private SSK keys. >> I still don't get why clients can't import our classes ... and do >> their own crypto with it (okay they are licencing issues... but we >> want everyone to use GPL, don't we ? :p) >> > > Because then client developers have to learn Yet Another API buried deep > within the bowels of another software. That sucks. FCP would be a clean > lean, and mean interface for crypto operations. And, frankly, from what > I've seen so far the freenet crypto API is far from being clean, > documented, and usable by other people. You'd have more success with > SUN's JCE. > > Just to be clear: What I want is to perform cryptographic operations in > a client. I want to create key pairs that can identify a user. I want to > create session keys to encrypt data. I want to sign data with the keys I > generated. Decrypting. Verifying. Client stuff, you know? :) > > What I do NOT want is to busy myself with JSE, JCA, BouncyCastle or any > other API because the node can already do all that for me. > I would add that importing the Freenet classes requires my project to be locked into Java, which is not desirable to me. Why not export the functionality via FCP, so any language can use the crypto libraries Freenet has built up rather than relying on whatever good/bad algorithm coverage might be easily available in the external project's language of choice. pyfcp apps could get crypto "for free" to use over Freenet rather than having some third party Python module need be installed because of crypto export restrictions for the developer and the like. I've already had one idea stall because of the crypto situation in Python and FCP exported crypto functions would have made it a non-issue. From nextgens at freenetproject.org Thu Nov 1 18:08:21 2007 From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=) Date: Thu, 1 Nov 2007 19:08:21 +0100 Subject: [freenet-dev] Expose Crypto Stuff via FCP In-Reply-To: <1193865660.7033.17.camel@localhost> References: <1193821127.10134.48.camel@localhost> <20071031153144.GA4141@freenetproject.org> <1193852061.7033.4.camel@localhost> <4728C6C0.3040709@david.sowder.com> <20071031211154.GH4141@freenetproject.org> <1193865660.7033.17.camel@localhost> Message-ID: <20071101180820.GB4236@freenetproject.org> * David ???Bombe??? Roden [2007-10-31 22:21:00]: > On Wed, 2007-10-31 at 22:11 +0100, Florent Daigni?re wrote: > > > Link security is the obvious thing... DoSes are an other one. > > We're talking about FCP here. Where is the DoS potential? Are all clients running on different threads ? Ever thought about entropy exhaustion ? > > > > Generally speaking, the less services the node provides, the simpler > > the protocol is... The best it is for everyone. > > Which is true for FNP but not necessarily for FCP. > The main asset of FCPv2 over v1 is simplicity. > > > By the way sharing our RNG with clients is probably a bad idea (most > > crypto operations involve using some randomness) and we will have to > > expose it at some point if we want clients to do some useful stuffs. > > You don't have to expose the RNG. The node just needs to perform a > couple of operations on behalf of the clients. You could even add the > FCP messages as an entropy source. > A shakeable entropy source is useless. > > > That's what the GenerateSSK message is for. > > You have no idea what I'm talking about, do you? Otherwise please tell > me how I use that key pair to encrypt data. Thank you in advance. :) > To encrypt you insert your data to a SSK... to decrypt you get the data from the pubkey of the SSK. To sign, you insert the data to a CHK and its hash to a SSK/USK. To verify the sig, you do the opposite. To do symmetrical encryption you share both the pubkey and the private key of the SSK. What's missing ? > > > I still don't get why clients can't import our classes ... and do > > their own crypto with it (okay they are licencing issues... but we > > want everyone to use GPL, don't we ? :p) > > Because then client developers have to learn Yet Another API buried deep > within the bowels of another software. That sucks. FCP would be a clean > lean, and mean interface for crypto operations. And, frankly, from what > I've seen so far the freenet crypto API is far from being clean, > documented, and usable by other people. You'd have more success with > SUN's JCE. Well, you're welcome to improve it. As far as I'm concerned I think the API is clean. Have a look to DSA (http://emu.freenetproject.org/cgi-bin/viewcvs.cgi/trunk/freenet/src/freenet/crypt/DSA.java?rev=15454&view=markup) for asymmetrical encryption/signature and Rijndael (http://emu.freenetproject.org/cgi-bin/viewcvs.cgi/trunk/freenet/src/freenet/crypt/ciphers/Rijndael.java?rev=15105&view=markup) for symmetrical one. You might need a BlockCypher too: see PCFBMode (http://emu.freenetproject.org/cgi-bin/viewcvs.cgi/trunk/freenet/src/freenet/crypt/PCFBMode.java?rev=15395&view=markup) > > Just to be clear: What I want is to perform cryptographic operations in > a client. I want to create key pairs that can identify a user. I want to > create session keys to encrypt data. I want to sign data with the keys I > generated. Decrypting. Verifying. Client stuff, you know? :) I don't think that YetAnotherLayerOfCrypto is needed to achieve the level of functionality you described. > > What I do NOT want is to busy myself with JSE, JCA, BouncyCastle or any > other API because the node can already do all that for me. > > > > NextGen$ > > Bombe > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071101/eb46a16b/attachment.pgp From nextgens at freenetproject.org Thu Nov 1 18:21:01 2007 From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=) Date: Thu, 1 Nov 2007 19:21:01 +0100 Subject: [freenet-dev] Expose Crypto Stuff via FCP In-Reply-To: <472A0405.8040209@david.sowder.com> References: <1193821127.10134.48.camel@localhost> <20071031153144.GA4141@freenetproject.org> <1193852061.7033.4.camel@localhost> <4728C6C0.3040709@david.sowder.com> <20071031211154.GH4141@freenetproject.org> <1193865660.7033.17.camel@localhost> <472A0405.8040209@david.sowder.com> Message-ID: <20071101182100.GC4236@freenetproject.org> * David Sowder [2007-11-01 11:51:17]: > David ???Bombe??? Roden wrote: [snip.] > > Which is true for FNP but not necessarily for FCP. > > > Yes. I in my thinking, FCP's job is to encourage Freenet related apps > and promote a standard method of communicating with Freenet and > Freenet-related facilities in the process. Sound idea and basis... I don't see how crypto is freenet specific or even related though. [snip.] > >> That's what the GenerateSSK message is for. > >> > > You have no idea what I'm talking about, do you? Otherwise please tell > > me how I use that key pair to encrypt data. Thank you in advance. :) > > > Yes, GPG-style key pairs rather than public and private SSK keys. I don't get it, sorry, why are those keytypes different ? Aren't we talking of asymmetrical keys in both cases ? > >> I still don't get why clients can't import our classes ... and do > >> their own crypto with it (okay they are licencing issues... but we > >> want everyone to use GPL, don't we ? :p) > >> > > > > Because then client developers have to learn Yet Another API buried deep > > within the bowels of another software. That sucks. FCP would be a clean > > lean, and mean interface for crypto operations. And, frankly, from what > > I've seen so far the freenet crypto API is far from being clean, > > documented, and usable by other people. You'd have more success with > > SUN's JCE. > > > > Just to be clear: What I want is to perform cryptographic operations in > > a client. I want to create key pairs that can identify a user. I want to > > create session keys to encrypt data. I want to sign data with the keys I > > generated. Decrypting. Verifying. Client stuff, you know? :) > > > > What I do NOT want is to busy myself with JSE, JCA, BouncyCastle or any > > other API because the node can already do all that for me. > > > I would add that importing the Freenet classes requires my project to be > locked into Java, which is not desirable to me. Why not export the > functionality via FCP, so any language can use the crypto libraries > Freenet has built up rather than relying on whatever good/bad algorithm > coverage might be easily available in the external project's language of > choice. Well, here there is both the language barrier and the licensing one. That's a valid point though :) > pyfcp apps could get crypto "for free" to use over Freenet rather than > having some third party Python module need be installed because of > crypto export restrictions for the developer and the like. I've already > had one idea stall because of the crypto situation in Python and FCP > exported crypto functions would have made it a non-issue. Not really... If you're living in a crypto-restricted country, accessing a freenet node is probably forbidden too. NextGen$ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071101/af0f454c/attachment.pgp From freenet-devl at david.sowder.com Thu Nov 1 19:35:14 2007 From: freenet-devl at david.sowder.com (David Sowder) Date: Thu, 01 Nov 2007 14:35:14 -0500 Subject: [freenet-dev] Expose Crypto Stuff via FCP In-Reply-To: <20071101182100.GC4236@freenetproject.org> References: <1193821127.10134.48.camel@localhost> <20071031153144.GA4141@freenetproject.org> <1193852061.7033.4.camel@localhost> <4728C6C0.3040709@david.sowder.com> <20071031211154.GH4141@freenetproject.org> <1193865660.7033.17.camel@localhost> <472A0405.8040209@david.sowder.com> <20071101182100.GC4236@freenetproject.org> Message-ID: <472A2A72.9010602@david.sowder.com> Florent Daigni?re wrote: > * David Sowder [2007-11-01 11:51:17]: > > >> David ???Bombe??? Roden wrote: >> > > [snip.] > > >>> Which is true for FNP but not necessarily for FCP. >>> >>> >> Yes. I in my thinking, FCP's job is to encourage Freenet related apps >> and promote a standard method of communicating with Freenet and >> Freenet-related facilities in the process. >> > > Sound idea and basis... I don't see how crypto is freenet specific or > even related though. > It's not directly related, but both are privacy related. >>>> That's what the GenerateSSK message is for. >>>> >>>> >>> You have no idea what I'm talking about, do you? Otherwise please tell >>> me how I use that key pair to encrypt data. Thank you in advance. :) >>> >>> >> Yes, GPG-style key pairs rather than public and private SSK keys. >> > > I don't get it, sorry, why are those keytypes different ? Aren't we > talking of asymmetrical keys in both cases ? > GPG-style key pairs are general use. SSKs are very purpose specific, though I admit I might be able to see where you're coming from, I just don't think I've wrapped my head all the way around it yet. >>>> I still don't get why clients can't import our classes ... and do >>>> their own crypto with it (okay they are licencing issues... but we >>>> want everyone to use GPL, don't we ? :p) >>>> >>>> >>> Because then client developers have to learn Yet Another API buried deep >>> within the bowels of another software. That sucks. FCP would be a clean >>> lean, and mean interface for crypto operations. And, frankly, from what >>> I've seen so far the freenet crypto API is far from being clean, >>> documented, and usable by other people. You'd have more success with >>> SUN's JCE. >>> >>> Just to be clear: What I want is to perform cryptographic operations in >>> a client. I want to create key pairs that can identify a user. I want to >>> create session keys to encrypt data. I want to sign data with the keys I >>> generated. Decrypting. Verifying. Client stuff, you know? :) >>> >>> What I do NOT want is to busy myself with JSE, JCA, BouncyCastle or any >>> other API because the node can already do all that for me. >>> >>> >> I would add that importing the Freenet classes requires my project to be >> locked into Java, which is not desirable to me. Why not export the >> functionality via FCP, so any language can use the crypto libraries >> Freenet has built up rather than relying on whatever good/bad algorithm >> coverage might be easily available in the external project's language of >> choice. >> > > Well, here there is both the language barrier and the licensing one. > That's a valid point though :) > > >> pyfcp apps could get crypto "for free" to use over Freenet rather than >> having some third party Python module need be installed because of >> crypto export restrictions for the developer and the like. I've already >> had one idea stall because of the crypto situation in Python and FCP >> exported crypto functions would have made it a non-issue. >> > > Not really... If you're living in a crypto-restricted country, accessing > a freenet node is probably forbidden too. > In my case, the crypto restriction is only that I have to do certain things to be able to legally share cryptography code with those outside of my country and since I haven't worked out the exact details of what that would entail, I've avoided "sharing" (i.e. exporting) such code. This is not the same kind of crypto restriction that would make Freenet nodes illegal though (yet). From NEOatNHNG at users.sourceforge.net Fri Nov 2 00:47:25 2007 From: NEOatNHNG at users.sourceforge.net (=?ISO-8859-15?Q?Michael_T=E4nzer?=) Date: Fri, 02 Nov 2007 01:47:25 +0100 Subject: [freenet-dev] Tiny Update of German the Language and broken Link (freenet.l10n.de.v1070) Message-ID: <472A739D.5090605@users.sourceforge.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there is a tiny language override attached and I wanted to report, that the link to Freemail (on http://freenetproject.org/freemail.html) is broken. Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHKnOdPUBAMhFf+J4RAtCgAJoDiG8OM/QV+WQHDcX21pxGxYeVZQCcCsAe kZd3NxsV40yM6i0TPt4N6Tw= =D0cz -----END PGP SIGNATURE----- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freenet.l10n.de.override.properties Url: http://emu.freenetproject.org/pipermail/devl/attachments/20071102/ced011ff/attachment.txt From nextgens at freenetproject.org Fri Nov 2 01:07:52 2007 From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=) Date: Fri, 2 Nov 2007 02:07:52 +0100 Subject: [freenet-dev] Tiny Update of German the Language and broken Link (freenet.l10n.de.v1070) In-Reply-To: <472A739D.5090605@users.sourceforge.net> References: <472A739D.5090605@users.sourceforge.net> Message-ID: <20071102010752.GF4236@freenetproject.org> * Michael T?nzer [2007-11-02 01:47:25]: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi > > there is a tiny language override attached and I wanted to report, that > the link to Freemail (on http://freenetproject.org/freemail.html) is broken. > > Michael > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFHKnOdPUBAMhFf+J4RAtCgAJoDiG8OM/QV+WQHDcX21pxGxYeVZQCcCsAe > kZd3NxsV40yM6i0TPt4N6Tw= > =D0cz > -----END PGP SIGNATURE----- > Node.inBWLimit=Limit f??r hereinkommende Bandbreite (Bytes pro Sekunde) > End Commited in r15658 and r15659 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071102/a8536ce2/attachment.pgp From Volodya at WhenGendarmeSleeps.org Fri Nov 2 16:24:10 2007 From: Volodya at WhenGendarmeSleeps.org (Volodya) Date: Fri, 02 Nov 2007 19:24:10 +0300 Subject: [freenet-dev] Expose Crypto Stuff via FCP In-Reply-To: <20071101180820.GB4236@freenetproject.org> References: <1193821127.10134.48.camel@localhost> <20071031153144.GA4141@freenetproject.org> <1193852061.7033.4.camel@localhost> <4728C6C0.3040709@david.sowder.com> <20071031211154.GH4141@freenetproject.org> <1193865660.7033.17.camel@localhost> <20071101180820.GB4236@freenetproject.org> Message-ID: <472B4F2A.2090400@WhenGendarmeSleeps.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > The main asset of FCPv2 over v1 is simplicity. > To encrypt you insert your data to a SSK... to decrypt you get the data from > the pubkey of the SSK. > > To sign, you insert the data to a CHK and its hash to a SSK/USK. To > verify the sig, you do the opposite. > > To do symmetrical encryption you share both the pubkey and the private > key of the SSK. > > What's missing ? Simplicity is missing. - -- http://freedom.libsyn.com/ Voice of Freedom, Radical Podcast http://freeselfdefence.info/ Self-defence wiki http://www.kingstonstudents.org/ Kingston University students' forum "None of us are free until all of us are free." ~ Mihail Bakunin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHK08puWy2EFICg+0RAuGwAJ9cPCmnqf79xGaZDaeqEarQvKbIMgCfR+Yi 5u6xrAH4gJe5qu7+wEBhvU4= =zsZw -----END PGP SIGNATURE----- From nextgens at freenetproject.org Fri Nov 2 16:24:59 2007 From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=) Date: Fri, 2 Nov 2007 17:24:59 +0100 Subject: [freenet-dev] Expose Crypto Stuff via FCP In-Reply-To: <472B4F2A.2090400@WhenGendarmeSleeps.org> References: <1193821127.10134.48.camel@localhost> <20071031153144.GA4141@freenetproject.org> <1193852061.7033.4.camel@localhost> <4728C6C0.3040709@david.sowder.com> <20071031211154.GH4141@freenetproject.org> <1193865660.7033.17.camel@localhost> <20071101180820.GB4236@freenetproject.org> <472B4F2A.2090400@WhenGendarmeSleeps.org> Message-ID: <20071102162458.GA7507@freenetproject.org> * Volodya [2007-11-02 19:24:10]: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > The main asset of FCPv2 over v1 is simplicity. > > > To encrypt you insert your data to a SSK... to decrypt you get the data from > > the pubkey of the SSK. > > > > To sign, you insert the data to a CHK and its hash to a SSK/USK. To > > verify the sig, you do the opposite. > > > > To do symmetrical encryption you share both the pubkey and the private > > key of the SSK. > > > > What's missing ? > > Simplicity is missing. > Would adding yetAnotherLayer of crypto contribute to simplicity ? How ? I fail to get your point. NextGen$ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071102/ca053ad2/attachment.pgp From jolantern60 at yahoo.com Fri Nov 2 23:25:19 2007 From: jolantern60 at yahoo.com (Jack O'Lantern) Date: Fri, 2 Nov 2007 16:25:19 -0700 (PDT) Subject: [freenet-dev] Diffie-Hellman security fix for freenet 0.5 Message-ID: <864265.36396.qm@web44816.mail.sp1.yahoo.com> Hi, it took me some time but I managed to subscribe to this list through TOR. I've sent and canceled a previous message, sorry for the confusion. I've attached a patch for freenet 0.5. It fixes the Diffie-Hellman exponential weakness. I hope I caught every instance of this weakness in the code. Please apply this patch and build freenet 0.5-5108. "Nomen Nescio" kindly posted the patch to the support list in the form in which I posted it on Frost at Freenet 0.5. The only difference in the attached patch is that the build.xml file remains unchanged, so you can use your own build process. Jack __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- A non-text attachment was scrubbed... Name: freenet_dh.patch Type: text/x-patch Size: 4475 bytes Desc: 3255486507-freenet_dh.patch Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071102/b37fd4ba/attachment.bin From martin.nyhus at sensewave.com Sun Nov 4 12:50:14 2007 From: martin.nyhus at sensewave.com (Martin Nyhus) Date: Sun, 04 Nov 2007 13:50:14 +0100 Subject: [freenet-dev] Updated Norwegian translation Message-ID: <1194180614.13567.2.camel@decoy.lan> A few new and updated strings for the Norwegian translation -------------- next part -------------- BookmarkEditorToadlet.urlDecodeError=Feil ved dekoding av URL ConfigToadlet.possibilitiesTitle=Dine muligheter ConnectionsToadlet.nodeStatus.BACKED OFF=OPPTATT ConnectionsToadlet.nodeStatus.BUSY=OPPTATT ConnectionsToadlet.nodeStatus.CLOCK PROBLEM=KLOKKEPROBLEM ConnectionsToadlet.nodeStatus.CONNECTED=TILKOPLET ConnectionsToadlet.nodeStatus.CONNECTION ERROR=TILKOPLINGSFEIL ConnectionsToadlet.nodeStatus.DISABLED=DEAKTIVERT ConnectionsToadlet.nodeStatus.DISCONNECTED=FRAKOPLET ConnectionsToadlet.nodeStatus.DISCONNECTING=KOBLER FRA ConnectionsToadlet.nodeStatus.LISTEN ONLY=BARE LYTT ConnectionsToadlet.nodeStatus.LISTENING=LYTTER ConnectionsToadlet.nodeStatus.NEVER CONNECTED=ALDRI TILKOPLET ConnectionsToadlet.nodeStatus.TOO NEW=FOR NY ConnectionsToadlet.nodeStatus.TOO OLD=FOR GAMMEL ConnectionsToadlet.nodeStatus.UNKNOWN STATUS=UKJENT STATUS DarknetConnectionsToadlet.addPeerTitle=Legg til en ny node DarknetConnectionsToadlet.backedOff=Tilkoblet, men opptatt: Disse nodene er tilkoblet, men er opptatt, s? noden din sender ingen foresp?rsler til dem. DarknetConnectionsToadlet.busy=Opptatt: Disse nodene er tilkoblet, men for opptatt til ? svare p? v?re foresp?rsler, s? noden din sender ingen foresp?rsler til dem. DarknetConnectionsToadlet.disabled=Ikke tilkoblet og deaktivert: Du har instruert noden din til ikke ? koble til disse nodene. DarknetConnectionsToadlet.listenOnly=Ikke tilkoblet og bare lytter: noden din vil ikke pr?ve ? koble til disse nodene, fordi brukeren har markert de med BareLytt. DarknetConnectionsToadlet.neverConnected=Aldri tilkoblet: Noden din har aldri koblet til disse nodene. DarknetConnectionsToadlet.noPeersWithHomepageLink=Freenet kan ikke fungere ettersom du ikke har lagt til noen noder s? langt. Vennligst g? til ${link}nodens hjemmeside${/link} og les den ?verste infoboksen for ? se hvordan dette gj?res. DarknetConnectionsToadlet.privateNote=Et privat notat om denne noden DarknetConnectionsToadlet.removePeers=Fjern valgte noder DarknetConnectionsToadlet.tooNew=Tilkoblet, men for ny: Disse nodenes laveste obligatoriske versjon er h?yere enn din nodes versjonsnummer. DarknetConnectionsToadlet.tooOld=Tilkoplet, men for gammel: Din nodes laveste obligatoriske versjon er h?yere enn denne nodens versjonsnummer. Noden din vil ikke sende foresp?rsler til denne noden. DarknetConnectionsToadlet.triedToAddSelf=Du kan ikke legge til din egen node til listen over eksterne noder. FProxyToadlet.opennet=Administrer fremmede noder FProxyToadlet.plugins=Administrer tillegg MeaningfulNodeNameUserAlert.noNodeNick=Det virker som noden din ikke vet om pseudonymet ditt. Generelt sett er det en god ide ? legge inn e-mail adressen din eller IRC pseudonymet ditt her s? vennene dine lettere kan identifisere noden din (merk at bare venner kan se node-navnet ditt, det vises ikke til fremmede). OpennetConnectionsToadlet.fullTitle=${counts} Fremmede (ukjente noder) tilkoblet ${name} OpennetConnectionsToadlet.peersListTitle=Mine Opennet koplinger (ukjente noder lagt til av noden din i promisku?s modus) OpennetUserAlert.warning=Noden din er for tiden i promisku?s modus. Den vil koble til Fremmede, and det betyr at alle kan finne ut at du har en node. De fleste angrep er lettere, blokkering av noden din (for eksempel med en nasjonal brannmur) er mye lettere og du har ingen kontroll over hvem noden din kopler til. Vi anbefaler sterkt at du skaffer deg noen koplinger til Venner (noder du som stoler p? og som er kontrollert av folk du allerede kjenner); promisku?s modus er bare ment som et midlertidig tiltak til du kan kople til vennene dine. Hvis du bare kopler til vennene dine er det mindre sjanse for at noden din er synlig for undertrykkende organisasjoner som vil kople til deg, selv vennene dine kan angripe deg. Merk at ? legge til en node i Venne-delen ikke hjelper mye hvis denne noden ikke kontrolleres av noen du faktisk kjenner (b?de for nettverkets- og for sikkerhetsgrunner)! OpennetUserAlert.warningTitle=Advarsel: Promisku?s modus aktivert: Noden din kan koble til Fremmede PeerManagerUserAlert.noConns=Noden din har ikke kunnet koble til noen andre noder s? langt; den vil ikke kunne fungere normalt. Forh?pentligvis vil noen av nodene koble til snart; hvis ikke, pr?v ? skaffe noen flere tilkoplinger. Du trenger minst 3 tilkoplinger, og b?r ha 5-10. PeerManagerUserAlert.tooManyConns=Denne noden har for mange tilkoblinger (${count} > ${max}). ? legge til et stort antall noder automatisk vil ikke gi en 'small-world' topologi og kan skade nettverket. PeerManagerUserAlert.tooManyDisconnectedTitle=For mange frakoplede noder PeerManagerUserAlert.twoConns=Denne noden har bare to tilkoplinger. Du vil ikke f? god ytelse eller sikkerhet, og noden din hjelper bare i liten grad nettverket. Pr?v ? ha minst 3 (helst 5-10) tilkoplede noder til en hver tid. PluginManager.loadedOnStartupLong=Klasse-sti, navn og lokasjon for tillegg som skal lastes n?r noden starter PluginManager.pluginLoadingFailed=Kunne ikke starte tillegget ${name} PluginManager.pluginLoadingFailedTitle=Kunne ikke starte tillegget! PluginManager.pluginLoadingFailedWithMessage=Kunne ikke starte tillegget ${name}: ${message} PluginManager.pluginReqNewerJVMTitle=Nyere JVM kreves av tillegget ${name}. PluginToadlet.failedToLoadPluginTitle=Tillegget mislyktes i ? starte PluginToadlet.loadPluginCommand=Start tillegg PluginToadlet.pluginListTitle=Liste over tillegg PproxyToadlet.Error=Feil PproxyToadlet.Load=Start PproxyToadlet.changeReloadOnStartup=Endre PproxyToadlet.downloadNotAllowedFromRemoteServer=Nedlasting av tillegg er bare tillat fra v?re servere. PproxyToadlet.loadOfficialPlugin=Start et offisielt tillegg PproxyToadlet.loadOfficialPluginLabel=Start et offisielt tillegg PproxyToadlet.loadOfficialPluginText=Disse tilleggene ligger p? servere hos The Freenet Project. Vi mener at disse tilleggene ikke lekker privat informasjon, men vi kan ikke garantere dette. PproxyToadlet.loadOtherPlugin=Start et uoffisielt tillegg PproxyToadlet.loadOtherPluginText=Her kan du legge inn en URL til et tillegg du vil starte. Tillegg som ikke er i listen over er ikke st?ttet eller sjekket av oss, s? bruk av dette feltet gj?res p? eget ansvar. PproxyToadlet.loadOtherURLLabel=URL til tillegg PproxyToadlet.loadPluginLabel=Start tillegg: PproxyToadlet.noPlugins=Ingen tillegg er lastet PproxyToadlet.pluginDirectoryNotCreated=Kunne ikke opprette tilleggskatalogen. PproxyToadlet.pluginNotDownloaded=Kunne ikke laste ned tillegget. PproxyToadlet.pluginNotFoundReload=Fant ikke det spesifiserte tillegget for ? starte det p? nytt. PproxyToadlet.pluginNotFoundReloadTitle=Fant ikke tillegget (starter det p? nytt) PproxyToadlet.pluginStopping=Tillegg stopper PproxyToadlet.pluginUnloaded=Tillegg stoppet PproxyToadlet.pluginUnloadedWithName=Tillegget ${name} ble stoppet. PproxyToadlet.pluginsWithNodeName=Tillegg for ${name} PproxyToadlet.refreshOnStartup=Last ned fra serveren ved oppstart PproxyToadlet.reload=Start p? nytt PproxyToadlet.reloadOnStartupShort=Last ned ved oppstart PproxyToadlet.returnToPluginPage=Returner til tillegg-siden PproxyToadlet.startingPluginName=Navn p? tillegg PproxyToadlet.startingPluginStatus=N?v?rende status PproxyToadlet.startingPluginTime=Brukt tid PproxyToadlet.startingPluginsTitle=Startende tillegg PproxyToadlet.unauthorized=Du har ikke adgang til ? vise denne siden. PproxyToadlet.unauthorizedTitle=Uautorisert tilgang PproxyToadlet.unload=Stopp PproxyToadlet.unloadPluginTitle=Stopp tillegg? PproxyToadlet.unloadPluginWithName=Er du sikker p? at du vil stoppe ${name}? PproxyToadlet.startingPluginStatus.downloading=Laster ned PproxyToadlet.startingPluginStatus.starting=starter QueueToadlet.globalQueueIsEmpty=Den globale k?en er tom QueueToadlet.insertFileBrowseLabel=Finn fil QueueToadlet.insertFileCompressLabel=Komprimer QueueToadlet.insertFileInsertFileLabel=Sett inn fil QueueToadlet.insertFileLabel=Fil QueueToadlet.insertFileResetForm=Tilbakestill skjema QueueToadlet.noTaskOnGlobalQueue=Det er ingen oppgaver i den globale k?en for ?yeblikket. StatisticsToadlet.fullTitle=Statistikk for ${name} StatisticsToadlet.inputRate=Inndata fart: ${rate}/s (av ${max}/s) StatisticsToadlet.outputRate=Utdata fart: ${rate}/s (av ${max}/s) StatisticsToadlet.payloadOutput=Nyttig utdata: ${total} (${rate}/s)(${percent}%) StatisticsToadlet.statisticGatheringTitle=Innsamling av statistikk StatisticsToadlet.totalInput=Inndate totalt: ${total} (${rate}/s) StatisticsToadlet.totalOutput=Utdata totalt: ${total} (${rate}/s) StatisticsToadlet.transferringRequests=Overf?rende Foresp?rsler: sender ${senders}, mottar ${receivers} TranslationToadlet.downloadTranslationsFile=Last ned din oversettelsesfil WelcomeToadlet.arkFetchCount=ARK Hentere: ${total} WelcomeToadlet.keyRequestLabel=N?kkel: WelcomeToadlet.versionHeader=Informasjon og kontroll av noden End -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071104/d51783a2/attachment.pgp From nextgens at freenetproject.org Sun Nov 4 19:11:59 2007 From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=) Date: Sun, 4 Nov 2007 20:11:59 +0100 Subject: [freenet-dev] Updated Norwegian translation In-Reply-To: <1194180614.13567.2.camel@decoy.lan> References: <1194180614.13567.2.camel@decoy.lan> Message-ID: <20071104191158.GA9734@freenetproject.org> * Martin Nyhus [2007-11-04 13:50:14]: > A few new and updated strings for the Norwegian translation Commited in r15684, thanks :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071104/553aa5ad/attachment.pgp From nextgens at freenetproject.org Wed Nov 7 22:00:46 2007 From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=) Date: Wed, 7 Nov 2007 23:00:46 +0100 Subject: [freenet-dev] alternative to #freenet-refs Message-ID: <20071107220045.GA4554@freenetproject.org> Hi, Seeing how many people are complaining about the complexity of setting an IRC client up, I've set up a "tribune" (sorry I dunno the english word for it). http://ref.freenetproject.org/ Shall we advertize it in the installer and deprecate #freenet-refs ? The caveat is that "private messaging" isn't possible... Well, most people weren't using it anyway as freenode requires registration... Atm we keep its history but I guess we shouldn't if we decide to switch it to "production" mode. NextGen$ PS: it would be associated to a dedicate pastebin where people would be given instructions on how to publish their references. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071107/42963b24/attachment.pgp From fred.rec at gmail.com Wed Nov 7 22:40:27 2007 From: fred.rec at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric?=) Date: Wed, 7 Nov 2007 23:40:27 +0100 Subject: [freenet-dev] alternative to #freenet-refs In-Reply-To: <20071107220045.GA4554@freenetproject.org> References: <20071107220045.GA4554@freenetproject.org> Message-ID: <78f82c3e0711071440y1f8a9e7ft6d25a6ebce5ca5d9@mail.gmail.com> Hi, A significant percentage of the new Freenet users doesn't understand the way to exchange refs through IRC. Some of them doesn't know how to use a pastebin and most of them who aren't registered at Freenode doesn't understand why their private messages never arrived. So, yes I think it's a good idea to provide our own exchange system. Mc2 From freenet-devl at david.sowder.com Thu Nov 8 00:29:01 2007 From: freenet-devl at david.sowder.com (David Sowder (Zothar)) Date: Wed, 07 Nov 2007 18:29:01 -0600 Subject: [freenet-dev] alternative to #freenet-refs In-Reply-To: <78f82c3e0711071440y1f8a9e7ft6d25a6ebce5ca5d9@mail.gmail.com> References: <20071107220045.GA4554@freenetproject.org> <78f82c3e0711071440y1f8a9e7ft6d25a6ebce5ca5d9@mail.gmail.com> Message-ID: <4732584D.7000201@david.sowder.com> Perhaps we could write a plugin or separate program to grab the opennet ref from the node, post it on this or some other pastebin, and provide the user with the URL to trade. I don't know about the plugin approach nor a Java program, but I don't think it'd take me much to code this with pyFreenet. Fr?d?ric wrote: > Hi, > > A significant percentage of the new Freenet users doesn't understand > the way to exchange refs through IRC. Some of them doesn't know how to > use a pastebin and most of them who aren't registered at Freenode > doesn't understand why their private messages never arrived. > So, yes I think it's a good idea to provide our own exchange system. > From nextgens at freenetproject.org Thu Nov 8 00:38:59 2007 From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=) Date: Thu, 8 Nov 2007 01:38:59 +0100 Subject: [freenet-dev] alternative to #freenet-refs In-Reply-To: <4732584D.7000201@david.sowder.com> References: <20071107220045.GA4554@freenetproject.org> <78f82c3e0711071440y1f8a9e7ft6d25a6ebce5ca5d9@mail.gmail.com> <4732584D.7000201@david.sowder.com> Message-ID: <20071108003859.GB4554@freenetproject.org> * David Sowder (Zothar) [2007-11-07 18:29:01]: > Perhaps we could write a plugin or separate program to grab the opennet > ref from the node, post it on this or some other pastebin, and provide > the user with the URL to trade. I don't know about the plugin approach > nor a Java program, but I don't think it'd take me much to code this > with pyFreenet. > pyFreenet is great... but do we want python to be yetAnotherDependency ? > Fr?d?ric wrote: > > Hi, > > > > A significant percentage of the new Freenet users doesn't understand > > the way to exchange refs through IRC. Some of them doesn't know how to > > use a pastebin and most of them who aren't registered at Freenode > > doesn't understand why their private messages never arrived. > > So, yes I think it's a good idea to provide our own exchange system. > > > > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071108/2667724a/attachment.pgp From freenet-devl at david.sowder.com Thu Nov 8 00:47:16 2007 From: freenet-devl at david.sowder.com (David Sowder (Zothar)) Date: Wed, 07 Nov 2007 18:47:16 -0600 Subject: [freenet-dev] alternative to #freenet-refs In-Reply-To: <20071108003859.GB4554@freenetproject.org> References: <20071107220045.GA4554@freenetproject.org> <78f82c3e0711071440y1f8a9e7ft6d25a6ebce5ca5d9@mail.gmail.com> <4732584D.7000201@david.sowder.com> <20071108003859.GB4554@freenetproject.org> Message-ID: <47325C94.4080001@david.sowder.com> If I were to write it, Python'd be a dependency until somebody wrote either a Freenet plugin or a standalone Java program that did the same thing. I just mention pyFreenet because it's what I know. Someone who is more comfortable in Java could probably code this up just as quickly. Florent Daigni?re wrote: > * David Sowder (Zothar) [2007-11-07 18:29:01]: > > >> Perhaps we could write a plugin or separate program to grab the opennet >> ref from the node, post it on this or some other pastebin, and provide >> the user with the URL to trade. I don't know about the plugin approach >> nor a Java program, but I don't think it'd take me much to code this >> with pyFreenet. >> >> > > pyFreenet is great... but do we want python to be yetAnotherDependency ? > > >> Fr?d?ric wrote: >> >>> Hi, >>> >>> A significant percentage of the new Freenet users doesn't understand >>> the way to exchange refs through IRC. Some of them doesn't know how to >>> use a pastebin and most of them who aren't registered at Freenode >>> doesn't understand why their private messages never arrived. >>> So, yes I think it's a good idea to provide our own exchange system. >>> From m.rogers at cs.ucl.ac.uk Thu Nov 8 02:25:14 2007 From: m.rogers at cs.ucl.ac.uk (Michael Rogers) Date: Thu, 08 Nov 2007 02:25:14 +0000 Subject: [freenet-dev] alternative to #freenet-refs In-Reply-To: <20071107220045.GA4554@freenetproject.org> References: <20071107220045.GA4554@freenetproject.org> Message-ID: <4732738A.9010804@cs.ucl.ac.uk> Florent Daigni?re wrote: > PS: it would be associated to a dedicate pastebin where people would be > given instructions on how to publish their references. Now that JFK's been implemented, would it be possible to avoid pastebins by reducing the amount of information in the ref? If all the cryptographic parameters (including the complete public keys) are established and verified during JFK, does the ref need to contain anything apart from an IP address, port number and key fingerprint? Cheers, Michael From bombe at pterodactylus.net Thu Nov 8 03:25:02 2007 From: bombe at pterodactylus.net (David =?UTF-8?Q?=E2=80=98Bombe=E2=80=99?= Roden) Date: Thu, 08 Nov 2007 04:25:02 +0100 Subject: [freenet-dev] alternative to #freenet-refs In-Reply-To: <47325C94.4080001@david.sowder.com> References: <20071107220045.GA4554@freenetproject.org> <78f82c3e0711071440y1f8a9e7ft6d25a6ebce5ca5d9@mail.gmail.com> <4732584D.7000201@david.sowder.com> <20071108003859.GB4554@freenetproject.org> <47325C94.4080001@david.sowder.com> Message-ID: <1194492302.25375.10.camel@localhost> On Wed, 2007-11-07 at 18:47 -0600, David Sowder (Zothar) wrote: > If I were to write it, Python'd be a dependency until somebody wrote > either a Freenet plugin or a standalone Java program that did the > same thing. I just mention pyFreenet because it's what I know. > Someone who is more comfortable in Java could probably code this up > just as quickly. I'd be willing and able to write a plugin to do just that. Additionally I even think that that's a good idea. :) If the node first starts up and realizes that it doesn't have a single peer, an alert will tell the user to go the plugins page and load the "OpenNet Collector" plugin and everything will be good. No fiddling with IRC clients, FreeNode registration, python bots, pastebins... just pure 1-click comfort. (We should register "1-Click Comfort" as trademark. ;) Bombe -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071108/901b1425/attachment.pgp From ian at locut.us Thu Nov 8 16:26:41 2007 From: ian at locut.us (Ian Clarke) Date: Thu, 8 Nov 2007 10:26:41 -0600 Subject: [freenet-dev] alternative to #freenet-refs In-Reply-To: <20071107220045.GA4554@freenetproject.org> References: <20071107220045.GA4554@freenetproject.org> Message-ID: <823242bd0711080826i4afeb240h2916b2f4adafb59f@mail.gmail.com> At the risk of stating the obvious, the real solution here is fully automatic opennet. Where are we with that? Ian. On 11/7/07, Florent Daigni?re wrote: > Hi, > > Seeing how many people are complaining about the complexity of > setting an IRC client up, I've set up a "tribune" (sorry I dunno > the english word for it). > > http://ref.freenetproject.org/ > > Shall we advertize it in the installer and deprecate > #freenet-refs ? The caveat is that "private messaging" isn't > possible... Well, most people weren't using it anyway as > freenode requires registration... > > Atm we keep its history but I guess we shouldn't if we decide to > switch it to "production" mode. > > NextGen$ > PS: it would be associated to a dedicate pastebin where people would be > given instructions on how to publish their references. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFHMjWNU/Z/dHFfxtcRAjspAKCpd7mQp06LEyow/roEjk3Ldq+t5gCcCChc > LOYRhnyyxbcnRRNAaVcmxLs= > =+YLP > -----END PGP SIGNATURE----- > > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > -- Founder and CEO, Thoof Inc Email: ian at thoof.com Office: +1 512 524 8934 x 100 Cell: +1 512 422 3588 AIM: ian.clarke at mac.com Skype: sanity From nextgens at freenetproject.org Thu Nov 8 17:54:55 2007 From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=) Date: Thu, 8 Nov 2007 18:54:55 +0100 Subject: [freenet-dev] alternative to #freenet-refs In-Reply-To: <823242bd0711080826i4afeb240h2916b2f4adafb59f@mail.gmail.com> References: <20071107220045.GA4554@freenetproject.org> <823242bd0711080826i4afeb240h2916b2f4adafb59f@mail.gmail.com> Message-ID: <20071108175455.GF4117@freenetproject.org> * Ian Clarke [2007-11-08 10:26:41]: > At the risk of stating the obvious, the real solution here is fully > automatic opennet. Where are we with that? Toad is the only one working on it or related matters. As far as I know he is away and likely to be unavailable for some time... Regarding "fully automatic opennet", the requirements are: - Implement something to discover which kind of NAT we are behind (we already have STUN but it's centralized and sucks) - Implement the support of anonymous connection over JFK - Implement the announcement protocol Last time we spoke about it, the plan was "will hopefully be ready for the end of the year" NextGen$ > > On 11/7/07, Florent Daigni?re wrote: > > Hi, > > > > Seeing how many people are complaining about the complexity of > > setting an IRC client up, I've set up a "tribune" (sorry I dunno > > the english word for it). > > > > http://ref.freenetproject.org/ > > > > Shall we advertize it in the installer and deprecate > > #freenet-refs ? The caveat is that "private messaging" isn't > > possible... Well, most people weren't using it anyway as > > freenode requires registration... > > > > Atm we keep its history but I guess we shouldn't if we decide to > > switch it to "production" mode. > > > > NextGen$ > > PS: it would be associated to a dedicate pastebin where people would be > > given instructions on how to publish their references. > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.6 (GNU/Linux) > > > > iD8DBQFHMjWNU/Z/dHFfxtcRAjspAKCpd7mQp06LEyow/roEjk3Ldq+t5gCcCChc > > LOYRhnyyxbcnRRNAaVcmxLs= > > =+YLP > > -----END PGP SIGNATURE----- > > > > _______________________________________________ > > Devl mailing list > > Devl at freenetproject.org > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > > > > -- > Founder and CEO, Thoof Inc > Email: ian at thoof.com > Office: +1 512 524 8934 x 100 > Cell: +1 512 422 3588 > AIM: ian.clarke at mac.com > Skype: sanity -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071108/62fc4ae3/attachment.pgp From nextgens at freenetproject.org Thu Nov 8 18:00:41 2007 From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=) Date: Thu, 8 Nov 2007 19:00:41 +0100 Subject: [freenet-dev] alternative to #freenet-refs In-Reply-To: <4732738A.9010804@cs.ucl.ac.uk> References: <20071107220045.GA4554@freenetproject.org> <4732738A.9010804@cs.ucl.ac.uk> Message-ID: <20071108180041.GG4117@freenetproject.org> * Michael Rogers [2007-11-08 02:25:14]: > Florent Daigni?re wrote: > > PS: it would be associated to a dedicate pastebin where people would be > > given instructions on how to publish their references. > > Now that JFK's been implemented, would it be possible to avoid pastebins > by reducing the amount of information in the ref? If all the > cryptographic parameters (including the complete public keys) are > established and verified during JFK, does the ref need to contain > anything apart from an IP address, port number and key fingerprint? > We haven't implemented an anonymous connection protocol. JFK assumes that there is a certificate chain or something we could use to verify who we are talking to... In our case it's the crypto. parameters we have in noderefs: We need them on darknet. Moreover our implementation of JFK features identity protection of both the responder and the initiator (as we are on darknet we know who we are "talking" to anyway). We could reduce the size of noderefs to the expense of flexibility... ATM we share a common DSA group... We could get rid of it in noderefs but they would remain be too big for beeing exchangeable over the phone. NextGen$ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071108/f2f52a0f/attachment.pgp From nextgens at freenetproject.org Thu Nov 8 18:04:11 2007 From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=) Date: Thu, 8 Nov 2007 19:04:11 +0100 Subject: [freenet-dev] alternative to #freenet-refs In-Reply-To: <1194492302.25375.10.camel@localhost> References: <20071107220045.GA4554@freenetproject.org> <78f82c3e0711071440y1f8a9e7ft6d25a6ebce5ca5d9@mail.gmail.com> <4732584D.7000201@david.sowder.com> <20071108003859.GB4554@freenetproject.org> <47325C94.4080001@david.sowder.com> <1194492302.25375.10.camel@localhost> Message-ID: <20071108180411.GH4117@freenetproject.org> * David ???Bombe??? Roden [2007-11-08 04:25:02]: > > On Wed, 2007-11-07 at 18:47 -0600, David Sowder (Zothar) wrote: > > > If I were to write it, Python'd be a dependency until somebody wrote > > either a Freenet plugin or a standalone Java program that did the > > same thing. I just mention pyFreenet because it's what I know. > > Someone who is more comfortable in Java could probably code this up > > just as quickly. > > I'd be willing and able to write a plugin to do just that. Additionally > I even think that that's a good idea. :) > > If the node first starts up and realizes that it doesn't have a single > peer, an alert will tell the user to go the plugins page and load the > "OpenNet Collector" plugin and everything will be good. No fiddling with > IRC clients, FreeNode registration, python bots, pastebins... just pure > 1-click comfort. (We should register "1-Click Comfort" as trademark. ;) > > You didn't get what I was suggesting; As explained on IRC, I'm not proposing to implement a wonky opennet but to replace #freenet-refs by the tribune in order to minimize the hassle the user has to go through to set up a node (installing an irc client, registering with freenode, ...). NextGen$ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071108/a152901e/attachment.pgp From m.rogers at cs.ucl.ac.uk Thu Nov 8 18:19:37 2007 From: m.rogers at cs.ucl.ac.uk (Michael Rogers) Date: Thu, 08 Nov 2007 18:19:37 +0000 Subject: [freenet-dev] alternative to #freenet-refs In-Reply-To: <20071108180041.GG4117@freenetproject.org> References: <20071107220045.GA4554@freenetproject.org> <4732738A.9010804@cs.ucl.ac.uk> <20071108180041.GG4117@freenetproject.org> Message-ID: <47335339.6040907@cs.ucl.ac.uk> Florent Daigni?re wrote: > We haven't implemented an anonymous connection protocol. JFK assumes > that there is a certificate chain or something we could use to verify > who we are talking to... In our case it's the crypto. parameters we have > in noderefs: We need them on darknet. Exactly - the parameters are exchanged during JFK. The ref only needs to contain the hash of the parameters so that we can verify them. That means the ref can be around 38 bytes (IP address + port + hash) - small enough to exchange over the phone, IRC, etc. Cheers, Michael From bombe at pterodactylus.net Thu Nov 8 18:22:30 2007 From: bombe at pterodactylus.net (David =?UTF-8?Q?=E2=80=98Bombe=E2=80=99?= Roden) Date: Thu, 08 Nov 2007 19:22:30 +0100 Subject: [freenet-dev] alternative to #freenet-refs In-Reply-To: <20071108180411.GH4117@freenetproject.org> References: <20071107220045.GA4554@freenetproject.org> <78f82c3e0711071440y1f8a9e7ft6d25a6ebce5ca5d9@mail.gmail.com> <4732584D.7000201@david.sowder.com> <20071108003859.GB4554@freenetproject.org> <47325C94.4080001@david.sowder.com> <1194492302.25375.10.camel@localhost> <20071108180411.GH4117@freenetproject.org> Message-ID: <1194546151.25375.32.camel@localhost> On Thu, 2007-11-08 at 19:04 +0100, Florent Daigni?re wrote: > replace #freenet-refs by the tribune in order to minimize the hassle > the user has to go through to set up a node (installing an irc > client, registering with freenode, ...). A bundled plugin would reduce the hassle even further - which was the only thing I suggested. :) > NextGen$ Bombe -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071108/377a760d/attachment.pgp From nextgens at freenetproject.org Fri Nov 9 17:45:19 2007 From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=) Date: Fri, 9 Nov 2007 18:45:19 +0100 Subject: [freenet-dev] 1071 is out! Message-ID: <20071109174518.GB5372@freenetproject.org> A new build has been released (1071): New features: - StartupToadlet - Refactoring of the /plugins/ toadlet to improve usability - Refactoring of part of the plugins API (work in progress) - Start plugins off-thread Bugfixes: - HTMLNode was a bit too strict - *loads* of various bugfixes to fproxy - Maybe fix completionTime on FCP ClientPuts - Handshake once a while even with really old nodes - Fix the worrying message displayed about jfk (exponent-unknown) Updated translations: - Norwegian thanks to Martin Nyhus - German thanks to Thomas Credits: - Bombe - nextgens - toad -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071109/b951a001/attachment.pgp From batosai at batosai.net Fri Nov 9 20:36:42 2007 From: batosai at batosai.net (Julien Cornuwel aka batosai) Date: Fri, 09 Nov 2007 21:36:42 +0100 Subject: [freenet-dev] Updated French translation (#1071 r15726) Message-ID: <4734C4DA.50501@batosai.net> Hi, Here is a updated version of the french translation file. It also fixes a few errors... Regards -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freenet.l10n.fr.override.properties Url: http://emu.freenetproject.org/pipermail/devl/attachments/20071109/302a23c6/attachment.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071109/302a23c6/attachment.pgp From nextgens at freenetproject.org Fri Nov 9 22:44:30 2007 From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=) Date: Fri, 9 Nov 2007 23:44:30 +0100 Subject: [freenet-dev] Updated French translation (#1071 r15726) In-Reply-To: <4734C4DA.50501@batosai.net> References: <4734C4DA.50501@batosai.net> Message-ID: <20071109224429.GE5372@freenetproject.org> * Julien Cornuwel aka batosai [2007-11-09 21:36:42]: > Hi, > > Here is a updated version of the french translation file. It also fixes > a few errors... > > Regards Commited in r15732 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071109/6ea71179/attachment.pgp From nextgens at freenetproject.org Sat Nov 10 23:12:57 2007 From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=) Date: Sun, 11 Nov 2007 00:12:57 +0100 Subject: [freenet-dev] Freenet build 1073 Message-ID: <20071110231256.GA4255@freenetproject.org> 1073: bugfix release You might loose the list of loaded plugins when you will update... That's a known issue we can't easily fix. Most people want at least the JSTUN plugin (and maybe the UPnP one) to be loaded to improve their connectivity. Bugfixes: - plugins weren't loadable anymore after a failed attempt - Unloading a FreenetIPDetector plugin could lead to a NPE - New nodes were unable to start fproxy up because of a bug Feature: - Bind services to both ipv4 and ipv6 by default - Allow plugins to be reloaded ignoring the cache - Accept local filenames as plugin URI L10n: - update to the french translation (thanks to batosai) - minor improvments to the english one Credits: - Bombe - nextgens -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071111/90c96331/attachment.pgp From batosai at batosai.net Sun Nov 11 14:52:14 2007 From: batosai at batosai.net (Julien Cornuwel aka batosai) Date: Sun, 11 Nov 2007 15:52:14 +0100 Subject: [freenet-dev] Updated French translation (#1073 r15753) Message-ID: <4737171E.2020301@batosai.net> Thanks to NextGen$ for http://emu.freenetproject.org/~svn-build/l10n/ I've been able to fix previous chains that had been modified in the english version. Every translator should have a look to this page... -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freenet.l10n.fr.override.properties Url: http://emu.freenetproject.org/pipermail/devl/attachments/20071111/67cb825e/attachment.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071111/67cb825e/attachment.pgp From nextgens at freenetproject.org Sun Nov 11 15:04:12 2007 From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=) Date: Sun, 11 Nov 2007 16:04:12 +0100 Subject: [freenet-dev] Updated French translation (#1073 r15753) In-Reply-To: <4737171E.2020301@batosai.net> References: <4737171E.2020301@batosai.net> Message-ID: <20071111150412.GC4717@freenetproject.org> * Julien Cornuwel aka batosai [2007-11-11 15:52:14]: > Thanks to NextGen$ for http://emu.freenetproject.org/~svn-build/l10n/ > > I've been able to fix previous chains that had been modified in the > english version. Every translator should have a look to this page... Commited in r15758 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071111/f65d43f9/attachment.pgp From batosai at batosai.net Sun Nov 11 15:05:33 2007 From: batosai at batosai.net (Julien Cornuwel aka batosai) Date: Sun, 11 Nov 2007 16:05:33 +0100 Subject: [freenet-dev] Freenet build 1073 In-Reply-To: <20071110231256.GA4255@freenetproject.org> References: <20071110231256.GA4255@freenetproject.org> Message-ID: <47371A3D.2010304@batosai.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Florent Daigni?re a ?crit : > 1073: bugfix release > > You might loose the list of loaded plugins when you will update... That's a known issue we can't easily fix. Most people want at least the JSTUN plugin (and maybe the UPnP one) to be loaded to improve their connectivity. Could someone give a few explanations about what these plugins are doing and in which situations they are usefull ? Maybe on the wiki ? I'd like to give some hints about them in my documentation but I don't know exactly what they do... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHNxo8o6N05NzaOvURApaxAJ9Yd6iKWTlg2Cbjjnl628Bl23KdhACfbmkc hZNol29I+aWjL0T2tfD9nNM= =9NUx -----END PGP SIGNATURE----- From Volodya at WhenGendarmeSleeps.org Sun Nov 11 20:49:27 2007 From: Volodya at WhenGendarmeSleeps.org (Volodya) Date: Sun, 11 Nov 2007 23:49:27 +0300 Subject: [freenet-dev] Freenet build 1073 In-Reply-To: <20071110231256.GA4255@freenetproject.org> References: <20071110231256.GA4255@freenetproject.org> Message-ID: <47376AD7.10709@WhenGendarmeSleeps.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > - Accept local filenames as plugin URI I don't understand what this means. Is that the ability to say /path/to/file.ext rather than file:///path/to/file.ext ? - Volodya - -- http://freedom.libsyn.com/ Voice of Freedom, Radical Podcast http://eng.anarchopedia.org/ Anarchopedia, A Free Knowledge Portal "None of us are free until all of us are free." ~ Mihail Bakunin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHN2rXuWy2EFICg+0RAsb8AKDPxDj2+1XvMTu+xqSHxshq+PRyLwCg67qd ZU0tO6TIMMsJ0GL9f5eDTmc= =enFT -----END PGP SIGNATURE----- From nextgens at freenetproject.org Mon Nov 12 09:44:30 2007 From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=) Date: Mon, 12 Nov 2007 10:44:30 +0100 Subject: [freenet-dev] Freenet build 1073 In-Reply-To: <47376AD7.10709@WhenGendarmeSleeps.org> References: <20071110231256.GA4255@freenetproject.org> <47376AD7.10709@WhenGendarmeSleeps.org> Message-ID: <20071112094430.GA5019@freenetproject.org> * Volodya [2007-11-11 23:49:27]: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > - Accept local filenames as plugin URI > > I don't understand what this means. Is that the ability to say /path/to/file.ext rather than > file:///path/to/file.ext ? Yes -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071112/0fa3bff8/attachment.pgp From toad at amphibian.dyndns.org Tue Nov 13 22:19:13 2007 From: toad at amphibian.dyndns.org (Matthew Toseland) Date: Tue, 13 Nov 2007 22:19:13 +0000 Subject: [freenet-dev] Diffie-Hellman security fix for freenet 0.5 In-Reply-To: <864265.36396.qm@web44816.mail.sp1.yahoo.com> References: <864265.36396.qm@web44816.mail.sp1.yahoo.com> Message-ID: <200711132219.17544.toad@amphibian.dyndns.org> On Friday 02 November 2007 23:25, Jack O'Lantern wrote: > Hi, > > it took me some time but I managed to subscribe to > this list through TOR. I've sent and canceled a > previous message, sorry for the confusion. > > I've attached a patch for freenet 0.5. It fixes the > Diffie-Hellman exponential weakness. I hope I caught > every instance of this weakness in the code. Please > apply this patch and build freenet 0.5-5108. > > "Nomen Nescio" kindly posted the patch to the support > list in the form in which I posted it on Frost at Freenet > 0.5. The only difference in the attached patch is that > the build.xml file remains unchanged, so you can use > your own build process. The patch posted to support has been applied (without the build.xml change). It was rather troublesome to apply probably because of its going via Frost (tab to space translations?). The weak DH keys issue is not the only security problem with Freenet 0.5, and as it is unmaintained by the core team, we would be happy for you to have an SVN account and maintain Freenet 0.5. Major security issues with 0.5 (there are probably more): - CSS filter updates - HTML filter updates - Link level encryption can be cheaply DoSed on CPU (hence JFK in 0.7); this can be done stealthily as it doesn't require much bandwidth and freenet commonly uses lots of CPU, it would have the effect of overloading the node and making traffic go elsewhere, thus the attacker would know that any requests from it originate locally. This might be possible on 0.7 but is definitely easier on 0.5 because of the link level crypto. - The most effective attack may simply be to cause lots of connection churn. This is also a problem on 0.7 opennet. - And of course, 0.5 is strictly opennet (thus harvestable), routing table takeover is probably not hard, and it's unlikely given current knowledge that NGR will scale (and likely that it can be manipulated). > > Jack -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071113/4bf6a6e8/attachment.pgp From toad at amphibian.dyndns.org Tue Nov 13 22:21:50 2007 From: toad at amphibian.dyndns.org (Matthew Toseland) Date: Tue, 13 Nov 2007 22:21:50 +0000 Subject: [freenet-dev] =?utf-8?q?=5Bfreenet-cvs=5D_r15647=09-=09in=09trunk?= =?utf-8?q?/freenet/src/freenet=3A_clients/http_l10n_pluginmanager?= In-Reply-To: <1193797504.10134.43.camel@localhost> References: <20071029184534.726EB4797F8@freenetproject.org> <200710310153.53826.toad@amphibian.dyndns.org> <1193797504.10134.43.camel@localhost> Message-ID: <200711132221.50209.toad@amphibian.dyndns.org> On Wednesday 31 October 2007 02:25, David ?Bombe? Roden wrote: > On Wed, 2007-10-31 at 01:53 +0000, Matthew Toseland wrote: > > > > Not really, we could and should reuse the existing auto-updater > > > infrastructure (freenet.node.updater). > > One prerequisite would be explicit versioning of plugins. > > USKs could take care of that, couldn't they? The Freenet side is easy. But we'd need to introduce an incompatible change to the plugin API (versioning). Which of course is feasible. > > Bombe -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071113/e88d7304/attachment.pgp From toad at amphibian.dyndns.org Tue Nov 13 22:22:51 2007 From: toad at amphibian.dyndns.org (Matthew Toseland) Date: Tue, 13 Nov 2007 22:22:51 +0000 Subject: [freenet-dev] Expose Crypto Stuff via FCP In-Reply-To: <1193821127.10134.48.camel@localhost> References: <1193821127.10134.48.camel@localhost> Message-ID: <200711132222.51101.toad@amphibian.dyndns.org> On Wednesday 31 October 2007 08:58, David ?Bombe? Roden wrote: > From the Frost "freenet" board: > > ----- Anonymous ----- 2007.10.28 - 18:12:54GMT ----- > > Is it planned to expose some basic cryptographic functions through FCP > so that client authors can make use of them? I'm thinking of things > such as creating public/private keys, and signing and encrypting data > with those keys. > > ----- > > I think that's a pretty good idea. The node already handles all that > crypto stuff and client applications, plugins, whatever, wouldn't have > to bundle BouncyCastle (or similar libraries). What's your response to the rest of the thread on Frost? They mentioned 1010, they mentioned gpg...? > > > Bombe > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071113/74f5a318/attachment.pgp From toad at amphibian.dyndns.org Tue Nov 13 22:25:57 2007 From: toad at amphibian.dyndns.org (Matthew Toseland) Date: Tue, 13 Nov 2007 22:25:57 +0000 Subject: [freenet-dev] alternative to #freenet-refs In-Reply-To: <47335339.6040907@cs.ucl.ac.uk> References: <20071107220045.GA4554@freenetproject.org> <20071108180041.GG4117@freenetproject.org> <47335339.6040907@cs.ucl.ac.uk> Message-ID: <200711132225.58393.toad@amphibian.dyndns.org> On Thursday 08 November 2007 18:19, Michael Rogers wrote: > Florent Daigni?re wrote: > > We haven't implemented an anonymous connection protocol. JFK assumes > > that there is a certificate chain or something we could use to verify > > who we are talking to... In our case it's the crypto. parameters we have > > in noderefs: We need them on darknet. > > Exactly - the parameters are exchanged during JFK. The ref only needs to > contain the hash of the parameters so that we can verify them. > > That means the ref can be around 38 bytes (IP address + port + hash) - > small enough to exchange over the phone, IRC, etc. Not if we want to remain undetectable. We need a key for the outer encryption wrapper. > > Cheers, > Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071113/7995f58b/attachment.pgp From toad at amphibian.dyndns.org Tue Nov 13 22:27:23 2007 From: toad at amphibian.dyndns.org (Matthew Toseland) Date: Tue, 13 Nov 2007 22:27:23 +0000 Subject: [freenet-dev] alternative to #freenet-refs In-Reply-To: <20071108175455.GF4117@freenetproject.org> References: <20071107220045.GA4554@freenetproject.org> <823242bd0711080826i4afeb240h2916b2f4adafb59f@mail.gmail.com> <20071108175455.GF4117@freenetproject.org> Message-ID: <200711132227.26959.toad@amphibian.dyndns.org> On Thursday 08 November 2007 17:54, Florent Daigni?re wrote: > * Ian Clarke [2007-11-08 10:26:41]: > > > At the risk of stating the obvious, the real solution here is fully > > automatic opennet. Where are we with that? > > Toad is the only one working on it or related matters. As far as I know > he is away and likely to be unavailable for some time... > > Regarding "fully automatic opennet", the requirements are: > - Implement something to discover which kind of NAT we are > behind (we already have STUN but it's centralized and sucks) > - Implement the support of anonymous connection over JFK > - Implement the announcement protocol > > Last time we spoke about it, the plan was "will hopefully be ready for > the end of the year" This is more or less correct: - Port forwarding detection - Anonymous connect - Announcement - Seednodes -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071113/42fabeb2/attachment.pgp From toad at amphibian.dyndns.org Tue Nov 13 22:58:09 2007 From: toad at amphibian.dyndns.org (Matthew Toseland) Date: Tue, 13 Nov 2007 22:58:09 +0000 Subject: [freenet-dev] [freenet-cvs] r15667 - in trunk/freenet/src/freenet: clients/http node In-Reply-To: <20071103115623.6341E47B2C3@freenetproject.org> References: <20071103115623.6341E47B2C3@freenetproject.org> Message-ID: <200711132258.10070.toad@amphibian.dyndns.org> Can we do this after we have the config framework up? Then it would be on the right port, and we could use L10n.. We could have a two stage initialisation, with the stuff that depends on the later parts of the node being added in the second stage, and the startup toadlet being added early? On Saturday 03 November 2007 11:56, you wrote: > Author: nextgens > Date: 2007-11-03 11:56:23 +0000 (Sat, 03 Nov 2007) > New Revision: 15667 > > Added: > trunk/freenet/src/freenet/clients/http/StartupToadletServer.java > Modified: > trunk/freenet/src/freenet/node/Node.java > trunk/freenet/src/freenet/node/NodeClientCore.java > Log: > Display a dirty toadlet using a dummy ToadletServer when the node is starting up. > > ~ I didn't test it much... > > Added: trunk/freenet/src/freenet/clients/http/StartupToadletServer.java > =================================================================== > --- trunk/freenet/src/freenet/clients/http/StartupToadletServer.java (rev 0) > +++ trunk/freenet/src/freenet/clients/http/StartupToadletServer.java 2007-11-03 11:56:23 UTC (rev 15667) > @@ -0,0 +1,271 @@ > +/* This code is part of Freenet. It is distributed under the GNU General > + * Public License, version 2 (or at your option any later version). See > + * http://www.gnu.org/ for further details of the GPL. */ > +package freenet.clients.http; > + > +import freenet.support.HTMLNode; > +import java.io.File; > +import java.io.IOException; > +import java.net.InetAddress; > +import java.net.JarURLConnection; > +import java.net.Socket; > +import java.net.SocketException; > +import java.net.SocketTimeoutException; > +import java.net.URI; > +import java.net.URL; > +import java.net.URLConnection; > +import java.net.URLDecoder; > +import java.util.ArrayList; > +import java.util.Enumeration; > +import java.util.List; > +import java.util.jar.JarEntry; > +import java.util.jar.JarFile; > +import freenet.io.NetworkInterface; > +import freenet.l10n.L10n; > +import freenet.support.Logger; > +import freenet.support.OOMHandler; > +import freenet.support.SimpleFieldSet; > +import freenet.support.Executor; > +import freenet.support.api.BucketFactory; > +import freenet.support.api.HTTPRequest; > +import freenet.support.io.ArrayBucketFactory; > + > +/** > + * A Placeholder displayed before fproxy starts up. > + * > + * @author nextgens > + * > + * TODO: Maybe add a progress bar or something ? > + * TODO: What about userAlerts ? > + * TODO: Shall l10n be loaded before ? > + */ > +public class StartupToadletServer implements Runnable { > + > + private int port; > + private final NetworkInterface networkInterface; > + private String cssName; > + private Thread myThread; > + private final PageMaker pageMaker; > + private String formPassword; > + private Executor executor; > + private final BucketFactory bf = new ArrayBucketFactory(); > + private final File configFile = new File("freenet.ini"); > + private final ToadletContainer container = new ToadletContainer() { > + > + public void register(Toadlet t, String urlPrefix, boolean atFront, boolean fullAccessOnly) { > + throw new UnsupportedOperationException("Not supported yet."); > + } > + > + public Toadlet findToadlet(URI uri) { > + return startupToadlet; > + } > + > + public String getCSSName() { > + return cssName; > + } > + > + public String getFormPassword() { > + return formPassword; > + } > + > + public boolean isAllowedFullAccess(InetAddress remoteAddr) { > + return false; > + } > + > + public boolean doRobots() { > + return true; > + } > + > + public HTMLNode addFormChild(HTMLNode parentNode, String target, String name) { > + throw new UnsupportedOperationException("Not supported yet."); > + } > + }; > + > + private final Toadlet startupToadlet = new Toadlet(null) { > + public void handleGet(URI uri, HTTPRequest req, ToadletContext ctx) throws ToadletContextClosedException, IOException, RedirectException { > + String path = uri.getPath(); > + if(path.startsWith(StaticToadlet.ROOT_URL)) { > + staticToadlet.handleGet(uri, req, ctx); > + } else { > + String desc = "Freenet is starting up"; > + HTMLNode pageNode = ctx.getPageMaker().getPageNode(desc, false, ctx); > + HTMLNode contentNode = ctx.getPageMaker().getContentNode(pageNode); > + > + HTMLNode infobox = contentNode.addChild(ctx.getPageMaker().getInfobox("infobox-error", desc)); > + HTMLNode infoboxContent = ctx.getPageMaker().getContentNode(infobox); > + infoboxContent.addChild("#", "Your freenet node is starting up, please hold on."); > + > + //TODO: send a Retry-After header ? > + writeHTMLReply(ctx, 503, desc, pageNode.generate()); > + } > + } > + > + public String supportedMethods() { > + return "GET"; > + } > + }; > + > + private final StaticToadlet staticToadlet = new StaticToadlet(null); > + > + /** > + * Create a SimpleToadletServer, using the settings from the SubConfig (the fproxy.* > + * config). > + */ > + public StartupToadletServer(Executor executor) { > + int configItemOrder = 0; > + this.executor = executor; > + formPassword = String.valueOf(this.getClass().hashCode()); > + > + List themes = new ArrayList(); > + try { > + URL url = getClass().getResource("staticfiles/themes/"); > + URLConnection urlConnection = url.openConnection(); > + if (url.getProtocol().equals("file")) { > + File themesDirectory = new File(URLDecoder.decode(url.getPath(), "ISO-8859-1").replaceAll("\\|", ":")); > + File[] themeDirectories = themesDirectory.listFiles(); > + for (int themeIndex = 0; (themeDirectories != null) && (themeIndex < themeDirectories.length); themeIndex++) { > + File themeDirectory = themeDirectories[themeIndex]; > + if (themeDirectory.isDirectory() && !themeDirectory.getName().startsWith(".")) { > + themes.add(themeDirectory.getName()); > + } > + } > + } else if (urlConnection instanceof JarURLConnection) { > + JarURLConnection jarUrlConnection = (JarURLConnection) urlConnection; > + JarFile jarFile = jarUrlConnection.getJarFile(); > + Enumeration entries = jarFile.entries(); > + while (entries.hasMoreElements()) { > + JarEntry entry = (JarEntry) entries.nextElement(); > + String name = entry.getName(); > + if (name.startsWith("freenet/clients/http/staticfiles/themes/")) { > + name = name.substring("freenet/clients/http/staticfiles/themes/".length()); > + if (name.indexOf('/') != -1) { > + String themeName = name.substring(0, name.indexOf('/')); > + if (!themes.contains(themeName)) { > + themes.add(themeName); > + } > + } > + } > + } > + } > + } catch (IOException ioe1) { > + Logger.error(this, "error creating list of themes", ioe1); > + } catch (NullPointerException npe) { > + Logger.error(this, "error creating list of themes", npe); > + } finally { > + if (!themes.contains("clean")) { > + themes.add("clean"); > + } > + } > + > + // hack ... we don't have the config framework yet > + try { > + SimpleFieldSet config = SimpleFieldSet.readFrom(configFile, false, false); > + port = config.getInt("fproxy.port"); > + cssName = config.get("fproxy.css"); > + } catch (Exception e) { > + port = SimpleToadletServer.DEFAULT_FPROXY_PORT; > + cssName = PageMaker.DEFAULT_THEME; > + } > + > + pageMaker = new PageMaker(cssName); > + > + boolean start = true; > + NetworkInterface ni = null; > + try { > + ni = NetworkInterface.create(port, SimpleToadletServer.DEFAULT_BIND_TO, SimpleToadletServer.DEFAULT_BIND_TO, executor); > + } catch (IOException e) { > + Logger.error(this, "Error starting SimpleToadletServer on " + port); > + System.err.println("Error starting SimpleToadletServer on " + port); > + start = false; > + } > + this.networkInterface = ni; > + > + if (start) { > + myThread = new Thread(this, "SimpleToadletServer"); > + myThread.setDaemon(true); > + myThread.start(); > + Logger.normal(this, "Starting SimpleToadletServer on " + port); > + System.out.println("Starting SimpleToadletServer on " + port); > + } > + } > + > + public void run() { > + try { > + networkInterface.setSoTimeout(500); > + } catch (SocketException e1) { > + Logger.error(this, "Could not set so-timeout to 500ms; on-the-fly disabling of the interface will not work"); > + } > + while (true) { > + synchronized (this) { > + if (myThread == null) { > + return; > + } > + } > + try { > + Socket conn = networkInterface.accept(); > + if (Logger.shouldLog(Logger.MINOR, this)) { > + Logger.minor(this, "Accepted connection"); > + } > + SocketHandler sh = new SocketHandler(conn); > + sh.start(); > + } catch (SocketTimeoutException e) { > + // Go around again, this introduced to avoid blocking forever when told to quit > + } > + } > + } > + > + public synchronized void kill() throws IOException { > + myThread = null; > + networkInterface.close(); > + } > + > + public class SocketHandler implements Runnable { > + > + Socket sock; > + > + public SocketHandler(Socket conn) { > + this.sock = conn; > + } > + > + void start() { > + executor.execute(this, "SimpleToadletServer$SocketHandler@" + hashCode()); > + } > + > + public void run() { > + freenet.support.Logger.OSThread.logPID(this); > + boolean logMINOR = Logger.shouldLog(Logger.MINOR, this); > + if (logMINOR) { > + Logger.minor(this, "Handling connection"); > + } > + try { > + ToadletContextImpl.handle(sock, container, bf, pageMaker); > + } catch (OutOfMemoryError e) { > + OOMHandler.handleOOM(e); > + System.err.println("SimpleToadletServer request above failed."); > + } catch (Throwable t) { > + System.err.println("Caught in SimpleToadletServer: " + t); > + t.printStackTrace(); > + Logger.error(this, "Caught in SimpleToadletServer: " + t, t); > + } > + if (logMINOR) { > + Logger.minor(this, "Handled connection"); > + } > + } > + } > + > + public String getCSSName() { > + return this.cssName; > + } > + > + public void setCSSName(String name) { > + this.cssName = name; > + } > + > + private static String l10n(String key, String pattern, String value) { > + return L10n.getString("SimpleToadletServer." + key, pattern, value); > + } > + > + private static String l10n(String key) { > + return L10n.getString("SimpleToadletServer." + key); > + } > +} > > Modified: trunk/freenet/src/freenet/node/Node.java > =================================================================== > --- trunk/freenet/src/freenet/node/Node.java 2007-11-03 11:49:44 UTC (rev 15666) > +++ trunk/freenet/src/freenet/node/Node.java 2007-11-03 11:56:23 UTC (rev 15667) > @@ -38,6 +38,7 @@ > import com.sleepycat.je.util.DbDump; > > import freenet.client.FetchContext; > +import freenet.clients.http.StartupToadletServer; > import freenet.config.EnumerableOptionCallback; > import freenet.config.FreenetFilePersistentConfig; > import freenet.config.InvalidConfigValueException; > @@ -360,6 +361,8 @@ > > public final long bootID; > public final long startupTime; > + > + public final StartupToadletServer startupPageHolder; > > public final NodeClientCore clientCore; > > @@ -538,6 +541,9 @@ > if(logConfigHandler != lc) > logConfigHandler=lc; > startupTime = System.currentTimeMillis(); > + // Will be set up properly afterwards > + L10n.setLanguage(L10n.FALLBACK_DEFAULT); > + startupPageHolder = new StartupToadletServer(executor); > nodeNameUserAlert = new MeaningfulNodeNameUserAlert(this); > recentlyCompletedIDs = new LRUQueue(); > this.config = config; > @@ -1255,7 +1261,7 @@ > > nodeStats = new NodeStats(this, sortOrder, new SubConfig("node.load", config), oldThrottleFS, obwLimit, ibwLimit); > > - clientCore = new NodeClientCore(this, config, nodeConfig, nodeDir, getDarknetPortNumber(), sortOrder, oldThrottleFS == null ? null : oldThrottleFS.subset("RequestStarters")); > + clientCore = new NodeClientCore(this, config, nodeConfig, nodeDir, getDarknetPortNumber(), sortOrder, oldThrottleFS == null ? null : oldThrottleFS.subset("RequestStarters"), startupPageHolder); > > nodeConfig.register("disableHangCheckers", false, sortOrder++, true, false, "Node.disableHangCheckers", "Node.disableHangCheckersLong", new BooleanCallback() { > > > Modified: trunk/freenet/src/freenet/node/NodeClientCore.java > =================================================================== > --- trunk/freenet/src/freenet/node/NodeClientCore.java 2007-11-03 11:49:44 UTC (rev 15666) > +++ trunk/freenet/src/freenet/node/NodeClientCore.java 2007-11-03 11:56:23 UTC (rev 15667) > @@ -16,6 +16,7 @@ > import freenet.clients.http.bookmark.BookmarkManager; > import freenet.clients.http.FProxyToadlet; > import freenet.clients.http.SimpleToadletServer; > +import freenet.clients.http.StartupToadletServer; > import freenet.clients.http.filter.FilterCallback; > import freenet.clients.http.filter.FoundURICallback; > import freenet.clients.http.filter.GenericReadFilterCallback; > @@ -113,7 +114,7 @@ > static final long MAX_ARCHIVED_FILE_SIZE = 1024*1024; // arbitrary... FIXME > static final int MAX_CACHED_ELEMENTS = 256*1024; // equally arbitrary! FIXME hopefully we can cache many of these though > > - NodeClientCore(Node node, Config config, SubConfig nodeConfig, File nodeDir, int portNumber, int sortOrder, SimpleFieldSet oldThrottleFS) throws NodeInitException { > + NodeClientCore(Node node, Config config, SubConfig nodeConfig, File nodeDir, int portNumber, int sortOrder, SimpleFieldSet oldThrottleFS, StartupToadletServer sts) throws NodeInitException { > this.node = node; > this.nodeStats = node.nodeStats; > this.random = node.random; > @@ -351,6 +352,7 @@ > // FProxy > // FIXME this is a hack, the real way to do this is plugins > try { > + sts.kill(); > toadletContainer = FProxyToadlet.maybeCreateFProxyEtc(this, node, config, fproxyConfig); > } catch (IOException e) { > e.printStackTrace(); > > _______________________________________________ > cvs mailing list > cvs at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/cvs > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071113/31f35a55/attachment.pgp From toad at amphibian.dyndns.org Tue Nov 13 23:04:01 2007 From: toad at amphibian.dyndns.org (Matthew Toseland) Date: Tue, 13 Nov 2007 23:04:01 +0000 Subject: [freenet-dev] [freenet-cvs] r15676 - trunk/freenet/src/freenet/support In-Reply-To: <20071103200815.CEC3C47AEDC@freenetproject.org> References: <20071103200815.CEC3C47AEDC@freenetproject.org> Message-ID: <200711132304.02350.toad@amphibian.dyndns.org> On Saturday 03 November 2007 20:08, bombe at freenetproject.org wrote: > Author: bombe > Date: 2007-11-03 20:08:15 +0000 (Sat, 03 Nov 2007) > New Revision: 15676 > > Modified: > trunk/freenet/src/freenet/support/ > trunk/freenet/src/freenet/support/HTMLNode.java > Log: > r12814 at natrium: bombe | 2007-11-01 13:39:34 +0100 > let a # tag with null content be a container for several adjacent childs Huh? > > > > Property changes on: trunk/freenet/src/freenet/support > ___________________________________________________________________ > Name: svk:merge > - 6a5e1407-ac3d-0410-81af-9028a69beae8:/branch/freenet-documentation-browser/src/freenet/support:12813 > + 6a5e1407-ac3d-0410-81af-9028a69beae8:/branch/freenet-documentation-browser/src/freenet/support:12814 > > Modified: trunk/freenet/src/freenet/support/HTMLNode.java > =================================================================== > --- trunk/freenet/src/freenet/support/HTMLNode.java 2007-11-03 20:07:41 UTC (rev 15675) > +++ trunk/freenet/src/freenet/support/HTMLNode.java 2007-11-03 20:08:15 UTC (rev 15676) > @@ -136,7 +136,7 @@ > } > > public StringBuffer generate(StringBuffer tagBuffer) { > - if (name.equals("#")) { > + if (name.equals("#") && (content != null)) { > HTMLEncoder.encodeToBuffer(content, tagBuffer); > return tagBuffer; > } > @@ -146,6 +146,13 @@ > tagBuffer.append(content); > return tagBuffer; > } > + if (name.equals("#")) { > + for (int childIndex = 0, childCount = children.size(); childIndex < childCount; childIndex++) { > + HTMLNode childNode = (HTMLNode) children.get(childIndex); > + childNode.generate(tagBuffer); > + } > + return tagBuffer; > + } > tagBuffer.append('<').append(name); > Set attributeSet = attributes.entrySet(); > for (Iterator attributeIterator = attributeSet.iterator(); attributeIterator.hasNext();) { > > _______________________________________________ > cvs mailing list > cvs at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/cvs > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071113/16272080/attachment.pgp From bombe at pterodactylus.net Tue Nov 13 23:43:36 2007 From: bombe at pterodactylus.net (David =?UTF-8?Q?=E2=80=98Bombe=E2=80=99?= Roden) Date: Wed, 14 Nov 2007 00:43:36 +0100 Subject: [freenet-dev] [freenet-cvs] r15676 - trunk/freenet/src/freenet/support In-Reply-To: <200711132304.02350.toad@amphibian.dyndns.org> References: <20071103200815.CEC3C47AEDC@freenetproject.org> <200711132304.02350.toad@amphibian.dyndns.org> Message-ID: <1194997419.24285.85.camel@localhost> On Tue, 2007-11-13 at 23:04 +0000, Matthew Toseland wrote: > > Log: > > let a # tag with null content be a container for several adjacent childs > Huh? You can now add e.g. 3 HTMLNode("div", "...") to an HTMLNode("#"). Previously you had to add them to e.g. another HTMLNode("div"). The new, empty "collector" node does not generate any additional tags. Bombe -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071114/e553fdc9/attachment.pgp From bombe at pterodactylus.net Wed Nov 14 00:17:25 2007 From: bombe at pterodactylus.net (David =?UTF-8?Q?=E2=80=98Bombe=E2=80=99?= Roden) Date: Wed, 14 Nov 2007 01:17:25 +0100 Subject: [freenet-dev] Expose Crypto Stuff via FCP In-Reply-To: <200711132222.51101.toad@amphibian.dyndns.org> References: <1193821127.10134.48.camel@localhost> <200711132222.51101.toad@amphibian.dyndns.org> Message-ID: <1194999445.24285.103.camel@localhost> On Tue, 2007-11-13 at 22:22 +0000, Matthew Toseland wrote: > > I think that's a pretty good idea. The node already handles all that > > crypto stuff and client applications, plugins, whatever, wouldn't have > > to bundle BouncyCastle (or similar libraries). > What's your response to the rest of the thread on Frost? They mentioned 1010, > they mentioned gpg...? a) Bugs can be in any API. When using the same crypto stuff as the node we can at least be sure that the client crypto is never worse than the node crypto. b) I'm not quite sure how GPG comes into play here. Sure, it can do all the operations I'd need but it's another crypto layer we do not control - does it even do its own crypto or does it rely on another layer? And how does it integrate into Java? And what about Windows? Bombe -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071114/b25018ce/attachment.pgp From nextgens at freenetproject.org Wed Nov 14 00:47:38 2007 From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=) Date: Wed, 14 Nov 2007 01:47:38 +0100 Subject: [freenet-dev] [freenet-cvs] r15667 - in trunk/freenet/src/freenet: clients/http node In-Reply-To: <200711132258.10070.toad@amphibian.dyndns.org> References: <20071103115623.6341E47B2C3@freenetproject.org> <200711132258.10070.toad@amphibian.dyndns.org> Message-ID: <20071114004738.GC16123@freenetproject.org> * Matthew Toseland [2007-11-13 22:58:09]: > Can we do this after we have the config framework up? Then it would be on the > right port, and we could use L10n.. We could have a two stage initialisation, > with the stuff that depends on the later parts of the node being added in the > second stage, and the startup toadlet being added early? > Too much hassle for the gain imho... What the problem with the current solution ? NextGen$ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071114/4719c378/attachment.pgp From m.rogers at cs.ucl.ac.uk Wed Nov 14 11:35:31 2007 From: m.rogers at cs.ucl.ac.uk (Michael Rogers) Date: Wed, 14 Nov 2007 11:35:31 +0000 Subject: [freenet-dev] alternative to #freenet-refs In-Reply-To: <200711132225.58393.toad@amphibian.dyndns.org> References: <20071107220045.GA4554@freenetproject.org> <20071108180041.GG4117@freenetproject.org> <47335339.6040907@cs.ucl.ac.uk> <200711132225.58393.toad@amphibian.dyndns.org> Message-ID: <473ADD83.10705@cs.ucl.ac.uk> Matthew Toseland wrote: >> That means the ref can be around 38 bytes (IP address + port + hash) - >> small enough to exchange over the phone, IRC, etc. > > Not if we want to remain undetectable. We need a key for the outer encryption > wrapper. Sorry, I don't follow - do you mean JFK takes place (or should take place) inside another layer of encryption? How is the key for the outer layer exchanged? To avoid CPU DoS it has to be a symmetric key, and to avoid an infinite regress of key agreement protocols it has to be derived non-interactively from the contents of the refs. Therefore it can't be secure against an attacker who's seen both the refs, regardless of how much information they contain - so what's the advantage of long refs? Cheers, Michael From nextgens at freenetproject.org Wed Nov 14 11:50:01 2007 From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=) Date: Wed, 14 Nov 2007 12:50:01 +0100 Subject: [freenet-dev] alternative to #freenet-refs In-Reply-To: <473ADD83.10705@cs.ucl.ac.uk> References: <20071107220045.GA4554@freenetproject.org> <20071108180041.GG4117@freenetproject.org> <47335339.6040907@cs.ucl.ac.uk> <200711132225.58393.toad@amphibian.dyndns.org> <473ADD83.10705@cs.ucl.ac.uk> Message-ID: <20071114115000.GA4504@freenetproject.org> * Michael Rogers [2007-11-14 11:35:31]: > Matthew Toseland wrote: > >> That means the ref can be around 38 bytes (IP address + port + hash) - > >> small enough to exchange over the phone, IRC, etc. > > > > Not if we want to remain undetectable. We need a key for the outer encryption > > wrapper. > > Sorry, I don't follow - do you mean JFK takes place (or should take > place) inside another layer of encryption? How is the key for the outer > layer exchanged? To avoid CPU DoS it has to be a symmetric key, and to > avoid an infinite regress of key agreement protocols it has to be > derived non-interactively from the contents of the refs. Therefore it > can't be secure against an attacker who's seen both the refs, regardless > of how much information they contain - so what's the advantage of long refs? Who said that people should exchange their references over an insecure medium ? ATM the key is a XOR in between both node's identity iirc We are not debating the strength of the key here... The only purpose of the outter layer encrytion is to avoid cheap pattern matching. NextGen$ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071114/e47e76b1/attachment.pgp From m.rogers at cs.ucl.ac.uk Wed Nov 14 13:19:31 2007 From: m.rogers at cs.ucl.ac.uk (Michael Rogers) Date: Wed, 14 Nov 2007 13:19:31 +0000 Subject: [freenet-dev] alternative to #freenet-refs In-Reply-To: <20071114115000.GA4504@freenetproject.org> References: <20071107220045.GA4554@freenetproject.org> <20071108180041.GG4117@freenetproject.org> <47335339.6040907@cs.ucl.ac.uk> <200711132225.58393.toad@amphibian.dyndns.org> <473ADD83.10705@cs.ucl.ac.uk> <20071114115000.GA4504@freenetproject.org> Message-ID: <473AF5E3.7060101@cs.ucl.ac.uk> Florent Daigni?re wrote: > We are not debating the strength of the key here... The only purpose of > the outter layer encrytion is to avoid cheap pattern matching. Agreed, the goal is obfuscation rather than strong encryption. However, that's orthogonal to the question of whether we need long refs to derive a suitable key. As far as I can see, we don't. For example, K = hash (A's ref, B's ref, random nonce generated by A). A's first message starts with the random nonce; the rest of the JFK exchange is obfuscated using K. The length of the refs has no effect on security, but it has a big effect on darknet usability. Cheers, Michael From nextgens at freenetproject.org Wed Nov 14 15:34:07 2007 From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=) Date: Wed, 14 Nov 2007 16:34:07 +0100 Subject: [freenet-dev] alternative to #freenet-refs In-Reply-To: <473AF5E3.7060101@cs.ucl.ac.uk> References: <20071107220045.GA4554@freenetproject.org> <20071108180041.GG4117@freenetproject.org> <47335339.6040907@cs.ucl.ac.uk> <200711132225.58393.toad@amphibian.dyndns.org> <473ADD83.10705@cs.ucl.ac.uk> <20071114115000.GA4504@freenetproject.org> <473AF5E3.7060101@cs.ucl.ac.uk> Message-ID: <20071114153407.GB4504@freenetproject.org> * Michael Rogers [2007-11-14 13:19:31]: > Florent Daigni?re wrote: > > We are not debating the strength of the key here... The only purpose of > > the outter layer encrytion is to avoid cheap pattern matching. > > Agreed, the goal is obfuscation rather than strong encryption. However, > that's orthogonal to the question of whether we need long refs to derive > a suitable key. As far as I can see, we don't. > Go ahead and suggest something that works then :) > For example, K = hash (A's ref, B's ref, random nonce generated by A). > A's first message starts with the random nonce; the rest of the JFK > exchange is obfuscated using K. > > The length of the refs has no effect on security, but it has a big > effect on darknet usability. We can't do that because if we shorten refs we will have to exchange them "in band"... during the JFK negociation... and that precludes using part of the reference as the key for the outer layer encryption. Needless to say that using only the nonce as the key isn't an option. NextGen$ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071114/509432c1/attachment.pgp From m.rogers at cs.ucl.ac.uk Wed Nov 14 16:03:24 2007 From: m.rogers at cs.ucl.ac.uk (Michael Rogers) Date: Wed, 14 Nov 2007 16:03:24 +0000 Subject: [freenet-dev] alternative to #freenet-refs In-Reply-To: <20071114153407.GB4504@freenetproject.org> References: <20071107220045.GA4554@freenetproject.org> <20071108180041.GG4117@freenetproject.org> <47335339.6040907@cs.ucl.ac.uk> <200711132225.58393.toad@amphibian.dyndns.org> <473ADD83.10705@cs.ucl.ac.uk> <20071114115000.GA4504@freenetproject.org> <473AF5E3.7060101@cs.ucl.ac.uk> <20071114153407.GB4504@freenetproject.org> Message-ID: <473B1C4C.9090806@cs.ucl.ac.uk> Florent Daigni?re wrote: > Go ahead and suggest something that works then :) OK, here's my suggestion: 1. Remove the address and port from the current ref 2. Call what remains (crypto parameters, public key etc) the "long ref" 3. The address, port, and the hash of the long ref form the "short ref" 4. The short refs (38 bytes) are exchanged out of band 5. Obfuscation key = hash (A's short ref, B's short ref, nonce) 6. The long refs are exchanged during obfuscated JFK (in the ID_I and ID_R fields of messages 3 and 4) 7. Before completing JFK, the long refs are verified by hashing them and comparing the hashes contained in the short refs Cheers, Michael From toad at amphibian.dyndns.org Wed Nov 14 18:04:51 2007 From: toad at amphibian.dyndns.org (Matthew Toseland) Date: Wed, 14 Nov 2007 18:04:51 +0000 Subject: [freenet-dev] =?utf-8?q?=5Bfreenet-cvs=5D_r15676_-=09trunk/freene?= =?utf-8?q?t/src/freenet/support?= In-Reply-To: <1194997419.24285.85.camel@localhost> References: <20071103200815.CEC3C47AEDC@freenetproject.org> <200711132304.02350.toad@amphibian.dyndns.org> <1194997419.24285.85.camel@localhost> Message-ID: <200711141804.56957.toad@amphibian.dyndns.org> On Tuesday 13 November 2007 23:43, David ?Bombe? Roden wrote: > > On Tue, 2007-11-13 at 23:04 +0000, Matthew Toseland wrote: > > > > Log: > > > let a # tag with null content be a container for several adjacent childs > > Huh? > > You can now add e.g. 3 HTMLNode("div", "...") to an HTMLNode("#"). > Previously you had to add them to e.g. another HTMLNode("div"). The new, > empty "collector" node does not generate any additional tags. Would it be better for it to be HTMLNode(null) ? > > > Bombe > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071114/ee202266/attachment.pgp From toad at amphibian.dyndns.org Wed Nov 14 18:08:16 2007 From: toad at amphibian.dyndns.org (Matthew Toseland) Date: Wed, 14 Nov 2007 18:08:16 +0000 Subject: [freenet-dev] alternative to #freenet-refs In-Reply-To: <473B1C4C.9090806@cs.ucl.ac.uk> References: <20071107220045.GA4554@freenetproject.org> <20071114153407.GB4504@freenetproject.org> <473B1C4C.9090806@cs.ucl.ac.uk> Message-ID: <200711141808.16199.toad@amphibian.dyndns.org> On Wednesday 14 November 2007 16:03, Michael Rogers wrote: > Florent Daigni?re wrote: > > Go ahead and suggest something that works then :) > > OK, here's my suggestion: > > 1. Remove the address and port from the current ref > 2. Call what remains (crypto parameters, public key etc) the "long ref" > 3. The address, port, and the hash of the long ref form the "short ref" > 4. The short refs (38 bytes) are exchanged out of band > 5. Obfuscation key = hash (A's short ref, B's short ref, nonce) > 6. The long refs are exchanged during obfuscated JFK (in the ID_I and > ID_R fields of messages 3 and 4) > 7. Before completing JFK, the long refs are verified by hashing them and > comparing the hashes contained in the short refs Is it port-scan resistant? How exactly would phase 0 work? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071114/6a631762/attachment.pgp From toad at amphibian.dyndns.org Wed Nov 14 18:08:56 2007 From: toad at amphibian.dyndns.org (Matthew Toseland) Date: Wed, 14 Nov 2007 18:08:56 +0000 Subject: [freenet-dev] Expose Crypto Stuff via FCP In-Reply-To: <1194999445.24285.103.camel@localhost> References: <1193821127.10134.48.camel@localhost> <200711132222.51101.toad@amphibian.dyndns.org> <1194999445.24285.103.camel@localhost> Message-ID: <200711141808.56588.toad@amphibian.dyndns.org> On Wednesday 14 November 2007 00:17, David ?Bombe? Roden wrote: > > On Tue, 2007-11-13 at 22:22 +0000, Matthew Toseland wrote: > > > > I think that's a pretty good idea. The node already handles all that > > > crypto stuff and client applications, plugins, whatever, wouldn't have > > > to bundle BouncyCastle (or similar libraries). > > What's your response to the rest of the thread on Frost? They mentioned 1010, > > they mentioned gpg...? > > a) Bugs can be in any API. When using the same crypto stuff as the node > we can at least be sure that the client crypto is never worse than the > node crypto. > > b) I'm not quite sure how GPG comes into play here. Sure, it can do all > the operations I'd need but it's another crypto layer we do not control > - does it even do its own crypto or does it rely on another layer? And > how does it integrate into Java? And what about Windows? The common claim is gpg libraries are available for all platforms and languages. > > > Bombe > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071114/09ba2a03/attachment.pgp From m.rogers at cs.ucl.ac.uk Wed Nov 14 19:05:13 2007 From: m.rogers at cs.ucl.ac.uk (Michael Rogers) Date: Wed, 14 Nov 2007 19:05:13 +0000 Subject: [freenet-dev] alternative to #freenet-refs In-Reply-To: <200711141808.16199.toad@amphibian.dyndns.org> References: <20071107220045.GA4554@freenetproject.org> <20071114153407.GB4504@freenetproject.org> <473B1C4C.9090806@cs.ucl.ac.uk> <200711141808.16199.toad@amphibian.dyndns.org> Message-ID: <473B46E9.5030306@cs.ucl.ac.uk> Matthew Toseland wrote: >> OK, here's my suggestion: >> >> 1. Remove the address and port from the current ref >> 2. Call what remains (crypto parameters, public key etc) the "long ref" >> 3. The address, port, and the hash of the long ref form the "short ref" >> 4. The short refs (38 bytes) are exchanged out of band >> 5. Obfuscation key = hash (A's short ref, B's short ref, nonce) >> 6. The long refs are exchanged during obfuscated JFK (in the ID_I and >> ID_R fields of messages 3 and 4) >> 7. Before completing JFK, the long refs are verified by hashing them and >> comparing the hashes contained in the short refs > > Is it port-scan resistant? How exactly would phase 0 work? In terms of port scanning, it doesn't make any difference whether the users exchange short or long refs. The CPU burden remains on the initiator. The paper I've looked at [1] doesn't mention phase 0 - does that refer to pre-computing/reusing the DH exponents? If so, it wouldn't be affected by the use of short refs. The only change to JFKi would occur at the end of the protocol, where the IDs are verified. By the way, I'm not trying to propose a particular type of obfuscation - step 5 above is only meant to be an example showing that the obfuscation key can be derived from the short refs before the long refs are exchanged. As Nextgens pointed out, obfuscation doesn't give us any real security, it just raises the bar for the attacker or data miner. We still depend on the out-of-band ref exchange being secure - but IMHO that will be easier if the refs are short. Cheers, Michael [1] http://people.csail.mit.edu/canetti/materials/jfk.pdf From toad at amphibian.dyndns.org Thu Nov 15 17:47:12 2007 From: toad at amphibian.dyndns.org (Matthew Toseland) Date: Thu, 15 Nov 2007 17:47:12 +0000 Subject: [freenet-dev] Short refs was Re: alternative to #freenet-refs In-Reply-To: <473B46E9.5030306@cs.ucl.ac.uk> References: <20071107220045.GA4554@freenetproject.org> <200711141808.16199.toad@amphibian.dyndns.org> <473B46E9.5030306@cs.ucl.ac.uk> Message-ID: <200711151747.18462.toad@amphibian.dyndns.org> On Wednesday 14 November 2007 19:05, Michael Rogers wrote: > Matthew Toseland wrote: > >> OK, here's my suggestion: > >> > >> 1. Remove the address and port from the current ref > >> 2. Call what remains (crypto parameters, public key etc) the "long ref" > >> 3. The address, port, and the hash of the long ref form the "short ref" > >> 4. The short refs (38 bytes) are exchanged out of band > >> 5. Obfuscation key = hash (A's short ref, B's short ref, nonce) > >> 6. The long refs are exchanged during obfuscated JFK (in the ID_I and > >> ID_R fields of messages 3 and 4) > >> 7. Before completing JFK, the long refs are verified by hashing them and > >> comparing the hashes contained in the short refs > > > > Is it port-scan resistant? How exactly would phase 0 work? > > In terms of port scanning, it doesn't make any difference whether the > users exchange short or long refs. The CPU burden remains on the initiator. No. If they get any sort of response at all, they can deduce that there is a high probability of its being a node. > > The paper I've looked at [1] doesn't mention phase 0 - does that refer > to pre-computing/reusing the DH exponents? If so, it wouldn't be > affected by the use of short refs. The only change to JFKi would occur > at the end of the protocol, where the IDs are verified. I meant phase 1, sorry. So what we have here then is we prepend the nonce to the phase 0 packet, and another nonce to the beginning of the phase 1 packet. The rest of the exchange is then encrypted with H ( nonce + A's pk hash + B's pk hash ). Okay, that's reasonable. Any downsides? - If the attacker knows, or can guess, *BOTH* A and B's pk hashes, he can decrypt the exchange and prove that one is occurring. So if you get busted and promise not to run a node again, and then do, you could be in trouble if you don't change the pubkey. Not a very realistic scenario - if they care that much they'll do traffic flow analysis. So all in all, this looks like a good idea. One advantage of long refs is they are big enough to include the ARK, so if you're already on the network, you can connect later on. Short refs must be exchanged in real time, while both sides' IPs are valid (or one side if only one side NATed). How does this compare to one-time invites? We should have both mechanisms, yes? An invite would be almost the same as a short ref, except that the hash would be a one-time shared secret allowing you to connect once to a (port forwarded) node. The advantage is you only need to pass them in one direction, and they can therefore be used comfortably "offline", provided you have a stable IP and a port forward. The disadvantage is they are more vulnerable to out-of-band MITM. So something like: A -> B: H(secret), g^x B -> A: challenge, g^y A -> B: E(H(secret + challenge), ...) ... Once we have port forward detection we can put a button in for this. Comments? > As Nextgens pointed out, obfuscation doesn't give us any real security, > it just raises the bar for the attacker or data miner. We still depend > on the out-of-band ref exchange being secure - but IMHO that will be > easier if the refs are short. Well sure, if the out of band ref exchange is busted we are visible, there's nothing we can do about that as Eve will know the IP's involved. > > Cheers, > Michael > > [1] http://people.csail.mit.edu/canetti/materials/jfk.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071115/87fcf4db/attachment.pgp From m.rogers at cs.ucl.ac.uk Thu Nov 15 23:21:49 2007 From: m.rogers at cs.ucl.ac.uk (Michael Rogers) Date: Thu, 15 Nov 2007 23:21:49 +0000 Subject: [freenet-dev] Short refs was Re: alternative to #freenet-refs In-Reply-To: <200711151747.18462.toad@amphibian.dyndns.org> References: <20071107220045.GA4554@freenetproject.org> <200711141808.16199.toad@amphibian.dyndns.org> <473B46E9.5030306@cs.ucl.ac.uk> <200711151747.18462.toad@amphibian.dyndns.org> Message-ID: <473CD48D.4000601@cs.ucl.ac.uk> Matthew Toseland wrote: >> In terms of port scanning, it doesn't make any difference whether the >> users exchange short or long refs. The CPU burden remains on the initiator. > > No. If they get any sort of response at all, they can deduce that there is a > high probability of its being a node. Right, I understand that port scanning is an issue, but it's independent from the question of whether we use short or long refs. Message 1 of JFKi includes a field called ID_R', "an indication by the initiator to the responder as to what authentication information (e.g., certificates) the latter should use." In other words, the initiator has to show that it knows the responder's identity. If someone scans the port and puts the wrong value in ID_R', the responder is free to ignore the message. Obfuscation raises the bar a bit further: the port scanner has to know the identities of both peers to get a response, because otherwise the message won't decrypt properly and ID_R' will be wrong. > So what we have here then is we prepend the nonce to the phase 0 packet, and > another nonce to the beginning of the phase 1 packet. The rest of the > exchange is then encrypted with H ( nonce + A's pk hash + B's pk hash ). I don't see the need for two nonces - the initiator just prepends a nonce to message 1 (using the terminology from section 2.2 of the JFK paper). The responder tries decrypting the packet with the hash of each of its disconnected peers; if the decryption succeeds (i.e. the ID_R' field has the right value) then it responds with message 2. > - If the attacker knows, or can guess, *BOTH* A and B's pk hashes, he can > decrypt the exchange and prove that one is occurring. Right, and this can be done live or after the fact: if Mallory has a list of intercepted refs and a huge database of, say, AT&T backbone traffic, she can take the first packet in every encrypted flow, assume it starts with a nonce, and try to decrypt the rest of the packet with hash (nonce, ref_1, ref_2) for every pair of refs. So it's by no means secure - it just raises the bar from wholesale filtering/data mining to targetted filtering/data mining using a list of intercepted refs. But obfuscation is cheap, so IMO it's worth raising the bar. > One advantage of long refs is they are big enough to include the ARK, so if > you're already on the network, you can connect later on. Short refs must be > exchanged in real time, while both sides' IPs are valid (or one side if only > one side NATed). Good point. We can get around that by merging the ARK with the long ref: the ARK contains all the information from the long ref as well as the list of addresses, ports, DNS names etc; the whole ARK is exchanged during JFK; the short ref is the address, port and ARK key. You can either use the ARK key to retrieve the ARK from Freenet, or you can do JFK and use the ARK key to validate the ARK exchanged during JFK. > An invite would be almost the same as a short ref, except that the hash > would be a one-time shared secret allowing you to connect once to a (port > forwarded) node. The advantage is you only need to pass them in one > direction, and they can therefore be used comfortably "offline", provided you > have a stable IP and a port forward. The disadvantage is they are more > vulnerable to out-of-band MITM. MITM can be solved by using the shared secret to generate a keypair, then putting the hash of the public key in the invite. During handshaking, the responder must sign both its own identity and the initiator's identity with the corresponding private key. But designing custom protocols is a bad idea... how can we fold this back into JFK? Another issue is whether the advantage of one-way exchange outweighs the danger of people using weak shared secrets such as dictionary words. I'd be more comfortable if each peer generated a separate keypair using a good source of randomness, and both peers exchanged invites. Cheers, Michael From bombe at pterodactylus.net Fri Nov 16 02:41:07 2007 From: bombe at pterodactylus.net (David =?UTF-8?Q?=E2=80=98Bombe=E2=80=99?= Roden) Date: Fri, 16 Nov 2007 03:41:07 +0100 Subject: [freenet-dev] Expose Crypto Stuff via FCP In-Reply-To: <200711141808.56588.toad@amphibian.dyndns.org> References: <1193821127.10134.48.camel@localhost> <200711132222.51101.toad@amphibian.dyndns.org> <1194999445.24285.103.camel@localhost> <200711141808.56588.toad@amphibian.dyndns.org> Message-ID: <1195180867.10271.3.camel@localhost> On Wed, 2007-11-14 at 18:08 +0000, Matthew Toseland wrote: > The common claim is gpg libraries are available for all platforms and > languages. A quick Google search only shows a single Java wrapper class around the gpg binary that is not even able to verify signatures. Bombe -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071116/1b385144/attachment.pgp From toad at amphibian.dyndns.org Fri Nov 16 13:36:30 2007 From: toad at amphibian.dyndns.org (Matthew Toseland) Date: Fri, 16 Nov 2007 13:36:30 +0000 Subject: [freenet-dev] Short refs was Re: alternative to #freenet-refs In-Reply-To: <473CD48D.4000601@cs.ucl.ac.uk> References: <20071107220045.GA4554@freenetproject.org> <200711151747.18462.toad@amphibian.dyndns.org> <473CD48D.4000601@cs.ucl.ac.uk> Message-ID: <200711161336.35167.toad@amphibian.dyndns.org> On Thursday 15 November 2007 23:21, Michael Rogers wrote: > Matthew Toseland wrote: > >> In terms of port scanning, it doesn't make any difference whether the > >> users exchange short or long refs. The CPU burden remains on the initiator. > > > > No. If they get any sort of response at all, they can deduce that there is a > > high probability of its being a node. > > Right, I understand that port scanning is an issue, but it's independent > from the question of whether we use short or long refs. Is it? > > Message 1 of JFKi includes a field called ID_R', "an indication by the > initiator to the responder as to what authentication information (e.g., > certificates) the latter should use." In other words, the initiator has > to show that it knows the responder's identity. If someone scans the > port and puts the wrong value in ID_R', the responder is free to ignore > the message. We don't exactly implement JFK, we drop the bits that we don't need. > > Obfuscation raises the bar a bit further: the port scanner has to know > the identities of both peers to get a response, because otherwise the > message won't decrypt properly and ID_R' will be wrong. Right. Obfuscation using a per-message IV and the hash of both the pubkey hashes, similar to what we do now. > > > So what we have here then is we prepend the nonce to the phase 0 packet, and > > another nonce to the beginning of the phase 1 packet. The rest of the > > exchange is then encrypted with H ( nonce + A's pk hash + B's pk hash ). > > I don't see the need for two nonces - the initiator just prepends a > nonce to message 1 (using the terminology from section 2.2 of the JFK > paper). The responder tries decrypting the packet with the hash of each > of its disconnected peers; if the decryption succeeds (i.e. the ID_R' > field has the right value) then it responds with message 2. Too complex, just use a random IV on each packet, and the wrapper key be the XOR of the two hashes, as it is now. > > > - If the attacker knows, or can guess, *BOTH* A and B's pk hashes, he can > > decrypt the exchange and prove that one is occurring. > > Right, and this can be done live or after the fact: if Mallory has a > list of intercepted refs and a huge database of, say, AT&T backbone > traffic, she can take the first packet in every encrypted flow, assume > it starts with a nonce, and try to decrypt the rest of the packet with > hash (nonce, ref_1, ref_2) for every pair of refs. So it's by no means > secure - it just raises the bar from wholesale filtering/data mining to > targetted filtering/data mining using a list of intercepted refs. Right, but this is possible *now*, with long references. > > But obfuscation is cheap, so IMO it's worth raising the bar. Indeed, and if at least one side is true darknet, Mallory will not know it and therefore cannot decrypt it. > > > One advantage of long refs is they are big enough to include the ARK, so if > > you're already on the network, you can connect later on. Short refs must be > > exchanged in real time, while both sides' IPs are valid (or one side if only > > one side NATed). > > Good point. We can get around that by merging the ARK with the long ref: > the ARK contains all the information from the long ref as well as the > list of addresses, ports, DNS names etc; the whole ARK is exchanged > during JFK; the short ref is the address, port and ARK key. You can > either use the ARK key to retrieve the ARK from Freenet, or you can do > JFK and use the ARK key to validate the ARK exchanged during JFK. Still doesn't work. As I said, we may very well need the ARK to connect in the first place, certainly if the exchange is "offline". Now, this assumes we already have a connection, but it's a fair assumption as the interesting case is a newbie who has a working opennet connection starting to get darknet refs. We need to include enough info to fetch the ARK in the short-ref. How? We can't make the ARK decryption key be dependant on the pubkey hash, because if we do we open up a gaping hole to harvesting. We can't include the full SSK as that's another 64 bytes. Suggestions? > > > An invite would be almost the same as a short ref, except that the hash > > would be a one-time shared secret allowing you to connect once to a (port > > forwarded) node. The advantage is you only need to pass them in one > > direction, and they can therefore be used comfortably "offline", provided you > > have a stable IP and a port forward. The disadvantage is they are more > > vulnerable to out-of-band MITM. > > MITM can be solved by using the shared secret to generate a keypair, > then putting the hash of the public key in the invite. During > handshaking, the responder must sign both its own identity and the > initiator's identity with the corresponding private key. But designing > custom protocols is a bad idea... how can we fold this back into JFK? We would be using JFK, we'd just add a few bits to it for a challenge/response on the one-time shared secret. It's not vulnerable to in-band MITM. If Mallory passively intercepts the invite, he can connect first and then MITM. If we put the hash of the pubkey in the invite, then the shared secret is now the hash of the pubkey. If we do a challenge/response, then we cannot send the pubkey in stage 2 (as we would normally do in anonymous connect JFK); we add at least one stage to the whole process. If we include BOTH a pubkey hash AND a shared secret, we can have a secure connection, however it would then be rather long - 70 bytes in base64 is 94 characters, so shorter than an SSK, it can be posted on IRC or on an IM client, but definitely not sent over the phone; but then, can 32 bytes be sent over the phone? One possibility, given these are time limited, is to shrink the shared secret aka one-time key to say 8 bytes; this should still be safe as an attacker would have to try every possible 8 byte sequence which is not going to be possible over any plausible internet connection! Then we have 62 characters, which comfortably fits in a single line, even if we have to separate the IP address (which we will have to if it's a DNS name). > > Another issue is whether the advantage of one-way exchange outweighs the > danger of people using weak shared secrets such as dictionary words. I'd > be more comfortable if each peer generated a separate keypair using a > good source of randomness, and both peers exchanged invites. The shared secret is generated from Yarrow in this proposal, and is only used once. It's a one-time invite. > > Cheers, > Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071116/59ce5073/attachment.pgp From toad at amphibian.dyndns.org Fri Nov 16 13:55:35 2007 From: toad at amphibian.dyndns.org (Matthew Toseland) Date: Fri, 16 Nov 2007 13:55:35 +0000 Subject: [freenet-dev] What we are really after was Re: Short refs was Re: alternative to #freenet-refs In-Reply-To: <200711161336.35167.toad@amphibian.dyndns.org> References: <20071107220045.GA4554@freenetproject.org> <473CD48D.4000601@cs.ucl.ac.uk> <200711161336.35167.toad@amphibian.dyndns.org> Message-ID: <200711161355.39811.toad@amphibian.dyndns.org> What exactly are we trying to make easier here? 1. Short refs: We could make #freenet-refs no longer need a pastebin, which would get us a few more users in the short term, but given opennet is rather pointless. We could make it slightly easier to IM your noderef, since it's a line to paste instead of a file to send ... but most IM clients (apart from IRC!) support sending files, and sending a file has the advantage that it can be automatically passed to the node if one is already installed. We could make it possible to include your noderef as a line in your email sig. This would be useful in the medium term IMHO, although obviously not in the long term. If you're sending somebody a noderef intentionally, as opposed to just advertising, you'd actually include it. Also if they end up on mailing lists etc you end up with lots of ubernode connections... 2. One-time Invites Invites are useful for offline connect, *provided* that the issuer is port forwarded and his IP doesn't change between issuing the invite and it being used. Could be bundled with a copy of the node on a USB key. Time limited, of course. 3. Really Easy Two Way Darknet Invites: SRP http://en.wikipedia.org/wiki/Secure_remote_password_protocol :) This would rock - you just exchange IP:port both ways, and a password. You only get one shot (or 3 shots, or whatever), so it's DoSable, but it would be *really* easy. You can e.g. write the IP:port and password (hopefully passphrase) on a piece of paper and give it to somebody. If there is a DoS, you have to fall back to exchanging noderefs. However, you will know there is a DoS and therefore there is a Good Reason to go to the hassle. SRP can either use a typed in password or we could have the node generate them. Again time-limited, and the password should not be reused. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071116/e77ed4b1/attachment.pgp From nextgens at freenetproject.org Fri Nov 16 14:01:39 2007 From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=) Date: Fri, 16 Nov 2007 15:01:39 +0100 Subject: [freenet-dev] What we are really after was Re: Short refs was Re: alternative to #freenet-refs In-Reply-To: <200711161355.39811.toad@amphibian.dyndns.org> References: <20071107220045.GA4554@freenetproject.org> <473CD48D.4000601@cs.ucl.ac.uk> <200711161336.35167.toad@amphibian.dyndns.org> <200711161355.39811.toad@amphibian.dyndns.org> Message-ID: <20071116140139.GD4272@freenetproject.org> * Matthew Toseland [2007-11-16 13:55:35]: > What exactly are we trying to make easier here? > > 1. Short refs: > I'm still not convinced we need that at all. > 2. One-time Invites > That might prove useful... Even though I'm not sure how often those would be used compared to 3. > > 3. Really Easy Two Way Darknet Invites: SRP > I've suggested that one to toad... and well, that's my favourite. NextGen$ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071116/475f7e19/attachment.pgp From m.rogers at cs.ucl.ac.uk Fri Nov 16 14:49:13 2007 From: m.rogers at cs.ucl.ac.uk (Michael Rogers) Date: Fri, 16 Nov 2007 14:49:13 +0000 Subject: [freenet-dev] Short refs was Re: alternative to #freenet-refs In-Reply-To: <200711161336.35167.toad@amphibian.dyndns.org> References: <20071107220045.GA4554@freenetproject.org> <200711151747.18462.toad@amphibian.dyndns.org> <473CD48D.4000601@cs.ucl.ac.uk> <200711161336.35167.toad@amphibian.dyndns.org> Message-ID: <473DADE9.4040308@cs.ucl.ac.uk> Matthew Toseland wrote: >> Right, I understand that port scanning is an issue, but it's independent >> from the question of whether we use short or long refs. > > Is it? Yes. The only difference between short and long refs is this: with long refs, you exchange most of the ID information up front, and a summary of the ID information during JFK. With short refs, you exchange a summary of the ID information up front, and most of the ID information during JFK. The issue of obfuscation is completely separate, because you can generate a suitable obfuscation key from any kind of ref, long or short. That means the issue of port scanning is also separate. > We don't exactly implement JFK, we drop the bits that we don't need. 0_o JFK doesn't exactly strike me as a bloated protocol. In fact it was designed to be the simplest possible protocol that would get the job done securely. What did you leave out? > Right. Obfuscation using a per-message IV and the hash of both the pubkey