Although I understand existing users of sync have had trouble with 2.7, I’m very-much in favour of encrypting materials stored in the cloud and have refrained from using DTPO cloud-sync functionality in the past due to the sensitive contents of some of my DBs.
To give me confidence in the new encrypted sync, I need to understand how the encryption/decryption process has been implemented. I understand a 256bit AES algorithm is used, but how is the key derived and how long is it? Where does the per-database password come in if one has been set?
As I don’t have to enter a passphrase on either end of a sync, the key must be known in advance and personalised - is it based on license code?
Looking froward to using encrypted sync once I understand the implementation.
The (first) encryption key is derived from a UUID generated during the first sync, which is then encrypted/decrypted using (second) a string derived from the username/password set for the database, if any. It ends up being about 64 characters, IIRC.
I’m also using initialization vectors, so it should be a little tougher still. I’ve also avoided encrypting files with easily-guessed contents, wherever possible, to prevent some attacks. It relies on the CommonCrypto library, so I’m fairly sure that the underlying implementation is about as good as any available.
I designed it this way so that:
The default requires no effort on the part of the user and decent security (enough to dissuade anyone who doesn’t decompile the binary or [possibly] snoop around with F-Script or something else).
Users who care about security can use existing functionality and significantly increase the safety of their data without further complicating the design of the sync code.
The user isn’t required to create/remember additional passwords.
If the user adds/changes/removes the database username/password, the store doesn’t have to be rewritten – instead, the encryption key is decrypted and re-encrypted.
AFAIK and AFAICT, I’ve done an okay job of it. However, I’m not by any means a security expert. And IIRC, Bruce Schneier considers AES-256 mildly compromised because of some theoretical attack that may become possible within the next twenty years or so, whereas no such theoretical attack exists against the (weaker) AES-224, but TBH I don’t think that people will be using DEVONthink 2.7 in twenty years, or ten.
If you’re aware of any practical weakness in this design, I would love to learn about it. I’m working on Sync 2, which I would like to be much better than Sync 1 in every way, and anything I can do within reason to make syncing more secure sounds good to me.
Thanks, that’s really helpful but I’m still not quite sure how the UUID is communicated between DT instances. Does it go in the clear? Can anyone running DTP(O) 2.7 copy a sync store and decrypt it if no separate DB username/password is set?
Happy to help The UUID is encrypted and saved in the per-database metadata that’s kept in the sync store.
So in other words, when you try to download a database that’s on Dropbox or whatever, DEVONthink downloads the database metadata, opens it, and asks the user for the username/password (if set), calculates the encryption key used to store the “real” encryption key, decrypts the “real” encryption key, and uses that to read the records and metadata it downloads.
When you make changes to the database, this process pretty much just runs in reverse.
Nope, it’s only handled unencrypted by DEVONthink.
Yes. Here you’re basically relying on the username/password to the sync store for your security. It’s unfortunate, but I couldn’t come up with a better solution.
Basically, using the license key won’t work because:
a) users would have to rewrite the sync store if they upgraded (Personal → Pro, etc).
b) users would be unable to share with other users.
c) users would have to rewrite the sync store if they used during a trial period.
There’s no “user ID” with DEVONtechnologies, although we’re contemplating a sort of single-sign-on system that would give access to the forums, license downloads, and other benefits. This could be used for Sync 2.
So, anyway, yes, security is compromised if someone has access to the sync store and you haven’t set a database username/password.
I set a password on a DB that I was already successfully syncing in 2.7 and made some local data changes which went to the sync store. On my other Mac, I didn’t set any password yet the data changes have been synchronised without prompting for any password.
What do I need to do to secure my sync store after setting a DB password?
Feedback suggestions for v2;
Separate the overloaded “DB password” option - AFAICT this is being used for authentication purposes (opening of DB and web-based sharing) and sync-store encryption. These are different use-cases having different requirements and functionality. In my particular case, I don’t need or want the authentication and associated prompting for passwords but do need the Cloud-bound data encryption.
If retained in this way, make it clear that security is only offered by sync-store encryption when a DB password or better still, a separate “sync-store encryption key” is specified in the DB properties - otherwise anyone with a copy of DTP can decrypt the data.
The UUID is encrypted and saved in the per-database metadata that’s kept in the sync store.