All of lore.kernel.org
 help / color / mirror / Atom feed
From: ".. ink .." <mhogomchungu@gmail.com>
To: Milan Broz <mbroz@redhat.com>, dm-crypt@saout.de
Subject: Re: [dm-crypt] blkid and aes-cbc-plain/aes-cbc-essiv:sha256
Date: Mon, 12 Mar 2012 21:03:10 -0400	[thread overview]
Message-ID: <CAFnMBaS9FYFTryhFFw3L7gFG=iJWGkCeOa5PN1Kvzy8aQ1Sgsw@mail.gmail.com> (raw)
In-Reply-To: <4F5E7A6B.2090207@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1556 bytes --]

Thanks for your quick response,


> For plain mode, user must provide the cipher, mode and keysize.
> Please do not invent autodetection - you just proved it will lead
> to data corruption. This is one of the reasons why LUKS was invented,
> where cipher and mode is stored in metadata.
>


>
>> My suggestion is to ignore "aes-cbc-plain" and just use current default
> (and give user option to overwrite it manually).
>
> Milan
>

My tool is meant to be simple, that means the user provides only a path to
encrypted volume and a passphrase .All other options are default and hard
coded and a user can not change them.If a user want to use non default
option then the tool is too simple for them as it will lead to unnecessary
complexity.

Below is what happen when a user provides a path to an encrypted volume and
a passphrase to open a volume

1. The volume is checked to see if its luks or not. If it is, it is then
opened as luks with luks default as they are 1.4.1.

2. If a volume is not luks, it is then assumed to be plain and the first
attempt is to open it with plain defaults as they are in 1.4.1. If that
fail, it is then opened as plain with default values are they were in 1.3.0

I do not see any danger with the current design of supporting both plain
modes as long as,as it currently appear to be, mount can distinguish the
two.  The advise to drop "legacy mode" will make sense if the mount failure
is not a guaranteed way to distinguish the two(.it seem to be working so
far with vfat, ext3/4 file systems). Is this what you are saying?

[-- Attachment #2: Type: text/html, Size: 2277 bytes --]

  reply	other threads:[~2012-03-13  1:03 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-12 21:30 [dm-crypt] blkid and aes-cbc-plain/aes-cbc-essiv:sha256 .. ink ..
2012-03-12 22:36 ` Milan Broz
2012-03-13  1:03   ` .. ink .. [this message]
2012-03-13 14:46     ` Sven Eschenberg
2012-03-13 14:56       ` Arno Wagner
2012-03-13 16:14         ` .. ink ..
2012-03-13 18:34           ` Arno Wagner
2012-03-13 17:49   ` Javier Juan Martínez Cabezón
2012-03-13 18:38     ` Arno Wagner

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='CAFnMBaS9FYFTryhFFw3L7gFG=iJWGkCeOa5PN1Kvzy8aQ1Sgsw@mail.gmail.com' \
    --to=mhogomchungu@gmail.com \
    --cc=dm-crypt@saout.de \
    --cc=mbroz@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.