On Fri, 2014-06-20 at 10:31 +0100, Matthew Toseland wrote: > On 15/06/14 20:25, Florent Daigniere wrote: > > On Sun, 2014-06-15 at 15:09 -0400, unixninja92 wrote: > >> Hi all, > >> > >> Going back to last week quickly, I forgot to mention that I sent an > >> email to the BouncyCastle email list asking them about support for > >> curve 25519 and ed25519. I got one response from a non-BCdev pointing > >> me towards a java implementation of curve 25519 which lead me to the > >> java implementation of ed25519 that I linked last week. > >> > >> This week I wrote the first version of the API for hashing. I really > >> liked how the HashType enum was set up and am planning on using this > >> model for the rest of the API. > >> > >> I started working on the API for signing. I am starting out just > >> supporting ECDSA. I am still working on figuring out the best way to > >> also support our custom DSA classes. After working on this I decided > >> that I would rather wait for BC to support ed25519 than try and > >> support our own implementation as it would be far less messy. The > >> SigType enum will keep track of the curve and algorithm being used so > >> we don't need a private curve class any more. > >> > >> The PreferredAlgorithms class now checks against NSS as well. > >> JCELoader will now check if NSS has Unlimited Policy file. Right now > >> it just prints an error, but maybe we should just not use NSS if it's > >> not unlimited? I can write a check against the java version to > >> determine if it should be used for key generation in java6 [1]. As far > >> as I can tell NSS keys and BC signing seem to work together (at least > >> for benchmarking purposes) but I will do some more testing. I've also > >> added benchmarks for ECDSA and EC for key generation. > >> > >> -Charles > > Good work! > > > > IIRC the whole policy limitation thing goes away in java7... > No it doesn't. > http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html > > we'll > > eventually require it to run Freenet... I suggest you design the API > > without thinking twice about it. Also, "recent" crypto in Freenet is > > 128bits... so even if the policy file is not present, it should work. > "Recent" crypto? Meaning what code? > > What you actually mean is you intend to use 128-bit encryption for > everything because it's marginally faster and to use 256-bit *properly* > would require using secp384 (slowish) and a better PRNG (relatively > hard). Right? >
I mean that it's unrealistic for us to aim at more than 128bits of security... so we shouldn't and that makes the restrictions irrelevant. Thank you for helping me formulate my thoughts in clearer terms. Florent
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
