Florent Daigni?re wrote:
> * 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.
>
It's not directly related, but both are privacy related.
>>>> 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 ?
>
GPG-style key pairs are general use. SSKs are very purpose specific,
though I admit I might be able to see where you're coming from, I just
don't think I've wrapped my head all the way around it yet.
>>>> 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.
>
In my case, the crypto restriction is only that I have to do certain
things to be able to legally share cryptography code with those outside
of my country and since I haven't worked out the exact details of what
that would entail, I've avoided "sharing" (i.e. exporting) such code.
This is not the same kind of crypto restriction that would make Freenet
nodes illegal though (yet).
