public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* dm-crypt, new IV and standards
@ 2004-02-19 22:06 Carl-Daniel Hailfinger
  2004-02-19 22:20 ` Christophe Saout
  0 siblings, 1 reply; 28+ messages in thread
From: Carl-Daniel Hailfinger @ 2004-02-19 22:06 UTC (permalink / raw)
  To: christophe; +Cc: Linux Kernel Mailing List, Andrew Morton

Hi,

after having read what I believe to be all dm-crypt related mails on lkml,
I have a question which I could not find an answer for:
(and I noticed Andrew Morton worrying about backwards compatibility)

Would it be sensible (AFAICS there is not technical limitation) to reserve
512/1024/2048/whatever bytes at the beginning of every backing device for
dm-crypt so that the dm-crypt device could get some info about the used
methods automatically?

So this meta-information superblock could contain the following:
- A magic string like CRYPTSPACE (like SWAPSPACE2)
- The key used to encrypt the device (the key would be encrypted with the
password)
- The IV algorithm used
- The cipher used
- The way the password was hashed
- If some conversion was underway last time the dm-crypt device was accessed

This way, the following benefits would appear:
- New dm-crypt devices can be differentiated from old cryptoloop ones
- Since the password is independent of the key, you can change the
password without reencrypting the entire device.
- Since the key is independent of the password, you can change the key,
reencrypt the entire device and still keep your old password.
- You can change the default IV to something more secure than the current
default one without having to fear userland breakage.
- There are multiple ways to hash a password and with the current scheme
we have to try all of them if we do not know which version of the tools
was used to create the file.
- If the device is currently being reencrypted and is halfway through and
the power fails, we would know that some part of the device is old
encryption and some part is new encryption.
- New (more secure) crypto algorithms/ IV generation schemes/ passphrase
hashing schemes could be added (or even made default) without violating
the principle of least surprise.

I am not an expert in crypto, so if you tell me this would reduce security
or cause other problems, I will accept that. I am aware that the more
information an attacker has, the easier it is for him to break the encryption.


Regards,
Carl-Daniel


^ permalink raw reply	[flat|nested] 28+ messages in thread
* RE: 2.6.3 adaptec I2O will not compile
@ 2004-02-26 14:56 Salyzyn, Mark
  2004-03-02  6:52 ` Jaco Kroon
  0 siblings, 1 reply; 28+ messages in thread
From: Salyzyn, Mark @ 2004-02-26 14:56 UTC (permalink / raw)
  To: David Lang, Jaco Kroon; +Cc: Adrian Bunk, Linux Kernel Mailing List

My code fragment has (original multiversion and version in 2.4.24):

/*
 * scsi_unregister will be called AFTER we return.
 */
static int adpt_release(struct Scsi_Host *host)
{
        adpt_hba* pHba = (adpt_hba*) host->hostdata[0];
//      adpt_i2o_quiesce_hba(pHba);
        adpt_i2o_delete_hba(pHba);
        return 0;
}

So I am unsure as to how *that* (the scsi_unregister call) got in there
in the 2.6.3 stream. adpt_i2o_queisce was commented out in version 2.4.5
of the driver (Prior to the `historical documents' and at least the
in-box driver for RH7.3). It was not part of the 2.6.2 tree I based my
patch on and not part of the submitted 2.6 patch for the dpt_i2o driver.

adpt_i2o_quiesce tells the adapter to stop all activity, including
builds, and is a blocking command with a 4 minute timeout.

Sincerely -- Mark Salyzyn

-----Original Message-----
From: David Lang [mailto:david.lang@digitalinsight.com] 
Sent: Thursday, February 26, 2004 5:24 AM
To: Salyzyn, Mark; Jaco Kroon
Cc: Adrian Bunk; Linux Kernel Mailing List
Subject: Re: 2.6.3 adaptec I2O will not compile

Mark, do you have any comments on this?

On Thu, 26 Feb 2004, Jaco Kroon wrote:

> Date: Thu, 26 Feb 2004 01:28:14 -0800
> From: Jaco Kroon <jkroon@cs.up.ac.za>
> To: David Lang <david.lang@digitalinsight.com>
> Cc: Adrian Bunk <bunk@fs.tum.de>,
>      Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Subject: Re: 2.6.3 adaptec I2O will not compile
>
> David Lang wrote:
>
> >I received a post from Mark Salyzyn with a new driver that does
> compile,
> >he said that he has submitted the patches (I didn't get a chance to
try
> >the new kernel yet, I expect to do that shortly and will report any
> >problems)
> >
> >D
> >
> Somebody just mailed me a patch too, but I found the following
> discrepancy:
>
> /*
>  * scsi_unregister will be called AFTER we return.
>  */
> static int adpt_release(struct Scsi_Host *host)
> {
>     adpt_hba* pHba = (adpt_hba*) host->hostdata[0];
> //  adpt_i2o_quiesce_hba(pHba);
>     adpt_i2o_delete_hba(pHba);
>     scsi_unregister(host);
>     return 0;
> }
>
> This is used to release the host, now read the comment, and then the
> line just before the return.  This line was added by the patch, which
> also commented out the quiesce line.  Is it possible to get any
> confirmation on how this is supposed to function?
>
> Jaco
>
> ===========================================
> This message and attachments are subject to a disclaimer. Please refer
> to www.it.up.ac.za/documentation/governance/disclaimer/ for full
> details.
> Hierdie boodskap en aanhangsels is aan 'n vrywaringsklousule
onderhewig.
> Volledige besonderhede is by
> www.it.up.ac.za/documentation/governance/disclaimer/ beskikbaar.
> ===========================================
>
>

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

^ permalink raw reply	[flat|nested] 28+ messages in thread
[parent not found: <547AF3BD0F3F0B4CBDC379BAC7E4189F38D76F@otce2k03.adaptec.com>]
end of thread, other threads:[~2004-03-16 17:42 UTC | newest]

Thread overview: 28+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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-26 14:56 2.6.3 adaptec I2O will not compile Salyzyn, Mark
2004-03-02  6:52 ` Jaco Kroon
     [not found] <547AF3BD0F3F0B4CBDC379BAC7E4189F38D76F@otce2k03.adaptec.com>
2004-03-16 14:20 ` Jaco Kroon

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox