TRESOR 0.3 from www1.informatik.uni-erlangen.de/tresor
TRESOR: Put name_to_dev_t in do_mounts.h for keydevice parameter.
TRESOR: s/custom thaw_kernel_processes/thaw_kernel_threads/

This switches from the custom thaw_kernel_processes which didn't
thaw workers (so that encryption requests weren't processed) to the
thaw_kernel_threads already in the kernel.  This allows keydevices
to be read when resuming from sleep.

In order to prevent any data corruption due to encrypting data when
the keys aren't present, we restructure TRESOR's use of the kernel
crypto APIs.  Instead of implementing a simple cipher, we implement
TRESOR as a asynchronous block cipher (CBC-only for now, though
others would be very trivial to add with a few minutes of
copy-paste).  This returns immediatey when keys are present (ie
essentially always) and only acts asynchronously when keys are
missing (ie when resuming from sleep, before userspace has been
restarted).
Zeroize some semi-sensitive info in sha256.

This tries to get the built-in sha256 slightly closer to TRESOR's
sha256 (which is dropped in favor of the built-in one in the next
commit).
TRESOR: Use built-in sha256 instead of a custom function.

It no longer limits password length (very important as keydevices
always make the length of the hashed data longer than that limit)
and it is a bit more proper in terms of coding standards.  Note
that while this means things like the length of your hashed data
is more likely to end up in memory, a. it already likely was on
the TRESOR stack, as assigning a variable at the end of a function
will likely just be optimized away and b. the length of the
passphrase is already displayed on the screen, which is
significantly more "leaky" than it ending up in memory.
TRESOR: Add support for "keydevices".

This allows you to use an arbitrary block of a block device as an
additional salt to TRESOR.

It uses the tresorkeydevice= parameter and name_to_dev_t (ie the
same semantics as root=) to select the block device.

Though the block number should be considered private data, no
effort is made to keep it out of memory.  This should be fixed.

The read uses a simple bio, so many block devices are likely to
cache the request, resulting in parts of your key ending up in
memory.  This might also be fixed, though it would likely require
significant effort.  If you use a regular block device as your key
device, you are likely safe.  (TODO: check that that is actually
true)

Note that you absolutely need to include all modules in your kernel
which are required to connect the keydevice.  If you fail to do so,
your boot will hang.

It is recommended that you not have a filesystem on the key block,
as it may end up overwriting your partiular block for little or no
reason (or atleast do lots of digging to make sure it won't).
TRESOR: When reading from terminal, try more than just one term.

Instead of just opening /dev/tty0 or /dev/console depending on the
circumstances, try opening more than one tty/console and see which
one the user responds on.

This fixes restore-from-sleep input in some cases.
TRESOR: Don't echo private information to screen.
TRESOR: Add shamirssecret.{h,c} from github.com/TheBlueMatt/shamirs
TRESOR: Encourage IOMMU usage to block most simple DMA attacks.
TRESOR: Coding standards (sizeof)
TRESOR: Encourage tboot use as that fixes some fun DMA attacks
TRESOR: Multi-key support with SSS for secret sharing

This adds support for using multiple keydevices which each has a
part of the secret split using an implementation of Shamir's on
the Rijndael GF(2^8) curve. Each share is prefixed with a 1-byte
X coordinate, giving us a secret of 511 bytes. This secret is
prepended to the password in the same way a regular keydevice is
prepended to the password (though regular keydevices provide 512
bytes).
The keydevices with shares on them can be provided using the new
kernel parameters tresorsharedevice[0-9]=... with the same syntax
for specifying the partition as tresorkeydevice=. In addition, the
tresorsharesrequired= parameter must be specified with the number
of shares required to recreate the secret.

You can find the implementation of Shamir's used to combine (and
which can be used to create the shares) at
https://github.com/TheBlueMatt/shamirs
TRESOR: Introduce ability to prepend one non-ascii char to password

This is intended to provide an upgrade path (and a testing path for
me) for those with regular keydevices who wish to upgrade to split
sharedevices. One can then split the first 511 bytes of the
keydevice block into each sharedevice (providing 512 bytes for each
share, including the 1-byte X coordinate). The 512th byte of the
original keydevice can then be entered in the new prompt,
creating the same key as before but with a split keydevice.

To enable this option, add tresorshamirscompat to the kernel boot
arguments.
TRESOR: Fix printf
TRESOR: Use struct to keep track of entered name.

Replace lookup of partuuid with struct keeping track of the name
which we used to lookup the disk. This could save us in the case of
a partition which wasn't looked up with PARTUUID=
TRESOR: Get worst-case printf down to 80 characters
TRESOR: BUG_ON key unset, so __tresor breaks instead of corrupting
TRESOR: Optionally encrypt the IV pre-run (essiv with plain64)
TRESOR: Add docs on keydevices/shamirs/ecbc vs essiv.