Hi:
This series of patches introduces IV generators which can be
accessed through the givcrypt operation on block ciphers (other
than crypto_blkcipher which should not be used for new code).
The givcrypt operation is identical to encrypt except that the
IV is generated by the algorithm instead of given by the user.
Algorithms can either provide their own IV generator or (as
most will do) use the default IV generators provided by the
system. If no IV generator is specified by the system, then
chainiv will be used for synchronous algorithms and eseqiv will
be used for asynchronous algorithms.
Counter mode algorithms (which include some stream ciphers) must
choose something other than the default to ensure uniqueness for
the IV.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Hi Herbert.
On Thu, Nov 22, 2007 at 04:47:58PM +0800, Herbert Xu ([email protected]) wrote:
> This series of patches introduces IV generators which can be
> accessed through the givcrypt operation on block ciphers (other
> than crypto_blkcipher which should not be used for new code).
>
> The givcrypt operation is identical to encrypt except that the
> IV is generated by the algorithm instead of given by the user.
>
> Algorithms can either provide their own IV generator or (as
> most will do) use the default IV generators provided by the
> system. If no IV generator is specified by the system, then
> chainiv will be used for synchronous algorithms and eseqiv will
> be used for asynchronous algorithms.
>
> Counter mode algorithms (which include some stream ciphers) must
> choose something other than the default to ensure uniqueness for
> the IV.
Idea and implementation look very good, I have couple of comments on
patches and one generic comment here: you absolutely have to write at
least bits of documentation for this new interfaces, how they behave and
who and how should use it :)
--
Evgeniy Polyakov
On Thu, Nov 22, 2007 at 02:25:59PM +0300, Evgeniy Polyakov wrote:
>
> Idea and implementation look very good, I have couple of comments on
> patches and one generic comment here: you absolutely have to write at
> least bits of documentation for this new interfaces, how they behave and
> who and how should use it :)
Sorry, when my employer starts paying me to do that or hires
someone to do that for me is when better docs will exist :)
Until that happens why don't you chip in and contribute some
documentation the user?
Of course if you have specific questions about how givcrypt
works or is supposed to be used I'm happy to answer them.
In any case, hopefully when I push out the actual patches for
ESP it might become clearer.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Thu, Nov 22, 2007 at 07:31:16PM +0800, Herbert Xu ([email protected]) wrote:
> > Idea and implementation look very good, I have couple of comments on
> > patches and one generic comment here: you absolutely have to write at
> > least bits of documentation for this new interfaces, how they behave and
> > who and how should use it :)
>
> Sorry, when my employer starts paying me to do that or hires
> someone to do that for me is when better docs will exist :)
Somehow you described that to others - just combine things together and
put to Documentation/crypto and that will be enough.
> Until that happens why don't you chip in and contribute some
> documentation the user?
It is only possible if I clearly understand the whole idea, but it is
not that simple like it looks from author's point of view :)
For example this patchset looks like possible first step in proper
chaining mechanism for hardware devices, but if this will be impemented
this way, then each hardware completion callback should be wrapped with
proper geniv methods (like those which copy iv back to req->info). Is
this right approach (for those users who care about correct returned
IV), or will it just use software implementation only?
--
Evgeniy Polyakov
On Thu, Nov 22, 2007 at 02:57:07PM +0300, Evgeniy Polyakov wrote:
>
> Somehow you described that to others - just combine things together and
> put to Documentation/crypto and that will be enough.
Patches are welcome :)
> For example this patchset looks like possible first step in proper
> chaining mechanism for hardware devices, but if this will be impemented
> this way, then each hardware completion callback should be wrapped with
> proper geniv methods (like those which copy iv back to req->info). Is
> this right approach (for those users who care about correct returned
> IV), or will it just use software implementation only?
I'm not sure I understand your question.
First of all givcrypt is designed to work for hardware devices too.
If they can generate their own IVs then they should directly hook
up to the givcrypt method and use the givcipher type.
If not then they can use one of the precanned geniv wrappers and
declare their preference in the in crypto_ablkcipher_alg->geniv.
As to chaining, I presume you mean something like encryption
followed by hashing? If so then this really doesn't have much to
do with chaining at all.
I think we don't really need chaining in general because the
hardware doesn't do arbitrary chaining. Instead what they do
is specific chains that are useful for particular applications.
Case in point would be encryption followed by hashing which is
designed for IPsec.
Therefore instead of having a general chaining abstraction I've
chosen to do chaining support on a case-by-case basis. For
instance, the above chaining is now supported by the new crypto_aead
transform type.
It just so happens that people are also designing algorithms
to make crypto_aead useful for software as well which is a
bonus :)
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Thu, Nov 22, 2007 at 08:09:37PM +0800, Herbert Xu ([email protected]) wrote:
> On Thu, Nov 22, 2007 at 02:57:07PM +0300, Evgeniy Polyakov wrote:
> >
> > Somehow you described that to others - just combine things together and
> > put to Documentation/crypto and that will be enough.
>
> Patches are welcome :)
I still do not understand thow whole concept.
> > For example this patchset looks like possible first step in proper
> > chaining mechanism for hardware devices, but if this will be impemented
> > this way, then each hardware completion callback should be wrapped with
> > proper geniv methods (like those which copy iv back to req->info). Is
> > this right approach (for those users who care about correct returned
> > IV), or will it just use software implementation only?
>
> I'm not sure I understand your question.
>
> First of all givcrypt is designed to work for hardware devices too.
> If they can generate their own IVs then they should directly hook
> up to the givcrypt method and use the givcipher type.
But for example chainiv_givcrypt() will not return correct iv when
called fro async device, since when givcrypt() returned operation is not
yet completed.
> If not then they can use one of the precanned geniv wrappers and
> declare their preference in the in crypto_ablkcipher_alg->geniv.
>
> As to chaining, I presume you mean something like encryption
> followed by hashing? If so then this really doesn't have much to
> do with chaining at all.
Yes, that what I meant. And also other possible crypto modes, which can
require iv-based tweaks.
> I think we don't really need chaining in general because the
> hardware doesn't do arbitrary chaining. Instead what they do
> is specific chains that are useful for particular applications.
>
> Case in point would be encryption followed by hashing which is
> designed for IPsec.
>
> Therefore instead of having a general chaining abstraction I've
> chosen to do chaining support on a case-by-case basis. For
> instance, the above chaining is now supported by the new crypto_aead
> transform type.
>
> It just so happens that people are also designing algorithms
> to make crypto_aead useful for software as well which is a
> bonus :)
This sheds some light on, thanks.
--
Evgeniy Polyakov
On Thu, Nov 22, 2007 at 03:37:02PM +0300, Evgeniy Polyakov wrote:
>
> > First of all givcrypt is designed to work for hardware devices too.
> > If they can generate their own IVs then they should directly hook
> > up to the givcrypt method and use the givcipher type.
>
> But for example chainiv_givcrypt() will not return correct iv when
> called fro async device, since when givcrypt() returned operation is not
> yet completed.
Chainiv is just one possible IV generator. You're right that
it cannot possibly work with async ciphers, that's why its alloc
function rejects any attempt to apply it to an async cipher :)
In any case what I meant above is something different. I'm
thinking of hardware that can naturally generate their own IVs
as part of the encryption operation, e.g., through a hardware
RNG for CBC or a counter for CTR.
> Yes, that what I meant. And also other possible crypto modes, which can
> require iv-based tweaks.
BTW, givcrypt should only be used for generating the entire IV.
If you're trying to adjust the IV, e.g. adding bits to it as
is done for CTR for IPsec then that should be done through the
usual ablkcipher interface by just wrapping around the encrypt
and decrypt functions.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt