-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dan Merillat wrote > That's not a bad idea. A FCP "Sign This" and "Verify This" would be useful for > a number of apps. Those suggested new FCP-commands would really be a very nice way to introduce the ability of signing to more freenet applications. But I am wondering if, in the case of fmb, it might perhaps be some performance overhead. Especially since there are people accessing their node from a remote computer, it might quite a waste of bandwidth to send all the messages to the node just to verify it. I'd rather do the signing / verifying inside fmb, using the freenet.crypt classes. As every fmb user should have freenet.jar lying around somewhere, this shouldn't be a too annoying dependency. I am just figuring out how to this and I will write another message with the questions I have about using DSA, SHA1 and stuff. I'd basically need a small class with those two methods: String calculateSignature(byte[] i_messageToBeSigned, String i_base64encodedSSKPrivateKey); boolean verifySignature(byte[] i_messageThatIsSigned, String i_base64encodedSSKPublicKey, String i_signature); If it would be a five-minute-task for anyone here to write such a simple class, I'd be very happy if he could do so, because I am not too sure how this works, I browsed the freenet javadocs to see how to do it, and got an idea, but there are still some things I don't understand about the crypto involved. > For instance, we could wire it into fproxy and have signed (optional) > Nearly Instant Messaging without the recipient having to listen on every possible > channel. Along with that, an "Encrypt This" and "Decrypt this" so only the > recipient can read it and you've got the basis for secure email over freenet. The main problem with KSK based messaging system is not the encryption/signing. This could always have been done with external tools like OpenPGP. The two problems with KSKs that (in my opinion) make them unusuable for any useful/secure messaging are those. 1. Spamming. You simply can never be sure what data you are about to retrieve from a KSK channel and who inserted it unless you have requested it and it appears on your node. It is especially dangerous that the data on that KSKs don't even have to be messages. If I wanted to publish large content on freenet and really be sure to have it available, I might just split it into small parts, insert the parts under the frost-board-KSK-slots from the next day, create a splitfile manifest pointing to those slots, and have a hundred frost users wondering why frost is so slow, not knowing that they spread my large file around freenet without ever deciding to do so. 2. Key Collisions. This is a very annoying thing. The theory looks quite simple, try inserting at slot 0, if there's a key collision, increase the index and try again. In reality, I often experienced different behaviour: If two users insert a message to the same slot with a rather low htl, it can (and does) happen that they both succeed, so that there are two different messages on the same slot. It is pure luck which msg you will retrieve from node. This means one message is definetly lost, which is about the worst thing that can happen to a messaging system. If both users insert with high htls at the same time, it can (and does) happen that both get a key collision and both increase their index, resulting in a empty slot, which might be filled later by a third user. Maybe that is just a bug in the current implementation, but I think if we don't have 2 but 100 users trying to post onto the same KSK slot at the same time, it will end up in a big mess of key collisions, lost messages and the last message being inserted two hours later at slot 400. Using SSK keyspaces, we don't have the key collision problem any more, because you usually should know what is the next free slot on your personal channel because no one interfere. The problem now is having to gather messages from every channel. Luckily it's not true that there are 2000+ active fmb NYMs, as you said. There are just about 10 active NYMs per day right now, which is still easy to handle. But of course you're right that if there would be 2000 NYMs, the system without broadcasting will be absolutely unusable. But did you ever notice that if you see suomynonA or green being the latest active user, and you listen to their channels only, you usually get all messages posted that day? That's the way fmb might work with a large user base. A frequent fmb user that runs fmb full time could mark itself as "moderator". Each moderator could specialize on a certain newsgroup. For example, my "moderator information" could look like this: "I am nacktschneck, I listen to all users channels that post messages in the fmb.news newsgroup and I will forward them. My policy of rating is that I ignore and won't forward any messages that are intentionally off-topic (no illegal activities on fmb.news, please) or of spamming nature. Testing messages should be posted in the fmb.test newsgroup, otherwise I won't forward them. If a user ignores these guides too often, I will stop listening to his channels and ignore his future messages" If a not-so-frequent fmb users starts fmb, gathers some announcements and then selects the fmb.news newsgroup, he should see a list of moderators, containing my moderator info, and maybe from someone else who is also gathering messages from that group, who might have different rating policies. You now can decide which moderators's channels to listen to and should get many messages from that newsgroup quite fast, because a lot of messages can be compressed into a single slot, and these moderator channels should be much better available than normal personal channels, because they are being requested more often. If you want to want the most uptodate messages, or think that the moderators are filtering out message that you would like to read, you still can listen to all other personal channels from users who say that they do post in the fmb.news newsgroup. Another way to reduce the number of channels to listen to would be to introduce message hubs. Any number of users that trust each other could stick together, have one of them run a command line version of fmb 24/7 that continuosly listens to all their channels and merges the messages together on a single fmb channel. Do you think this idea might work? Or is the redundancy introduced by the message bundling worse than 2000 users listening to 2000 channels? nacktschneck -----BEGIN PGP SIGNATURE----- Version: Hush 2.1 Note: This signature can be verified at https://www.hushtools.com wmEEARECACEFAj1CrOoaHG5hY2t0c2NobmVja0BodXNobWFpbC5jb20ACgkQ2++6pAG1 GbDxWwCeOdNSJxxBX3SrpiTT1pB5IvazQo4AoJSkzafTFY+N1RI/bt+B9i1goaET =sor2 -----END PGP SIGNATURE----- Communicate in total privacy. Get your free encrypted email at https://www.hushmail.com/?l=2 Looking for a good deal on a domain name? http://www.hush.com/partners/offers.cgi?id=domainpeople _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
