First I'll confess I have not gone over the code with a fine tooth code, not plumbed the devl list, nor read the specs. That's just too much for me to take on a hobby - I'm trying to look at what I am finding and feeling as a neophyte approaching Freenet with a desire to lend a hand. And luckily I'm dumb enough to ask a lot of questions and thick skinned enough to be completely fine with criticism (if you're OK with the questions :)
>From my peculiar perspective, trying to get Freenet to work on a platform I've >come to really like in the last six months after trying Freenet over quite a >few years, I feel that there's now a way I can meaningfully add to the >project, both in work and equipment (i.e. a dedicated node with 24x7 up-time). >I think it can be made into a Freenet appliance - it does hardware AES 256/256 >_I think_, but I will be confirming that soon. But I'll be getting back to the >code and I'll dig into the tests a little, and perhaps I'll look into what >Fred would look like using Maven organization, which is a increasingly widely >used standard a large and growing number of people are used to. I might try >and knock out a test Maven pom to build Fred. Addressing security, Maven is a >build system, it will not put anything in your distribution that is not >specified by you (even if it does need to download a whole bunch of files into >its repo to do so), so security should not an issue. What it does add is the >ability to address quality issues more easily, say, by creating consistent >builds and test runs, and by providing interfaces for tools such as Sonar >(http://www.sonarsource.org/) to give you feedback on what you are doing, >making management easier. First though, the biggest issue I have using the ARM detection in Fred 1358, using my *special* freenet-ext.jar with the ARM .so's in it, is that there's not enough entropy :( Maybe it's something to do with the 'plug having no hardware clock! So I'll look at that, and also bringing the platform detection code in Fred out from a number of duplicates into, for example, a single enum. Using JCE is an interesting discussion point, as if you do look at JCE providers there are few to choose from that really utilize the available hardware, or even OS. Look at MSCAPI as a stunted JCE provider for example. I think you'd be good extracting the crypto out of Fred into a JCE provider... into a Freenet JCE provider sub-project. That would throw out options to use OS and hardware if coded and as needed. But all said and done, Freenet is *waaayyyy waayyyy* faster today than it has been, ever, especially the last few builds. But looking forward from the great leap in response times, it leads me to think about the challenges in installing and deploying it (e.g. on embedded headless systems), of QOS for the small (text) files vs, the large (graphics) files, and now in the challenge of developing it and keeping Freenet a viable project. ---------------------------------------------------------------- There are lots of unit tests in the test/ folder, including for crypto. However there aren't many unit tests for crypto. The more serious concern is that crypto is somewhat nonstandard (256/256 Rijndael, whereas AES is 256/128 Rijndael, with PCFB/CFB, which is a somewhat uncommon mode and looking slightly weak). Fixing this would require significant work. It will happen eventually but is not IMHO a critical issue at present. Non-standard crypto means hardware acceleration may not work. Native C code might still work on the other hand. I suggest you do some profiling - what is actually using the CPU? Is it symmetric crypto or asymmetric crypto, or is it garbage collection due to not having enough memory, or is it something else? There is already some native code acceleration for modPow(), which is the biggest part of asymmetric crypto (in NativeBigInteger). However, recent JVMs are much faster than older ones. And of course you'd have to recompile for ARM. There *are* interfaces, for instance Rijndael is a BlockCipher. Try to get a bit more specific. What classes do you need interfaces for? Or more likely factory methods? IIRC we call new Rijndael(...) in various places - but we usually store it as a BlockCipher. Ideally we would use the Java official crypto API. We would then have to ship Bouncycastle because some JVMs don't have full strength encryption (I'm not sure if this is still true in 1.6?). And we could take advantage of native acceleration libraries on some platforms. I'd prefer not to shift to maven at this point. It would be a lot of work and from using it I suspect it is grossly insecure. That is, whenever I've run it it's downloaded vast numbers of tarballs with no sign of signature verification. I'm sorry if I appear critical; that's not my intention, IMHO a Freenet appliance is a great idea. -------------- next part -------------- A non-text attachment was scrubbed... Name: sw.asc Type: text/pgp Size: 1979 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20110320/1f3171c5/attachment.bin>
