Bitcoin Forum
May 09, 2024, 09:06:13 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: [BETA] tor sshfs, a secure filesystem on the tor network.  (Read 2184 times)
kokjo (OP)
Legendary
*
Offline Offline

Activity: 1050
Merit: 1000

You are WRONG!


View Profile
May 04, 2011, 07:07:38 PM
 #1

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

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.

"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell
1715245573
Hero Member
*
Offline Offline

Posts: 1715245573

View Profile Personal Message (Offline)

Ignore
1715245573
Reply with quote  #2

1715245573
Report to moderator
1715245573
Hero Member
*
Offline Offline

Posts: 1715245573

View Profile Personal Message (Offline)

Ignore
1715245573
Reply with quote  #2

1715245573
Report to moderator
TalkImg was created especially for hosting images on bitcointalk.org: try it next time you want to post an image
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
Nefario
Hero Member
*****
Offline Offline

Activity: 602
Merit: 512


GLBSE Support support@glbse.com


View Profile WWW
May 04, 2011, 07:11:43 PM
 #2

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

PGP key id at pgp.mit.edu 0xA68F4B7C

To get help and support for GLBSE please email support@glbse.com
kokjo (OP)
Legendary
*
Offline Offline

Activity: 1050
Merit: 1000

You are WRONG!


View Profile
May 04, 2011, 07:34:42 PM
 #3

this is going to kill tor, thats not what it's for, use i2p for higher bandwidth needs.
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.

"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell
Nefario
Hero Member
*****
Offline Offline

Activity: 602
Merit: 512


GLBSE Support support@glbse.com


View Profile WWW
May 05, 2011, 03:41:20 AM
 #4

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.

PGP key id at pgp.mit.edu 0xA68F4B7C

To get help and support for GLBSE please email support@glbse.com
kokjo (OP)
Legendary
*
Offline Offline

Activity: 1050
Merit: 1000

You are WRONG!


View Profile
May 05, 2011, 06:30:16 AM
 #5

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.
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.

"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell
wolciph
Newbie
*
Offline Offline

Activity: 33
Merit: 0


View Profile
May 13, 2011, 12:35:26 PM
 #6

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
Code:
lnQ6yoBTxQuQU8EQ1FlF395ITIQF-HGJxUeFvzETLFnoczNjQvKDbtSB7aHhn853zjVXrJBgwlB9sO57KakBDaJ50lUZgVPhjlI19TgJ-CxyHhHSCeKx5JzURdEW-ucdONMynr-b2zwhsx8VQCJwCEkARvt21YkOyQDaB9IdV8aTAmP~PUJQxRwceaTMn96FcVenwdXqleE16fI8CVFOV18jbJKrhTOYpTtcZKV4l1wNYBDwKgwPx5c0kcrRzFyw5~bjuAKO~GJ5dR7BQsL7AwBoQUS4k1lwoYrG1kOIBeDD3XF8BWb6K3GOOoyjc1umYKpur3G~FxBuqtHAsDRICkEbKUqJ9mPYQlTSujhNxiRIW-oLwMtvayCFci99oX8MvazPS7~97x0Gsm-onEK1Td9nBdmq30OqDxpRtXBimbzkLbR1IKObbg9HvrKs3L-kSyGwTUmHG9rSQSoZEvFMA-S0EXO~o4g21q1oikmxPMhkeVwQ2VHB0-LZJfmLr4SAAAA

I2P's encryption is probably much better.
kokjo (OP)
Legendary
*
Offline Offline

Activity: 1050
Merit: 1000

You are WRONG!


View Profile
May 13, 2011, 12:55:29 PM
 #7

From what I understand, using another layer of encryption (ssh) over the tor network is redundant since it is already secure.

I2P's encryption is probably much better.

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.

"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell
TehZomB
Sr. Member
****
Offline Offline

Activity: 294
Merit: 250



View Profile
May 14, 2011, 02:33:10 AM
 #8

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.

Quote
On tor, addresses look like kpvz7ki2v5agwt35.onion
On i2p, addresses look like<snip>

I2P's encryption is probably much better.
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.
kokjo (OP)
Legendary
*
Offline Offline

Activity: 1050
Merit: 1000

You are WRONG!


View Profile
May 14, 2011, 09:01:35 AM
 #9

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.

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.

Quote
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.

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

"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell
jrigjeij
Newbie
*
Offline Offline

Activity: 1
Merit: 0


View Profile
May 14, 2011, 09:01:37 PM
 #10

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.

Nefario
Hero Member
*****
Offline Offline

Activity: 602
Merit: 512


GLBSE Support support@glbse.com


View Profile WWW
May 15, 2011, 02:49:14 PM
 #11

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.



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.

PGP key id at pgp.mit.edu 0xA68F4B7C

To get help and support for GLBSE please email support@glbse.com
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!