public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Artem B. Bityuckiy" <dedekind@yandex.ru>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "Artem B. Bityuckiy" <dedekind@infradead.org>,
	dwmw2@infradead.org, linux-kernel@vger.kernel.org,
	linux-crypto@vger.kernel.org
Subject: Re: [RFC] CryptoAPI & Compression
Date: Sun, 03 Apr 2005 12:22:12 +0400	[thread overview]
Message-ID: <424FA7B4.6050008@yandex.ru> (raw)
In-Reply-To: <20050401221303.GA6557@gondor.apana.org.au>



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.

  reply	other threads:[~2005-04-03  8:22 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-25 16:08 [RFC] CryptoAPI & Compression Artem B. Bityuckiy
2005-03-26  4:44 ` Herbert Xu
2005-03-26 11:32   ` Artem B. Bityuckiy
2005-03-28 17:22   ` Artem B. Bityuckiy
2005-03-29 10:35     ` Herbert Xu
2005-03-29 11:55       ` Artem B. Bityuckiy
2005-03-31  2:19         ` Herbert Xu
2005-03-31 10:43           ` Artem B. Bityuckiy
2005-03-31 11:11             ` Herbert Xu
2005-04-01 14:36               ` Artem B. Bityuckiy
2005-04-01 14:44                 ` David Woodhouse
2005-04-01 14:57                   ` Artem B. Bityuckiy
2005-04-01 15:05                     ` David Woodhouse
2005-04-01 15:22                       ` Artem B. Bityuckiy
2005-04-01 15:33                         ` Jörn Engel
2005-04-03  8:47                           ` Artem B. Bityuckiy
2005-04-01 15:23                 ` Herbert Xu
2005-04-01 15:41                   ` Artem B. Bityuckiy
2005-04-01 22:13                     ` Herbert Xu
2005-04-03  8:22                       ` Artem B. Bityuckiy [this message]
2005-04-03  8:27                         ` Artem B. Bityuckiy
2005-04-03  8:29                         ` Artem B. Bityuckiy
2005-04-03  8:44                         ` Herbert Xu
2005-04-03  8:59                           ` Artem B. Bityuckiy
2005-04-03  9:30                             ` Herbert Xu
2005-04-03  9:45                               ` Artem B. Bityuckiy
2005-04-03 10:00                                 ` Herbert Xu
2005-04-03 10:06                                   ` David Woodhouse
2005-04-03 10:17                                     ` Herbert Xu
2005-04-03 10:23                                       ` Artem B. Bityuckiy
2005-04-03 11:42                                         ` Herbert Xu
2005-04-03 15:24                                           ` Artem B. Bityuckiy
2005-04-03 11:19                                       ` David Woodhouse
2005-04-03 11:40                                         ` Herbert Xu
     [not found]                                           ` <4250175D.5070704@yandex.ru>
     [not found]                                             ` <20050403213207.GA24462@gondor.apana.org.au>
2005-04-18 15:09                                               ` Artem B. Bityuckiy
2005-04-19  9:25                                                 ` Herbert Xu
2005-04-19 12:51                                                   ` Artem B. Bityuckiy
2005-04-19 22:10                                                     ` Herbert Xu
2005-04-03 10:19                                   ` Artem B. Bityuckiy
2005-04-03  9:20                           ` Artem B. Bityuckiy
2005-03-31  9:51     ` Herbert Xu
2005-04-03 11:41       ` Artem B. Bityuckiy
2005-04-03 11:47         ` Herbert Xu
2005-04-03 11:53           ` Artem B. Bityuckiy
2005-04-03 12:00             ` Herbert Xu
2005-04-03 12:01           ` Artem B. Bityuckiy
2005-04-03 12:07             ` Herbert Xu
2005-04-03 12:18               ` Artem B. Bityuckiy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=424FA7B4.6050008@yandex.ru \
    --to=dedekind@yandex.ru \
    --cc=dedekind@infradead.org \
    --cc=dwmw2@infradead.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox