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