[
https://issues.apache.org/jira/browse/CAY-1925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrus Adamchik updated CAY-1925:
---------------------------------
Description:
This is about transparently compressing encrypted data. Compression can be
optionally enabled via CryptoModuleBuilder. By default we'll use GZIP
compression, but as with everything in cayenne-crypto, this is a pluggable
strategy.
If compression is enabled, we should distinguish between small and large
values. For small values compression only adds overhead and should be skipped.
Per [1] Google recommends not compressing files smaller than 150 - 1000 bytes
(this is of course for the web content). We'll use an internal threshold
somewhere in this range, and then we should just do some performance tests.
Compression will happen *before* encryption, as it is likely to be more
efficient on plaintext than randomized encrypted data [2].
We'll need to add compression flag to the "header" block of the ciphertext.
This means we will need to narrow the length of the allowed key name. For now
it is 16 bytes... Perhaps squeeze it to 8 to have some space for the future
metadata extensions.
[1]
https://developers.google.com/speed/docs/best-practices/payload#GzipCompression
[2]
http://superuser.com/questions/257782/compress-and-then-encrypt-or-vice-versa
was:
This is about transparently compressing encrypted data. Compression can be
optionally enabled via CryptoModuleBuilder. By default we'll use GZIP
compression, but as with everything in cayenne-crypto, this is a pluggable
strategy. There can be 3 configuration states in regards to compression:
1. No compression (default)
2. Unconditional compression
3. Compression of data > certain number of data bytes
Compression will happen *before* encryption, as it is likely to be more
efficient on plaintext than randomized encrypted data [1].
We'll need to add compression flag to the "header" block of the ciphertext.
This means we will need to narrow the length of the allowed key name. For now
it is 16 bytes... Perhaps squeeze it to 8 to have some space for the future
metadata extensions.
[1]
http://superuser.com/questions/257782/compress-and-then-encrypt-or-vice-versa
> cayenne-crypto: add optional compression to the encryption pipeline
> -------------------------------------------------------------------
>
> Key: CAY-1925
> URL: https://issues.apache.org/jira/browse/CAY-1925
> Project: Cayenne
> Issue Type: Bug
> Reporter: Andrus Adamchik
> Assignee: Andrus Adamchik
>
> This is about transparently compressing encrypted data. Compression can be
> optionally enabled via CryptoModuleBuilder. By default we'll use GZIP
> compression, but as with everything in cayenne-crypto, this is a pluggable
> strategy.
> If compression is enabled, we should distinguish between small and large
> values. For small values compression only adds overhead and should be
> skipped. Per [1] Google recommends not compressing files smaller than 150 -
> 1000 bytes (this is of course for the web content). We'll use an internal
> threshold somewhere in this range, and then we should just do some
> performance tests.
> Compression will happen *before* encryption, as it is likely to be more
> efficient on plaintext than randomized encrypted data [2].
> We'll need to add compression flag to the "header" block of the ciphertext.
> This means we will need to narrow the length of the allowed key name. For now
> it is 16 bytes... Perhaps squeeze it to 8 to have some space for the future
> metadata extensions.
> [1]
> https://developers.google.com/speed/docs/best-practices/payload#GzipCompression
> [2]
> http://superuser.com/questions/257782/compress-and-then-encrypt-or-vice-versa
--
This message was sent by Atlassian JIRA
(v6.2#6252)
