Topic: [BETA] tor sshfs, a secure filesystem on the tor network. (Read 2184 times)

The solution is to have i2p eepsite gateways.

Having a server that runs i2p, and then forwards traffic for several eepsites over a vpn. When the eepsites  themselves go down, no big deal.

Having more than one gateway for all those eepsites (more than one machine with the same private keys) would provide redundancy.

Start doing this on a large scale, lots of...eepsite clusters behind a gateway and you've a weener.

I hope you have 100% up time if you run I2P, because if the server ever goes down it is as good as traced. All I2P nodes act as relays for other nodes, and although there are more I2P relays than Tor (~5,000 I2P - 2,000 Tor) there still are not many. So it is not hard for a single attacker to find every single I2P nodes I2P address. And monitor up time of the relay versus up time of the hidden service. If both go down at the same time, then the hidden service (Eepsite actually) is determined. This is called an intersection attack and I2P is terribly weak to it. They tried to solve the issue with multi-homing but it actually doesn't help at all because tunnels rotate every ten minutes usually, but multihomed Eepsites use different tunnels, so you can just look for tunnel change outside of ten minutes with malicious final node in your chain, and if it changes in less than ten minutes in the same time period a node went down you can assume that node is one of the homes of the Eepsite.

Tor hidden services are not nearly as weak to this attack, because they are not usually run as relay. Tor hidden services are weak for their own reasons though, mostly because it is very easy to find their entry guards. And after you find their entry guards you are only one hop away from the hidden service. A hidden service on Tor opens a new circuit for every rendezvous point a client asks it to connect to. So if a client adds some bad nodes to the network, they can then force the hidden service to open like two thousand circuits and send it a stream modulated in a certain pattern. Then looking for this pattern in their flooded nodes, will quickly identify three entry guards the hidden service always enters through. Now they are one hop from the hidden service, and have various ways they can attempt to compromise the entry guards or hidden service from this positioning.

I would suggest Freenet in darknet mode for a content store. But even Freenet is not that hot, the biggest issue being that content is not encrypted in layers but rather a message is encrypted one single time and then travels through series of encrypted tunnels. This is bad if the encrypted data is known by many people, but if you are storing unique content that only you access it is not as much of a risk.

see: http://www.i2p2.de/how_networkcomparisons
it says tor has:

• Has already solved some scaling issues I2P has yet to address
• Tor client nodes have very low bandwidth overhead
• A core of high capacity nodes provides higher throughput and lower latency

but also things i2p it better to do:

• Fully distributed and self organizing
• Designed and optimized for hidden services, which are much faster than in Tor  <-- i know
• Both TCP and UDP transports

i knew this already.
and i have read the source codes for bout tor and i2p.
tor is clean and simple and very eazy to understand, and well documented.
while i2p is bloated, and is difficult to understand.


i am not, go read the source and you will find out. the way i2p is using the keys is weird.

Tor is horrible for transferring files for three reasons-
1. IT WAS NOT DESIGNED FOR IT. Read the documentation, it's designed for web browsing. By transferring large amounts of files you ARE killing the network.
2. Less relays compared to I2P - therefore, less bandwidth. I2P is essentially already p2p, so using bittorrent inside i2p works fine. P2P inside tor is painfully slow, and not even allowed by most exit nodes.
3. Know how onion routing works? Yeah.

Comparing security by looking at hostnames of services used within the network is about as silly as you can get. The 16-digit .onion address is a /summary/ of the hidden service's public key.

no they are about the same.
only that i2p's encryption is more obscure. and obscureiry only leads to holes and flaws. http://en.wikipedia.org/wiki/Security_through_obscurity

tor's code is clean and simple. i2p is obscure and diffecult to understand.

From what I understand, using another layer of encryption (ssh) over the tor network is redundant since it is already secure.
You think tor is the same as I2P? Well, from my personal experience I2P is much better at transferring big files. 99% of the I2P traffic must be torrents using the i2psnark implementation of torrents on the I2P network.
I don't know how strong tor's encryption is compared to what you get with ssh, but I'm quite sure that if you use I2P there is no need for extra encryption. You might as well use ftp instead of sftp.
There is also no need for special authentication of the server. That is also guaranteed by the tor or i2p addresses which are cryptographic signatures.
On tor, addresses look like kpvz7ki2v5agwt35.onion
On i2p, addresses look like
I2P's encryption is probably much better.

tor and i2p is working like the same as far as i can understand, except tor is stream based and i2p is packet based. they both use onion or garlic routing, so it would kill then both if you are using some high bandwide app.

and the point is that no one knows where the datastore is(except me), and no one can see that you are using the datastore, so your data is stored absolutly secretly.

I just think that unless you don't want to know where your datastore is(because you don't want anyone else to know either) you're better off having a vpn connection between you and your datastore.

However, if it IS the case that you want your datastore so untraceable that even you don't know where it is, then yeah I guess, I still think i2p is better for this kind of thing, I remember they were working on getting Tahoe running over i2p.

it's not going to kill tor. if its are going to, i will set a bandwide limiter up, but i don't think it will.

this is going to kill tor, thats not what it's for, use i2p for higher bandwidth needs.

HI! im am needing bata testers for a filesystem in the tor network.
it will be using sftp, so its mountable with sshfs

just to try the idea out... so if you want to try it PM me, i will need a username and password, you want to use with the service.
i will take 0.1btc for a month.

of course i will in the future make a gui interface for signing up(and maybe to access the files).
but right now my concern is how it will work, or if there are any intrested.

i only have 40gb of space so don't upload big files.