Re: Data compression APIs?

You're exactly right about the need to compress before encrypting, but my inclination would be to say that a crypto API is probably not the right place for compression/decompression.  

In general, one of the goals of crypto software design is to be validatable (e.g., for FIPS 140-2 validation [1]), and the addition of unnecessary features within the "crypto perimeter" tends to make that validation harder.  For example, Firefox contains a FIPS-accredited crypto module [2], so one could imagine that if the bridge to the Javascript API were implemented properly, this accreditation might be extended to the Javascript layer as well.  This would be more difficult if functions were introduced at the Javascript layer beyond what is present in the FIPS-accredited module.  (I do note that NSS includes a copy of zlib [3], but it's not immediately clear whether that's within the accredited part.)

--Richard


[1] <http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf>
[2] <http://support.mozilla.org/en-US/kb/Configuring%20Firefox%20for%20FIPS%20140-2>
[3] <http://hg.mozilla.org/mozilla-central/file/8eab8fdaa675/security/nss/lib/zlib>



On Jan 25, 2012, at 8:11 PM, Mitch Zollinger wrote:

> In designing the technology that satisfies the use case doc posted previously (http://www.w3.org/wiki/NetflixWebCryptoUseCase) it would appear that we need to support compression / decompression APIs.
> 
> The reason is that for our "MsgSec" protocol, we encrypt every message going over the wire and since encrypted data cannot be compressed, the compression has to happen before encryption. Therefore standard things like HTTP gzip compression will not work.
> 
> What we're looking for is something along the lines of:
> 
>  function compress(data, algorithm)
>  function uncompress(data, algorithm)
> 
> where algorithm is one of the standard ones (gzip, bzip2, etc.)
> 
> Is this the right forum for looking at this type of functionality?
> 
> Mitch
> 
>

Received on Thursday, 26 January 2012 02:56:22 UTC