forum.i2p ~ View topic - syncing via mail?

FAQ Search Memberlist Usergroups Profile Log in to check your private messages

Author

Message

syncing via mail?

Guest

Posted: Tue Oct 20, 2009 11:03 pm

HungryHobo wrote:

nothing stops multiple people from sharing the private keys for one email destination.

How do users retrieve messages stored in an email destination? I assume that this is where the high-latency transport comes into play?

HungryHobo wrote:

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.

It is if a large number of people use a single email destination. If only a small group who trust each other share a destination it's not a problem.

HungryHobo wrote:

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.

The potential advantage I see in this is not its distributed nature. Syndie is already distributed. It's the high-latency transport that matters. None of the DHT proposals or implementations I have seen include that.

mixxy wrote:

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.

That is possible. It's not very efficient, though. It means sending one email per Syndie message per Syndie client. It also means the archive must maintain a complete list of the subscribed email addresses. It might also have negative anonymity implications.

(Example: the archive generates a new message containing a unique identifier and sends it to one client. It does the same for each client it knows. Then, one or more colluding HTTP archives wait to see if any clients push the marked messages. If one does, it's not a certainty that the client in question belongs to the email address associated with the unique identifier. However if you repeat the process and combine it with other statistical attacks, who knows what's possible?) (Obviously this particular example of an attack only works if clients that syndicate over i2p mail also syndicate over some other transport.)

mixxy wrote:

Therefore it would require the syndication to be done packet passed, not in streams.

This has nothing to do with packets or streams. To Syndie HTTP is just a convenient way to serve files, nothing more. You can already syndicate via email or a thumb drive. You just have to export and import the message files manually.

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?

If I have understood you and HungryHobo correctly, no, I don't think this will ever come. However it will likely be possible to use Syndie and 'i2p mail' together in the way described in the first reply in this thread. The one you replied to and said no, that's not what you want.

mixxy

Posted: Tue Oct 20, 2009 11:27 pm

I2Phile

Joined: 17 Sep 2009
Posts: 415

Anonymous wrote:

HungryHobo wrote:

nothing stops multiple people from sharing the private keys for one email destination.

How do users retrieve messages stored in an email destination? I assume that this is where the high-latency transport comes into play?

If you have read the i2p-bote thread, you know that the high-latency transport is mail tunnels with delays.

Anonymous wrote:

HungryHobo wrote:

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.

It is if a large number of people use a single email destination. If only a small group who trust each other share a destination it's not a problem.

I don't think, it would be wise to share destinations for this at all.

Anonymous wrote:

HungryHobo wrote:

The new serverless mail system called I2P-Bote will have this. At each hop you can define a delay, so that the original sender of a message can be offline when his message will get delivered. No statistical profiling on who is when online will help determine the originator or receiver.

Anonymous wrote:

mixxy wrote:

What implications?
Of course the addresses could NOT be the normal use addresses, it would be addresses only for use with Syndie - even one-time addresses are thinkable. This would be more anonymous than an i2p-dest.
Also, of course the archive needs to know the addresses, but so does it now need to know the dests, so I see no big difference.

Anonymous wrote:

(Example: the archive generates a new message containing a unique identifier and sends it to one client. It does the same for each client it knows. Then, one or more colluding HTTP archives wait to see if any clients push the marked messages. If one does, it's not a certainty that the client in question belongs to the email address associated with the unique identifier. However if you repeat the process and combine it with other statistical attacks, who knows what's possible?) (Obviously this particular example of an attack only works if clients that syndicate over i2p mail also syndicate over some other transport.)

I don't see what usable information could be gathered this way?
It's like finding out the i2p destination of a Syndie client. Same works now, you can send out tagged messages and see which dest replies.
Or am I not gettin your point?

Anonymous wrote:

mixxy wrote:

Therefore it would require the syndication to be done packet passed, not in streams.

Then maybe you wouldn't have to send each message separately, maybe you could send several ones in a big package? But you're right that in a high-latency network there is no easy and quick way to compare client and server lists of messages. Maybe you simply request all new messages after date X.

Guest

Posted: Wed Oct 21, 2009 3:48 am

mixxy wrote:

Anonymous wrote:

How do users retrieve messages stored in an email destination? I assume that this is where the high-latency transport comes into play?

If you have read the i2p-bote thread, you know that the high-latency transport is mail tunnels with delays.

Let's pretend I haven't read it. It seems to me that three things happen to a message:
a) it is sent through a series of intermediate mixes (or hops or routers or whatever you're calling them) which store it for a specified period of time and then forward it to the next mix
b) It is stored in the recipient's 'email destination' (I don't know exactly what that is but I'm prepared to treat it as a black box for now)
c) The recipient somehow connects to the 'email destination' and retrieves the message

So, fine. Nobody can tell who the sender is because the message is mixed and delayed all over the place. But what protections, if any, are in place to prevent whatever computer is hosting the 'email destination' from attacking the recipient? That is what I was trying to ask. Is it clear now? Have I misunderstood something?

mixxy wrote:

I don't think, it would be wise to share [email] destinations for [Syndie archives] at all.

Why not?

mixxy wrote:

I know that. HungryHobo was suggesting I use some other DHT instead of i2p mail (or whatever you want to call it) for Syndie archives, and I was pointing out that some other DHT will not have this feature. I don't need a DHT. I just need a high-latency transport.

mixxy wrote:

Anonymous wrote:

the archive must maintain a complete list of the subscribed email addresses. It might also have negative anonymity implications.

What implications?

You're assigning a long-lived ID (the email address) to each Syndie client. Syndie wasn't designed like that, so it's an important change which could have all kinds of unforseen consequences. (Syndie has identities, but they are independant of the particular client. I can post with my identity from any Syndie client where I have my private key.)

mixxy wrote:

Of course the addresses could NOT be the normal use addresses, it would be addresses only for use with Syndie - even one-time addresses are thinkable. This would be more anonymous than an i2p-dest.

What's this? One-time addresses? How do the archives and clients learn each other's addresses in this case? How are Syndie addresses different from 'normal' addresses? Why should they be different?

mixxy wrote:

Also, of course the archive needs to know the addresses, but so does it now need to know the dests, so I see no big difference.

It's completely different, because now, only archives have long-lived destinations. Clients always connect to archives, never the other way round. So clients can generate new destinations every single time they connect. The archive never knows if the client connected to it right now has ever connected before, or anything about its past behavior. If we use email, archives must send messages to clients, so clients must have long-lived addresses, which allows archives to profile them and analyze them.

mixxy wrote:

I don't see what usable information could be gathered [by sending tagged messages to specific Syndie clients over email]?
It's like finding out the i2p destination of a Syndie client.

The point of using i2p email to synchronize with an archive is that it should be much safer than using HTTP. If archives can use a trick like this to get your I2P destination, what's the point of using i2p mail?

mixxy wrote:

Same works now, you can send out tagged messages and see which dest replies.

If you did it now, you couldn't select an individual Syndie client to send your tagged messages to. All you could do is scatter them out to all the clients that connect to your archive. It would be useless. That's the point I was trying to make about a long-lived ID attached to each Syndie client.

mixxy wrote:

But you're right that in a high-latency network there is no easy and quick way to compare client and server lists of messages. Maybe you simply request all new messages after date X.

You have to be very careful with that. You're giving the archive a clue about the last time your client synchronized with that archive, which might help the archive identify you. Of course if you've already told it your long-lived ID its not going to matter.

mixxy

Posted: Wed Oct 21, 2009 5:37 pm

I2Phile

Joined: 17 Sep 2009
Posts: 415

Anonymous wrote:

Let's pretend I haven't read it.

No problem.
But then you get the short explanation.

Anonymous wrote:

It seems to me that three things happen to a message:
a) it is sent through a series of intermediate mixes (or hops or routers or whatever you're calling them) which store it for a specified period of time and then forward it to the next mix
b) It is stored in the recipient's 'email destination' (I don't know exactly what that is but I'm prepared to treat it as a black box for now)

Correct.
The nodes form a kademlia network for storing packets, that's your black box.
(maybe have a look at the small diagram at http://i2pbote.i2p/documentation.txt which illustrates it quite well.)

Anonymous wrote:

c) The recipient somehow connects to the 'email destination' and retrieves the message

So, fine. Nobody can tell who the sender is because the message is mixed and delayed all over the place. But what protections, if any, are in place to prevent whatever computer is hosting the 'email destination' from attacking the recipient? That is what I was trying to ask. Is it clear now? Have I misunderstood something?

It depends on what you refer to by "hosting an e-mail destination". I understand it the way that you refer to the final receiver of the mail, not the storing nodes.

The receivers are protected the very same way, the sender is: they fetch their mails or whatever via 'inbound' mail tunnels or chains. It's like using nymservers and single use reply blocks.you send out a query for new messages via an outbound high-latency tunnel and send a single use reply block with it, which will be used by the 'fetcher' node in order to send the message back to the destination holder via the inbound tunnel the destination holder has defined beforehand.

Picture the whole system like i2p network, just with big delays, thus making it high latency.
You can think of it as a distributed e-mail system or simply as a high latency transport layer, similar to i2p or tor, just slower.
Think of mixminion and you get a good notion of what it does.

Anonymous wrote:

mixxy wrote:

I don't think, it would be wise to share [email] destinations for [Syndie archives] at all.

Why not?

If I share my private keys with other users, they can delete messages intended for me before I even read them. I

Anonymous wrote:

mixxy wrote:

Then maybe it could be of interest for you, as said the op. I don't know. Your decision - technical problems apart.

Anonymous wrote:

mixxy wrote:

Anonymous wrote:

the archive must maintain a complete list of the subscribed email addresses. It might also have negative anonymity implications.

What implications?

Not necessarily. Of course, you could.
But you need not use long-lived ID's. You can change them and use a different one for every new communication. You can also use a different one for sending than for receiving. you can send messages without even giving any information about your ID.
The 'email address' is a public key or its hash - just like i2p dests.

Anonymous wrote:

mixxy wrote:

Of course the addresses could NOT be the normal use addresses, it would be addresses only for use with Syndie - even one-time addresses are thinkable. This would be more anonymous than an i2p-dest.

What's this? One-time addresses? How do the archives and clients learn each other's addresses in this case?

Quite what it says: an address you use only once. The archive's address would have to be static, so it can be contacted. The clients would use dinamic ones. Create a dest, query for new messages, receive new messages, delete dest.

Anonymous wrote:

How are Syndie addresses different from 'normal' addresses? Why should they be different?

They are not DIFFERENT FROM 'normal addresses', but they DIFFERENT ONES than the ones for 'normal' use - i.e.the former would be used exclusively for syndication only, so you cannot correlate a syndie peer with a peer's normal use e-mail address, i.e. a mail user - just as you would not use the 'shared clients' option in i2p for syndication and your eepproxy and you mail accounts ,,,

Anonymous wrote:

mixxy wrote:

Also, of course, the archive needs to know the addresses, but so does it now need to know the dests [now], so I see no big difference.

Same here.

Anonymous wrote:

If we use email, archives must send messages to clients, so clients must have long-lived addresses, which allows archives to profile them and analyze them.

Not needed. See above.

Anonymous wrote:

mixxy wrote:

I don't see what usable information could be gathered [by sending tagged messages to specific Syndie clients over email]?
It's like finding out the i2p destination of a Syndie client.

They won't ever know my i2p destination if I chose only to syndicate this way - no chance for tagging attacks.

Anonymous wrote:

mixxy wrote:

Same works now, you can send out tagged messages and see which dest replies.

obsolete - (see above!).

Anonymous wrote:

mixxy wrote:

But you're right that in a high-latency network there is no easy and quick way to compare client and server lists of messages. Maybe you simply request all new messages after date X.

No long-lived ID's needed - obsolete (see above)
The date would however disclose your last contact time, true.
I don't know how syndication is done currently, but I doubt it will always send ALL messages the archive has. If so, this wouldn't scale at all. So I think you have found a way around this, and I'm convinced you could make it work also via different transports.

Guest

Posted: Thu Oct 22, 2009 12:45 am

mixxy wrote:

Picture the whole system like i2p network, just with big delays, thus making it high latency.

Alright. You answered my question. (As an aside: it seems like recipients are more vulnerable than senders. A sender can start a message on its way into its outbound tunnels and then go offline. A recipient must stay online until the messages it requested are delivered through its inbound tunnels, so whichever Kademlia node is storing that recipient's messages will know when the recipient is online. Right?)

mixxy wrote:

If I share my private keys with other users, they can delete messages intended for me before I even read them.

This is obvious. That's why I said it would only make sense to do this within a small, trusted group. I thought you had a reason why it wouldn't work with a trusted group.

mixxy wrote:

Then maybe it could be of interest for you, as said the op. I don't know. Your decision - technical problems apart.

It IS of interest to me - IF it can be made to work, technically. Only technical issues matter. That's why I'm asking all these technical questions.

mixxy wrote:

The archive's address would have to be static, so it can be contacted. The clients would use dinamic ones. Create a dest, query for new messages, receive new messages, delete dest.

OK, that's possible. It's terrifically inefficient but possible. You can do it one of several ways:

a) Create email destination. Send index request to archive. Receive index. Request desired messages. Receive messages. Delete dest.

This requires two email round-trips, and means querying the email destination twice. The archive can learn a little bit about you from what messages you DON'T request (eg. you might have requested a message earlier, or you might have gotten it from a different archive, or you might have that identity banned). HTTP syndication works this way (though it relies on I2PTunnel to manage the destinations). The index is a complete list of identities and messages which the archive has available.

b) Create email destination. Send 'new message' request to archive. Receive messages. Delete dest.

This requires one email round-trip, and means querying the email destination once. If you do this, the archive will choose what messages are 'new'. You won't know what messages the archive might have that it didn't send you, and it might send you messages you don't want (eg. messages from identities you've banned). If the archive considers messages less than one week old to be new, then you'll get many duplicate messages if you do this procedure once per day.

c) Create email destination. Send 'all messages since timestamp X' request to archive. Receive messages. Delete dest.

This has many of the disadvantages of b) and gives away information about the last time you synchronized.

Whereas, if your client keeps using the same address, all you do is send one email to the archive requesting that from now on, it send you any messages it receives. It will never send you the same message twice, and if you want you can tell it what identities you've banned.

So. To do a meaningful comparison of the four strategies, I need to know how safe it is to:

1) create an email destination
2) delete an email destination
3) send messages
4) retrieve messages

and I need to know whether it's any riskier to retrieve messages more than once from the same email destination, than to only retrieve messages once.

I will read the i2pbote.i2p site and see if I can answer those questions myself.

mixxy wrote:

you can send messages without even giving any information about your ID.

Seriously? That seems like a monumentally bad idea to me. How are you going to deal with spammers and mail bombers? Aren't you just begging for someone to come along and make your fancy new email system completely unusable? (Don't try telling me spammers won't bother with an anonymous network. These networks attract troublemakers in droves.)

mixxy wrote:

They won't ever know my i2p destination if I chose only to syndicate [via i2p mail] - no chance for tagging attacks.

I said as much myself.

A Syndie 'community' (a group of archives containing mostly the same set of messages, and the clients that connect to them) depends on some clients or archives synchronizing across network boundaries. This is what allows a community to have archives running both on I2P and Tor, for example (otherwise it would be two communities, and Tor users couldn't communicate with I2P users and vice versa). So however this works, it MUST be no more dangerous to run a client that synchronizes with HTTP archives and i2p mail archives, than it is to run a client that only synchronizes with HTTP archives.

Guest

Posted: Thu Oct 22, 2009 12:30 pm

Anonymous wrote:

mixxy wrote:

Picture the whole system like i2p network, just with big delays, thus making it high latency.

No. The receiver can be offline while his inbound chain will fetch the message and forward it and last hop will retain it until receiver comes online or deadline is reached.
So the storing node cannot know when exactly the receiver is online.
Of course it can determine the week.

Anonymous wrote:

mixxy wrote:

If I share my private keys with other users, they can delete messages intended for me before I even read them.

This is obvious. That's why I said it would only make sense to do this within a small, trusted group. I thought you had a reason why it wouldn't work with a trusted group.

no, no additional reasons. I simply don't trust anybody. not even a trusted group.
at least not when they all have deleting rights.

Anonymous wrote:

mixxy wrote:

Then maybe it could be of interest for you, as said the op. I don't know. Your decision - technical problems apart.

It IS of interest to me - IF it can be made to work, technically. Only technical issues matter. That's why I'm asking all these technical questions.

Well, with technical I mean, the protocol. And what we are talking now, is what I refer to as conceptual.

Anonymous wrote:

mixxy wrote:

The archive's address would have to be static, so it can be contacted. The clients would use dinamic ones. Create a dest, query for new messages, receive new messages, delete dest.

Well, as long as it's the same you do with html, it's not more risky to do it here.

Anonymous wrote:

So. To do a meaningful comparison of the four strategies, I need to know how safe it is to:

1) create an email destination

How safe is it to create an i2p-dest?

Anonymous wrote:

2) delete an email destination

rm privkey.dat
of course, others can go on sending something to it, as they won't know that the address is no longer used. but they gain nothing with it.

Anonymous wrote:

3) send messages
4) retrieve messages

forge your own opinion

Anonymous wrote:

and I need to know whether it's any riskier to retrieve messages more than once from the same email destination, than to only retrieve messages once.

= retrieve syndie messages more than once with the same i2p-dest.

Anonymous wrote:

A Syndie 'community' (a group of archives containing mostly the same set of messages, and the clients that connect to them) depends on some clients or archives synchronizing across network boundaries. This is what allows a community to have archives running both on I2P and Tor, for example (otherwise it would be two communities, and Tor users couldn't communicate with I2P users and vice versa). So however this works, it MUST be no more dangerous to run a client that synchronizes with HTTP archives and i2p mail archives, than it is to run a client that only synchronizes with HTTP archives.

Don't know, see for yourself.

Guest

Posted: Thu Oct 22, 2009 3:33 pm

Anonymous wrote:

And the receiver will build inbound tunnels that include offline nodes?

Anonymous wrote:

I simply don't trust anybody. not even a trusted group.

You aren't a Syndie user. I have to consider the features Syndie users might want to use.

Anonymous wrote:

Well, as long as it's the same you do with html, it's not more risky to do it here.

If syndicating via i2p mail isn't any safer than syndicating via HTTP, this discussion is nothing but a huge waste of time. Don't you agree? If i2p mail claims to offer greatly improved security over I2P, it must be held to VERY high standards, and very closely scrutinized. Don't you agree?

Anonymous wrote:

and I need to know whether it's any riskier to retrieve messages more than once from the same email destination, than to only retrieve messages once.

= retrieve syndie messages more than once with the same i2p-dest.

No. Because at least one of the syndication strategies (strategy b) above) that uses single-use addresses still involves querying the email destination twice: once for the archive index and once for the messages. And if we take it as a given (just for the sake of argument, I know this won't be at all true in reality) that i2p mail is 100% secure for any operation, that strategy appears to be the most secure when we consider the way Syndie works.

Guest

Posted: Thu Oct 22, 2009 4:13 pm

Anonymous wrote:

And the receiver will build inbound tunnels that include offline nodes?

yes

Anonymous wrote:

sure.
As it's a system in development, and new systems usually have some shortcommings in the beginning, it would not be wise to consider it safe from the very beginning on - if it was implemented independantly on the internet.
But this is mitigated, IMHO, by the fact that i2p itself already grants a high degree of anonymity.
We only need to pay attention not to diminish it with any feature we introduce.
So if right now you use no static addresses in i2p, you would want to not use static addresses in the bote network either.
That's actually the only thingI see. Apart from that I don't see a way to decrease i2p's anonymity with that.
(Why am I talking of decreasing? Because if you want to improve, you first must make sure you don't improve on one side at the cost of lowering standards on another. What the benefit is (high-latency) we have already pointed out. So the only important point is to see that there are no negative implementations. The worst a tagging attack could do, is bring it back to standard i2p anonymity - and only in case you do multiple sync methods with the same client.)

If querying once for index and once for the messages is too unsafe, is decision of the app using the network. Or you just use the "get only new messages" option.
I have no opinion on that.

So if you see issues that could lead to lower bote's anonymity below that of standard, let us know!
I guess that as long as we don't send any system info (IP, router ident, time zone, language, ...) or static bote id with the peer/mail dest

Guest

Posted: Thu Oct 22, 2009 8:07 pm

I don't want to talk you into anything.
But you have to decide yourself:
either you want high latency
- then you can only
either fetch all messages the archive holds,
or fetch a subset of the messages which is compiled by the archive,
or you must contact the archive twice (or another source)
- once for fetching the index and then for fetching the individual messages;
or you don't want high latency.

re: tagged messages
wouldn't here p2p-syndication and content hashes be helpful?
A peer gets a tagged message from an archive, which hopes to gather information about when this user is online again by awaitung a relpy to the tagged message. Now another peer who got the tagged message by p2ps would reply thus destroying all the archive's hopes to identify the peer it had sent the message to.

mixxy

Guest

Posted: Thu Oct 22, 2009 8:15 pm

I think, the more different uses it gets, the more users it gets, the better it is, but, again, I know little about Syndie's working .
Don't wanna canvince you to use it or not to use it, I just answered to op's question and yours to the best of my knowledge.
you see, if you can / want to use it or not.

but in case you do want to use it, please consult HungryHobo first, as he is the project's dev and he will know if the system can handle it or not.

to op:
anyways, all we are talking in here is highly speculative, as the distributed mail system I2P-Bote has not yet come into being.
So maybe spare your efforts for the time when a first release is there and all can see what it is and how it performs, check the documentation and the source code.

Thx.

Cheers!
mxy

Guest

Posted: Fri Oct 23, 2009 3:04 am

Anonymous wrote:

We only need to pay attention not to diminish [I2P's anonymity] with any feature we introduce.

I disagree very strongly with this statement. Adding a large amount of extra complexity and indirection for no net gain in anonymity is not acceptable. Software developers know from experience and from research that the more code you have, the more bugs you have. In this kind of software, bugs sometimes mean things don't work, and sometimes mean that people who thought they were anonymous are not.

I don't want to argue with you. I'll wait and see what happens with i2p mail's development before I decide what to do.

mixxy

Posted: Fri Oct 23, 2009 7:40 am

I2Phile

Joined: 17 Sep 2009
Posts: 415

Anonymous wrote:

We only need to pay attention not to diminish [I2P's anonymity] with any feature we introduce.

you got me wrong.
Of course, it is important to provide extra anonymity - otherwise there would be no justification for adding this complex structure.
But the logic is:
only the above condition must be met, and the system automatically provides more anonymity, as i2p is low latency.
But I've explained that already, so I'm not reiterating it here.
m

Display posts from previous:

All times are GMT

View next topic View previous topic	Page 2 of 2 Goto page Previous 1, 2
forum.i2p Forum Index -> Syndie

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