0

We have to deliver a zero-knowledge SQLite based accounting/reviewing app running on Mac 10.6 and above.

We are asked to upload snapshots of database to cloud (AWS S3 or GCP) at regular intervals; so any accountant with right credentials can download the DB and start auditing with no geographical limitations.

We have decided to do the snapshots thing by uploading encrypted sqldiffs to the server. Also, once the auditing is complete, the entire DB is uploaded.

I am a junior programmer not a security guy, so it's probably none of my business but out of curiosity--

does the practice of storing hundereds of encrypted files, which in plain text would be like incremental diffs, undermine hidden-ness of the underlying data in any way?


In essence

I have patch files like so:

taken at 3.00 AM

alice

taken at 3.01 AM

alice
bianca
carolina

taken at 3.02 AM

alice
bianca
carolina
doofenshmirtz
  1. Size of patch files is always less than 100 kB.
  2. Patch files contain redundant data, just look at the examples.
  3. Patch files are uploaded at every minute-of-operation.
  4. Client probably has more threat from local (in nation) competitors than the giants.
  5. All these patch files are encrypted client-side, using openssl, AES256 CBC.
  6. Users (less than 50) would have to memorize the keys shared in person
  7. We hadn't thought of changing password periodically but we plan to enforce the usual password requirements.

I am curious about the implications of points 1, 2, and 3.

1

does the practice of storing snapshots of encrypted sqldiffs undermine hidden-ness of the underlying plain text in any way?

Not quite clear what you are asking here. I assume that you are asking whether it is safe to store encrypted plaintext in the cloud?

The short answer is "maybe".

In theory, this may well be sufficiently safe for the risks it presents. Of course, only people familiar with those risks can realistically make a proper assessment so this answer should, in no way, be taken as a recommendation.

There are a number of potential issues that need to be considered when assessing the risk:

  • How protective is the encryption being used? Does it meet the latest standards?
  • How long a key is being used?
  • Is the passcode strong enough?
  • Is there only a single passcode? (reusing the same passcodes to encrypt different data can ultimately compromise the encryption).
  • How is the passcode/key managed? How is it shared? Who has access?
  • How long does the encrypted data stay online?
  • How valuable is the data? (is it worth attackers spending lots of time/money to get to the data)

I could go on but hopefully you can see the shape here.

Really, the question is not about putting encrypted data into the cloud, it is, as so often with security, about how things are managed and what is the overall risk and risk appetite.

  • For example, if you use XTS mode, you leak a huge amount of information, since XTS is not supposed to ever be used for snapshots (hopefully a SQL database dump will not be using XTS anyway). – forest Feb 8 '18 at 14:19
  • Hi Julian Knight & @forest I have made clarifications, please take a look – vvsLaxman Feb 9 '18 at 3:54
  • I'm not an encryption expert so I can't comment in detail but I can say that hundreds of files with duplicate data and the same key - sounds like a recipe for brute force decryption. But if the business risk and data value is low then it is probably only of theoretical interest. – Julian Knight Feb 9 '18 at 20:56
  • @JulianKnight It's not an issue as long as the IV is different. Obviously you need to use a proper mode of operation if you are encrypting files with duplicate data and the same key. – forest Feb 15 '18 at 3:11
  • Thanks @forest, though you should probably explain "IV" for readers who may not know what it means. – Julian Knight Feb 26 '18 at 14:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.