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@xxxxxxxx
> http://www.saout.de/mailman/listinfo/dm-crypt
>
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx
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
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
