text:
Template:Article summary start Template:Article summary text Template:Article summary end
- 1 Introduction
- 1.1 Why Use Encryption?
- 1.2 What Methods are Available for System Encryption?
- 1.3 Caveats
- 1.3.1 Key Complexity and Availability
- 1.3.2 Encryption Algorithm
- 1.3.3 discard/TRIM support for solid state disks
- 1.3.4 System Encryption
- 1.3.5 Data Encryption
- 2 Initial Setup
- 2.1 Overview and Preparation
- 2.2 Secure Erasure of the Hard Disk Drive
- 2.3 Partitioning
- 3 Configuring LUKS
- 3.1 Mapping Physical Partitions to LUKS
- 3.2 Storing the Key File
- 3.2.1 External Storage on a USB Drive
- 3.2.2 Using udev
- 3.2.3 Generating the keyfile
- 3.2.4 Storing the keyfile
- 3.2.5 Configuration of initcpio
- 3.2.6 Storing the key as a plain (visible) file
- 3.2.7 Storing the key between MBR and 1st partition
- 3.3 Encrypting the Swap partition
- 3.4 Using a swap file for suspend-to-disk support
- 4 Installing the system
- 5 Remote unlocking of the root (or other) partition
- 6 Backup the cryptheader
- 7 Encrypting a loopback filesystem
- 8 Encrypting a LVM setup
- 8.1 LVM with Arch Linux Installer (>2009.08)
- 8.2 Applying this to a non-root partition
- 8.3 LVM and dm-crypt manually (short version)
- 8.3.1 Notes
- 8.3.2 Partitioning scheme
- 8.3.3 The commands
- 8.3.4 Install Arch Linux
- 8.3.5 Configuration
- 8.3.6 After rebooting
- 8.4 / on LVM on LUKS
- 9 Securing the unencrypted boot partition
- 10 Resources
Why Use Encryption?
In the simplest terms encryption is a method for establishing privacy.
There are presently two approaches to partition level encryption data encryption and system encryption.
Data encryption, defined as encrypting a users data, provides for many benefits including:
- Preventing unauthorized physical access to private data.
- Some confidence in data disposal when discarding obsolete systems.
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive, thus reducing the effectiveness of any data encryption system in place.
System encryption, defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:
- Preventing unauthorized physical access to operating system files
- Preventing unauthorized physical access to private data that may cached by the system.
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:
- Attempts to bypass the operating system by inserting a boot CD/USB
- Copying, modifying, or removing the hard disk drives when the computer is off
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the
/boot partition which must remain unencrypted in order for the machine to properly boot. However, system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.
What Methods are Available for System Encryption?
There are multiple current methods that can be employed for system encryption, including:
- loop-AES (loop-AES)
- loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.
- However loop-AES is considered less user-friendly than other options as it requires non-standard kernel support.
- standard device-mapper encryption (dm-crypt)
- This is the standard device mapper which can be used for those who like to have control over all aspects partition management.
- LUKS for dm-crypt (LUKS)
- LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.
- Briefly some key features that LUKS provides include:
- Support for either passphrase or keyfiles as encryption keys
- Per partition key creation and revocation
- Multiple passphrases or keyfiles for a particular partition
For any type of encryption the security of your privacy is dependent on two things:
- The complexity/availability of your key (see Wikipedia:Kerckhoffs's principle)
- The usage of a proven encryption algorithm
Key Complexity and Availability
The user-provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is too simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys.
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.
Encryption Algorithm
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.
discard/TRIM support for solid state disks
Solid state disk users should be aware that by default, Linux's full-disk encryption mechanisms will not forward TRIM commands from the filesystem to the underlying disk. The device-mapper maintainers have made it clear that TRIM support will never be enabled by default on dm-crypt devices because of the potential security implications; if TRIM support were enabled, an attacker may be able to tell which blocks have been used, how many blocks have been used, and other information that is exposed directly to the device when a TRIM is issued.
It may be possible to determine the filesystem utilized by your encrypted device through the data that is leaked by TRIM. Furthermore, any information that may be derived by a profile of block usage may be exposed by enabling TRIM support on an encrypted device.
As of linux version 3.1, support for dm-crypt TRIM pass-through can be toggled upon device creation or mount with dmsetup. Support for this option also exists in cryptsetup version 1.4.0 and up. To add support during boot, you will need to add "
:allow-discards" to the
cryptdevice option. The option should look like this:
For more information, including specific commands and details on dm-crypt TRIM pass-through, see these mailing list threads:
* http://article.gmane.org/gmane.linux.kernel.device-mapper.devel/14134 * http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/5166
System Encryption
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user-accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shut down. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.
/boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap,
/tmp, or root filesystems are unencrypted, only Data Encryption level of security has been accomplished.
Data Encryption
There are two common forms of data encryption:
- Encryption of data partitions on the same physical disk as the system.
- Encryption of data partitions on separate physical disks from the system.
Encryption of data partitions on the same physical disk as the system
The most common form of data encryption is encrypting the
/home partition.
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decreased by orders of magnitude when compared to system encryption. The reason for this is that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition.
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to
/var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or
/var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted
/home partition, readily available to assist them in accessing the encrypted data present on the disk.
Some have compared this to reducing the level of security from partition-based encryption to filesystem level encryption like System Encryption with eCryptfs.
Encryption of data partitions on separate physical disks from the system
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:
- USB Flash Drives
- External Hard Disk Drives or Separate Internal Hard Disk Drives
- CD/DVD/Blu-Ray Optical Media
- Magnetic Storage Media
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB flash drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.
Initial Setup
Overview and Preparation
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can be accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the Official Arch Linux Install Guide or the Beginners' Guide after the encrypted partitions are set up.
Routine creation of an encrypted system follows these general steps:
- Secure erasure of the hard disk drive(s)
- Partitioning and setup of encryption (LVM optional)
- Routine package selection and installation
- System Configuration
Secure Erasure of the Hard Disk Drive
Secure erasure of the hard disk drive involves overwriting the entire drive with random data.
Why perform secure of erasure of a drive?
There are two types of hard disk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.
- New Hard Disk Drives
- In hard drives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data, it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.
- Used Hard Disk Drives
- Repartitioning or reformatting a used hard drive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straightforward using data tools like Foremost to access the remnant data. Therefore hard drives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.
Overwriting a hard disk drive with random data
There are two sources of random data commonly used for securely overwriting hard disk partitions.
- badblocks
Using urandom
#dd if=/dev/urandom of=/dev/<drive> bs=1M
/dev/<drive> is the drive to be encrypted.
/dev/urandom will take a long time to completely overwrite a drive with "random" data. In the strictest sense,
/dev/urandom is less random than
/dev/random; however,
/dev/random uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of
/dev/random for overwriting hard disks impractical.
/dev/urandom takes an excessively long time on large drives of several hundred gigabytes or more (more than twenty-four hours). Frandom offers a faster alternative.
kill -USR1 $(pidof dd)
Using badblocks
#badblocks -c 10240 -wsvt random /dev/<drive>
/dev/<drive> is the drive to be encrypted.
badblocks command overwrites the drive at a much faster rate by generating data that is not truly random.
See also badblocks.
After the drive has been securely overwritten, it is time to create partitions and begin setting up an encrypted system.
There are multiple ways to create disk partitions:
LUKS is compatible with systems that require LVM and/or RAID as well as with with standard primary, extended, and logical partitions.
Standard Partitions
These are the partitions that most people are familiar with. They come in three flavors: primary partitions, extended partitions, and logical partitions.
- Primary Partitions
- These are the normal partitions recognized by the system BIOS. There can be up to four of these stored in the MBR.
- Extended Partitions
- These are primary partitions that also define another partition within themselves. Extended partitions were created to work around the original limit of four primary partitions.
- Logical Partitions
- These are the partitions that are defined within extended partitions.
LVM: Logical Volume Manager
The LVM allows for creation of volume groups for systems that require complex combinations of multiple hard disk drives and partitions that are not possible with standard partitions. LVM is covered in detail in the Arch Linux LVM Wiki Article which is recommended reading prior to continuing with the instructions on setting up LUKS with LVM located below.
How does LVM fit into the overall system?
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKS). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKS on LVM). However, the deployment of LVM on LUKS is considered much more generalizable. One reason for this is that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In this case, logical volume management would be layered on top of the hardware encryption – usage of LUKS would be superfluous.
Creating Disk Partitions
Disk partitions are created using:
# cfdisk
This will display a graphical interface for creating disk partitions.
There are two required partitions for any encrypted system:
- A root file system
- Will be encrypted and store all system and user files (
/home, etc.)
- An initial boot partition
- Will not be encrypted; the bootloader needs to access the
/bootdirectory where it will load the initramfs/encryption modules needed to load the rest of the system which is encrypted (see Mkinitcpio for details). For this reason,
/bootneeds to reside on its own, unencrypted partition.
Single Disk Systems
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However, if LVM is to be used, the space unoccupied by
/boot and swap should be defined as single large partition which will be divided up later at the LVM level.
Multiple Disk Systems
In systems that will have multiple hard disk drives, the same options exist as a single disk system. After the creation of the
/boot and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.
Configuring LUKS
Creating LUKS partitions with a passphrase is supported by the
/arch/setup program.
This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system.
The steps for accomplishing this through the graphical installer are very similar and can be located in the dialogue for manual configuration of the hard drive.
Mapping Physical Partitions to LUKS
Once the desired partitions are created it is time to format them as LUKS partitions and then mount them through the device mapper.
When creating LUKS partitions they must be associated with a key.
A key is either a:
- Passphrase
- Keyfile
It is possible to define up to 8 different keys per LUKS partition.
Using LUKS to Format Partitions with a Passphrase
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.
A full list of options
cryptsetup accepts can be found in the [Cryptsetup Manpage]
The options used here are:
-cdefines the cipher type
-yprompts for password confirmation on password creation
-sdefines the key size
- luksFormat addresses the LUKS extensions built into cryptsetup.
In the following examples for creating LUKS partitions, we will use the AES cipher in XTS mode; at present this is most generally used preferred cipher. Other ciphers can be used with cryptsetup, and details about them can be found here: Wikipedia:Block_cipher
Formatting LUKS Partitions
First of all make sure the device mapper kernel module is loaded by executing the following:
# modprobe dm_mod
In order to format a desired partition as an encrypted LUKS partition execute:
# cryptsetup -c <cipher> -y -s <key size> luksFormat /dev/<partition name>
Enter passphrase: <password> Verify passphrase: <password>
This should be repeated for all partitions except for
/boot and possibly swap.
The example below will create an encrypted root partition using the AES cipher in XTS mode (generally referred to as XTS-AES).
cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2
/boot partition must remain separate and unencrypted in order to load the kernel and boot the system.
Unlocking/Mapping LUKS Partitions with the Device Mapper
Once the LUKS partitions have been created it is time to unlock them.
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that
/dev/<partition name> is actually an encrypted device and should be addressed through LUKS using the
/dev/mapper/<name> so as not to overwrite the encrypted data.
In order to open an encrypted LUKS partition execute:
# cryptsetup luksOpen /dev/<partition name> <device-mapper name>
Enter any LUKS passphrase: <password> key slot 0 unlocked. Command successful.
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:
- cryptsetup luksOpen /dev/sda2 swap
- Once opened, the swap partition device address would be
/dev/mapper/swapinstead of
- Once opened, the swap partition device address would be
- cryptsetup luksOpen /dev/sda3 root
- Once opened, the root partition device address would be
/dev/mapper/rootinstead of
- Once opened, the root partition device address would be
/boot is not encrypted, it does not need a device mapped name and will be addressed as
Using LUKS to Format Partitions with a Keyfile
What is a Keyfile?
A keyfile is any file in which the data contained within it is used as the passphrase to unlock an encrypted volume. Therefore if these files are lost or changed, decrypting the volume will no longer be possible.
Why use a Keyfile?
There are many kinds of keyfile. Each type of keyfile used has benefits and disadvantages summarized below:
- keyfile.passphrase:
- this is my passphrase I would have typed during boot but I have placed it in a file instead
This is a keyfile containing a simple passphrase. The benefit of this type of keyfile is that if the file is lost the data it contained is known and hopefully easily remembered by the owner of the encrypted volume. However the disadvantage is that this does not add any security over entering a passphrase during the initial system start.
- keyfile.randomtext:
- fjqweifj830149-57 819y4my1- 38t1934yt8-91m 34co3;t8y;9p3y-
This is a keyfile containing a block of random characters. The benefit of this type of keyfile is that it is much more resistant to dictionary attacks than a simple passphrase. An additional strength of keyfiles can be utilized in this situation which is the length of data used. Since this is not a string meant to be memorized by a person for entry, it is trivial to create files containing thousands of random characters as the key. The disadvantage is that if this file is lost or changed, it will most likely not be possible to access the encrypted volume without a backup passphrase.
- keyfile.binary:
- where any binary file, images, text, video could be chosen as the keyfile
This is a binary file that has been defined as a keyfile. When identifying files as candidates for a keyfile, it is recommended to choose files that are relatively static such as photos, music, video clips. The benefit of these files is that they serve a dual function which can make them harder to identify as keyfiles. Instead of having a text file with a large amount of random text, the keyfile would look like a regular image file or music clip to the casual observer. The disadvantage is that if this file is lost or changed, it will most likely not be possible to access the encrypted volume without a backup passphrase. Additionally, there is a theoretical loss of randomness when compared to a randomly generated text file. This is due to the fact that images, videos and music have some intrinsic relationship between neighboring bits of data that does not exist for a text file. However this is controversial and has never been exploited publicly.
Creating a Keyfile with Random Characters
dd is used to generate a keyfile of 2048 bits of random characters.
# dd if=/dev/urandom of=mykeyfile bs=512 count=4
The usage of
dd is similar to initially wiping the volume with random data prior to encryption. While badblocks may also be used, most key files are on the order of a few kilobytes and there is no noticeable speed difference between dd or badblocks.
Creating a new LUKS encrypted partition with a Keyfile
When creating a new LUKS encrypted partition, a keyfile may be associated with the partition on its creation using:
# cryptsetup -c <desired cipher> -s <key size> luksFormat /dev/<volume to encrypt> /path/to/mykeyfile
This is accomplished by appending the bold area to the standard cryptsetup command which defines where the keyfile is located.
Adding Additional Passphrases or Keyfiles to a LUKS Encrypted Partition
LUKS supports the association of up to 8 keys with any single encrypted volume. Keys can be either keyfiles or passphrases.
Once an encrytped partition has been created, the initial key is associated at slot 0. Additional keys will occupy slots 1–7.
The addition of new keys to an encrypted partition is accomplished using cryptsetup with the
luksAddKey extension.
# cryptsetup luksAddKey /dev/<encrypted volume> /path/to/mykeyfile
/dev/<encrypted volume> is the volume that is to have the new key associated with it.
If the bolded area is present, cryptsetup will look for the keyfile defined at that location to associate with the encrypted volume specified.
Storing the Key File
External Storage on a USB Drive
Preparation for permanent device names
For reading the file from an USB stick it is important to access it through a permanent device name.
The numbering of the normal device names e.g.
/dev/sdb1 is somewhat arbitrary and depends on how many storage devices are attached and in what order, etc.
So in order to assure that the
encrypt HOOK in the initcpio finds your keyfile, you must use a permanent device name.
Quick method
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run the following:
# ls -l /dev/disk/by-label/
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1
# ls -l /dev/disk/by-uuid/
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1
In this case, I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in
/dev/disk/by-label/Keys, or if I had wanted to use the UUID I would find
/dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.
sdb2, ...) but not to the USB device (
sdb) itself.
Create a udev rule instead as described in the following section.
Using udev
Optionally you may choose to set up your flash drive with a udev rule. There is some documentation in the Arch wiki about that already; if you want more in-depth, structural info, read this guide. Here is quickly how it goes.
Get the serial number from your USB flash drive:
lsusb -v | grep -A 5 Vendor
Create a udev rule for it by adding the following to a file in
/etc/udev/rules.d/, such as
KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"
$SYMLINK and
$SERIAL with their respective values.
%n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute. If you have a custom rule of your own, you can put it in as well (e.g. using the vendor name).
Rescan your sysfs:
udevadm trigger
Now check the contents of
ls /dev
It should show your device with your desired name.
Generating the keyfile
Optionally you can mount a tmpfs for storing the temporary keyfile.
# mkdir ./mytmpfs # mount tmpfs ./mytmpfs -t tmpfs -o size=32m # cd ./mytmpfs
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.
So copy your keyfile to some place you consider as secure before unmounting.
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g.
The keyfile can be of arbitrary content and size. We will generate a random temporary keyfile of 2048 bytes:
# dd if=/dev/urandom of=secretkey bs=512 count=4
If you stored your temporary keyfile on a physical storage device, remember to not just (re)move the keyfile later on, but use something like
cp secretkey /destination/path shred --remove --zero secretkey
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)
Add the temporary keyfile with cryptsetup:
# cryptsetup luksAddKey /dev/sda2 secretkey Enter any LUKS passphrase: key slot 0 unlocked. Command successful.
Storing the keyfile
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure). In any case you have to do some further configuration, if not already done above.
Configuration of initcpio
You have to add two extra modules in your
/etc/mkinitcpio.conf, one for the drive's file system and one for the codepage. Further if you created a udev rule, you should tell
mkinitcpio about it:
MODULES="ata_generic ata_piix nls_cp437 vfat" FILES="/etc/udev/rules.d/8-usbstick.rules"
In this example it is assumed that you use a FAT formatted USB drive. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.
Additionally, insert the
usb hook somewhere before the
encrypt hook.
HOOKS="... usb encrypt ... filesystems ..."
If you have a non-US keyboard, it might prove useful to load your keyboard layout before you are prompted to enter the password to unlock the root partition at boot. For this, you will need the
keymap hook before
Generate a new image (maybe you should backup a copy of your old kernel26.img first):
mkinitcpio -g /boot/kernel26.img
Storing the key as a plain (visible) file
Be sure to choose a plain name for your key – a bit of 'security through obscurity' is always nice ;-). Avoid using dotfiles (hidden files) – the
encrypt hook will fail to find the keyfile during the boot process.
You have to add a kernel parameter in your
/boot/grub/menu.lst (GRUB). It should look something like this:
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey
This assumes
/dev/usbstick is the FAT partition of your choice. Replace it with
/dev/disk/by-... or whatever your device is.
That is all, reboot and have fun!
Storing the key between MBR and 1st partition
We will write the key directly between the Master Boot Record (MBR) and the first partition.
If you have a bootloader installed on your drive you have to adjust the values. E.g. GRUB needs the first 16 sectors (actually, it depends on the type of the file system, so do not rely on this too much), so you would have to replace
seek=4 with
seek=16; otherwise you would overwrite parts of your GRUB installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key.
Optional If you do not know if you have enough free space before the first partition, you can do
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors hexcurse 64sectors # determine free space xxd 64sectors | less # alternative hex viewer
Write your key to the disk:
dd if=secretkey of=/dev/usbstick bs=512 seek=4
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.
You should not simply use
rm as the keyfile would only be unlinked from your filesystem and be left physically intact.
Now you have to add a kernel parameter in your
/boot/grub/menu.lst file (GRUB); it should look something like this:
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048
Format for the
cryptkey option:
OFFSET and
SIZE match in this example, but this is just coincidence - they can differ (and often will). An other possible example could be
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048
That is all, reboot and have fun! And look if your partitions still work after that ;-).
Encrypting the Swap partition
Without suspend-to-disk support
In systems where suspend to disk is not a desired feature, it is possible to create a swap file that will have a random passphrase with each boot.
This is accomplished by using dm-crypt directly without LUKS extensions.
Append a similar line to /etc/crypttab to set up a randomly encrypted swap partition:
<device-mapper name> <swap physical partition> SWAP "-c aes-xts-plain -h whirlpool -s 512"
<device-mapper name>represents the name you want to use as label in /etc/fstab
<swap physical partition>should be the ID of the actual partition.
Warning: You should use IDs here because if there are multiple hard drives installed in the system, their naming order (sda, sdb,...) can occasionally be scrambled upon boot and thus the swap would be created over a valuable file system, destroying its content.
ls -l /dev/disk/*/* | grep sdl7should help you to find the desired partition.
SWAPidentifies the partition as a swap partition
-cdefines a cipher
-hdefines a hash algorithm
-sdefines the key size
Example line (where
/dev/sdl7 is the physical partition and
LABEL=swap the desired label):
swap /dev/disk/by-id/scsi-SATA_Hitachi_HDS7220_JK1130YAGX0R1T-part7 SWAP "-c aes-xts-plain -h whirlpool -s 512"
- Maps
/dev/mapper/swapas a swap partition which we can now add in /etc/fstab like a normal swap.
If the partition chosen for swap was previously a LUKS partition, crypttab will not overwrite the partition to create a swap partition. This is a safety measure to prevent data loss from accidental mis-identification of the swap partition in crypttab. In order to use such a partition the LUKS header must be removed. This can be accomplished with:
# dd if=/dev/zero of=/dev/sdl7 bs=1M
With suspend-to-disk support
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a pre-existent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before
/etc/crypttab can be used, it is required to create a hook in
/etc/mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.
If you want to use a partition which is currently used by the system, you have to disable it first:
# swapoff /dev/<device>
To create the swap partition, follow steps similar to those described in mapping partitions above.
- Format the partition you want to use as swap with the
cryptsetupcommand. For performance reasons, you might want to use different ciphers with different key sizes.
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device>
Check the result with:
# cryptsetup luksDump /dev/<device>
- Open the partition in
# cryptsetup luksOpen /dev/<device> swapDevice
- Create a swap filesystem inside the mapped partition:
# mkswap /dev/mapper/swapDevice
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in
/etc/crypttab which uses this device. Now you have to create a hook to open the swap at boot time.
- Create a hook file containing the open command:
# vim: set ft=sh: run_hook () { cryptsetup luksOpen /dev/<device> swapDevice }
- Then create and edit the hook setup file:
# vim: set ft=sh: build () { MODULES="" BINARIES="" FILES="" SCRIPT="openswap" } help () { cat<<HELPEOF This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice HELPEOF }
- Add the hook
openswapin the
HOOKSarray in
/etc/mkinitcpio.conf, before
filesystem, but after
encryptwhich is mandatory as well. Do not forget to add the
resumehook between
filesystemas well.
- Regenerate the boot image:
# mkinitcpio -p linux
- Add the mapped partition to
/etc/fstabby adding the following line:
/dev/mapper/swapDevice swap swap defaults 0 0
- Set up your system to resume from
/dev/mapper/swapDevice. For example, if you use GRUB with kernel hibernation support, add
resume=/dev/mapper/swapDeviceto the kernel line in
/boot/grub/menu.lst. A line with encrypted root and swap partitions can look like this:
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro
At boot time, the
openswap hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they are placed after
openswap in the
HOOKS array. Please note that because of initrd opening swap, there is no entry for swapDevice in
/etc/crypttab needed in this case.
Using a swap file for suspend-to-disk support
- Choose a mapped partition (e.g.
/dev/mapper/rootDevice) whose mounted filesystem (e.g.
/) contains enough free space to hold the entire contents of your system's RAM. For example, if your system has 4 GiB RAM, then you need at least that much free space on the mounted filesystem of your chosen mapped partition for the swap file.
- Create the swap file (e.g.
/swapfile) inside the mounted filesystem of your chosen mapped partition. Be sure to activate it with
swaponand also add it to your
/etc/fstabfile afterward.
- Set up your system to resume from your chosen mapped partition. For example, if you use GRUB with kernel hibernation support, add
resume=your chosen mapped partition and
resume_offset=see calculation command below to the kernel line in
/boot/grub/menu.lst. A line with encrypted root partition can look like this:
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/rootDevice resume_offset=123456789 ro
You can calculate the
resume_offset of your swap file like this:
# filefrag -v /swapfile | awk '{if($1==0){print $3}}'
- Add the
resumehook to your
etc/mkinitcpio.conffile and rebuild the image afterward:
HOOKS="... encrypt resume ... filesystems ..."
Installing the system
Now that
/dev/mapper/root and
/dev/mapper/home are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.
# /arch/setup
Prepare hard drive
Skip the Partitioning and Auto-Prepare steps and go straight to manual configuration.
Instead of choosing the hardware devices (
/dev/sdaX) directly, you have to select the mapper devices created above.
/dev/mapper/root for your root and
/dev/mapper/home as
/home partition respectively and format them with any filesystem you like.
The same is valid for a swap partition which is set up like the
/home partition. Make sure you mount
/dev/sda1 as the
/boot partition, or else the installer will not properly set up the bootloader.
Select and Install packages
Select and install the packages as usual: the base package contains all required programs.
Configure System
encrypt hook is only needed if your root partition is a LUKS partition (or a LUKS partition that needs to be mounted before root). The
encrypt hook is not needed if any other partition (swap, for example) is encrypted. System initialization scripts (
/etc/rc.sysinit and
/etc/crypttab among others) take care of those.
Afterwards you can check the files presented to you by the installer, the most important one being
/etc/mkinitcpio.conf. For detailed information about mkinitcpio and its configuration refer to Mkinitcpio. You have to make sure that your
HOOKS array in
/etc/mkinitcpio.conf looks something like this:
HOOKS="... encrypt ... filesystems ..."
It is important that the
encrypt hook comes before the
filesystems hook. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:
HOOKS="... usb encrypt ... filesystems ..."
For safety, add
usb before
encrypt because the hooks are run in the order they appear.
If you need support for foreign keymaps for your encryption password, you have to specify the hook
keymap as well. I suggest putting this in
/etc/mkinitcpio.conf immediately before
If you have a USB keyboard, you will need the
usbinput hook in
/etc/mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.
If your root partition is a LUKS partition, add the used filesystem to the
MODULES section.
MODULES="... ext3 ext4 xfs ..."
Install Bootloader
GRUB: You have to make some small changes to the entries generated by the installer by replacing
/dev/mapper/root with
/dev/sda3. The important point to remember here is to use the same
cryptdevice name you assigned when you initially unlocked your device. In this example, the device name is
cryptroot; customize yours accordingly:
# (0) Arch Linux title Arch Linux root (hd0,0) kernel /vmlinuz-linux cryptdevice=/dev/sda3:cryptroot root=/dev/mapper/cryptroot ro initrd /initramfs-linux.img
For kernels older than 2.6.37, the syntax is:
# (0) Arch Linux title Arch Linux root (hd0,0) kernel /vmlinuz26 root=/dev/sda3 ro initrd /kernel26.img
LILO: Edit the Arch Linux section in
/etc/lilo.conf and include a line for the
append option, over the initrd, with the
root=/dev/sda3 parameter. The
append section makes the same kernel line as in GRUB. Also, you can omit the
root option above the
image option. The section looks like this:
# Arch Linux lilo section image = /vmlinuz26 # root = /dev/sda3 label = Arch initrd = /kernel26.img append = "root=/dev/sda3" read-only
cryptkey option. See the corresponding section below.
Exit Install
Now that the install is finished the only thing left to do is add entries to the
/etc/crypttab file so you do not have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.
# vi /mnt/etc/crypttab
Add the following line for the
/home partition
home /dev/sda5 "myotherpassword"
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described above.
Then add the following information to the
/etc/crypttab file for automounting:
home /dev/sda5 /path/of/your/keyfile
After rebooting you should now be presented with the text
A password is required to access the root filesystem:
followed by a prompt for a LUKS password. Type it in and everything should boot.
Once you've logged in, have a look at your mounted partitions by typing
mount. You should have
/dev/mapper/root mounted at
/ and, if you set up a separate encrypted home partition,
/dev/mapper/home mounted at
/home. If you set up encrypted swap,
swapon -s should have
/dev/mapper/swap listed as your swap partition.
Remote unlocking of the root (or other) partition
If you want to be able to reboot a fully LUKS-encrypted system remotely, or start it with a Wake-on-LAN service, you will need a way to enter a passphrase for the root partition/volume at startup. This can be achieved by running the
net hook along with an SSH server in initrd. Install the dropbear_initrd_encryptAUR package from the AUR and follow the post-installation instructions. Replace the
encrypt hook with
dropbear encryptssh in
/etc/mkinitcpio.conf. Put the
net hook early in the HOOKS array if your DHCP server takes a long time to lease IP addresses.
If you would simply like a nice solution to mount other encrypted partitions (such as
/home)remotely, you may want to look at this forum thread.
-–allow-discards from
/boot/grub/menu.lst. (Version: dropbear_initrd_encrypt 0.8-16). You won't notice any error when using online discard, but you see an error when you try to use
fstrim.For a temporary solution just add
-–allow-discards to every cryptsetup line of
/lib/initcpio/install/dropbear(1 line) and
/lib/initcpio/hooks/encryptssh(3 lines)
Backup the cryptheader
If the header of your encrypted partition gets destroyed, you will not be able to decrypt your data. Therefore, having a backup of the headers and storing them on another disk might be a good idea.
Attention: Many people recommend NOT backing up the cryptheader, but even so it's a single point of failure! In short, the problem is that LUKS is not aware of the duplicated cryptheader, which contains the master key which is used to encrypt all files on your partition. Of course this master key is encrypted with your passphrases or keyfiles. But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader! I.e. if someone has got your cryptheader and one of your keys he can decrypt the master key and access all your data. Of course the same is true for all backups you create of your partions. So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not. See also [1]Template:Linkrot for further details on this.
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)
cryptsetup luksDump /dev/sdaX | grep "Payload offset" Payload offset: 4040
Now that you know the value, you can backup the header with a simple dd command
dd if=/dev/sdaX of=./backup.img bs=512 count=4040
Using cryptsetup
You can also use the luksHeaderBackup command instead:
cryptsetup luksHeaderBackup /dev/sdaX --header-backup-file ./backup.img
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition). Restoring the wrong header or restoring to an unencrypted partition will cause data loss.
Again, you will need to the same values as when backing up:
dd if=./backup.img of=/dev/sdX bs=512 count=4040
Using cryptsetup
Or you can use the luksHeaderRestore command:
cryptsetup luksHeaderRestore /dev/sdaX --header-backup-file ./backup.img
Note: All the keyslot areas are overwritten; only active keyslots from the backup file are available after issuing this command.
Encrypting a loopback filesystem
[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]
Preparation and mapping
First, start start by creating an encrypted container!
dd if=/dev/urandom of=/bigsecret bs=1M count=10
This will create the file
bigsecret with a size of 10 megabytes.
losetup /dev/loop0 /bigsecret
This will create the device node
/dev/loop0, so that we can mount/use our container.
/dev/loop0: No such file or directory, you need to first load the kernel module with
modprobe loop. These days (Kernel 3.2) loop devices are created on demand. Ask for a new loop device with
losetup -f.
cryptsetup luksFormat /dev/loop0
This will ask you for a password for your new container file.
Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors, then run
modprobe dm-mod.
cryptsetup luksOpen /dev/loop0 secret
The encrypted container is now available through the device file
Now we are able to create a partition in the container:
mkfs.ext2 /dev/mapper/secret
and mount it...
mkdir /mnt/secret mount -t ext2 /dev/mapper/secret /mnt/secret
We can now use the container as if it was a normal partition! To unmount the container:
umount /mnt/secret cryptsetup luksClose secret losetup -d /dev/loop0 # free the loopdevice.
so, if you want to mount the container again, you just apply the following commands:
losetup /dev/loop0 /bigsecret cryptsetup luksOpen /dev/loop0 secret mount -t ext2 /dev/mapper/secret /mnt/secret
Encrypt using a key-file
Let us first generate a 2048 byte random keyfile:
dd if=/dev/urandom of=keyfile bs=1k count=2
We can now format our container using this key
cryptsetup luksFormat /dev/loop0 keyfile
or our partition :
cryptsetup luksFormat /dev/hda2 keyfile
Once formatted, we can now open the LUKS device using the key:
cryptsetup -d keyfile luksOpen /dev/loop0 container
You can now like before format the device
/dev/mapper/container with your favorite filesystem and then mount it just as easily.
The keyfile is now the only key to your file. I personally advise encrypting your keyfile using your private GPG key and storing an off-site secured copy of the file.
Resizing the loopback filesystem
First we should unmount the encrypted container:
umount /mnt/secret cryptsetup luksClose secret losetup -d /dev/loop0 # free the loopdevice.
After this we need to expand our container file with the size of the data we want to add:
dd if=/dev/urandom bs=1M count=1024 | cat - >> /bigsecret
Be careful to really use TWO
>, or you will override your current container!
You could use
/dev/zero instead of
/dev/urandom to significantly speed up the process, but with
/dev/zero your encrypted filesystems will not be as secure. (A better option to create random data quicker than
/dev/urandom is
frandom [2], available from the AUR).
Now we have to map the container to the loop device:
losetup /dev/loop0 /bigsecret cryptsetup luksOpen /dev/loop0 secret
After this we will resize the encrypted part of the container to the maximum size of the container file:
cryptsetup resize secret
Finally, we can resize the filesystem. Here is an example for ext2/3/4:
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs resize2fs /dev/mapper/secret
You can now mount your container again:
mount /dev/mapper/secret /mnt/secret
Encrypting a LVM setup
It's really easy to use encryption with LVM. If you do not know how to set up LVM, then read Installing_with_Software_RAID_or_LVM.
The easiest and best method is to set up LVM on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: Arch Linux: LVM on top of an encrypted partition
The most important thing in setting LVM on top of encryption is that you need to have the
encrypt hook before the
lvm2 hook (and those two before the
filesystems hook, but that's repeating) because they are processed in order.
To use encryption on top of LVM, you have to first set up your LVM volumes and then use them as the base for the encrypted partitions. That means, in short, that you have to set up LVM first. Then follow this guide, but replace all occurrences of
/dev/sdXy in the guide with its LVM counterpart. (E.g.:
/dev/sda5 ->
/dev/<volume group name>/home).
Do not forget to add the
encrypt hook in
/etc/mkinitcpio.conf before the
lvm2 hook, if you chose to set up encrypted partitions on top of LVM. Also remember to change
USELVM in
/etc/rc.conf to
LVM with Arch Linux Installer (>2009.08)
Since Arch Linux images 2009.08, LVM and dm_crypt is supported by the installer out of the box. This makes it very easy to configure your system for LVM on dm-crypt or vice versa. Actually the configuration is done exactly as without LVM: see the corresponding section above. It differs only in two aspects.
The partition and filesystem choice
Create a small, unencrypted boot partition and use the remaining space for a single partition which can later be split up into multiple logic volumes by LVM.
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params /dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512 /dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params /dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params /dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M /dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params /dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params
The configuration stage
- In
- In
/etc/mkinitcpio.confadd the
encrypthook before the
lvm2hook in the
HOOKSarray, if you set up LVM on top of the encrypted partition.
That is it for the LVM & dm_crypt specific part. The rest is done as usual.
Applying this to a non-root partition
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in
/lib/initcpio/hooks/encrypt (the first one to your
/dev/sd* partition, the second to the name you want to attribute). That should be enough.
The big advantage is you can have everything automated, while setting up
/etc/crypttab with an external key file (i.e. the keyfile is not on any internal hard drive partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change the order of
/etc/fstab (at least).
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking
/etc/rc.sysinit or similar files. Unlike
/etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.
If you want to do this on a software RAID partition, there is one more thing you need to do. Just setting the
/dev/mdX device in
/lib/initcpio/hooks/encrypt is not enough; the
encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices are not brought up until after the
encrypt hook is run. You can solve this by putting the RAID array in
/boot/grub/menu.lst, like
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5
If you set up your root partition as a RAID, you will notice the similarities with that setup ;-). GRUB can handle multiple array definitions just fine:
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5
LVM and dm-crypt manually (short version)
If you are smart enough for this, you will be smart enough to ignore/replace LVM-specific things if you do not want to use LVM.
Partitioning scheme
/dev/sda2-> LVM
The commands
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2 dd if=/dev/urandom of=/dev/mapper/lvm cryptsetup remove lvm lvm pvcreate /dev/sda2 lvm vgcreate lvm /dev/sda2 lvm lvcreate -L 10G -n root lvm lvm lvcreate -L 500M -n swap lvm lvm lvcreate -L 500M -n tmp lvm lvm lvcreate -l 100%FREE -n home lvm cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root cryptsetup luksOpen /dev/lvm/root root mkreiserfs /dev/mapper/root mount /dev/mapper/root /mnt dd if=/dev/zero of=/dev/sda1 bs=1M mkreiserfs /dev/sda1 mkdir /mnt/boot mount /dev/sda1 /mnt/boot mkdir -p -m 700 /mnt/etc/luks-keys dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256
Install Arch Linux
USELVM="no" to
lvm2 and
encrypt (in that order) before
filesystems in the
HOOKS array. Again, note that you are setting encryption on top of LVM.)
root=/dev/hda3 to
For kernel >= 2.6.30, you should change
root=/dev/hda3 to the following:
cryptdevice=/dev/lvm/root:root root=/dev/mapper/root
/dev/mapper/root / reiserfs defaults 0 1 /dev/sda1 /boot reiserfs defaults 0 2 /dev/mapper/tmp /tmp tmpfs defaults 0 0 /dev/mapper/swap none swap sw 0 0
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512 tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512
After rebooting
The commands
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home mkreiserfs /dev/mapper/home mount /dev/mapper/home /home
home /dev/lvm/home /etc/luks-keys/home
/dev/mapper/home /home reiserfs defaults 0 0
/ on LVM on LUKS
Make sure your kernel command line looks like this:
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group>
For example:
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg
Or like this:
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root
Securing the unencrypted boot partition
Referring to an article from the ct-magazine (Issue 3/12, page 146, 01.16.2012 http://www.heise.de/ct/inhalt/2012/03/6/) the following script checks all files under /boot for changes of sha1 hash, inode and occupied blocks on the hard drive. It also checks the MBR.
The script with installation instructions is available here: ftp://ftp.heise.de/pub/ct/listings/1203-146.zip (Autor: Juergen Schmidt, ju at heisec.de; License: GPLv2)
There is also an AUR package: https://aur.archlinux.org/packages.php?ID=56934
After installation do
echo "/usr/local/bin/chkboot.sh &" >> /etc/rc.local
And as chkboot_user.sh need to be excuted after login, add it to the autostarts.
- Install Archlinux on top of raid, LVM2 and encrypted partitions
- FreeOTFE - Supports unlocking LUKS encrypted volumes in Microsoft Windows.


text:
KaleidoscopeBook - 2002
When a brilliant young violinist dies in a horrific accident, Madame Karitska has only to hold the victim's instrument in her hands to perceive the shocking truth. But when an insecure wife asks whether her husband will abandon her to join a sinister cult, Madame Karitska-as wise as she is lovely-chooses not to reveal all that she foresees. And when an attach#65533; case is suddenly dropped into her lap by a man fleeing a crowded subway, she knows it's time to consult her good friend Detective-Lieutenant Pruden.
A nine-year-old accused of murder, a man dying a slow death by witchcraft- for the hunted and the haunted, Madame Karitska's shabby downtown apartment becomes a haven, where brilliant patterns of violence, greed, passion, and strange obsessions mix and disintegrate with stunning, kaleidoscopic beauty.
Once again Dorothy Gilman exercises her own uncanny power to render readers spellbound.
From the Hardcover edition.
From the critics
Community Activity
CommentAdd a Comment
My favorite author. Her story plots consistently have a different bent to them. It's unfortunate that she is no longer with us as I suspect that she could have continued writing many more unique story lines.
Dorothy Gilman's mysteries are not like the challenging multiple character complex mysteries like Patricia Cornwell's, or Elizabeth George's, or Michael Connelly's are. They are rather simple, but fun.
The reader doesn't have to work so hard and can just relax and enjoy a captivating little tale. In between the more intense mysteries, it's fun to read one of her books, or the books by Lilian Jackson Braun, of "The Cat Who" mystery series.
Dorothy Gilman's "Mrs. Pollifax" mystery series is also very delightful. To a woman who is almost 60, it's nice to see a woman of retirement age become expert in Karate, who can go on challenging adventures for the CIA.
This second book about the intriguing and mysterious Madam Karitska, is quite interesting and I hope Dorothy Gilman writes more about this capable and intelligent psychic who cares deeply for her clients. I just hope it doesn't take her another 27 years to write the 3rd book about Madame Karitska!! The 1st book about Madame Karitska was written in 1975, entitled, " The Clairvoyant Countess."
AgeAdd Age Suitability
There are no ages for this title yet.
SummaryAdd a Summary
There are no summaries for this title yet.
NoticesAdd Notices
There are no notices for this title yet.
QuotesAdd a Quote
There are no quotes for this title yet.

subset: commoncrawl


text:
On my shared drive, a single "fail" occurred. Do I have to worry, is this a temporary problem or a known issue?
Code: Select all
TOS version : 0206
Running from drv: O
Tested drive : N
Fsfirst, Fsnext, Fsetdta, Fgetdta
[0303] [Fsfirst & Fsnext - match all files ] [fail] [0000]


text:
Spend Time on Your Business. Not Sales Tax.
Let TaxJar automate your sales tax calculations, reporting, and filings in minutes.
Get started in minutes
Easily connect to the places where you sell
- Merchants: Simple one-click connection to your marketplace or cart. Say goodbye to spreadsheets and messy CSVs.
- Developers: View our demo and get your API token instantly! Use our docs to send your first API call for your custom cart.
TaxJar instantly prepares your state return-ready reports
- Merchants: Use TaxJar Reports to finish your returns in minutes, or choose to automate your filing with AutoFile.
- Developers: Share TaxJar Reports with your clients to help them easily remit their sales tax payments to the state.
Enroll in AutoFile.
You're done!
- Merchants & Developers: Choose to automate your filings with AutoFile and let TaxJar handle filing.
- Never miss a due date again. On-time, every time.
Need help along the way?
Just ask!
We're proud to offer world-class customer support for all customers. When you partner with TaxJar, you'll gain access to an experienced team of professionals who understand the ins and outs of sales tax.Visit support
Learn more about how TaxJar can save you hours on sales tax.Request a demo
See what others think of TaxJar
Are you a developer looking for accurate sales tax calculations?
TaxJar SmartCalcs comes with detailed documentation and open-source clients on GitHub for languages such as Ruby, PHP, Node, and .NET with more on the way. All you need is an API key to get started.
- Accurate Sales Tax Rates and Calculations
- Shipping and Product-Level Taxability
- International Support
- Easy to Use and Developer Friendly
Get started or Learn more
const Taxjar = require('taxjar'); const client = new Taxjar({ apiKey: '365ab65aa4d2200ce859fd64d4a762ff' }); // Get rates for a location (ZIP+4 w/ Street Address for Rooftop Accuracy) const rates = await client.ratesForLocation('05495-2086', { street: '312 Hurricane Lane', city: 'Williston', state: 'VT', country: 'US' }); // Click 'run'to see a rooftop accurate sales tax calculation
See how your business can save hours on sales tax
"When [a TaxJar Competitor] filed a zero return in California by mistake, TaxJar was able to file the correct return and rectify the problem."
Still Learning About Sales Tax?
We've got you covered.
Dig into more than 600+ relevant articles.
Learn what you need to know, subscribe and join the conversation.


text:
Stone City Bottled Water in Anamosa will soon distribute "his-and-hers" vitamin-enhanced bottled water – branded as H 10 O, with 10 essential gender-specific vitamins in each bottle – to local stores in 60 Iowa and Illinois counties. Men's flavors include "Citrus Sport," "Lemon Ice Tea," and "Orange Energy." Women's flavors are "Berry Sport," "Peach Mango Tea," and "Tropical Energy." The company sales account manager, Patrick Lage admits that there is really not much difference between the flavors for men and those for women. Mainly, the men's bottles have more B vitamins. Both men and woman can drink all six flavors without any problems. These bottles will be sold for a promotional price of $1 per bottle and then switch to a range between $1.59 and $1.79.
This is almost as ridiculous as the Candwich (sandwich in a can). Are bottled water companies getting desperate in the wake of environmentalist efforts? There is even an "environment" tab in the "About Us" section on the H 10 O website, to inform the consumer that these bottles are made with PET plastic, "the most easily recycled plastic available." They're not fooling me though. My advice? Save your money. Buy a water filter, take a multivitamin, eat healthy and exercise. It sounds like a lot, but the result is much more worthwhile in the end..


text:
It's getting closer and closer to Christmas and with that comes the inevitable flood of Christmas apps and games. To be sure, there's a lot of garbage that ends up in the Play Store this time of year but, there can also be some genuinely fun apps. The type of apps and games that make you happy about Christmas without ramming it down your neck. I think we've found one of those apps in Run, Santa Run! Read on to see if we're right!
Description: Run, Santa Run is a game that has you take on the role of ol' Saint Nic himself in order to deliver as many presents as he can before Christmas comes. It might sound easy but the game has you continuously running on a spherical world and you have to time your jumps in order to deliver the presents to each house. It starts off easy but as Santa slowly runs out of time, things start to get a little tricky. Take a look at the trailer below to see more:
How it Works: First of all, you'll need to go and install the app from the Play Store, after that you're good to go. From the main menu you can see that there are two modes to select from and that's a Kids Mode and a Normal mode. It also displays your personal record as well.
The aim of the game is pretty simple, you're tasked with delivering as many presents as you possibly can. To do this, you need to go from rooftop to rooftop. To do that, all you have to do is tap the screen at the right time.
The game starts off simply as you can see above but it soon gets pretty tricky and you end up having to really watch your timing with only short gaps in between buildings:
When you're up there things can get pretty hectic and if you fall from such a height then that's it – game over. Whenever you do fall from a building, you'll be given a Polaroid with your record, try to see what record you can come up with and let us know.
Let's go ahead and take a look at the Kids Mode, in general, buildings feature longer roof tops and the space between them isn't as close. There are also more coins to collect and trampolines along the way to lend a helping hand.
Opinion: I really enjoyed playing this game and not only because I quite like Christmas at heart but because it was the sort of game that goes well with Christmas cheer. It's a simple game that doesn't ask too much of the user and yet still presents great visuals and challenging gameplay. It's a very simple concept but if you've ever played Canabalt you'll know that not everything needs to be complicated to be fun. The kids mode is something I feel is a brilliant addition – it's that little bit easier and the kids will be able to play without getting too stuck or struggling.
- Speed (5/5) – Run, Santa Run runs brilliantly on a lot of devices and the pacing is just right for this sort of game.
- Features (4/5) – The gameplay might be considered too simple for some but if you want a challenging game that's easy to pick up and play then this is a great game for you to try out.
- Theme (5/5) – It's a Christmas game and it certainly looks the part and the graphics are really good as well – even on high-resolution displays.
- Overall (5/5) – As Christmas apps and games go, this might be the simplest but it's also one of the most polished and was a whole lot of fun.
Conclusion: If I were to recommend one game to help get yourself get in to the Christmas spirit, it'd certainly be this one. There's something that works so well about the combination of simple gameplay and good-looking Christmas graphics that makes this so appealing. It doesn't hurt that it's a free game either and with the Kids Mode built into the app it might well be a way for you to distract the little ones as you wrap their presents! For those that love Christmas and games in general, this is an excellent game to give a try and it's come at the right time!


text:
State Street Global Advisors said it plans to start disclosing the daily valuations of its money market mutual fund shares, following the lead of Fidelity Investments and a number of Wall Street banks earlier this month.
Money market funds typically price their shares at a constant $1, but there has been pressure from regulators to let the price float, reflecting the actual value of the bonds and other investments in the funds.
Boston-based Fidelity, State Street Global Advisors, and others have argued that a floating price and other proposed measures would weaken the $2.6 trillion industry. They want to keep listing the shares at $1 and to separately disclose the actual value, to appease regulators.
In a statement Wednesday, State Street Global Advisors, which is also known as SSgA, said, "As one of the largest providers of cash management solutions, SSgA actively supports steps to increase transparency in the money market fund industry."
State Street Global Advisors said it would begin disclosing the values on Jan. 28.
State Street Global Advisors is the asset management business of State Street Corp., a large financial services company headquartered in Boston.
Beth Healy can be reached at firstname.lastname@example.com.


text:
Adelaide consumers are paying more for power and water than is the case for people in the other capitals, the South Australian Council of Social Service (SACOSS) says.
SACOSS said Adelaide jumped ahead of Canberra and Melbourne for the first time in the September quarter this year.
Its latest check on utility prices found that people in Adelaide were spending an average of $53 a week on electricity and gas and $17.75 on water for a total bill of $70.75.
The next highest was Canberra on $69.23 followed by Melbourne on $67.38.
The cheapest city was Perth at $52.62.
"Expenditure on utilities is important because the bills are large, lumpy costs which are increasing at a rate that makes budgeting very difficult," SACOSS executive director Ross Womersley said.
"Utilities bills are a major driver of financial hardship, so it is disappointing to find that South Australian households are now the hardest hit, spending an average $153 per quarter more on utility bills than they were a year ago.
"There is now an urgent need to take action to provide relief to struggling households."
SACOSS said South Australia's Essential Services Commission should confirm a ruling which has called for an eight per cent drop in electricity prices and the state government should continue to offer rebates on water bills.


text:
Taxt1271 Imperator Wednesday 05/12/2012, 21:09
I'm level 33 with an ELO record of 1320 on this account and 1367 in a former one. I'm a decent ELO player when I put my mind to it and I'm currently working on getting clintz and doing better in Survivor ELO mode. Those are the only two modes I really play, but I'm quite decent at them considering my lackluster collection. I have much more experience with the game and knowledge of cards then this account would suggest because my former account had every non Cr card in the game.
I've been in several guilds, however all failed to deliver on what they promised and what I was looking for. The thing I want most in a guild is a really active message board and large, active member base. I don't care what level it is or what the guild perks are. Guild events/giveaways is always nice, but I'm mainly looking at message boards and member base.
I also run an Urban Rivals tumblr.
LB_Abnormal Titan Wednesday 05/12/2012, 23:56
Might wanna check out limit break buddy, seems we have everything you're looking for.


text:
Episode 29- Mike in Indy comes on for the final episode of the podcast- we chop up Smackoff 25 and the jungle conspiracy theories. Jeff in Southfield and the rest of the golden ticket holders and more
@THEMikeinIndy @BelligerentNuck
Episode 29- Mike in Indy comes on for the final episode of the podcast- we chop up Smackoff 25 and the jungle conspiracy theories. Jeff in Southfield and the rest of the golden ticket holders and more
@THEMikeinIndy @BelligerentNuck
Episode 28- Austin Huff- Former producer of "the Jim Rome show" – Host of "The Show" Podcast- and producer of "The Kevin Wheeler show" joins me to talk podcasting, the jungle and some of our random Any Given Sunday takes
Episode 24- Scott Callahan- AKA -Mama Cass AKA -Mama loves Ham is former fire fighter and US Army veteran. Scott is a long time clone and we get into his experience working for the FDNY on Sept.11/2001 and his subsequent decision to join the Army, and more.
Twitter: @Mama_loves_ham
Episode 23-Jeff Pearlman- Jeff is a New York Times bestselling author and frequent guest on "The Jim Rome Show"- his new book "Football for a buck" comes out Sept 11. 2018- its an in depth look at the USFL- Jeff and I discuss the book and more!
Twitter – @JeffPearlman
Episode 21- Vic in NoCal-Broadway
Vic in NoCal (Smackoff champ 2010) and legendary jungle villain joins me a week out from Smackoff 24 to talk about his twitter ban, the Smackoff and more.
Twitter- @DPeterbilt
Episode 20-Smackoff preview- Part 5- Team Canada
Team Canada weighs in on the Smackoff field in the last podcast before the event.
tweet at us your predictions.
Episode 20-Smackoff preview- part 4 Mike in Indy -Mike joins me to talk about the Smackoff field and who might be left out when its all said an done. we talk about the stuck nut odds and more.
Episode 20-Part 3-Mark in Hollywood joins me for some smack off talk (there is some political talk, be warned) and then the Champ Leff in Laguna joins me to break down the field and we respond to Brad in Corona.
Twitter: @MarkCharran @LeffinLaguna
Episode 20-Smackoff Preview Part 2- Smackoff participants Benny in Wisco, Mark in Boston and Kaleb in Green Bay join Matt and Tyler for some Smackoff talk.
Twitter- Benny @BennyinWisco Mark @MarkTheNomad Kaleb @KalebinGreenbay
Episode 20-Smackoff Preview episode-Part 1
Smackoff Golden Ticket holders Rick in Buffalo and Luke in Fort Collins check in. Ticket Hopefuls Cal in Vegas and Nooch (Mike in Little Rock) check in with updates on their golden ticket pursuits and the Smackoff field
Twitter Rick@RickinBuffalo Cal @CalinVegas Nooch @Bobaganooch
Episode 19-Tyler and Anton- The podcast residents join me again for our thoughts on the NHL playoffs and whats to come. (Hockey talk until until approx the 20:00 minute mark) Then Tyler and I recap our NewYork trip and we briefly discuss tinder and online dating.
Twitter Tyler @TylerinEdmonton Anton @AntonHimmel
Episode 18- 45 got fat (Warren)
Warren (@45gotFAT) a jungle favourite – joins me to discuss his brutal/unbelievable trip to Maui earlier this month. He discusses in detail the injuries, including nearly bleeding out where he was initially injured, and popping his replaced hip out in the hospital and subsequently experiencing the worst 5-7 minutes of his life.
Episode 17-Shey from the Bay-
We discuss calling the Jim Rome show, and twitter. we send some thoughts to first overall pick 45 after I learn of his recent injury live on the air after I randomly bring up his cat Denz. We discuss the NBA playoffs and the fact KD is a babyback bitch
Twitter @Sheyfromthebay
Episode 16-Leff in Laguna-The Sequel
Leff joins me again to talk about the Jim Rome Podcast, we have an email contest featuring some "known" emailers. and Leff and I draft a starting 5 of clones. whose team is better?
Episode 15- Cal in Vegas and Nooch (Mike in Little Rock)
Cal in Vegas Nooch and myself get on the phone to catch up around the 1 year anniversary of the infamous Vegas scope. We got loose about the smack off and more.
Episode 14- The Mike in Indy – The sequel
Episode 13-Toi Cook
Toi is an 11 year NFL veteran/in the Stanford Hall of Fame as a 2 sport star/Was drafted by MLB as well as the NFL/And he's a CLONE. We talk about the Jim Rome Show-clones and smack off. Toi discusses joining the 49ers and tells some great Jim Mora stories and much more.
Tyler and Anton and myself get to talking hockey after all doing some drinking. We cold call the Smackoff champ Leff in Laguna. we talk about clones, Twitter and sharing the reality of being a clone with friends and loved ones.
Benny is a Smackoff Participant, a hilarious clone and we had a good chat about his Smackoff adventures, winning our golden tickets on the same day, clones and smack off guys and more.
Adam Hawk is the Executive producer of "The Jim Rome Show" and joined me from Minnesota where he is working radio row for the Super Bowl. we discuss how he arrived in radio, the Jungle, The pacific North West, Canada, losing our NBA teams and more.
Twitter – Adam Hawk
Jason Stewart is a long time clone and a former longtime employee of the Jim Rome show. he's an actor and currently an executive producer. check out his Podcast "the bachelor lifestyle". we talk Jim Rome Show, clones, and the Smackoff evolution.
Jason Stewart – Twitter
Mark in Hollywood is an actor, a Smackoff Champ. An all around hilarious guy. We talk about his 20 Days in jail, working in hollywood and the Smackoff.
Mark in Hollywood – Twitter
Episode description – THE Mike in Indy is a legendary radio show caller known for his work on "The Jim Rome Show" radio program – He has takes for days and spares no suckers in this debut conversation for The Belligerent Canadian.


text:
Mixed messages for cycle safety in London
Mixed messages for cycle safety in London
75% of cyclists' injuries are at or near a junction, rising to 79% in London (see p14 of TfL's Cycle Safety Action Plan, PDF, 2.2MB). There is also good evidence that reducing traffic speeds at junctions - whether by introducing traffic lights, or by making drivers turn more sharply as they enter and leave a junction - are highly effective ways to improve cycle safety. Tackling major junctions surely has to be THE major cycle safety investment priority for the immediate years ahead, not just in London but in other parts of the UK too.
It may have taken the media furore following the deaths of Min Joo Lee at Kings Cross, and of Brian Dorling and Svitlana Tereshchenko at the Bow roundabout, before Transport for London finally started taking cycle safety at junctions seriously. But it is clear they are now doing so.
Once TfL got going, the rate at which they started reviewing junctions was initially more than the London Cycling Campaign's volunteers could keep up with! There is an obvious dilemma here for the cycle campaigner. You know that cycle safety requires urgent attention if we are to enable and encourage more people to cycle, and to feel safe and confident when doing so. However, it is also important that the new junction designs are done well, and not rushed through with inadequate planning and dialogue with local cyclists. It remains to be seen how good the solutions themselves will be. However, the planned rate of junction improvements - 10 to be done by 2012, another 40 by 2013, and a further 100 to be under consideration by then - now seems reasonable. The London Cycling Campaign are rightly pleased too - credit to them for some fantastic campaigning on the issue, particularly over the past year or so.
However, just 3 days after the announcement on planned junction improvements, the Mayor launched a draft road safety strategy for consultation. Unfortunately, it doesn't remotely reflect the very positive relationship which CTC, LCC and others have with TfL staff through their Cycle Safety Working Group. Here are a couple of quotes:
"We need to target risk by focusing on and tackling the specific road users and behaviours that are over-represented in the casualty data".
"A programme ... will target vulnerable road users with road safety campaigns and information to increase awareness of the main causes of collisions and to provide advice on travelling safety."
The draft strategy's 1960s approach to road safety - making the victim responsible, rather than the aggressor - is a bit like telling women not to wear clothing that might tempt men to rape them. The focus really needs to shift from tackling the symptoms of road danger to the underlying causes.
So, here's our "starter for 10" as a list of key points that the Mayor's Road Safety Strategy needs to take on board. The key underlying point is that it must adopt "road danger reduction" (i.e. tackling the sources rather than the symptoms of road danger) as an overarching principle. This in turn means:
- There must be a willingness to prioritise the safety of pedestrians and cyclists over "smoothing the traffic" - a Mayoral priority widely blamed for TfL's original reluctance to provide safe cycling conditions at the Bow Roundabout, at the Elephant & Castle and elsewhere.
- The junction safety improvement programme must include early analysis of how innovative solutions (e.g. advance cycle signals, as implemented at Bow Roundabout) are performing , in order to inform future programme development.
- TfL's plans for road safety research and analysis should focus on understanding the causes (not the symptoms) of cyclists' injuries, and how best to address these.
- Whilst it is undoubtedly useful to advise vulnerable road users of ways they can protect themselves from road danger, the primary focus of road safety awareness campaigns should be on the driver behaviours which endanger cyclists in the first place.
- There must be a much greater willingness to make 20mph speed limits the norm for most London streets (given that higher limits are only appropriate on a minority of the road network, and in locations signing is generally less intrusive than the streets where 20mph is appropriate).
- There must be a much greater willingness to explore solutions to the lethal risks posed by lorries, not just through better driver training / cameras and sensors / vehicle design etc (much as we welcome the progress made on these solutions), but also by reducing the volume of goods vehicles on London's roads at busy times, drawing on continental best practice (e.g. on traffic management solutions and trans-shipment).
- The joint TfL / Met Police study of how the criminal justice system deals with cyclist fatalities is a useful start, and a model for police forces and other CPS divisions around the country to follow. However, this and other recent developments have highlighted the need improvements performance in crash investigation, the management of cases (including liaison with police and other witnesses, and with the victims), charging decisions, and the accountability of the process overall.
- In order to gather data on perceptions of safety, we should urge TfL to ensure that all 33 boroughs are covered by the National Highways and Transport Survey (NHTS). This survey, run by MORI, collects data on public perceptions of various aspects of transport safety, and asks some very useful questions. Most, but not all, boroughs are taking part in it, yet the data remains under-exploited because it is only collected so that councils can benchmark their performance against one another, i.e. it is not published in a form which enables "the big society" to assess how their councils are performing.
CTC will be liaising with the London Cycling Campaign, Sustrans, British Cycling RoadPeace and others to ensure we deliver a strong joined-up message. The way London tackles cycle safety looks set to be a model that is now likely to be followed by other cities (notably Manchester) in the coming years. It is therefore really important to get the strategy right.


text:
Reginald Dwayne Betts's Sunday Afternoon [1]
Washington, D.C.-based poet Reginald Dwayne Betts, author of Shahid Reads His Own Palm and the memoir A Question of Freedom, blogs about participating in the P&W-supported reading at the Historical Society of Washington, D.C. in April 2010.
Kim Roberts's anthology, Full Moon on K Street: Poems About Washington, D.C., brought D.C. poets together at the Historical Society of Washington, D.C. [3] on a sunny April Sunday in 2010.
As soon as I arrived, I began reading a poem for Mississippi Avenue. The poem is about a couple of kids I once knew. They would play what we use to call throwback. Throwback is a game in which players would toss a football (or any ball) into a crowd of people, and then begin chasing the person who caught it. If the ball is memory, then the boys doing the chasing are hungry to remember. Full Moon on K Street is a little like that: memories we toss into crowds, then chase down.
Just as good as the reading was Roberts's welcome. She relived the history of the project and the tidbits of D.C. history that can be found within the book as an accompaniment to the poems. Full Moon on K Street is history and poetry. Truth is, Roberts's anthology is about making memories live in the present...that's what the reading was about too.
Photo: Reginald Dwayne Betts. Credit: Rachel Eliza Griffiths.
Support for Readings/Workshops [4] events in Washinton, D.C., is provided by an endowment established with generous contributions from the Poets & Writers Board of Directors [5] and others. Additional support comes from the Friends of Poets & Writers [6].


text:
Mauge is an established creative marketing and advertising agency specializing in unique solutions to help our clients reach their marketing goals. We provide well-planned approaches to effective, inventive advertising and develop marketing campaigns with a broad appeal. Recognizing that identity and branding are the keys to success, we have the skill and experience to place our broad range of clients in competitive market positions.
An expertise in high-end product and service communications drives our process and directs our team of experienced agency professionals, artists, designers, writers and IT experts. We blend experience with innovation to bridge the divides and develop intelligent, sharp-witted, polished campaigns.
A nimble agency of boutique size, we have the flexibility to work large jobs quickly and efficiently. Our diverse capabilities in the media arena including exceptional print, web, interactive, environment, film, video and broadcast experience.
LISTEN & EXPLORE — Meet our Account Management team – the listeners and askers. How do you envision your position within the marketplace? What are your customers thinking? Where would you like your company to be five years from now? What makes you passionate about your product or service? We need to know.
CREATE & APPLY — Guided by the insights and strategy already developed we embark on the creation of your project. It's here where our Creative Team begins brainstorming, jotting down and sketching out concepts. Coming up with ideas to best communicate your identity, brand and message.
DELIVER & REFLECT — The result of our process is consistently work delivered to you on time and on budget, with excellence and integrity. Anything less and we are not at the top of our game.
We are defined by our partnerships and supremely dedicated to the intelligent, creative work that results. We truly believe the creative process is a collaboration that merges our deep-rooted design and marketing abilities with our client's expertise in his/her field. Does Mauge sound like your kind of agency? Do you share a passion for great design? Great, let's get to work.
1629 N. Milwaukee Ave.
2nd Floor
Chicago, Illinois 60647
773 395 9919


text:
Groucho - Black / Cream
Black / Cream
What a spectacle! Show your humorous side and make your Marx with this small, perfectly round frame with a wonderful keyhole bridge. Brilliant for perching on the end of your nose.
Available in 12 colours!
* Licorice
* Crystal Tortoise
* Vintage Tortoiseshell
* Classic Tortoiseshell
* Caramel
* Taupe Tortoise
* Black/Tortoiseshell
* Blue Crystal
* Black/Cream Pearl
* Light Amber Crystal
* Black/Chocolate Swirl
* Crystal
Available in clear lens ready for reglazing to your prescription and
standard reading strengths.
**please note these frames require 1.60 index lens or thinner**
* Hand Made in France
* Hand polished frame
* Fixed hinges
* Keyhole bridge
This is a very small frame, please measure carefully
Size 35-28-145
width 145mm
width inside (hinge to hinge) 135mm
lens 35mm x 35mm
temple 135mm
bridge 17-28mm


text:
The Bayeux Tapestry might be a big deal for the French and English, but come on. It's old, the people look rubbish and it's not even a real tapestry!
It's embroidery, just like this epic image of all 151 original Pokémon, and if I had to choose between which one I'd hang on my wall, it'd be the Pokémon. Mostly because my office wall isn't big enough for the Bayeux Tapestry (it's 230 feet long), but partly because of the Pokémon.
Pokemon first generation — completed [Eponases]


text:
"Worldwide Email Encryption Market Historical Analysis and Forecast 2019-2028″ is created to give boundless guideline about contemporary market trends, size, share, progressive growth, driving factors and key competitors of Email Encryption market along with their strategies and methodologies. The report mainly focuses on the market dynamics with reference to all insightful analysis, value, and volume of players segmented by product, by region, by end users, and revenue structure.
In the beginning, the report adds market properties, industry structure, business stratagem, issues, and industry effectiveness. Email Encryption Market report will help you in planning business strategies, as well as in growth prospects, prior and futuristic revenue and costs Analysis. It covers a significant appraisal based on regions including market forecast up to 2028.
Further, the examination of Email Encryption Market provides an in-depth representation of key market growth drivers, future opportunities, threat, and their impact. The technological development associated with the market caused to uplift the Insight adoption.
To Get Exclusive Sample Copy Of this Report- https://marketresearch.biz/report/email-encryption-market/request-sample
There Are 5 Key Segments Covered In This Email Encryption Market Report:
– Competitor Segment
– Product Type Segment
– End-Use/Application Segment
– Geography Segment
– For Competitor Segment (The Report Includes Global TOP KEY PLAYERS Of Email Encryption Market As Well As Some Small Players.)
Global Email Encryption Market Segmentation:
Segmentation by type:
End-To-End Email Encryption
Gateway Email Encryption
Boundary Email Encryption
Hybrid Email Encryption
Client Plugins
Segmentation by deployment mode:
Segmentation by industry vertical:
IT and Telecom
Others (Education, Media & entertainment, Manufacturing, and Retail)
Promising Regions & Countries Mentioned In The Email Encryption Market Report:
1. North America (United States, Canada)
2. Europe (Germany, Spain, France, UK, Russia, and Italy)
3. Asia-Pacific (China, Japan, India, Australia, and South Korea)
4. South America (Brazil, Mexico, etc.)
5. The Middle East and Africa (GCC and South Africa)
Inquire for further detailed information of Email Encryption Market Report at: https://marketresearch.biz/report/email-encryption-market/#inquiry
• Email Encryption Market Drivers & Challenges:
* The Email Encryption Market report is inclusive of the pivotal driving forces influencing the commercialization landscape of the Email Encryption market and their impact on the revenue scale of this business field.
* The rising product demand from the key geographies as well as the essential key applications and potential business Field are also included in the Email Encryption Market Research report.
* Alongside, the Email Encryption Market research study is inclusive of the latest trends proliferating the market as well as the Claims that this business space is likely to present to the prominent competition of this business insight.
TOC of Email Encryption Market Report Contains:
=>Industry Overview
=>Production Market Analysis
=>Sales Market Analysis
=>Consumption Market Analysis
=>Production, Sales and Consumption Market Comparison Analysis
=>Major Manufacturers Production and Sales Market Comparison Analysis
=>Major Type of Email Encryption Analysis
=>Major Organization Size Analysis
=>Industry Chain Analysis
=>Global and Regional Market Forecast
=>Major Manufacturers Analysis
=>New Project Investment Feasibility Analysis
Pricing Details For Email Encryption Market Report: (Limited Period Offer) Single User- $3,995.00 | Multiple User- $6,600.00 | Corporate Users- $8,200.00
To Get Instant Access, Purchase Report @ https://marketresearch.biz/purchase-report/?report_id=11125
What is Single User, Multi-User and Corporate Users license?
Single user, multiple user, and corporate licenses are differentiated on the basis of the number of users permitted to use the ordered reports. For a single user license, the distribution of a report copy will be restricted to only one user. Understood by its term, a multiple user license will be restricted to more than one user, typically five users only. Corporate license holders, on the other hand, will be able to distribute a report copy across their organization.
Get in touch with us:
Mr. Benni Johnson
MarketResearch.Biz (Powered By Prudour Pvt. Ltd.)
420 Lexington Avenue, Suite 300
New York City, NY 10170,
United States
Tel: +1 347 826 1876
Email: email@example.com


text:
You got to love structural engineering…
Admin - 03:17 @ Structures | Add a comment
Seemingly Simplistic - Highly Technical
The Peace Bridge was designed by Spanish architect Santiago Calatrava. A double helix tubular truss for both pedestrians and cyclists crossing the Bow River in Calgary, Alberta, Canada.
The design required a different approach, due to the strict requirements with no piers in the riverbed or vertical elements above, and with a restricted height - resulting in its tubular form. Seemingly simplistic at first glance, but according to Calatrava, this is a highly technical bridge.
The helical structure with glass roof and integrated linear lighting for night-time illumination, consists of about 850 metric-tonnes of steel. Total length of the red and white bridge is 130.6 meters, with a height of 5.85 meters and a width of 6.2 meters, (3.7 meters for pedestrians and 2.5 meters for the cycle-way).
Today, this bridge is being used by approximately 6000 people a day.
World Architecture News (9 Aug 2009). "A stretch for Calatrava" (http://www.worldarchitecturenews.com/index.php?fus
eaction=wanappln.projectview&upload_id=12132). Retrieved 20090912.
Admin - 02:25 @ Structures | Add a comment
One of the most fascinating structures - the oil rigs…
Click here to open video of the Hejre Jacket installation.
Admin - 02:56 @ Structures | 1 comment
The Norway Sky Bridge
The name of the bridge changed from "Hardanger Brigdge" to " Norway Sky Bridge", after seeing this photo where the construction crew walked on the walkway on the bridge suspension cables. The rest of the bridge is shrouded in cloud, giving the appearance that the suspension cable walkway was the actual bridge.
The main span of the Bridge is 1,310 meters (4297.9 ft) – approximately 20 m longer than the Golden Gate Bridge of San Francisco. This makes the bridge the longest in Norway and 9th longest in the world.
The towers of the bridge must stand on shore due to the depth of the fjord. The maximum water depth near the bridge is about 500 m (1,600 ft), and the mountains surrounding the fjord are about 1,200 m (3,900 ft) high.
Admin - 03:42 @ Structures | 57 comments


text:
Uruguay, let yourself go!
Prosperous, tolerant and open onto the world, through the 20th century Uruguay has earned itself the nickname of the Switzerland of latin America. The mild mannered character of the Uruguayans is an invitation for visitors who enjoy history and culture to come and discover this country.
So close to the Argentinians in many respects and yet, so different… Just like their neighbors of the Rio de la Plata, they enjoy the tango, maté and football, but nevertheless in Montevideo you will discover a radically different way of life. A holiday in Uruguay is the opportunity to discover a unique country, which has managed like no other to successfully blend it's european roots with the characteristic south american boldness.
A stay in Uruguay is the promise of superb beaches. A popular fixture with Argentinians and the Brazilian jet-set, the seaside town of Punta del Este has vibrant night life during the austral, from december to February. The region boasts some of the best restaurants of the entire continent, such as La Bourgogne or the Parador la huella. If you are looking for calm and proximity with nature, you are sure to enjoy the village of Cabo Polonio: run solely on sustainable energy, this fishing village annually attracts an alternative crowd of travelers. N earer to Brazil, you will find the beaches of Punta del Diablo which will provide you with a most relaxing setting, as well as ideal conditions for surfing in Uruguay. Finally, history buffs should enjoy visiting Colonia del Sacramento: founded by the portuguese in 1680, it is the oldest town in the country.
Take the time to visit Montevideo and be seduced by its gentle way of life… The market on the port showcases delicious uruguayan meats, which you can enjoy slow cooked over glowing embers in numerous authentic restaurants. In February, the ambient temperature climaxes with the carnaval: colorful and full of surprises, this traditional festival flies high the flag of candombe, an afro-uruguayan percussion based music. Throughout the year, around the Solis theater, the city is bursting with cultural activities which will make your holiday in Uruguay an unforgettable one.


text:
Do not unknowingly become your child's drug supplier!
PALM BAY, FL - One of the most common drug sources for children according to drug enforcement agencies is their parent's medicine cabinet in their own home!
Consider these statistics from the U.S. Drug Enforcement Administration:
1) Every day, on average, 2,500 teens use prescription drugs to get high for the first time.
2) One in seven teens admitted to abusing prescription drugs to get high in the past year. Sixty percent of teens who abused prescription pain relievers did so before the age of 15.
3) Fifty-six percent of teens believe that prescription drugs are easier to get than illicit drugs.
4) Two in five teens believe that prescription drugs are "much safer" than illegal drugs. And three in ten teens believe that prescription pain relievers are not addictive.
5) Sixty-three percent of teens believe that prescription drugs are easy to get from friends' and family's medicine cabinets.
On Saturday, October 29, Palm Bay Hospital will be 'Ground Zero' for 'Operation Medicine Cabinet'- a joint effort of our hospital and law enforcement officers to reduce the amount of prescription drugs that can illegally fall into the hands of children and teenagers. The last time this was done at the hospital, more than a quarter-ton of drugs were turned in and destroyed.
Palm Bay Hospital, together with the Palm Bay Police Department, WILL ACCEPT the following: nonprescription over-the-counter medications, prescription medications, and even pet medications in the form of pills, liquids, ointments, or lotions. You can leave the medications in the original packaging or put them in a sealable plastic bag. You can even combine medications in one bag. If you bring in a liquid medication, please put the bottle in a sealable plastic bag to avoid leakage. No IDs or signatures are required. The medications will be turned over to the U.S. Drug Enforcement Agency to be destroyed.
'Operation Medicine Cabinet' CANNOT ACCEPT the following: syringes, asthma inhalers, drugs in aerosol canisters, or chemotherapy drugs of any type.


text:
Scooby Dooby Doo! Our favorite canine mystery crusader is back in action with Scooby-Doo! and the Spooky Swamp. Scooby-Doo, Shaggy, Daphne, Velma and Fred are on an all-new adventure to uncover the mystery behind a strange swamp girl and her peculiar cauldron of brew. Players can jump in as any of the Mystery, Inc. characters (including Scooby-Doo) at any time to travel beyond the swamp and into other haunted locales, such as the snow covered Alpine village or the Southwestern ghost town, to uncover more clues and solve the mystery of the strange brew.
Release Region: United States
Release Date: Q3 2010
Publisher: Warner Bros. Interactive