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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
