Some attack cases (http://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot#TOC-Attack-cases) considered by design.
Each user is allocated one encrypted image file that can grow to fill the free space on its disk partition. The image file is stored in a directory specific to the user using a hash of the user name with a salt value. The image itself is a sparse file that is attached to the system through a loop device. Using the device mapper subsystem, a virtual, encrypting block device, dm-crypt, is layered on top of the loop device.
The image encryption key for the dm-crypt device is generated randomly during setup using the randomness generator provided by the kernel, and if supported, seeded by a hardware random number generator. It is then encrypted with a partial cryptographic hash derived from the user's Google Accounts password and stored with the encrypted image on the underlying file system. On login, the encryption key is decrypted, and the encrypted image is mounted over the user's home directory. If the user's password changes, the image encryption key is re-encrypted with a new weak hash generated from the new passphrase. There are still some outstanding issues around what happens if a user changes her password from a non-Chromium OS machine….