Wish: security and management


mat

Recommended Posts

Sync uses aes256 encryption, which is great, because it's very, very, very hard to break.

The problem of aes256 is that there is only one key; if ten people have the key and suddenly a lot more, somebody is leaky and you're probably not going to find out who. In this case, files are no longer protected and might be publicly available. Also the secret key has to be shared outside of Sync, now you have to be very carefull, because you'll need a safe way to send the key to trusted clients while a lot of people probably think using email is safe enough; it's not.

I think it would be nice if an option would be added to be able to manage a "secret".

With public key cryptography this can be achieved in some way. Every client should generate its own set of asymmetric keys (one made available to the secrets you join / try to join and the other will be kept completely private, only available to the client itself), now a secure connection can be initiated without sharing the the secret key unencrypted or outside Sync (like email or im).

Now the master-client (the client where the the "secret" was created) decides who it will allow or refuse (or even invite). Now you could also create groups inside a shared secret, the master-client decides who is in what group and sets the rights for each group. When implemented right, you could create multiple groups wherein the clients can't determine they are in a specific group and also they don't know they might be the only one having access to a file while sharing data to all clients in the shared secret. As long as the master-client is not online, no changes can be made in groups but new files can still be added and everything will stay available.

Of course, in a managed shared secret, people can still share files to others by just sending a copy, but they can't give others direct access to the managed shared secret so the master-client keeps control. Also the group thing makes the master-client able to send wrong or different information to specific groups or clients; when such information leaks (the client doesn't know it is the only one, besides the master-client, who has this data), the person in posession of the master-client can determine who is leaky and might decide to kick a specific client.

So, that's my wish. I know it is pretty complex; if you don't understand, feel free to ask anything about this, I'll tro to explain.

Link to post
Share on other sites

I fully understand your concerns, and agree that sharing secret over insecure media like email or im, makes it vulnerable.

Let me give you some background on how we come with the idea of secret. Usually consumer applications use some sort of login/password combination to identify user and create groups of users. In case of Sync we don't have any central server that do such linking, we don't need ability to recover passwords, authenticate users. So we decided not to use login/password, but rather find some other way - that will be clear enough to users.

So this way we come with the Secret idea. Why we do understand all security risks, it was interesting to see how people will understand this concept and that concept will it be clear to them.

Seems that the concept of Secret is fine with users, so we will tighten security. I can't tell now how it will be done, this is still in development. But all your concerns will be addressed.

To clarify complexity that we have, we don't have master-client relation in the system, so implementing key management where any computer is master and can come and go at any time, is something less trivial than master-slave key management.

Link to post
Share on other sites

Archived

This topic is now archived and is closed to further replies.