From: Jean-Luc Cooke <jlcooke@certainkey.com>
To: James Morris <jmorris@redhat.com>
Cc: Christophe Saout <christophe@saout.de>,
Carl-Daniel Hailfinger <c-d.hailfinger.kernel.2004@gmx.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@osdl.org>
Subject: Re: dm-crypt, new IV and standards
Date: Sat, 21 Feb 2004 12:36:57 -0500 [thread overview]
Message-ID: <20040221173657.GB14873@certainkey.com> (raw)
In-Reply-To: <20040221164821.GA14723@certainkey.com>
On Sat, Feb 21, 2004 at 11:48:21AM -0500, Jean-Luc Cooke wrote:
> > Please focus your recommendations on security, not backward compatibility
> > with something that is new to the kernel tree, broken and maintainerless.
> I'll start writing OMAC now.
FYI OMAC spec:
http://crypt.cis.ibaraki.ac.jp/omac/omac.html
As you can see, there is a fixed output no matter how large the input it, the
output is always 128 bits.
So how will this fit into the cipher.c interface?
case CRYPTO_TFM_MODE_CTR:
ops->cit_encrypt = omac_compute;
ops->cit_decrypt = nocrypt;
ops->cit_encrypt_iv = nocrypt_iv;
ops->cit_decrypt_iv = nocrypt_iv;
break;
But now the user will have to call cit_encrypt(tfm, dst[0], src[i], nbytes);
Notice how dest will always have to be dst[0]. Unless we use the hash interface.
Thoughts?
static int omac_encrypt(struct crypto_tfm *tfm,
struct scatterlist *dst,
struct scatterlist *src,
unsigned int nbytes)
{
return crypt(tfm, dst, src, nbytes,
tfm->__crt_alg->cra_cipher.cia_encrypt,
omac_process, 1, tfm->crt_cipher.cit_iv);
}
JLC - has CTR mode implemented and will post once he has OMAC done as well.
--
http://www.certainkey.com
Suite 4560 CTTC
1125 Colonel By Dr.
Ottawa ON, K1S 5B6
next prev parent reply other threads:[~2004-02-21 17:46 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-19 22:06 dm-crypt, new IV and standards Carl-Daniel Hailfinger
2004-02-19 22:20 ` Christophe Saout
2004-02-20 17:22 ` Jean-Luc Cooke
2004-02-20 21:26 ` James Morris
2004-02-20 21:52 ` 2.6.3 adaptec I2O will not compile David Lang
2004-02-25 16:25 ` Adrian Bunk
2004-02-26 8:02 ` Jaco Kroon
2004-02-26 8:08 ` David Lang
2004-02-26 9:28 ` Jaco Kroon
2004-02-26 10:24 ` David Lang
2004-02-21 0:31 ` dm-crypt, new IV and standards Carl-Daniel Hailfinger
2004-02-21 16:48 ` Jean-Luc Cooke
2004-02-21 17:36 ` Jean-Luc Cooke [this message]
2004-02-21 19:01 ` Andreas Jellinghaus
2004-03-03 8:35 ` dean gaudet
2004-03-03 15:06 ` Jean-Luc Cooke
2004-03-03 21:40 ` David Wagner
2004-03-08 19:58 ` Jean-Luc Cooke
2004-03-04 1:48 ` dean gaudet
2004-03-04 13:24 ` Jean-Luc Cooke
2004-03-04 17:44 ` David Wagner
2004-03-05 1:19 ` dean gaudet
2004-03-05 2:14 ` Jean-Luc Cooke
2004-03-04 15:08 ` Pavel Machek
2004-03-07 4:14 ` DM for detecting bad disks was: " Mike Fedyk
-- strict thread matches above, loose matches on Subject: below --
2004-02-22 19:20 Adam J. Richter
2004-02-22 20:53 ` Christophe Saout
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=20040221173657.GB14873@certainkey.com \
--to=jlcooke@certainkey.com \
--cc=akpm@osdl.org \
--cc=c-d.hailfinger.kernel.2004@gmx.net \
--cc=christophe@saout.de \
--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