I would also like to quiz any student going for the crypto proposal and veto anyone that doesn't meet the minimum theoretical requirements.
On 15/04/13 15:22, Matthew Toseland wrote: > 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. > > > > _______________________________________________ > Devl mailing list > [email protected] > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl -- GPG: 4096R/5FBBDBCE https://github.com/infinity0 https://bitbucket.org/infinity0 https://launchpad.net/~infinity0
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
