>>>>> Christian Grothoff <[email protected]> writes: >>>>> On 10/21/2012 05:59 PM, Ivan Shmakov wrote:
[…] >> There may be a privacy issue to consider, BTW. Namely, I've got an >> impression that keyword searches are, to an extent, “public”, in the >> sense that a node learns at least a part of the searches it takes >> part on behalf of the other nodes (and perhaps the results of such >> searches as well.) And if such a search contains a public key >> (which corresponds to a particular identity), that may be a problem. > You might want to read > https://gnunet.org/bugs/view.php?id=2564 > which still needs to be implemented. ACK, thanks for the pointer. The proposal seems sensible, though I doubt that I'll be able to participate in its implementation. […] >> Conceptually, we already have a facility to transfer arbitrary >> binary data, and a symmetric key-encrypted message is certainly such >> a data. What we'd need is the format for the “pointer” messages, >> containing a reference to the (encrypted) message, as well as >> linking public keys to public key-encrypted symmetric keys of the >> recipients (and, perhaps, the public key of the sender, and an >> encrypted digest of the original, unencrypted data, to form a >> digital signature), like (speaking X.680): > You've lost me here. You've never fully explained what you're trying > to do. Based on what you write below, I guess it is some variant of > pseudonymous E-mail? If so, in what way does Mixminion not solve > your problem? Its documentation is somewhat scarce, but it doesn't seem to implement a routing scheme to get through restricted topologies' networks. (Unlike GNUnet.) Also to note is that I'm more interested in a solution that provides strong message integrity (authenticity) checking, rather than anonymity. I believe that contemporary e-mail has a few major issues, in particular: • inefficient routing and delivery — the routing is often “static”, and there doesn't seem to be a way to make it adapt to the location of the recipient (rather, the routing takes into account the location of the recipient's mailbox server); for delivery, even if the link used is 8 bit-clean, most of the ASCII “control” codes have to be escaped, thus increasing the overall message size (by ⅓, should Base64 be employed); delivery to multiple recipients is also inefficient; • spam — which forced e-mail, while initially simple, to evolve into a quite complex system, with various tricks to fight unsolicited mail traffic; • due to the aforementioned complexity, it becomes infeasible for individuals and small businesses to deploy their own e-mail infrastructure, and forces them to rely on major e-mail providers instead, raising privacy issues among others. Thus, the goal is simple: a complete replacement for e-mail. (And I suspect that the very same application could then replace netnews, mailing lists, Web fora, and even bug trackers and wikis.) The basic ideas to remedy the issues above are: • use public key-based identifiers as “mailbox addresses”, and allow the user to “publish” the list of preferred hosts for the senders to “post” the messages sent to him to; certainly, it should be possible for such lists to be maintained automatically, perhaps only requiring confirmation to use user's private key to publish them; • establish a loose web of trust, thus making spam largely infeasible; (eventually, one's web of trust will be large enough for the vast majority of incoming mail to possess a signature of a “friend of a friend”); • given that the routing can now largely be user-driven, switching to, from, or between major “new mail” providers would be a non-issue. My guess is that both Secure Share and FreeTalk (check, e. g., [1]) are intended to solve roughly the same issues. So, perhaps, working on a similar solution on top of GNUnet routing (or some other) would be a duplication of effort. Or may be not, for there still may be a lot of room for exploration. […] [1] http://comments.gmane.org/gmane.network.freenet.devel/28953 -- FSF associate member #7257 _______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
