From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Sun, 8 Feb 2015 17:31:56 +0100 (CET) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YKUm3-0001pm-8M for dm-crypt@saout.de; Sun, 08 Feb 2015 17:31:55 +0100 Received: from ip4d151e07.dynamic.kabel-deutschland.de ([77.21.30.7]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 08 Feb 2015 17:31:55 +0100 Received: from for-gmane by ip4d151e07.dynamic.kabel-deutschland.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 08 Feb 2015 17:31:55 +0100 From: "U.Mutlu" Date: Sun, 08 Feb 2015 17:31:49 +0100 Message-ID: References: <54D77140.3060804@ramses-pyramidenbau.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit In-Reply-To: <54D77140.3060804@ramses-pyramidenbau.de> Subject: Re: [dm-crypt] inner workings of block mode encryption List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de Ralf Ramsauer wrote, On 02/08/2015 03:22 PM: > Hi, > > maybe you should start here: > https://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions > > On 02/08/2015 03:06 PM, U.Mutlu wrote: >> Hi, >> I'm interessted in the inner workings of encrypting block devices >> like the encrypted volumes created with the cryptsetup tool. >> >> Let's say a file of size 200K is stored on an encrypted ext2 filesystem. >> How is the enrcyption key applied to it? > To sum it up: > cryptsetup is independent of the overlying filesystem and does not care > about it. > It just acts as a "mapper" and creates a new block device which > represents plain text data. > You can use this device for any purpose of your choice: create a > filesystem on it, use it as a LVM Volume, .... >> >> I guess the password is used only for accessing/mounting the volume, >> and the key is only a starting value (ie. a "seed") for the underlying >> cipher. > You can use a passphrase or a keyfile with cryptsetup LUKS. > This key is applied to a key derivation function which derives an > intermediate key which is used for decrypting a key slot which contains > the actual master-key for decrypting your volume. > This key slot or "lock box" concept opens the possibility that several > key files or passphrases may unlock the volume. > The material which is needed for decrypting the device is located in the > LUKS header. See FAQ. >> >> Since in these cases usually a blockwise operating cipher is used, >> that means that the file will be encrypted of course blockwise, >> for example in blocks of 32 bytes. > Yes, almost. > dm-crypt uses a sector size of (correct me if i'm wrong) 512 Byte which > means that every sector of 512 Byte gets en/decrypted independently. > The encryption of each sector is parameterized by an initialization > vector which may be influenced by the logical number of the sector. >> >> Now the question: are the blocks of that file all encrypted using the >> same one key? Or does a kind of "streaming" or HMAC get used for the >> subsequent blocks of the file? > Well yes and no. > Yes, the same key is used for all sectors of the volume and no, dm-crypt > does not use HMAC to generate key streams. Hmm. IMO this is the major weak point of such static/symmetric crypto solutions. Knowing just one cleartext file, for example a well known static system file from the /etc directory, and its encrpted data, could easily lead to the master key (assuming the encrypted volume contains such system files). OTOH, a streaming crypto solution (I think also called 'asymmetric'), ie. where each block gets encrypted with a new key derived from the previous/initial key together with xoring with varying parts of the user data in the block, would IMO make up a much more secure crypto solution. > Just imagine: if you'd like to access the last sector of your volume > you'd have to generate the whole key stream which would probably take a > long time. Yes, true, but I think this problem could be somehow solved. > > cheers > Ralf -- cu Uenal