--- sn_wot.txt.05 Tue Mar 23 18:02:18 2004 +++ sn_wot.txt Sun Mar 28 22:39:26 2004 @@ -1,12 +1,11 @@ -An idea for distributed secure/reliable social network -version 5 +An idea for distributed secure/reliable community/social network +version 7 (a.k.a. lazy bastard edition) by Vasil Kolev, vasil(at)ludost(dot)net -1) Todo - - Check appendix B for needed clarifications - - Possible attacks against the native transport + - recheck 0) Disclaimer (all rights reserved, blah blah) @@ -59,9 +58,8 @@ verify it's authenticity. It has the following parameters: 'level of trust' (LoT) - this parameter tells how trusted a key is. For example, a low level of trust means that this key is trusted, -but every key, signed with it, is not. Trust can also be negative, -in the sense that a person is SURE that the owner of the key isn't the -person that he/she presents to be. +but every key, signed with it, is not. Negative LoT means a revoked +key, and is usable only when the key signs itself. 'friendship level' (FL) - this tells the relation of the signer with the key owner. This has a meaning that's similar to the level of trust, but it's from the other direction, e.g. LoT tells you how much @@ -70,12 +68,6 @@ have a friend that other people can trust only when they agree with this implicitly. This can be negative, too, implying a enemy, hated person. - It's important to be noted that if a signature has negative -FL or LoT, then the other shouldn't be trusted/used. If you have -negative LoT, there can be no positiveness that the person which -uses the key is really known, and if you have negative FL, then -you can't be trusted to provide right measurement for the trust -level given to the signed key. Timestamp - it's the exact time when the signature was made. This can be used to distinguish which event is the latest, which signature should be used, etc. @@ -100,6 +92,7 @@ of a person, and ways for direct communication with him. They're optional, and are just an aid for the direct request transportation method. They also have public/private key pair. +(they're a part of the native transport layer) 3) Layering of the system @@ -107,7 +100,7 @@ things: 1. Generate public/private keys - 2. Sign other people's keys + 2. Sign other keys 3. Create and parse requests in common format 4. Encrypt, decrypt, sign, and check signatures of requests/documents 5. Use some mode of transportation to send out and receive requests @@ -135,7 +128,7 @@ Every request here, unless stated otherwise, is signed _and_ encrypted. Every received request is acknowledged by the receiver, and has unique id, -consisting of user's key id, the current time, and a random string. +consisting of user's key fingerprint, the current time, and a random string. 4.1) Joining the network @@ -151,7 +144,8 @@ some other information, that can be used as a shared secret, so it's recommended to use the standard practices adopted by PGP users, like exchanging key fingerprints on paper, to be able to verify the authenticity -of someone's key. +of someone's key. More information can be found by searching for "key signing +party" in your favorite search engine. 4.2) Making a friendship relation with someone @@ -201,12 +195,13 @@ request signed with the key itself, and propagate it through the transport layer (there are some problems with this, that will be discussed elsewhere). The other way (if the key itself was lost, or there is something that makes -it unusable, like forgotten passphrase), is to have it's LoT changed to it's -lowest value by everyone who has signed it, and have the new key of the -person/entity signed by them. Changing soneone's key means that the new key -has to be signed again. +it unusable, like forgotten passphrase), is to have it revoked by everyone +who has signed it, and have the new key of the person/entity signed by them. +Changing someone's key means that the new key has to be signed again. (note: the revocations request itself is a signature done with the private key, -with the lowest LoT). +with negative LoT). +(see 5.5) + Revocation requests are final and terminal, after one such request the key becomes invalid. Key expiration is done the following way: some time before the key expires, @@ -214,7 +209,30 @@ through the network as his new key, to have it signed by the people that have signed the old one. It's up to them then to sign it and start using it. (It can also be mandated, that if you have more that one key for an entity, to -use the one with the later expiration date). +use the one with the latest expiration date). + + 4.6) Eviction/disconnected sets, dealing with spam + (if not noted otherwise, the following paragraphs are strictly + about users' keys, not community or trackers') + It's something normal (although not very good) for a community to have +different sets within it, sometimes disconnected. This network is no +exception, and there's the possibility to have no way to send messages +between two groups, if some signatures are revoked, or levels of trust +lowered, based on someone's actions. This is possible if the group that's +connected to the offending subnetwork revokes or lowers it's trust for +all it's members. This way you can establish a subnet, that can receive +read/check requests from the network, but won't have anything accepted +(except revocations). + This creates a way to easily deal with spam, with isolating the +offending members. When the users understand the significance of their +recommendations/signatures, the problem will be even lower, because +it'll be hard or impossible to get an offender to be trusted again. + + Keys can still be validated through trackers' keys, to ensure that +a request will be sent to the right person, that's not in your subnet +of signatures. The decision about accepting such messages is left to +the user. + 5) Some interesting questions @@ -234,8 +252,10 @@ it's not _full_ anonymity - you can never be sure what the implementation of the community server will do, and all your requests are ultimately signed and traceable to you (or to be exact - to your key). +There will be anonymity in the common sense, only the community +will know about you, and it can possibly forget it. - One other possibility is anonymous ranting system, equivalent to + One other possibility is anonymous ranking system, equivalent to that in orkut. It's anonymity again will depend on the service itself, but the difference here is that all your ratings have to be kept in their original form, so when you decide to modify any rating, @@ -268,6 +288,36 @@ nodes in such a network. And, you can always use email exclusively, which gives you the same benefits with enough reliability. +5.4) Why use cryptography? + + (this was suggested by a friend) + A lot of people forget that every bit of information passing +through the internet can be sniffed by everyone that has the +resources to do it - and a lot of people have it. Almost all +of the end users have no control over the route that their data +takes to reach it's destination. So there is really no other way +to send data over the internet that can be sure to not be +sniffed and used by someone else. + Also, the cryptography is still one of the most reliable and +easy methods for really 'signing' data, e.g. guaranteeing somewhat +the source of the data. Most people aren't really aware of the ways +to send faked mail, that's not too easily recognizable as fake +(in fact, everybody can send email that looks like originating +from you, and has your email address as source, there are a lot +of quick tutorials on that). + Yes, you need a healthy dose of paranoia to really want to use +crypto, but in the case of the Internet, paranoia is a requirement, +not a feature ... + +5.5) And what protects me from someone stealing my key, losing + my key, a break-in into my machine, etc? + + Nothing in this system protects you from yourself. Your key +is protected by your passphrase, but that won't help if the passphrase +is empty, if you've written in in passphrase.txt, or something +equally stupid. Security isn't something that you just install, +it's a process of knowing what to do, and doing it. + 6) Why?