All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jean-Luc Cooke <jlcooke@certainkey.com>
To: James Morris <jmorris@redhat.com>
Cc: "David S. Miller" <davem@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH/proposal] dm-crypt: add digest-based iv generation mode
Date: Tue, 24 Feb 2004 17:44:51 -0500	[thread overview]
Message-ID: <20040224224451.GB32286@certainkey.com> (raw)
In-Reply-To: <Xine.LNX.4.44.0402241713220.26251-100000@thoron.boston.redhat.com>

On Tue, Feb 24, 2004 at 05:17:12PM -0500, James Morris wrote:
> On Tue, 24 Feb 2004, Jean-Luc Cooke wrote:
> 
> > The two patches are:
> >  - http://jlcooke.ca/lkml/ctr_and_omac.patch
> >    (added ctr to cipher.c and omac.c)
> >    Using the init/update/final interface.
> >  - http://jlcooke.ca/lkml/ctr_and_omac2.patch
> >    (added ctr to cipher.c and integrated OMAC into all
> >    existing modes of operation. If cipher_tfm.cit_omac!=NULL, OMAC is stored
> >    into cipher_tfm.cit_omac)
> 
> Looks good so far, although the duplicated scatterwalk code needs to be 
> put into a separate file (e.g. scatterwalk.c).

OK.  So which patch do you want?  :)  The omac.c with scatterwalk, or the
cipher.c with omac performed in-place when needed?

> > ps. Will crypto_cipher_encrypt/crypto_cipher_decrypt *always* be called in
> > onesies?  I need to perform come final() code on the OMAC before it's
> > ready to pass test vectors - how do I know when we're done?
> 
> I don't understand what you mean here.

finish_omac() needs to be called once all data is processed.  How do I know
for sure the caller is done with this cipher context instance?

For example:
  loop {
    /* get more data into sgin */
    crypto_cipher_encrypt(tfm, sgout, sgin, len);
    /* send our data out of sgout */
  }
  /* get the 128bit OMAC and send it since we're done with all our encryption */

And decryption:
  loop {
    /* get more data into sgin */
    crypto_cipher_decrypt(tfm, sgout, sgin, len);
    /* send our data out of sgout */
  }
  /* get the 128bit OMAC and compare it with transmitted OMAC since we're done
     with all our decryption */

There is no explicit/implicit "crypto_cipher_encrypt_final()" to inform the
API to finalise the OMAC.

> Thanks for all this work!

Gladly.  Makes the beer at the pub go down with less guilt when I can say my
name has appear in one more kernel source file.  :)

JLC

-- 
http://www.certainkey.com
Suite 4560 CTTC
1125 Colonel By Dr.
Ottawa ON, K1S 5B6

  reply	other threads:[~2004-02-24 22:54 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20040223214738.GD24799@certainkey.com>
     [not found] ` <Xine.LNX.4.44.0402231710390.21142-100000@thoron.boston.redhat.com>
2004-02-24 20:22   ` [PATCH/proposal] dm-crypt: add digest-based iv generation mode Jean-Luc Cooke
2004-02-24 22:17     ` James Morris
2004-02-24 22:44       ` Jean-Luc Cooke [this message]
2004-02-25 13:52         ` James Morris
2004-02-25 15:11           ` Jean-Luc Cooke
2004-02-19 17:02 Christophe Saout
2004-02-19 19:18 ` Andrew Morton
2004-02-20 17:14   ` Jean-Luc Cooke
2004-02-20 18:53     ` Christophe Saout
2004-02-20 19:09       ` Jean-Luc Cooke
2004-02-20 19:23         ` Christophe Saout
2004-02-20 21:23         ` James Morris
2004-02-20 22:40       ` Christophe Saout
2004-02-21  0:07         ` James Morris
2004-02-21  2:17     ` Christophe Saout
2004-02-24 19:11       ` Matt Mackall
2004-02-24 19:43         ` Christophe Saout
2004-02-24 20:38           ` Matt Mackall
2004-02-25 21:43             ` Matt Mackall
2004-02-26 19:35               ` Christophe Saout
2004-02-26 20:02                 ` Matt Mackall
2004-02-27 16:05                   ` Christophe Saout
2004-02-27 18:37                     ` Christophe Saout
2004-02-27 20:02                     ` Matt Mackall
2004-02-27 20:13                       ` Christophe Saout
2004-02-27 20:55                         ` Matt Mackall
2004-02-27 21:16                           ` Christophe Saout
2004-02-28  0:39                             ` Matt Mackall
2004-02-28 13:02                               ` Christophe Saout
2004-02-24 22:26           ` James Morris
2004-02-24 22:31             ` Christophe Saout
2004-02-24 22:45               ` James Morris
2004-02-24 20:01         ` James Morris
2004-02-24 20:24           ` Matt Mackall
2004-02-25  2:25         ` Christophe Saout
2004-02-25  3:05           ` Jean-Luc Cooke
2004-02-23  0:35 ` Fruhwirth Clemens
2004-02-23 13:44   ` Jean-Luc Cooke
2004-02-23 15:36     ` James Morris

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=20040224224451.GB32286@certainkey.com \
    --to=jlcooke@certainkey.com \
    --cc=davem@redhat.com \
    --cc=jmorris@redhat.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.