Re: [dm-crypt] En/decrypting in multi-sector batches?

[Arno Wagner <arno@wagner.name>]

Hi Will,

as far as I know, unless you go to really large block size, in 
escess of megabytes, there is no negative security impact.
For really large block sizes, I would have to check, but if I 
remember correctly, the problem with CBC starts only at the 
point where you start to have a real chance to re-use the IV 
by the birthday paradox. That would be somewhere above the TB
range.

As to why these small sectors are used, as far as I understand, 
they are what the device mapper uses internally as smallest 
possible blocksize, but Milan would know more.

Any benchmarkks about your results? 

Arno


On Tue, Apr 26, 2011 at 10:17:40AM -0500, Will Drewry wrote:
> Hi,
> 
> Recently, I've been benchmarking some different hardware crypto
> accelerators and many of them appear to be tuned toward largish
> requests (up to 16k) with a given key and a base IV.  I've created a
> very simple patch for dm-crypt that uses PAGE_SIZE blocks to aid in
> the driver performance testing, but I lack the cryptographic
> understanding to determine if there is significant exposure by
> allowing a dm-crypt device to use a block size that exceeds the sector
> size.  For instance, I was thinking about allowing a block size that
> is a multiple of sectors - rather than just one sector.  (I was
> picturing adding an argument to the end of the table that was the
> number of sectors to use as the block size with a default of "1".)
> But I'm not confident that I understand the full impact (but it sure
> is nice to more fully utilize the available hardware :).
> 
> So,
> 1. Does anyone know if there will be significant exposure to the
> plaintext if dm-crypt used larger block sizes?
> 2. Would an optional, configurable block-size (up to PAGE_SIZE) be of
> interest?  If so, would it make sense to be per-target or a
> compile-time constant?
> 
> I've attached the basic patch without any sort of ability to configure
> the value to provide a more concrete explanation of what I'm trying to
> explain It changes the dm-crypt block size to PAGE_SIZE from sector
> size.
> 
> Any and all thoughts about change viability or cryptographic impact
> would be appreciated!  I'm more than happy to rewrite this into
> something that would be acceptable, if there's interest.
> 
> thanks!
> will
> 
> 
> 
> --- drivers.orig/md/dm-crypt.c	2011-02-17 17:26:08.246685915 -0600
> +++ drivers/md/dm-crypt.c	2011-02-01 16:53:03.764387497 -0600
> @@ -416,20 +416,20 @@ static int crypt_convert_block(struct cr
> 
>  	dmreq->ctx = ctx;
>  	sg_init_table(&dmreq->sg_in, 1);
> -	sg_set_page(&dmreq->sg_in, bv_in->bv_page, 1 << SECTOR_SHIFT,
> +	sg_set_page(&dmreq->sg_in, bv_in->bv_page, 1 << PAGE_SHIFT,
>  		    bv_in->bv_offset + ctx->offset_in);
> 
>  	sg_init_table(&dmreq->sg_out, 1);
> -	sg_set_page(&dmreq->sg_out, bv_out->bv_page, 1 << SECTOR_SHIFT,
> +	sg_set_page(&dmreq->sg_out, bv_out->bv_page, 1 << PAGE_SHIFT,
>  		    bv_out->bv_offset + ctx->offset_out);
> 
> -	ctx->offset_in += 1 << SECTOR_SHIFT;
> +	ctx->offset_in += 1 << PAGE_SHIFT;
>  	if (ctx->offset_in >= bv_in->bv_len) {
>  		ctx->offset_in = 0;
>  		ctx->idx_in++;
>  	}
> 
> -	ctx->offset_out += 1 << SECTOR_SHIFT;
> +	ctx->offset_out += 1 << PAGE_SHIFT;
>  	if (ctx->offset_out >= bv_out->bv_len) {
>  		ctx->offset_out = 0;
>  		ctx->idx_out++;
> @@ -442,7 +442,7 @@ static int crypt_convert_block(struct cr
>  	}
> 
>  	ablkcipher_request_set_crypt(req, &dmreq->sg_in, &dmreq->sg_out,
> -				     1 << SECTOR_SHIFT, iv);
> +				     1 << PAGE_SHIFT, iv);
> 
>  	if (bio_data_dir(ctx->bio_in) == WRITE)
>  		r = crypto_ablkcipher_encrypt(req);
> @@ -1294,6 +1294,17 @@ static int crypt_map(struct dm_target *t
>  	return DM_MAPIO_SUBMITTED;
>  }
> 
> +#define CRYPT_BLOCK_SIZE PAGE_SIZE
> +static void crypt_io_hints(struct dm_target *ti,
> +			    struct queue_limits *limits)
> +{
> +	limits->logical_block_size = CRYPT_BLOCK_SIZE;
> +	limits->physical_block_size = CRYPT_BLOCK_SIZE;
> +	blk_limits_io_min(limits, CRYPT_BLOCK_SIZE);
> +}
> +
> +
> +
>  static int crypt_status(struct dm_target *ti, status_type_t type,
>  			char *result, unsigned int maxlen)
>  {
> @@ -1433,6 +1444,7 @@ static struct target_type crypt_target =
>  	.message = crypt_message,
>  	.merge  = crypt_merge,
>  	.iterate_devices = crypt_iterate_devices,
> +	.io_hints = crypt_io_hints,
>  };
> 
>  static int __init dm_crypt_init(void)
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier