Not all Panic apps are available in the App Store, which means no iCloud. And the type of data Panic syncs doesn’t lend itself well to Dropbox or file sync solutions. We wrote our own sync server out of necessity—to give you the best sync experience possible.
There’s a lot we can do now that we couldn’t do before. We can sync data across applications. We can give you access to your data and control the authorization of devices. And since we control both sides of the equation, we can troubleshoot problems much more effectively.
No system is perfect, and if somebody tells you their server is hacker-proof, they're a charlatan. On the other hand, security through obscurity is not security. So we're here to tell you, in absolute detail, how we designed and built Panic Sync. We want you to be able to make a truly informed decision on if it meets your standards.
Here’s what you need to know.
We can’t see your data. Your data is encrypted with a symmetric key based on a passphrase that you choose—and only you know. We don’t store your passphrase on our server. Since we don’t know your passphrase, your data can’t be read by us—or anyone else.
We brought in a third party to audit our code. The security-minded folks at ^Lift audited every piece of Panic Sync, poring over our code line-by-line. They suggested we increase the minimum length of user passphrases, but otherwise found zero issues with our design.
All your data is encrypted. We use two 256-bit AES keys: one to encrypt and one to verify the data. And of course any data transmission uses HTTPS with a 2048-bit key and TLS 1.2. All encryption and decryption is done on your device—not ours.
It’s very good to be curious. To lay it all on the table, here’s a technical explanation of how Panic Sync handles your data.
- When encryption is enabled, all sensitive data (passwords, usernames, private keys, server names and addresses, etc.) is encrypted.
- Encrypting this data is performed using AES128 and a per-user master key, using a randomly chosen initialization vector.
- Verification/integrity is performed using HMAC and a second per-user master key.
- The ciphertext is combined with the HMAC signature and some non-user-related metadata to form the actual data transmitted.
- All encryption/decryption is performed on the user’s device.
The two master keys are derived as follows:
- The user chooses a master passphrase.
- The master passphrase is used to generate a pair of derived keys (256-bit each, one for encryption and one for verification) using PBKDF, SHA-256 and a 512-bit random block of data taken from /dev/random.
- The derived keys are used to create a pair of master keys (256-bit each, one for encryption, one for verification).
- The master keys are used to encrypt and verify each block of sensitive data, as described above.
- The master keys are encrypted using the derived keys and stored alongside the encrypted data.
- Verification is performed before decryption of all data, using the HMAC created during encryption.
The derived key is never transmitted from the user’s devices, and can be regenerated using the same method and master passphrase on new devices the user adds later.