On Wed, Aug 07, 2019 at 10:49:36PM -0700, Eric Biggers wrote: > On Thu, Aug 08, 2019 at 12:26:42PM +0800, Gao Xiang wrote: > > 1. decrypt->verity->decompress > > > > 2. verity->decompress->decrypt > > > > 3. decompress->decrypt->verity > > > > 1. and 2. could cause less computation since it processes > > compressed data, and the security is good enough since > > the behavior of decompression algorithm is deterministic. > > 3 could cause more computation. > > > > All I want to say is the post process is so complicated since we have > > many selection if encryption, decompression, verification are all involved. > > > > Maybe introduce a core subset to IOMAP is better for long-term > > maintainment and better performance. And we should consider it > > more carefully. > > > > FWIW, the only order that actually makes sense is decrypt->decompress->verity. That used to be true, but a paper in 2004 suggested it's not true. Further work in this space in 2009 based on block ciphers: https://arxiv.org/pdf/1009.1759 It looks like it'd be computationally expensive to do, but feasible. > Decrypt before decompress, i.e. encrypt after compress, because only the > plaintext can be compressible; the ciphertext isn't.
