jtroth
-
Posts
14 -
Joined
-
Last visited
Posts posted by jtroth
-
-
Super cool, and really want to try it out. Unfortunately, can't get it working. I run python syncnet.py and the GUI comes up; I'm assuming I have the enaml dependency resolved correctly. I have python-btsync, wasn't sure where syncnet needs this so I just symlinked it into the same directory as syncnet.py. I have btsync running with default un/pass/port and have included my api key into the config.json file (does this need to run in the same directory as syncnet?). Btsync is running and the api works as expected.
When I enter "sync://B4KWMK3VBJSH35YZMS7ZEMSQ6XNVBHALY", nothing happens, and I don't see anything in stdout. Any ideas as to what I could be doing wrong? I'm on 64 bit linux if that helps.
-
To encrypt a string on a linux box:
echo '$BTSYNC_SECRET' | openssl enc -base64 -e -aes-256-cbc -nosalt -pass pass:correct_horse_battery_staple
This generates the string "dSsDqj3ilLCNosmWNYpbzA==". You can send this, in the clear, to your friend.
Your friend will then enter:
echo "dSsDqj3ilLCNosmWNYpbzA==" | openssl enc -base64 -d -aes-256-cbc -nosalt -pass pass:correct_horse_battery_staple
Then just tell them the password through some other channel.
Sometimes if I'm lazy, I'll just put the key in a password protected pdf/rar/word doc and attach it to an email.
-
I've made some improvements to this, and have added a more feature rich file manager. My favorite feature is that you can now edit and save text files from the web if you've entered a full-access key. File creation/uploading will probably come in the next few days.
Demo:
https://www.btcloudsync.com/a-mixed-bag
-
@deadserious
What functionality do you need? If you're looking to create/remove shared folders, the linux client exposes a REST api that can work in a pinch.
@ctismer
You're right. The BT team is probably the best in the world at solving the NAT traversal problem, but it simply does not yet have the reliability of dropbox (and reliability is usually the most important factor in transferring high value data). In my experience, LAN sync works well, and sync with publicly accessible nodes works well.....but when you have nodes behind several layers of NAT, QoS starts degrading quickly. Such is the nature of p2p technology.
-
If you figure out any other leakage, I do want to get it bottled up.
This runs on BitTorrent, so the tracker (or DHT) gives a list of every host sharing a given folder. If you want to know which hosts are communicating with Alice, just ping the tracker with Alice's invite secret every second. This gives a list of every host initiating a conversation with Alice; you can then do reverse lookups on these hosts to find the initiating accounts (reverse lookups might be tough if it's difficult to enumerate all nonsa namespaces). Perhaps this is acceptable for your requirements.....I don't know your threat model.
The hash of the id however causes any messages a spammer might send from validating the signature unless they also know the real id.
Can you elaborate on how this works? I don't really understand what the hashed ID is good for aside from a way to link a writeable invite key to an account. After that, is it ever used again?
From the spec:
Bill creates an invite.json file announcing who the message is from and the BTSync key for the conversation and signing that data with Bill’s private key.
Bill compresses invite.json file to invite.gz and encrypts to invite.gz.enc using Ted’s public key as found in the newly synced settings.json file.
Bill hashes the contents of invite.gz and renames invite.gz.enc to {hash}.gz.enc and places it in Ted’s invite folder for syncing.
Ted receives a new {hash}.invite.gz.enc file in his invite sync folder.
Ted validates the hash, decrypts, decompresses and validates the signature.
How does Ted validate the signature if he does not yet have Bill's public key? Does he do the nonsa DNS lookup, sync the namespace file, and get Bill's pub key that way?
EDIT: Ummm....how do you quote text?
-
I like this idea. Few questions/clarifications.
Is this intended to hide "metadata"? Could an omniscient adversary determine which users are messaging each other? If nonsa is truly private, it would be substantially better than PGP and significantly more scalable than BitMessage (it might provide some strong defenses against spam as well). Is 'private metadata' a requirement with which you designed the platform?
If you're hashing the user id, any reason why you aren't also hashing the writeable invite key as well? When it's hashed, spammers can't just send messages to every account in the namespace file.....they need to know a specific destination account (just like email).
You mention using symmetric crypto with AES in the 'assumptions' section, but only refer to asymetric crypto in the rest of the document. Are you using PGP for all message communication? S/MIME?
Is there a mechanism for re-initiating a conversation? Say one party loses their conversation secrets; can the other party determine whether a new invitation needs to be sent? Perhaps the conversations should have short time limits.
In any event....I'd definitely like to play around with this. Shoot me an invite:
joe@nonsa.btcloudsync.com
Also, I saw that you changed from ECC to RSA; did you make the switch for ease of development? I recently worked with ECC and was surprised how hard it was to find good tools and documentation......hope it catches up soon.
-
I've seen some people set their btsync device name as their vol folder secret. So, let's say we're both friends with Dimtar, you could see my vol secret as a shared node with Dimtar's folder. A clever, decentralized way of seeing "friends of friends."
-
What measures are in place to protect any random person from stumbling onto my shared folder? Is it possible for these addresses to be scraped by a bot/crawler? Is there a robust mechanism in place to prevent directory listings.
Yes, I have designed the site to prevent enumeration of shared secrets and the shares' 'nicknames.' This is done with OS level permissions. I've tried to keep things as simple as possible; there is no database so no vector for sql injection. Both the BTSync process (which owns everyone's files) and the web server are given very limited access, so even if someone could get code from their shares to execute on the server, they wouldn't be able to do much (and I've also protected against remote code execution). The weak link is the BTSync process......but these guys seem like they know their stuff and I'm not too worried.
Have you thought about creating a folder name and password which can be used to access the folder - the idea being that a shorter password is easier to remember than typing in the long shared secret?
I've thought about it, but it's tough to implement without a database. Databases add complexity and another attack vector, but it's something that I'll consider for the future. Thanks for the input.
Good work. Are you planning to commercialise / open source / keep it to yourself ? (Edit: hint: I'd love to run my own instance of this on my VPS!)
I was actually thinking of releasing a docker image; it will give me a good excuse to play around with docker
But yea, I'll put the source out there one of these days if you're interested.How long do you plan to keep the contents of a removed shared folder before you consider it abandonned?
Until I run out of disk space.
I don't know, I'll have to make a policy decision before this becomes an issue, but it's luckily not an issue now. I have a cron job that auto removes egregious disk hogs, but that's the extent of it right now. I'll be putting a 'remove' button on the directory list page sometime this week.Glad you can get some use out of the site.
-
BTSync is a really high quality product and I thoroughly enjoy using it. You guys are great; thanks for all your work.
Over the past couple weekends, I've put together a site that gives me public access to my sync folders. Did this for a couple reasons.....
1. My computers are seldom on at the same time (when I go to work, my laptop goes to sleep, when I come back home, my work computer gets disconnected from the internet, phone has limited space), and I needed an 'always online' node.
2. I wanted read/write access to my shares without having to sync on the local device.
3. I'd like to start experimenting with some RSS type feature (subscribe to feeds with shares).....needed a testing playground and this had some overlap.
I'm waiting with bated breath for encrypted nodes so I can approach these requirements from a TNO perspective.....but looks like we're a few weeks away from that happening. In the meantime.....feel free to use this if it suits your needs.
But yea, I'll put the source out there one of these days if you're interested.
I don't know, I'll have to make a policy decision before this becomes an issue, but it's luckily not an issue now. I have a cron job that auto removes egregious disk hogs, but that's the extent of it right now. I'll be putting a 'remove' button on the directory list page sometime this week.
Encrypt Files Using Viivo Before Syncing
in Sync Stories
Posted
You could use the encrypted backup key for this. It saves btsync'd files in encrypted format on target machines, Search around the forums for instructions on how to use it.