From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by mail.saout.de (Postfix) with ESMTP for ; Sat, 21 Aug 2010 09:30:25 +0200 (CEST) Date: Sat, 21 Aug 2010 09:30:25 +0200 From: Heinz Diehl Message-ID: <20100821073025.GA7167@fancy-poultry.org> References: <20100819142817.GA12238@fancy-poultry.org> <20100819183532.GB22363@tansi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100819183532.GB22363@tansi.org> Subject: Re: [dm-crypt] luksFormat Password Entropy List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On 19.08.2010, Arno Wagner wrote: > > So if you choose base64, P will always be 64, > No, actually, the input can restrict P to something smaller. I don't think you're right. If the input doesn't lead to the use of all of the chars available in base64, so does it "choose" from this pool anyway. P is the amount of possibly available chars and is unrelated to how many different ones out of this pool actually are used. To bruteforce the password, you'll have to try all the 64 possibilities for each position (ok, statistically you'll have to try 50% of the whole headroom). If you e.g. build a password which uses 5 numbers, P is 10 [0-9]. A password out of 5 capital letters, P = 26 [A-Z]. For each of the positions ("slots") in the password, there are 10 different possibilities related to the first, and 26 to the second password.