[freenet-dev] Expose Crypto Stuff via FCP

[Florent Daignière]

* David Sowder <freenet-devl at david.sowder.com> [2007-11-01 11:51:17]:

> David ???Bombe??? Roden wrote:

[snip.]

> > Which is true for FNP but not necessarily for FCP.
> >   
> Yes.  I in my thinking, FCP's job is to encourage Freenet related apps 
> and promote a standard method of communicating with Freenet and 
> Freenet-related facilities in the process.

Sound idea and basis... I don't see how crypto is freenet specific or
even related though.

[snip.]

> >> 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. :)
> >   
> Yes, GPG-style key pairs rather than public and private SSK keys.

I don't get it, sorry, why are those keytypes different ? Aren't we
talking of asymmetrical keys in both cases ?

> >>  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.
> >
> > 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? :)
> >
> > 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.
> >   
> I would add that importing the Freenet classes requires my project to be 
> locked into Java, which is not desirable to me.  Why not export the 
> functionality via FCP, so any language can use the crypto libraries 
> Freenet has built up rather than relying on whatever good/bad algorithm 
> coverage might be easily available in the external project's language of 
> choice.

Well, here there is both the language barrier and the licensing one.
That's a valid point though :)
 
> pyfcp apps could get crypto "for free" to use over Freenet rather than 
> having some third party Python module need be installed because of 
> crypto export restrictions for the developer and the like.  I've already 
> had one idea stall because of the crypto situation in Python and FCP 
> exported crypto functions would have made it a non-issue.

Not really... If you're living in a crypto-restricted country, accessing
a freenet node is probably forbidden too.

NextGen$
-------------- 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/af0f454c/attachment.pgp