handle
-
Posts
46 -
Joined
-
Last visited
-
Days Won
2
Posts posted by handle
-
-
If the option is to use GPG/PGP, or some form of encrypted chat to send the keys to be shared, wouldn't / shouldn't I just use GPG to encrypt the file im trying to share anyways, at which point i could use any syncing / sharing service.
To sync with someone else requires that you share your key, and if you cant share that key securely .. then you can't sync securely.
To say sharing your key is outside of Bt Syncs scope is to say that sharing your key so that you can Sync securely it outside of BT's scope and defeats it purpose.
You can make the exact same argument 20 more times but it's not going to make it any more correct.
-
It will act almost exactly the same as uTorrent would with a torrent. Tough to say if uTorrent compensates for slow connections, however you should be able to set your max bandwidth.
-
Seems cool, but bittorrent sync already uses /dev/random (or /dev/urandom, but that's also very secure) to generate secrets and so I don't really see a use for this
-
It will work, but you'll be wasting your bandwidth. It should work, but your sync client will have to download changes every time you restart your computer.
-
Can a mod or administrator please close this topic? I've found all of the information I wanted.
-
there is a million and one ways the key could be obtained prior to me being able to "write it down" (which is very inconvenient) and there is no way for me to confirm that this doesn't occur without the source being open.
In which case you are diverging off of the original argument and moving the goal fields. This was never about keys being obtained prior to you writing it down. It was about how to securely share keys.
And I still stand by my opinion that it's really not Bittorrent Sync's problem. Stop using insecure email and IM altogether and you'll have no problems.
-
Hi there,
I was wondering whether this was a bug or if it was as designed.
I got one computer that is sharing files (117gb) and two read only computers. When the main computer is offline the other two stop syncing between them completely, one of them has gotten a lot further ahead in syncing than the other one so I would have thought the one behind would catch up while the main computer is offline.
However I could understand there might be some complications regarding authority, as in those two read only computers cant tell the other one that they should sync according to them because they are both just read-only.
So like I said, is it a bug or by design?
Regards,
Gilli
It is a possibility. What happens (as far as I understand) is RW nodes send out "modification requests" to RO nodes. These requests are "signed" in a way that only RW nodes can sign them, and RO nodes can verify that these signatures are legitimate but cannot create the signatures themselves.
Now, there are two possibilities beyond this that a dev would have to verify for me. If an RO node actually stores these modification requests with signatures, they can then pass them on to other RO nodes. If these requests are not stored however, they cannot tell other RO nodes to modify anything, and so they cannot propogate changes to other RO nodes.
-
We do use AES-128 in 1.1.x. Protocol has changed since version 1.0.x. AES-256 was removed from user guide PDF, but not from Technology section on site. We will update site shortly. You may find a lot of discussions AES-128 vs. AES-256 in Internet (including related keys attack). We believe AES-128 is not weak at all and it's a good choice for session encryption today. Also it's ~30-40% faster, which is critical for low end CPUs and mobile devices.
Thank you very much for your response. I am happy to see that SRP is used for authentication and Ed25519 for the protection of data in the situation of read-only keys. I feel much more confident using this tool, and await the protocol spec (and even more so, I await the release of the source code (hopefully))
Cheers
-
Thank you, thats indeed what I think of.
No it isn't. Your entire argument is a red herring, and "truthfulness" is not "using a different cipher than is said".
Luckily it appears to have just been a documentation mistake, and there is a valid reason (faster encryption for mobile devices), however your argument really does not fit into any of this.
-
Potentially means nothing to me. Prove beyond a reasonable doubt that they are using 128-bit AES instead of 256-bit AES and I'll demand an explanation -- not before. Since you're not a first hand programmer, and are not fluent in the way that the application was designed, or released, I'm more inclined to believe the original statements of 256-bit AES in lieu of 128-bit AES; as that's what I've been told and have not been told otherwise since.
Secondly, any cypher mode could potentially, in the eyes of the programmers, put the entire protocol at risk if released. Although it does look suspicious I won't immediately rebuke their decision to keep such information away from public view.
I posted proof... twice. If you actually read through the original post instead of stopping at the word "potentially" (and basing your entire argument on that) then you would have seen the screenshot I posted two times that gave me reason to believe that 128-bit AES was being used.
Also it's cipher, not cypher. Cypher is a Matrix character.
Your entire second argument is moot, as that is considered "security through obscurity", and arguably weakens the security of any system. Cryptography is based on the ability to open your algorithms to scrutiny from the world and still have it strong. The only thing that should ever be kept secret are keys used in a cryptosystem.
-
Basically.
There are plenty of secure means of transmission out there, just use those to transfer passwords.
The actual app security is just fine. What you're asking for falls outside the scope of the app security.
Edit: If you really wanted to, you could save the secret key to a text file, compress and encrypt it, email the encrypted file and SMS the recipient the key to decrypt the text file.
Or just use single-use keys.
Exactly.
Not to mention that you could easily just share a key by writing it down on a piece of paper, then it's completely off any network.
-
thats like saying linksys, belkin, or asus only has to develop a router to transfer your data, not secure it by using some fancy wpa2 encryption.
do they need to develop new ways to communicate securely? No, but they could.
should they implement already existing features to secure your data and the applications reputation? of course they should.
This application is built around one single premise, sharing your key. Your advocating that the most important aspect of this application is not the burden of the application and protocol developers?
I'd argue that the router analogy is invalid. That would be more accurate if BTSync sent data unencrypted, but it does not. In fact, WPA2 works in arguably the same way as BTSync in this case - they both use pre-shared keys. You know, the part where you have to enter the wifi password to gain access to the router's network? And then at that point the communications are encrypted? Yeah.
Also, the application is not built around sharing your key. There are other applications that are. BTSync is built around sharing your DATA with a pre-shared key.
-
it becomes the burden of the application to offer ways to share that key securely.
No, it really doesn't.
Let the developers concentrate on building a secure syncing solution - use secure key transfer solutions to securely transfer keys. If they build that into bittorrent sync, that's great, but it's in no way their burden.
-
Also, is there a reason you aren't using CryptoAPI's CTR mode and instead using a (what I assume is) homebrewed CTR mode?
-
It is not. Read those ToU again. It is a violation to reverse engineer the binary code of btsync, but not a violation to reverse engineer the protocol used by the program. There is a difference.
Allow the question: Why are you (greatmarko) so upset about this? Obviously, you're not with BitTorrent or a developer of btsync. Why the zealotry that the btsync developers didn't even ask for?
In order to learn the protocol, either the binary has to be reverse engineered, or one must be very lucky at guesses. I think he meant Bittorrent Sync as in the binary program. Though I might be wrong.
As for the second paragraph, he doesn't seem upset - it sounds like more of a friendly warning than a "Silence, naysayers" sort of deal. Though I might be wrong on this as well.
-
Also in my opinion, you could leave the choice to the user.
Those who wish may decide to enter a password to encrypt the departure of btsync (client side) their secret keys.
The same password can be requested at the time of display of the keys in the GUI.
So, in windows, there is the possibility to set a config file to change the directory location .sync?
Francesco
Indeed, hence why I said "allow". The "require" is only if they chose to do so.
It is possible to change the directory location with a tool called mklink, however it won't accomplish much because it'll still be on your drive, and whether the path is in the symlink or the config, it'll still be easy to find.
-
I use only linux, and the problem I see much less noticeable!
As you said, I can run with a user btsync ad hoc and block the permissions so much stronger than you could do a "simple" windows user.
Maybe you did not understand: I really like the idea of secret keys!
But I think it is much harder to find a decryption key in the process memory rather than reading the key in a file, especially if the majority of people who use windows put the keys in the same position!
By the way, you can change the directory location .sync as in linux?
Thanks,
Francesco
That's fair enough. You should be able to use a symlink (junction in windows) to change the directory location, however that would not accomplish anything in this case. The best way to solve this would be to allow someone to encrypt their secret with a password, and require that password to be entered on startup.
-
Please note, that attempting to "reverse engineer" BitTorrent Sync violates the current Terms of Use
This is true, however when people do this to expose good security being used, it helps the product because more security-conscious people are likely to use it, and to spread it around as a good thing. Because of this, I do not believe this portion of the Terms of Use is being actively enforced, and for good reason.
I'm waiting for answers from a developer in a different thread, however I really do want to use Bittorrent Sync, as do many other people. Due to the lack of protocol information or source code, security-conscious people have to either wait for developers (who are most likely very busy) to answer questions about how the system works, or it can be partially reverse engineered to explain better how the internals work.
As one of the developers have stated that they do not abide by Security through Obscurity, I see no problem with this when done reasonably. Using it to explain the security of a program is perfectly reasonable.
-
No, there is no IRC channel. The developers frequent this forum, so all comments/feedback/suggestions etc should be posted here and they will be seen by the developers
Fair enough, thanks.
-
Hi all of you,
first of all thank you for all the responses so far (especially for the ones
)When I posted that message I already suspected that some of you might not be all that happy about what I am doing...
I've been thinking a lot about it, but I think I've done the right thing.
And what I've done so far was basically a mix of thinking how I'd do it myself, running tcpdump+writing a script that
makes it easier to see patterns in the transmitted packets and a little research in "[uses] bittorrent technology",
so it hasn't been that difficult (and would've been done anyway sooner or later).
I am in no way trying to pose a threat to btsync. It's in my best interest that it'll be as successful as it can be,
because I am (as most of you I suppose) part of the minority of cloud storage users that really are concerned about
having their private data stored unencrypted in some data center (we've all heard the PRISM discussions lately, so I'll
skip that here).
But as I said, I think we (the security-concerned users) only make a small percentage of cloud storage users. So for
btsync to gain real momentum, it has to be rock solid. They say they use secure AES-based encryption (which I believe
is correct but I (and I'm sure many others) would prefer to have actual proof.
The other killer feature of btsync - the (virtually) unlimited storage - comes with a downside though: It's only
interesting for people having their own server or at least NAS with 24/7 uptime.
There already were proposals in the forum for an additional secret that'll only gain you encrypted access to the share.
That was also one of my first thoughts after learning about btsync as it will allow us to get rid of the one downside
and allow btsync-providers that can't access our data. Those could also implement daily off-site backups of your
encrypted data - which will be a very interesting feature for small and middle-sized businesses (which in turn will increase
btsync's market share).
I do want btsync to get as successful as possible (as I don't want to fall back to dropbox and the like when it comes
to sharing data with people that simply don't have it) so market share is important (and the market's already close to
being saturated if you ask me)
As to your statements that it doesn't make sense to analyze a protocol that's not yet stable I can say that I think (like @cdata, ...)
you can't start too early for several reasons. The first one is that one of my aims is simply to prove (or disprove)
make sure the used encryption really is secure (All the threads @GreatMarko linked to are either about implementation bugs
or "how-secure-is-the-secret". That's one part of the question, but I'm more interested in things like: which AES-Mode is
used, does it encrypt everything or just the files, etc.).
The other reason is that I look at BitTorrent itself and the huge ecosystem of apps and services that grew around it.
I'd like something like that for btsync too. I also see other services built based on the same technology (e.g. think of
having a remote desktop app that uses btsync technology (not the file sharing, but the discovery and transport layers)).
To sum it up, I'd love to see other developers using that technology for whatever reason in their apps (there's just so
much potential in the technology).
To the API:
Yes, I've read the announcements of an API, but as @rippelhans answered to the post @GreatMarko linked above, it kind of
pokes a hole into the whole noone-else-has-access-to-your-data argument. Yeah, they could write an API-Software that's
self-hosted or runs on the client but then you're back at needing a server.
Ok, that about sums up what I wanted to say. Sorry that it's quite a lot to read (and sorry if some parts may be hard to read, I'm not
a native speaker).
Anyway, please ask if anything's unclear or I left questions unanswered. (And help is very much welcome
)Thank you for reverse engineering the protocol some. Would you be able to divulge and/or explain some more information?
If you are still persuing this, keep up the good work!
-
Hello,
Is there an IRC channel for discussing Bittorrent Sync, potentially with developers? Such as #BittorrentSync on freenode or anything?
Thanks
-
Hmmm... so which is safer? A secret in someone's head, or a password stored on a remote 3rd party server!!? ...I think the former! If you were to go down the username/email and password route, these details would need to be stored on a server somewhere - this is FAR less secure than the current method of "secrets"!
First off, the secret is on disk and not necessarily in one's head. Secondly, a password would not be stored in plain text on a remote third party server - it would most likely be hashed, or hopefully stretched (think PBKDF2). Extra points if the hashing or stretching is done client-side.
The problem that comes from using a centralized server to authenticate is that you effectively give that server authority, meaning they can authenticate themselves and access all of your information. It also becomes a central point of failure - if this were the way things worked and Bittorrent Inc. decided to close their doors, Bittorrent Sync would stop working completely. The way they actually work right now (which in my opinion is the right way), is that even if the company shut down, the current version of Sync would still work without problems.
-
Oh, this is named SSH, isn't it ?
A fingerprint may be provided by the host, maybe… It may be a nice feature, but as you pointed out, it will be a hasle to validate them while having more than 6 devices…
SSH is not comparable to bittorrent sync. SSH usually has multiple clients connecting to a single server. Each client verifies that the server has the correct key, and the server authenticates the client via a password so no key verification is needed on that side. So if you have one server and 6 clients, you verify 6 times. If you add one more client, you verify one more time, if you add another client on top of that, you only verify once again, etc.
With BTSync, on the other hand, every peer connects to every other peer. That means if you have 6 nodes, you verify 6 times. If you add one more node, you verify 7 more times. If you add one more node, you verify 8 more times, etc.
-
A secure method to share keys is needed, is the point.
I disagree, as this is a problem that has been solved numerous times over. Not to mention that using a one-time key is an additional solution over all of the other solutions already out there.
)
Your secret key and PRISM
in Sync General Discussion
Posted
This however, is a good idea.