calvinmetcalf
commented
7 years ago you could just add a field to your document with with a known key with data of a random length
On Mon, Feb 6, 2017 at 11:48 AM Jack Kleeman notifications@github.com wrote:
I was thinking of creating another plugin for this, or perhaps forking crypto-pouch, but I figured it might be useful to other users in the context of zero knowledge applications. I would like to be able to optionally (either per document or per database) pad the encrypted data with random bytes to some minimum length, or maybe to the neareast order of magnitude length, to reveal less about the content of the document. This padding would be applied after the encrypted body, to save some computation, but is rerandomised on every document update so that it is impossible to tell which part of the data is the real bit. Ideally, the random padding could be deterministic based on the unencrypted document, eg using the hash of the plaintext as a random seed, so that the same document ends up with the same encrypted+padded document, which keeps deterministic revision ids useful.
I guess you would need to encrypt the length of the true encrypted data and store it in a seperate field.
This would be simplified if you padded before encryption (you could just pad by repeating some non-changing letter after the plaintext) but I'm unsure how bad that'd be for performance.
If anyone else would find this interesting, I could submit a pull request.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/calvinmetcalf/crypto-pouch/issues/51, or mute the thread https://github.com/notifications/unsubscribe-auth/ABE4n-VBR3pI79gMlGcmSl7Qk_wCOSU9ks5rZ07ZgaJpZM4L4cEW .
garbados
I was thinking of creating another plugin for this, or perhaps forking crypto-pouch, but I figured it might be useful to other users in the context of zero knowledge applications. I would like to be able to optionally (either per document or per database) pad the encrypted data with random bytes to some minimum length, or maybe to the neareast order of magnitude length, to reveal less about the content of the document. This padding would be applied after the encrypted body, to save some computation, but is rerandomised on every document update so that it is impossible to tell which part of the data is the real bit. Ideally, the random padding could be deterministic based on the unencrypted document, eg using the hash of the plaintext as a random seed, so that the same document ends up with the same encrypted+padded document, which keeps deterministic revision ids useful.
I guess you would need to encrypt the length of the true encrypted data and store it in a seperate field.
This would be simplified if you padded before encryption (you could just pad by repeating some non-changing letter after the plaintext) but I'm unsure how bad that'd be for performance.
If anyone else would find this interesting, I could submit a pull request.