by Herbert Xu

[permalink] [raw]

Subject: Re: [PATCH 3/4] crypto: md5 - Add export support

On Mon, Dec 28, 2009 at 06:59:14PM +0000, Max Vozeler wrote:
> This patch adds export support to md5. The exported type is
> defined by struct md5_state.
>
> This is modeled after the equivalent change to sha1_generic,
> except only export is added for now.
>
> Signed-off-by: Max Vozeler <[email protected]>
> Cc: Jari Ruusu <[email protected]>

Please add an import function as the shash API requires import
to be present if export is present.

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

2010-01-13 17:29:53

by Max Vozeler

[permalink] [raw]

Subject: Re: [PATCH 1/4] dm-crypt: clarify cipher vs. cipher mode

Hi Richard,

On Mon, Jan 11, 2010 at 10:28:39PM +0100, Richard Zidlicky wrote:
> On Mon, Jan 04, 2010 at 04:25:42PM +0100, Max Vozeler wrote:
> > +
> > +These modes have two main characteristics compared to regular CBC
> > +with sector IV. The first is implemented in dm-crypt, the second
> > +is implemented in the lmk2 and lmk3 blkciphers.
>
> the formulation is not very clear. Possibly better wording -
>
> + There are two main differences distinguishing the lmk2 and lmk3 modes
> + from the blok cipher implemented in dm-crypt:

I reworked this part in the new version below.

> > +1) Use of 64 independent keys which are alternatingly applied to
> > +different sectors.
> > +
> > + key = keys[sectornum % 64]
>
> not really "alternating" when there is more than 2, my try
> "different sectors are encrypted with 64 independent keys selected by the
> following rule"
> + key = keys[sectornum % 64]

Good point, thanks.

> > +2) IV derivation from an MD5 digest of the sector number, parts
> > +of the plaintext data and a mode specific format constant. The
> > +multi-key-v3 mode additionally uses a 128-bit IV seed.
>
> slightly rephrased:
>
> +2) IVs are derived from an MD5 digest of the sector number, parts
> +of the plaintext data and a mode specific format constant. The
> +multi-key-v3 mode additionally uses a 128-bit IV seed.

Agreed. I included your rephrasing.

> > + v2IV = MD5(plaintext[16..511] ||
> > + truncated-sector-number ||
> > + format-magic)
> > +
> > + v3IV = MD5(ivseed ||
> > + plaintext[16..511] ||
> > + truncated-sector-number ||
> > + format-magic)
>
> that seems different than what is described here -
> http://mail.nl.linux.org/linux-crypto/2006-01/msg00006.html
>
> so is it compatible after all? Or where is format-magic' equivalent
> hidden in Jari's description?

The format-magic is not mentioned in Jari's description, but
is indeed used by Loop-AES.

Compare loop-AES-v3.2h/glue.c:402:

/* 4024 bits == 31 * 128 bit plaintext blocks + 56 bits of sector number */
/* For version 3 on-disk format this really should be 4536 bits, but can't be */
/* changed without breaking compatibility. V3 uses MD5-with-wrong-length IV */
buf[14] = 4024;
buf[15] = 0;

> > +The format-magic for both modes is fixed at the value 4024
> > +encoded as 32-bit little endian.
>
> I am not familiar with this detail and the description does not make it
> completely clear, it appears to refer to some magic value of the on disk
> representation?

The magic is only used as an additional input to the MD5 digest
as part of the IV derivation.

Changed the description to hopefully clarify this.

> > +Encryption:
> > +
> > + IV = IVFUNC(optional-ivseed,
> > + plaintext[16..511],
> > + truncated-sector-number,
> > + format-magic)
>
> optional first argument in formalism makes it hard to relate to above decriptions.
> So maybe introduce IVFUNC where you describe them above, including ivseed which is
> simply unused in one variant.
>
> > + ciphertext[0..511] = CBC-ENCRYPT(key, IV, plaintext[0..511])
>
> I know that key=key_table[sector_number & 63] is mentioned further above but
> might be "too far back" for many readers as it is one of the things that are
> special about this encryption modes.

Agreed on both points. Could you have a look and see if you
find it clearer now in the new version?

Thanks a lot for your comments,

Max

Attachments:

(No filename) (3.36 kB)
lmk_doc_v2.patch (3.28 kB)
Download all attachments

2010-01-13 17:39:43

On Mon, Feb 01, 2010 at 11:32:27AM +0100, Max Vozeler wrote:
>
> I'm wondering if I'm heading in the right direction since
> this is stretching my understanding of the API:
>
> Would it look something like ccm, in that

Not quite.

> alloc does
> - crypto_grab_skcipher(spawn, "cbc(aes)"
> - crypto_skcipher_spawn_alg()
>
> then my alg.cra_init does
> - crypto_spawn_skcipher ?

The skcipher interface is synchronous only. It's OK for CCM and
GCM as we don't currently have an async CTR implementation.

For CBC however you really need the ablkcipher interface so that
all hardware implementations are available, notably the Intel AES
implementation is only available through the async interface.

The authenc/chainiv/seqiv drivers should serve as an example as
to how the ablkcipher interface can be used.

The other place where it differs from ccm is that ccm is an
AEAD algorithm, thus presenting itself through the crypto_aead
interface. You will on the other hand present an ablkcipher
interface.

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