"real" And One-Time "secrets"

[Hopkins]

Integrating a the public key based "one-time secret" is a fantastic solution to the problem of the secure transmission of secrets. I also realise that it was added relatively recently to the product. However, in my opinion, BTSync should change to discourage the use of anything except a one-time secret for communication.  Calling both the real and one-time secrets "secrets" implies that they are similar, but they are absolutely not.  Losing control of a real secret is a complete disaster.  Perhaps the one-time secret should even have a different name to reinforce that the actual secret is just that: it must, absolutely, remain a secret.

 

Imagine this alternative.  Instead of seeing very easily the real secret of a folder, instead you are presented with the option to generate a "Communication Code".  Before generating it, the user could specify whether the recipients can see or not see the real secret, how many times it can be used, how long before it times out and whether the recipient will have the permission to create new Communication Codes.  The aim should be to avoid any requirement actually to use the real secret.

 

I realise that this is quite a major change, but since one of the strong points of BTSync is security, it would be a shame if it was difficult for non-techy users to understand how to use it securely.

[Hopkins]

Can I assume from the lack of replies that this is way off-piste, and not at all in line with anyone else's thoughts on how BTSync should develop?

 

Re-reading it, perhaps my use of "Communication Code" is confusing.  What I meant is that perhaps the one-time secret should be renamed to Communication Code in order to make it clear that it is designed for communicating, and to dispel the illusion that it is "just as secret" as the real secret!

 

The motivation for all this is that if I want to share a folder with someone, then the simple act of sharing it with them gives them the freedom to redistribute the secret (whether full access or read only) to anyone else.  I lose control of who has access to the folder.

[ChrisH]

As soon as you share a folder with someone, you lose control over the contents anyway. Even with your idea of communication codes, you cannot stop them from just creating a new BTSync share (with a secret THEY control) with your data in it. Or posting it to Facebook or whatever. 

 

You are looking for a technical solution to a social problem. If you don't want someone to give away your data or your secret, tell them. If you don't trust them, don't give them your data. It's as simple as that.

[casacota]

Indeed it would be usefull if applying read-only one time secrets would not show the regular secret, avoiding publishing and subsequent shares.

It's clear that one can copy and paste files between folders, and have the copies shared, but it is not the same.

 

If I wish to share material with my students I can give everyone an one-time readonly code on a folder that I can update and change, but I don't wish that someone else connects to them and sees all this changes as they happen. If they give away some or all shared files, that is an explicit fraudulent action that can be investigated and prosecuted. With a visible common sharing code that can be leaked this is more difficult if not impossible.

[ChrisH]

Then maybe BTSync just isn't the optimal solution for your requirements and you would be better off with a traditional system that uses distinct credentials like username and password specific to each user. Anything slapped onto BTSync with its peer-to-peer design will just be a makeshift solution, not an inherently secure one.