  |
|
| Author |
Message |
| syncing via mail? |
|
 Posted:
Wed Sep 23, 2009 10:15 pm
|
|
|
|
|
If we had a decentralized, high latency mail system on top of i2p, would it be possible and/or desirable to sync Syndie via it, instead of using low latency and less anonymous communication via i2p tunnels??
link:
http://forum.i2p/viewtopic.php?p=19949#19949 |
|
|
|
|
|
| Posted:
Thu Sep 24, 2009 7:50 pm
|
|
|
|
|
It would be possible but not necessarily desirable. Syndie's existing synchronization model assumes that many users can connect to an archive (archive: a collection of posts, maybe hosted on HTTP or Usenet or Freenet or something else) to push and pull messages. Archives are forum/identity-independent (Syndie doesn't keep track of what forums/identities use which archives). Messages are syndicated using a broadcast approach: every archive and every client eventually gets every message, even if most of those syndie instances don't have the necessary decryption keys to open a given message. Presumably this email thing would be multicast (one message has one sender and one or more recipients) which essentially means naming and sending to every email-syndication user for every new message. Or doing something much more limited involving knowledge of which email address belongs to which syndie forum/identity and sending only private messages created by the sender to the correct recipient (because you don't know which identity(s) private messages created by others are decryptable by).
The only use case that makes sense to me is this: you and your buddy decide to establish a private direct syndication relationship between your Syndie instances over email. You'll send him any messages you get that he doesn't send you first.
It might be useful in certain scenarios but in general Syndie already solves most of the latency-related security concerns (because the person transmitting a given message may or may not have authored it, and may or may not even be connected to the same networks as the person who authored it). Archive operators are still subject to intersection attacks, but they have a lot of deniability.
The short answer is: yes, if someone writes the code, but I can't imagine it being widely useful. |
|
|
|
|
|
| Posted:
Mon Sep 28, 2009 12:03 am
|
|
|
|
|
| Anonymous wrote: | Presumably this email thing would be multicast (one message has one sender and one or more recipients) which essentially means naming and sending to every email-syndication user for every new message. Or doing something much more limited involving knowledge of which email address belongs to which syndie forum/identity and sending only private messages created by the sender to the correct recipient (because you don't know which identity(s) private messages created by others are decryptable by).
The only use case that makes sense to me is this: you and your buddy decide to establish a private direct syndication relationship between your Syndie instances over email. You'll send him any messages you get that he doesn't send you first.
It might be useful in certain scenarios but in general Syndie already solves most of the latency-related security concerns (because the person transmitting a given message may or may not have authored it, and may or may not even be connected to the same networks as the person who authored it). Archive operators are still subject to intersection attacks, but they have a lot of deniability.
The short answer is: yes, if someone writes the code, but I can't imagine it being widely useful. |
No, what I mean is not exchanging messages only to peers, but rather host an archive somewhere and all users access it instead of via tor or open internet or plain i2p, over i2p+i2p mail getting all the messages they would normally get when syncing with the archive, but not via normal tunnels, but via mail tunnel. an e-mail address would be as little linked to a forum/blog identity as an i2p destination or even less. |
|
|
|
|
|
| Posted:
Mon Sep 28, 2009 4:38 am
|
|
|
|
|
| Anonymous wrote: | | host an archive somewhere and all users access it [...] over i2p+i2p mail [..] not via normal tunnels, but via mail tunnel. |
I haven't read the linked thread. I'm making assumptions about how 'i2p mail' works based on how Internet mail works. In the case of Internet mail, there's no generalized way to create a publicly readable information store. You can cheat and do things like creating a webmail account whose username and password you distribute but it hasn't been designed for that kind of use and doesn't include any of the kind of fine-grained access control you might like (for example, any of the people with access can *beep* up everything for everyone else).
If you can host an archive which all users can access via 'mail tunnels', what's the difference between i2p and 'i2p mail'? |
|
|
|
|
|
| Posted:
Wed Oct 07, 2009 4:43 pm
|
|
|
|
|
right now, if a syndie user connects to an archive and uploads one message it is highly likely that this user also wrote the message, as if it was another user who wrote it, then this other user would have uploaded it.
As far as I know, you upload your messages to an archive and not directly to other peers who then upload it for you.
Thus an easy identification of a user with it's i2p dest is possible, which can be used to gather statistical information in order to link it to an ip. Then you're not anonymous anymore.
with the above outlined way of syncing with the archives this is no longer possible, as you can no longer link the i2p destination to a syncing.
Does Syndie already do archiveless peer-to-peers syndication?
If so, then this is new to me. |
|
|
|
|
|
| Posted:
Fri Oct 16, 2009 3:44 pm
|
|
|
|
|
| Anonymous wrote: | | right now, if a syndie user connects to an archive and uploads one message it is highly likely that this user also wrote the message |
Yes and no. If I push a message to archive A, you pull from archive A and then push to archive B, you will push my message to archive B. If my message is the only 'new' message (the only message you have which archive B does not) your push will be indistinguishable from one I might have done. The archive operator will attack you instead of me, if he's not bright enough to work this out for himself.
If you happen to think that you'd be safer if you only pushed messages you wrote along with messages other people wrote, Syndie could easily be modified to offer that as an option. It might not be very scalable though.
| Anonymous wrote: | | Thus an easy identification of a user with it's i2p dest is possible, which can be used to gather statistical information in order to link it to an ip. |
One easy way to reduce this risk is to restart your client tunnels regularly so that your destination changes. IIRC recent versions of I2P can do this automatically.
| Anonymous wrote: | | with the above outlined way of syncing with the archives this is no longer possible, as you can no longer link the i2p destination to a syncing. |
The trouble is that nothing is outlined above. There's just some hand-waving about mail tunnels and no explanation of how they're different from or better than I2P tunnels. AFAIK mail tunnels are just as vulnerable to statistical attack as the ones we already use.
| Anonymous wrote: | | Does Syndie already do archiveless peer-to-peers syndication? |
How would that help? Wouldn't your peers have the same opportunity to attack you that archives do now? |
|
|
|
|
|
| Posted:
Sun Oct 18, 2009 5:49 pm
|
|
|
I2Phile
Joined: 17 Sep 2009
Posts: 415
|
|
i2p is a low-latency network. no changing dest can change that. and if there are only two archives and these might by synchronized with one another without the user knowing it, so the one uploading a message would not necessarily have a higher anonymity than standard i2p - which, by the way, is already pretty good!! We're talking here about really strong anonymity. But as said: it's low-lateny.
But in order to answer the op's question: at least it was originally planned to provide an option to sync via mixmaster/mixminion or to do peer-to-peers syncs (see http://syndie.i2p2.de/index.html and http://syndie.i2p2.de/roadmap.html ) |
|
|
|
|
|
| Posted:
Mon Oct 19, 2009 2:34 am
|
|
|
|
|
| mixxy wrote: | | i2p is a low-latency network |
Agreed, but so what? How do 'mail tunnels' fix it?
| mixxy wrote: | | if there are only two archives and these might by synchronized with one another without the user knowing it |
I don't understand this objection. If an archive pushes messages to another archive, it looks the same to the passive archive as if a client had pushed the messages. It doesn't change the scenario described above in a meaningful way.
| mixxy wrote: | | at least it was originally planned to provide an option to sync via mixmaster/mixminion |
The code was never written. If it had been written, it would have worked just like what's described in the first reply in this thread. Two individuals decide to set up a private channel through which to synchronize their two Syndie instances. It's a manual process and it doesn't scale.
The OP thinks that 'i2p mail' can be used to set up a publicly readable and writable information store which many Syndie instances could use as an archive. Is he right? |
|
|
|
|
|
| Posted:
Mon Oct 19, 2009 7:00 am
|
|
|
I2Phile
Joined: 17 Sep 2009
Posts: 415
|
|
| Anonymous wrote: |
| mixxy wrote: | | i2p is a low-latency network |
Agreed, but so what? How do 'mail tunnels' fix it?
|
The op refers to a high-latency transport on top of i2p.
| Anonymous wrote: |
| mixxy wrote: | | if there are only two archives and these might by synchronized with one another without the user knowing it |
I don't understand this objection. If an archive pushes messages to another archive, it looks the same to the passive archive as if a client had pushed the messages. It doesn't change the scenario described above in a meaningful way.
|
I meant if they collude, and if they collude, of course, they know they collude.
| Anonymous wrote: |
The OP thinks that 'i2p mail' can be used to set up a publicly readable and writable information store which many Syndie instances could use as an archive. Is he right? |
Me too, I understand him the way you just stated. If he is right with it, i.e. if it is doable, I don't know. For one: it isn't implemented in Syndie, and secondly, more important even: The op refers to a design that was being discussed recently, but is not (yet) implemented. (see the thread started by HungryHobo, linked above in the beginning of this thread).
Presumably the op is the same as a guest that asked the same question in our thread.
As I don't use Syndie and don't know anything about it, I cannot answer if "he is right" or not.
Just looked ate the homepage of it, in hope of providing an answer. All I can tell was the scheme image I saw there - dunno how it was originally meant or if these plans have been altered.
All I can say is that this new distributed mail design the op refers to would built remailer chains with an option for macroscopic delays on top of i2p... |
|
|
|
|
|
| Posted:
Tue Oct 20, 2009 2:02 am
|
|
|
|
|
| mixxy wrote: | | The op refers to a high-latency transport on top of i2p. |
That's not enough detail. What does the high-latency transport look like from the perspective of applications that use it? Can I run HTTP over it? If not, what? (Today, Syndie archives run HTTP over I2P or Tor)
| mixxy wrote: | | I meant if [two archives] collude, and if they collude, of course, they know they collude. |
Yes, if they collude they will know that the message didn't come from either of them. But unless *all* archives collude, there's no way they can be sure that whichever client uploaded the message to the colluding archives was the author of the message.
Though Syndie doesn't yet include built-in support for any alternative transports (such as mixmaster/mixminion), it's important that it eventually does get that support. It improves everyone's security, even the people that only syndicate via HTTP, because it increases the uncertainty about where a message might have come from.
| mixxy wrote: | | it isn't implemented in Syndie |
Don't worry about that. Syndie messages are just encrypted files (in a particular format). They can be transferred in any way that arbitrary files can be transferred. A syndication mechanism can be built on top of just about any protocol. (Also you don't need to tell me that. I know very, very well what is and is not implemented in Syndie. I know that you didn't know that I knew it, but now you do.)
What I want to know is whether 'i2p mail' supports publicly readable and writable information stores.
| mixxy wrote: | | The op refers to a design that was being discussed recently, but is not (yet) implemented. |
I get that. But someone somewhere ought to be able to tell me something about the theoretical capabilities of the design. I read the thread. It didn't help. |
|
|
|
|
|
| Posted:
Tue Oct 20, 2009 6:00 am
|
|
|
I2Partisan
Joined: 27 Aug 2009
Posts: 204
|
|
| Anonymous wrote: | | What I want to know is whether 'i2p mail' supports publicly readable and writable information stores. |
It wasn't designed with that in mind, but nothing stops multiple people from sharing the private keys for one email destination.
Any one of those people will be able to store, read, and delete emails. I don't know if the delete part is a problem here.
Maybe what I2P really needs is a generic DHT service that can store any type of data: shared files, websites, blog posts, etc.
It should support downloading from multiple nodes at a time for faster speed.
If it's done right, it could be used as a web server, file sharing client, and possibly more. |
|
|
|
|
|
| Posted:
Tue Oct 20, 2009 7:02 am
|
|
|
I2Phile
Joined: 17 Sep 2009
Posts: 415
|
|
| Anonymous wrote: |
| mixxy wrote: | | I meant if [two archives] collude, and if they collude, of course, they know they collude. |
Yes, if they collude they will know that the message didn't come from either of them. But unless *all* archives collude, there's no way they can be sure that whichever client uploaded the message to the colluding archives was the author of the message.
Though Syndie doesn't yet include built-in support for any alternative transports (such as mixmaster/mixminion), it's important that it eventually does get that support. It improves everyone's security, even the people that only syndicate via HTTP, because it increases the uncertainty about where a message might have come from. |
I fully ack that.
| Anonymous wrote: |
| mixxy wrote: | | it isn't implemented in Syndie |
Don't worry about that. Syndie messages are just encrypted files (in a particular format). They can be transferred in any way that arbitrary files can be transferred. A syndication mechanism can be built on top of just about any protocol. (Also you don't need to tell me that. I know very, very well what is and is not implemented in Syndie. I know that you didn't know that I knew it, but now you do.)
What I want to know is whether 'i2p mail' supports publicly readable and writable information stores. |
It will be a message-based e-mail distribution system with a kademlia store.
| Anonymous wrote: |
| mixxy wrote: | | it isn't implemented in Syndie |
[...](Also you don't need to tell me that. I know very, very well what is and is not implemented in Syndie. I know that you didn't know that I knew it, but now you do.) |
Oh, so you're MOSFET?
It's hard to tell whom you're talking with when all are 'GUEST'.
Even now after you told, next time GUEST could be someone else.
But I guess I'll recognize your writing style more or less, as you do quite detailed replies... 
Anyway, it was also meant to be for completeness sake (to the best of my knowledge) for other thread readers. Was not meant as lecturing somebody.
| Anonymous wrote: |
What I want to know is whether 'i2p mail' supports publicly readable and writable information stores. |
It will have a kademlia-based store, but I think you would make more sense to use it as a mere transport layer and have the archive itself do its own storing. It would thus only receive and send out the things via mails, instead of palin HTTP. Therefore it would require the syndication to be done packet passed, not in streams. Dunno if this is doable or if it is even already done that way. No idea.
Again, I am not the most competent person to speak about that, as I'm neither involved in Syndie-dev nor do I know the very details of I2P-Bote.
Last edited by mixxy on Tue Oct 20, 2009 7:11 am; edited 1 time in total |
|
|
|
|
|
| Posted:
Tue Oct 20, 2009 7:06 am
|
|
|
I2Phile
Joined: 17 Sep 2009
Posts: 415
|
|
| HungryHobo wrote: |
| Anonymous wrote: | | What I want to know is whether 'i2p mail' supports publicly readable and writable information stores. |
It wasn't designed with that in mind, but nothing stops multiple people from sharing the private keys for one email destination.
Any one of those people will be able to store, read, and delete emails. I don't know if the delete part is a problem here.
Maybe what I2P really needs is a generic DHT service that can store any type of data: shared files, websites, blog posts, etc.
It should support downloading from multiple nodes at a time for faster speed.
If it's done right, it could be used as a web server, file sharing client, and possibly more. |
I heard, a DDS is being developed for i2p - however I don't know anything about its status (still active or abandoned) - in any way not too close to completion... |
|
|
|
|
|
| Posted:
Tue Oct 20, 2009 4:22 pm
|
|
|
|
|
yes, I mean it that it will use not a i2p dest but a mail addres.
the syndie user and the archive.
Will this come? |
|
|
|
|
|
| Posted:
Tue Oct 20, 2009 6:28 pm
|
|
|
I2Phile
Joined: 17 Sep 2009
Posts: 415
|
|
| Anonymous wrote: | yes, I mean it that it will use not a i2p dest but a mail addres.
the syndie user and the archive.
Will this come? |
quick answer: not too soon, I'd say - if at all.
What will likely come is some usage of the new distributed data store in i2p - once this comes into being; however, I fear this won't be too soon either. |
|
|
|
|
|
|
You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
(http://www.mikelothar.com/community)
Forum software: php BB (http://www.php bb.com) v2 © 1976 php BB Group
|
