[jira] [Updated] (CAY-1925) cayenne-crypto: add optional compression to the encryption pipeline

["Andrus Adamchik (JIRA)" <ji...@apache.org>]

     [ 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)