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 15:22:23 -0500 [thread overview]
Message-ID: <20040224202223.GA31232@certainkey.com> (raw)
In-Reply-To: <Xine.LNX.4.44.0402231710390.21142-100000@thoron.boston.redhat.com>
On Mon, Feb 23, 2004 at 05:11:45PM -0500, James Morris wrote:
> As far as I can tell, you should just be adding a new wrapper interface
> like HMAC. Have a look at that code.
OK got the hint. ;)
I'll repeat my recommendation that OMACs be computed at the same time as
encryption/decryption and not in a "two pass" approach like this. Ideally by
passing two cipher contexts (one for encryption other for MACing) into
functions like cbc_encrypt() - alas I'm too nervous with this API to
implement that.
A Not-So-Ideal compromise would be using the same cipher context and
storing the MAC in a new member of the cipher_tfm struct. This would require
minimal amount of new code to test and will probably go faster as well.
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)
So in other words, current implementations using the CryptoAPI will not see
performance change and no new .c files.
No OMAC:
tfm = crypto_alloc_tfm (algo, CRYPTO_TFM_MODE_CBC);
With OMAC:
tfm = crypto_alloc_tfm (algo, CRYPTO_TFM_MODE_CBC | CRYPTO_TFM_MODE_OMAC);
...
crypto_cipher_get_omac(tfm, omac_val, 128/8);
** J-L likes this one more! **
Now implementing CCM mode (the final mode of operation specified for use with
AES by NIST) will be my next task. CCM is an IEEE standard and is going
through the motions of becoming a FIPS standard as well. Reference:
http://csrc.nist.gov/publications/drafts/Draft_SP_800-38C_9-04-2003.pdf
It's effectively CTR mode with a CBC MAC at the end of it. I'll start
implementing it, but we'll hold off until the spec is out of draft.
JLC
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?
--
http://www.certainkey.com
Suite 4560 CTTC
1125 Colonel By Dr.
Ottawa ON, K1S 5B6
next parent reply other threads:[~2004-02-24 20:32 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 ` Jean-Luc Cooke [this message]
2004-02-24 22:17 ` [PATCH/proposal] dm-crypt: add digest-based iv generation mode James Morris
2004-02-24 22:44 ` Jean-Luc Cooke
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=20040224202223.GA31232@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox