* 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: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20071101/af0f454c/attachment.pgp>
