Simple (username+)password that unlocks a hidden WoT identity. - Private key is either derived from the above, or is stored on the network. - The rest is also stored on the network: Latest versions of USKs that the other identities don't poll etc. - This could be a KSK derived from the above. Or it could be some sort of mechanism where we post it (or a pointer to it? better to have it all but size is an issue?) on the identity's WoT identity daily insert, or something global (anti-spam issues if global) - Password must be strong! If bad guys can guess it they can decrypt! - Tradeoff between key derived from password (in theory the request is visible, once you have the u+p), versus including it in the identity (downloading the identity is universal, so no suspicion; but offline attacks are possible). Former is probably better, although data persistence is an issue. And if they are surveilling your node, they can see your posts anyway! - Can strengthen by tying to a computer (combine with long stored nonce). Tradeoff is seized computer + username + password proves beyond doubt the user was using it - plus not portable. Optional. - This will work best if the identities that can be seen by the hidden WoT identity are equal to, or a subset of, the main visible identity (which will be created during the first-time wizard). We need to consider how to deal with this best. - UI: It will take a while to download the data. We can't cache it in the client-cache! We will need to show a progress bar or something. - Can we make offline attacks against the client-cache and client database harder via a similar mechanism? I.e. username and password give a key, which has to be fetched, making offline attacks infeasible unless the bad guys are connected? Possibly... - Possible client layer architecture issue: If we fetch a key for a hidden identity, should a non-hidden identity see the block? I guess that's really down to tunnels - tunneled stuff should not be seen by other identities.
Benefits: Case A) Portability, and absolutely no way to tie the username and password to the computer, no physical evidence whatsoever, provided the username and password are very strong. Case B) No possibility of an offline attack resulting in impersonation, even if the attacker can see the key requested. In the case of seizure, the nonce allows for an offline attack... if there was anything to attack, which afaics there isn't. I'm sure people have suggested things close to this. However I don't think it was fully formed until now. It is true that relying on password security is generally a bad thing. However, it's what users are used to, and it is possible for the determined to memorise a meaningfully secure password - and to remember it, if they use it frequently. And it would be very close to what a lot of users want: Very good local security (provided swap is encrypted too), good remote security (with darknet, and eventually tunnels), and a simple login exactly as if they were using any of the web services. Also, to improve on passwords, tokens could be integrated eventually; so could biometrics, although the fact that they return a fuzzy result means using them for keying material is problematic. It would probably be a good idea to have a revocation mechanism, although WoT provides a third party revocation mechanism in some sense with negative trust. (Which I still mostly think is a bad idea)
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] http://freenetproject.org/cgi-bin/mailman/listinfo/devl
