On Saturday 19 Mar 2011 06:14:16 freenet.10.technomation at recursor.net wrote: > Hi y'all > > I've been working to get Freenet working on my Sheevaplug - I figure a 5watt > 1GHz appliance with hardware crypto for $100 is something I can keep running > 24x7. > > Now, I have it running, but it sucks all the CPU out of the little fella and > it times-out like crazy, so I've been thinking on how to best use the > hardware, and what I'd need to do, assuming that crypto is a large part of > the CPU hole... And that is to knock out a JNI interface to the hardware > crypto and more generally to the *nix crpto api when it's available (as it > would be more efficient than the Freenet java impl). But I look at the Fred > code and and I am a little overwhelmed. There are no unit tests, so I am > going to break something and not know it, and the package structure is > flatter than I'd like... I find interfaces above impls gives me room to > change the impl as I need. I'd like to find some place to write unit tests, > and I'm used to the Maven dir structure, so I'd need to push the code in Fred > down a directory or two. I'd need to choose a standard unit test framework > (I'm a fan of TestNG and PowerMock over JUnit). I'd need to document. I'd > want to start tidying up > the structure a little so I could grok the whole codebase better.. and drop > some package-info.java's in there too. Package by package. I'd touch a lot of > things and shift code in flight. It would piss any one off. But I'd like to > start doing just that with Crypto and the coupling to it it. > > Ultimately what I'd like to do is post a 'plug *nix image with Freenet on it > that would boot up and self configure, locking out the user (making plausible > deniability all the more plausible) except for limited status info. I figure > this would be a no-hassle way to create a backbone from which more ad-hoc > users would benefit. > > I'd appreciate your thoughts on if/when/when to start this and how to manage > folding updates back in. > > Thanks for all your hard work guys! > > Sebastian Weetabix
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: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20110319/ba7c9910/attachment.pgp>
