From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Sun, 8 Feb 2015 18:42:04 +0100 (CET) Received: from localhost ([88.90.246.181]) by mrelayeu.kundenserver.de (mreue001) with ESMTPSA (Nemesis) id 0Ldwwm-1XqgI33YYG-00pt3l for ; Sun, 08 Feb 2015 18:42:04 +0100 Date: Sun, 8 Feb 2015 18:42:02 +0100 From: Heinz Diehl Message-ID: <20150208174202.GA7437@fritha.org> References: <54D77140.3060804@ramses-pyramidenbau.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 On 08.02.2015, U.Mutlu wrote: > 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). Neither AES, serpent nor twofish are prone to known-plaintext attacks. Breaking some rounds is not the same as breaking the cipher. > 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. You're mixing symmetric/asymmetric crypto and block cipher modes. A stream cipher is a symmetric key cipher. The random keystream is used to encrypt the plaintext, using its seed as the "key". (Btw: dm-crypt works symmetrically, too). An example for asymmetric encryption would be GPG, which uses a public/private keypair. What you describe reminds me on the (ages old - around 1980?) CBC mode, where the IV is derived from the previous encrypted block. The first plaintext block is xor'ed to an IV with the same size as the plaintext block itself. CBC is therefore prone to choosen plaintext attacks. The last "C" in the name says it. All of this is by no means specific for LUKS/dmcrypt. And there are surely a lot of others with deeper knowledge who can explain this better to you..