Your secret key and PRISM


Recommended Posts

I simply want to purpose the discussion around the recent revelations of NSA spying techniques, and how this effects the security of our sacred "Secret Key".

assuming the keys are shared via unencrypted email, skype, facebook, aol, yahoo, etc etc .... then our keys are no longer really "Secret" to say the least. This doesn't even begin to cover malware, keyloggers, etc.

This leaves our data at the hands of the government, their contractors, and anyone who obtains this information (attackers) ......

Now that Sync is in beta, is it to late?

Link to comment
Share on other sites

it's very simple: you don't share secret keys via unsecured channels. ;) also, you can replace your secret keys anytime if you shared them unsecurely in the past.

the real question is whether btsync is going to be open sourced or not. but that was questioned 100x times at other threads, still no final decision.

Link to comment
Share on other sites

assuming the keys are shared via unencrypted email, skype, facebook, aol, yahoo, etc etc .... then our keys are no longer really "Secret" to say the least. This doesn't even begin to cover malware, keyloggers, etc.

In other news, accessing hotmail in a Chinese internet cafe is also a bad idea. As is giving your banking details to a Nigerian prince.

Link to comment
Share on other sites

the real question is whether btsync is going to be open sourced or not. but that was questioned 100x times at other threads, still no final decision.

I don't see how that's relevant in any way to the topic of this particular thread?! The OP was concerned about the possibility of government agencies obtaining "secrets" that were shared through email/IM/social media... this has no bearing on whether Sync is open source or closed source!

Link to comment
Share on other sites

I'm using GPG in order to crypt my mails - easy, fast, works on any computer and android phone ;). Provide a good way to transfert such sensible data.

Regarding Torxic-hero concern: for now, we can just trust Bittorrent there is no "master key" being able to decrypt all contents… That's why opensourcing the code would be a great move from their part.

PRISM and other stuff like that (go back in time - Echelon ;) ) just show more than once we cannot really trust closed application…

More over, opensourcing stuff may provide some great improvement if the community may provide patches to the code, more application, more apps, more security, more… just MOAR :)

Cheers,

C.

Link to comment
Share on other sites

The immediate solution is for users to only share keys via trusted channels, PGP encrypted email, possibly Heml.is, OTR, etc ...

but one has to ask oneself. When building the platform for BT sync, since we are only using one key here and your data is only as safe as the weakest link why wasn't some secure method created to share the keys in the first place?

PGP and GPG encryption for email communications is great, if you know how to use it and can discipline yourself to use it each and every time.

forget mining secret keys .... an attacker could setup an ssl strip MITN and collect secret keys shared via insecure communication channels.

Link to comment
Share on other sites

There is already a solution to this: one-time keys. You send a one-time key over unencrypted email, and provided you set up your copy of bittorrent sync with that one-time key before someone else does, the problem is solved. If someone reads your email afterwards and sees a one-time key, if they use it they will get nowhere because it has already been used.

SSL Strip does not work here because not only is SSL not being used, but no keys are being shared and so MITM is impossible and useless unless the attacker already has the key.

Link to comment
Share on other sites

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.

+1

This is a user problem, not btsync… *user* is responsible for his own security, as well as his devices security. If he wants to share keys between devices, there are a fair number of existing solutions… GPG is the one I'm using, as I, by default, use it on all my devices, but there are others… why not use SCP in order to push the configuration to some other hosts ? Or even webdav over SSL with some strong password (and, of course, SSL for the server) ?

BTSync is one piece of the puzzle - it's working, provides nice features - the rest of the puzzle should be solved by the users.

Some howto may be more intersting as "implementing some new stuff which will create more problems than solve" like a "secure way to exchange keys"…

Link to comment
Share on other sites

when you are required to share your key to sync data, it becomes the burden of the application to offer ways to share that key securely. This is undoubtedly the weakest link.

one time keys are not suitable for all syncing needs

I disagree, as this is a problem that has been solved numerous times over.

solved, yet not implemented in this application.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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?

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Your exactly right, and it's already happening.

In a statement, Microsoft said: "When we upgrade or update products we aren't absolved from the need to comply with existing or future lawful demands.

IE: backdoors to your data

http://www.guardian....ation-user-data

Microsoft has collaborated closely with US intelligence services to allow users' communications to be intercepted, including helping the National Security Agency to circumvent the company's own encryption, according to top-secret documents obtained by the Guardian. The documents show that:

• Microsoft helped the NSA to circumvent its encryption to address concerns that the agency would be unable to intercept web chats on the new Outlook.com portal;

• The agency already had pre-encryption stage access to email on Outlook.com, including Hotmail;

Link to comment
Share on other sites

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.

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

BT doesn't have to even develop a secure way to share keys or communicate, just implement already existing features, team up with up and coming services like heml.is, or at least inform users that your security is dependent on the secrecy of that key, and that sending keys via unencrypted chat or email like facebook, yahoo, aim, aol, gmail, google hangout, outlook, etc is insecure.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

BT doesn't have to even develop a secure way to share keys or communicate, just implement already existing features, team up with up and coming services like heml.is, or at least inform users that your security is dependent on the secrecy of that key, and that sending keys via unencrypted chat or email like facebook, yahoo, aim, aol, gmail, google hangout, outlook, etc is insecure.

This however, is a good idea.

Link to comment
Share on other sites

If we had decent logging and a record of every device that connected and disconnected from a share we would at least be able to monitor what is going on and maybe even put decent alerts on any time a new device connects. Heck, you could have an option to require a manual acceptance of a new device into a folder by at least one of the existing participants.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share