Re: [RFC] CryptoAPI & Compression

[Artem B. Bityuckiy]

Herbert Xu wrote:
> The question is what happens when you compress 1 1GiB input buffer into
> a 1GiB output buffer.
If user provides 1 GB output buffer then either we successfully compress 
all the 1 GB input or we compress just a part of it.

In the former case user may provide a second output buffer and 
crypto_comp_pcompress() will compress the rest of the input to it. And 
the user will have two independently de-compressible buffers.

The latter case is possible if the input isn't compressible and it is up 
to user to detect that handle this situation properly (i.e., just not to 
compress this). So, IMO, there are no problems here at least for the 
crypto_comp_pcompress() function.

In case of crypto_comp_pcompress() if the input isn't compressible, 
error will be returned.

If somebody needs a more flexible compression interface, he may think 
about implementing an deflate-like Crypto API interface. Or something 
else like crypto_comp_compress() which saves its internal state between 
calls and may be called several times with more input/output. I didn't 
think on it but we might as well.

> It'd be a good idea to use /dev/urandom as your input.
Yes, this is what I think about. I'm going to extend the tcrypt.ko test.

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/