From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1t85Xb-3KzB for ; Thu, 28 Jun 2012 13:36:37 +0200 (CEST) Received: from awesome.dsw2k3.info (unknown [IPv6:2a01:198:661:1f::3]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Thu, 28 Jun 2012 13:36:36 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by awesome.dsw2k3.info (Postfix) with ESMTP id 2BAB0BFE52 for ; Thu, 28 Jun 2012 13:36:35 +0200 (CEST) Received: from awesome.dsw2k3.info ([127.0.0.1]) by localhost (awesome.dsw2k3.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5WpusH7Td0s for ; Thu, 28 Jun 2012 13:36:32 +0200 (CEST) Received: from citd.de (p4FC4E2BF.dip.t-dialin.net [79.196.226.191]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by awesome.dsw2k3.info (Postfix) with ESMTPSA for ; Thu, 28 Jun 2012 13:36:32 +0200 (CEST) Date: Thu, 28 Jun 2012 13:36:30 +0200 From: Matthias Schniedermeyer Message-ID: <20120628113630.GA10275@citd.de> References: <20120628063449.GB1499@fancy-poultry.org> <4FEC0DCA.9090604@gmail.com> <20120628102828.GA1523@fancy-poultry.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120628102828.GA1523@fancy-poultry.org> Subject: Re: [dm-crypt] maximum keyfile size List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On 28.06.2012 12:28, Heinz Diehl wrote: > On 28.06.2012, Milan Broz wrote: > > > Passphrase is interactively entered string > > (from real terminal, not stdint), keyfile is everything else. > > So the length of a keyfile is equivalent to the length of a > passphrase, or is there any difference which should let me choose a > bigger keyfile than one containing 64 chars for "maximum security", > assumed I'm using 512 bit encryption? If you shoot for maximum security that means you need at last 512 bit of ENTROPHY not characters (per se). As there are "values/bits missing" (at least the "\n") a 64 char key can't have the full 512 bit entrophy. But when using e.g. base64 encoding you can pack the full 512 bits of entrophy into 85.33 chars. Personally i round that up to 528 bit, to get an even 88 chars. For base64 encoding the length should be divisible by 3, otherwise you still get 88 chars (in this case) but the rest is filled with one or two "=" (Which you could also strip, it's no like you you need to be able to decode the string.) head -c 66 /dev/random | openssl base64 -A which gets you 88 chars. or head -c 64 /dev/random | openssl base64 -A | tr -d = which gets you 86 chars. Case one has 528 bits of entropy. Case two has 512 bits of entrophy + 4 "empty" bits. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous.