[freenet-dev] Expose Crypto Stuff via FCP

[Florent Daignière]

* David ???Bombe??? Roden <bombe at pterodactylus.net> [2007-10-31 22:21:00]:

> On Wed, 2007-10-31 at 22:11 +0100, Florent Daignière wrote:
> 
> >  Link security is the obvious thing... DoSes are an other one.
> 
> We're talking about FCP here. Where is the DoS potential?

Are all clients running on different threads ? Ever thought about
entropy exhaustion ?

> 
> 
> >  Generally speaking, the less services the node provides, the simpler
> >  the protocol is... The best it is for everyone.
> 
> Which is true for FNP but not necessarily for FCP.
> 

The main asset of FCPv2 over v1 is simplicity.

> 
> >  By the way sharing our RNG with clients is probably a bad idea (most
> >  crypto operations involve using some randomness) and we will have to
> >  expose it at some point if we want clients to do some useful stuffs.
> 
> You don't have to expose the RNG. The node just needs to perform a
> couple of operations on behalf of the clients. You could even add the
> FCP messages as an entropy source.
> 

A shakeable entropy source is useless.

> 
> > That's what the GenerateSSK message is for.
> 
> You have no idea what I'm talking about, do you? Otherwise please tell
> me how I use that key pair to encrypt data. Thank you in advance. :)
> 

To encrypt you insert your data to a SSK... to decrypt you get the data from
the pubkey of the SSK.

To  sign, you insert the data to a CHK and  its hash to a SSK/USK. To
verify the sig, you do the opposite.

To do symmetrical encryption you share both the pubkey and the private
key of the SSK.

What's missing ?

> 
> >  I still don't get why clients can't import our classes ... and do
> >  their own crypto with it (okay they are licencing issues... but we
> >  want everyone to use GPL, don't we ? :p)
> 
> Because then client developers have to learn Yet Another API buried deep
> within the bowels of another software. That sucks. FCP would be a clean
> lean, and mean interface for crypto operations. And, frankly, from what
> I've seen so far the freenet crypto API is far from being clean,
> documented, and usable by other people. You'd have more success with
> SUN's JCE.

Well, you're welcome to improve it. As far as I'm concerned I think the
 API is clean. Have a look to DSA
 (http://emu.freenetproject.org/cgi-bin/viewcvs.cgi/trunk/freenet/src/freenet/crypt/DSA.java?rev=15454&view=markup)
 for asymmetrical encryption/signature and Rijndael
 (http://emu.freenetproject.org/cgi-bin/viewcvs.cgi/trunk/freenet/src/freenet/crypt/ciphers/Rijndael.java?rev=15105&view=markup)
 for symmetrical one. You might need a BlockCypher too: see PCFBMode
 (http://emu.freenetproject.org/cgi-bin/viewcvs.cgi/trunk/freenet/src/freenet/crypt/PCFBMode.java?rev=15395&view=markup)

> 
> Just to be clear: What I want is to perform cryptographic operations in
> a client. I want to create key pairs that can identify a user. I want to
> create session keys to encrypt data. I want to sign data with the keys I
> generated. Decrypting. Verifying. Client stuff, you know? :)

I don't think that YetAnotherLayerOfCrypto is needed to achieve the
level of functionality you described.

> 
> What I do NOT want is to busy myself with JSE, JCA, BouncyCastle or any
> other API because the node can already do all that for me.
> 
> 
> >  NextGen$
> 
> 	Bombe



> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071101/eb46a16b/attachment.pgp