lkml.org 
[lkml]   [2005]   [Apr]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] CryptoAPI & Compression


    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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-04-06 13:31    [W:0.019 / U:183.200 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site