At 04:02 AM 8/17/2007 -0700, =?UTF-8?Q?Ivan_Krsti=C4=87?= wrote:
On Aug 16, 2007, at 8:30 AM, Ali, Saqib wrote:
The other problem is that it lacks any centralized management. If you
are letting TPM manage your Bitlocker keys you still need a TPM
management suite with key backup/restore/transfer/migrate capabilities
in case your computer goes bad.

How so? If your computer goes bad, you need a *backup*. That's
entirely orthogonal to the drive encryption problem. Bitlocker uses
the TPM to provide assurance that your drive -- really, volume -- is
locked to your computer, and that the early boot environment hasn't
been messed with. When either check fails, you use the BitLocker
recovery password (either on a USB stick or entered manually) to
recover your data. This holds in the event that you take your drive
out and stick it in a different machine. In other words, the TPM is
not a single point of failure, so I don't understand why you think
you care about TPM backup/restore/transfer.

It depends on your requirements.  For a large numbers of computers
owned by a corporation/organization centralized key management
makes a lot of sense.  For a single user with a privately purchased
computer then the recovery password makes more sense.

The third problem is that it is software based encryption, which uses
the main CPU to perform the encryption.

Security is never free, but in 2007, we can afford the cycles. What's
a better use for them? Drawing semi-transparent stained glass window
borders?

Agreed, for most requirements.  Sometimes one may need to keep keys
in trusted hardware only.  The only real fly-in-the-ointment is that current
hash algorithms (SHA-1, SHA-2, etc.) don't scale across multiple CPU
cores (assuming you need integrity along with your privacy).

- Alex

--

Alex Alten
[EMAIL PROTECTED]



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to