Re: New DoD encryption mandate

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
alexalten.org



------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

On Fri, Aug 17, 2007 at 05:21:16PM -0700, Alex Alten wrote:

> 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).

The basic algorithms don't but you can easily enough use
multiple CPUs
with a hash tree or hash list. I'd also guess that in many
cases you'd
want to hash many files, which offers easy parallelism by
spawning a
pool of threads that work off a series of files. If you can
afford a
patent license for PMAC, that would work as well.

-Jack

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com