On Tuesday 27 June 2006 09:29, Miroslav Kure wrote: > I wrote a new section for d-i manual about using encryption. This was > greatly revised by David Hardeman and Max Vozeler and now we'd like to > receive some feedback from others. (Especially about the used English.) > Thanks for any comments! Thanks for writing! First question: where exactly do you intend to include this section? Should we maybe also add a few links to this section in the existing partman section. Also, we may need to add an arch parameter "supports-crypto"? Are there arches that are known not to support crypto? Review of the text itself and comments below. I've concentrated on grammar and readability, not on factual correctness. I've not done a real check for spelling although I suspect that may already have been done. Cheers, FJP > <!-- retain these comments for translator revision tracking --> > <!-- $Id: partman-crypto.xml 33725 2006-01-03 19:39:07Z mck-guest $ --> > > <sect3 id="partman-crypto"> > <title>Configuring Encrypted Volumes</title> > <para> > > &d-i; allows you to set up encrypted partitions. Every file you write > to such a partition is immediately saved to the device in encrypted > form. Access to the encrypted data is granted only after entering > the <firstterm>passphrase</firstterm> used when the encrypted > partition was originally created. This feature is useful to protect > sensitive data in case your laptop or hard drive gets stolen. The > thief might get physical access to the hard drive, but without knowing > the right passphrase, the data on the hard drive will look like random > characters. > > </para><para> > > The two most important partitions to encrypt are: the home partition, > where your private data resides, and the swap partition, where > sensitive data might be stored temporarily during operation. Of > course, nothing prevents you from encrypting any other partition that might s/partition/partitions/ > be of interest, for example database servers, mail servers or print > servers store their data in <filename>/var</filename>, various > programs put interesting temporary files in <filename>/tmp</filename>, > etc. Maybe better: be of interest. For example <filename>/var</filename> where database servers, mail servers or print servers store their data, or <filename>/tmp</filename> which is used by various programs to store potentially interesting temporary files. > Some people may even want to encrypt their whole system. The only > exception is the <filename>/boot</filename> partition, which must > remain unencrypted, because currently there is no way to load the s/,// > kernel from an encrypted partition. > > </para><note><para> > > Please note that the performance of encrypted partitions will be > less than that of unencrypted ones because the data needs to be > decrypted or encrypted for every read or write. The performance impact > depends on your CPU speed, chosen cipher and a key length. > > </para></note><para> > > To use encryption, you have to create new partition by selecting some > free space in the main partitioning menu. Another possibility is to s/new/a new/ s/possibility/option/ > choose an existing partition (e.g. a regular partition, LVM logical > volume or a RAID volume). In the <guimenu>Partition setting</guimenu> s/LVM/an LVM/ (for consistency) > menu, you need to change the first option to > read <menuchoice> <guimenu>Use as:</guimenu> > <guimenuitem>physical volume for encryption</guimenuitem> > </menuchoice>. The menu will then change to include several different > cryptographic options for the partition. Hmm. IMO better: you need to select <guimenuitem>physical volume for encryption</guimenuitem> at the <menuchoice> <guimenu>Use as:</guimenu> </menuchoice> s/several different/several/ > </para><para> > > Currently &d-i; supports several encryption methods. The default Either: s/Currently// or: s/several/two/ > method is <firstterm>dm-crypt</firstterm> (included in newer Linux > kernels, able to host LVM physical volumes), the other > is <firstterm>loop-AES</firstterm> (older, maintained separately from > the Linux kernel tree). Unless you have compelling reasons to do > otherwise, it is recommended to use the default. > > <!-- TODO: link to the "Debian block device encryption guide" > once Max writes it :-) --> > > </para><para> > > First, lets have a look at available options when you have selected s/lets/let's/ IMO better and more consistent with intro for loop-AES further down: s/available options when you have selected/ options available when you select/ [...] > The <firstterm>Initialization Vector</firstterm> or > <firstterm>IV</firstterm> algorithm is used in cryptography to ensure > that applying the cipher on the same <firstterm>clear text</firstterm> > data with the same key always produces unique s/unique/a unique/ > <firstterm>cipher text</firstterm>. The idea is to prevent the > attacker from deducing information from repeated patterns in the encrypted > data. > > </para><para> > > >From the provided alternatives, the default > <userinput>cbc-essiv:sha256</userinput> is currently the least > vulnerable to known attacks. Use the other alternatives only when you > need to ensure compatibility with some previously installed system > that is not able to use newer algorithms. > > </para></listitem> > </varlistentry> > > <varlistentry> > <term>Encryption key: <userinput>Passphrase</userinput></term> > > <listitem><para> > > Here you can choose the type of the encryption key for this partition. Maybe also mention in the discussion of the various options if/how a passphrase will need to be entered when the system is booted or partition is mounted. > <variablelist> > <varlistentry> > <term>Passphrase</term> > <listitem><para> > > The encryption key will be computed<footnote> > <para> > > Using a passphrase as the key currently means that the partition will > be setup using <ulink url="&url-luks;">LUKS</ulink>. s/setup/set up/ ? Don't forget to add &url-luks; ;-) > </para></footnote> on the basis of a passphrase which you will be able > to enter later in the process. Maybe better: </para></footnote>. You will be prompted for a passphrase later in the partitioning process. > </para></listitem> > </varlistentry> > > <varlistentry> > <term>Random key</term> > <listitem><para> > > A new encryption key will be generated from random data each time you > try to bring up the encrypted partition. In other words: on every > shutdown the content of the partition will be lost as the key is > deleted from memory. (Of course, you could try to guess the key with a > brute force attack, but unless there is an unknown weakness in the > cipher algorithm, it is not achievable in our lifetime.) > > </para><para> > > Random keys are useful for swap partitions because you do not need to > bother yourself with remembering the passphrase or wiping sensitive > information from the swap partition before shutting down your > computer. However, it also means that you will not be able to use the s:not:<emphasis>not</emphasis>: > <quote>suspend-to-disk</quote> functionality offered by newer Linux > kernels as it will be impossible (during a subsequent boot) to recover > the suspended data written to the swap partition. > > </para></listitem> > </varlistentry> > </variablelist> > > </para></listitem> > </varlistentry> > > <varlistentry> > <term>Erase data: <userinput>yes</userinput></term> > > <listitem><para> > > Whether the content of this partition should be overwritten with s/Whether/Determines whether/ > random data before setting up the encryption. This is recommended > because it might otherwise be possible for an attacker to discern > which parts of the partition are in use and which are not. In > addition, this will make it harder to recover any leftover data from > previous installations.<footnote><para> > > It is believed that the guys from three-letter agencies can restore > the data even after several rewrites of the magnetooptical media, > though. > > </para></footnote> The "." belongs after the closing tag of the footnote (as previously agreed with especially French translator). > </para></listitem> > </varlistentry> > > </variablelist> > > </para><para> > > If you select <menuchoice> <guimenu>Encryption method:</guimenu> > <guimenuitem>Loopback (loop-AES)</guimenuitem> </menuchoice>, the menu > changes to provide the following options: > > > <variablelist> > <varlistentry> > <term>Encryption: <userinput>AES256</userinput></term> > > <listitem><para> > > Unlike the dm-crypt, loop-AES has the options for cipher and key size > combined, so you can select both at the same time. Please see the > above sections on ciphers and key sizes for further information. s/the dm-crypt/dm-crypt/ Or maybe: "For loop-AES, unlike dm-crypt, the options for ... are combined, ..." > </para></listitem> > </varlistentry> > > <varlistentry> > <term>Encryption key: <userinput>Keyfile (GnuPG)</userinput></term> > > <listitem><para> > > Here you can choose the type of the encryption key for this partition. s/choose/select/ [...] > After you have selected the desired parameters for your encrypted > partitions, return back to the main partitioning menu. There should > now be a new menu item called <guimenu>Configure encrypted > volumes</guimenu>. After you select it, you will be asked to confirm > the deletion of data on partitions marked to be erased and possibly > other actions such as writing a new partition table. On large > partitions this might take some time. s/On large/For large/ s/might/may/ ? s/some/considerable/ ??? > </para><para> > > Next you will be asked to enter a passphrase for partitions configured > to use one. Good passphrases should be longer than 8 characters, > should be a mixture of letters, numbers and other characters and > should not contain common dictionary words or information easily > associable with you (such as birthdates, hobbies, pet names, names of > family members or relatives, etc.). > > </para><tip><para> > > Before you input any passphrases, you should have made sure that your > keyboard is configured correctly and generates the expected > characters. If you are unsure, you can switch to the second virtual > console and type some text at the prompt. This ensures that you won't be > surprised later, e.g. by trying to input a passphrase using a qwerty > keyboard layout when you used an azerty layout during the installation. Hmm. I understood that the issue is more that the keyboard layout when rebooting may be different from the one during installation. This is not really covered by this text. I would also expect "warning" for that situation. > </para></tip><para> > > If you selected to use methods other than a passphrase to create > encryption keys, they will be generated now. Because the kernel may > not have gathered a sufficient amount of entropy at this early stage > of the installation, the process may take a long time. You could speed s/could/can help/ > up the process by generating entropy: e.g. by pressing random keys on > the keyboard, or by switching to the shell on the second virtual console > and generating some network and disk traffic (downloading some files, > feeding big files into <filename>/dev/null</filename>, etc.). > > <!-- TODO: Mention hardware random generators when we will support > them --> > > This will be repeated for each partition to be encrypted. > > </para><para> > > After returning to the main partitioning menu, you will see all > encrypted volumes as additional partitions which can be configured in > the same way as ordinary partitions. Now is the time to create > filesystems on them, assign them mount points, and, once you are > pleased with the partitioning scheme, continue with the installation. s/filesystems/file systems/ s/pleased/satisfied/ > </para><para> > > If everything went well, after the installation finishes and you > boot your new system, you should be asked to enter the passphrases for > your encrypted volumes after which the boot should continue as usual. > > </para> > </sect3>
Attachment:
pgp6fmTTFnmeo.pgp
Description: PGP signature