On Monday 15 Apr 2013 06:23:35 Trung Hieu Nguyen wrote: > Dear FreeNet, > > My name is Nguyen Trung Hieu, 3rd year computer science student specialized > in Information Security at National University of Singapore, > I am interested in Freenet Security Projects, especially the following two > projects: > Use ECC for SSKs > Review Crypto and use JCA where possible > I would like to have a chance to discuss with you. It would be great if I > can know more about those projects to prepare for the proposals.
The devl list is probably most appropriate for this, so I've CC'ed it. The main difficulty with this project will be finding a mentor. I might be able to do it, as GSoC officially starts after my exams are over. Maybe nextgens has time? I would be very happy to discuss this with you, and hopefully nextgens will be too. We can talk on the mailing list and if appropriate on IRC (#freenet on irc.freenode.net, I'm toad_, nextgens is nextgens). Most of this is on the bug tracker: https://bugs.freenetproject.org/ Search for ECC and then follow the links between bugs. Some of the more annoying problems relate to symmetric encryption: We can't use 256-bit keys with JCA (even if you install the Unlimited Strength crypto files, they get deleted whenever the JVM updates itself!), and since we use 256-bit keys now, it would be best to keep using them, so we will probably have to keep using our built-in crypto code, or Bouncycastle's lightweight API. 256-bit isn't really needed for opennet connections though, only for darknet connections, so it might be nice to have a layer that can use the fastest available implementation for a given key size... Of course native code JCA implementations are actually slower on x86, mostly because we only encrypt packets (~1KB) and freenet blocks (CHKs are 32KB, SSKs are 1KB); the overhead of calling native code usually exceeds the speed gains. Connection crypto currently uses an outer obfuscation layer (to make it harder to fingerprint), and JFKi (a variant of STS designed to limit denial of service attacks), and generates separate keys for the IV (derived from the packet number), and packet encryption in each direction. Packets are encrypted using Rijndael with CTR mode with 256-bit block size and 256-bit keys, so not strictly AES. Most of this needs changing. Nextgens is in favour of just using TLS, for example. Apart from generally looking at crypto for both connections and keys (SSKs and CHKs), ECC-based SSKs are closely linked with two other related areas: - Convert the datastore from storing SSKs and public keys for SSKs separately to a single store including the public key. This is important because it allows us to have 1KB and 2KB SSKs which fit in roughly the same size on disk as the current 1KB SSKs; at the network level, 1KB ECC SSKs fit in a single packet including the pubkey, so are ideal for e.g. real time chat over Freenet; 2KB SSKs still fit in the same slot on disk and are more appropriate for forum-style chat. - Programmable key verification (PSKs). This allows e.g. "this key is valid if you include a signature by public key signed by the owner's public key". So there's a lot to look at, and we'll need to decide roughly what can realistically be part of your Summer of Code project. Note that for you to be accepted as a Summer of Code student we will need to see you fix a bug or contribute a minor feature before the SoC starts.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
