Re: New DoD encryption mandate

2007-08-20 Thread Jack Lloyd
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 [EMAIL PROTECTED]


Re: New DoD encryption mandate

2007-08-19 Thread Ali, Saqib
On 8/17/07, Ivan Krstic [EMAIL PROTECTED] wrote:
 How so? If your computer goes bad, you need a *backup*. That's
 entirely orthogonal to the drive encryption problem.

One of the functions provided by the TPM is to wrap/bind and store the
bulk encryption keys. Now let's us say the mother board or the TPM
goes bad on your notebook or you simply want to upgrade the computer.
You need to be able to restore+transfer the information stored in the
TPM to your new computer. This is where you need TPM management suite
that support key backup/restore and transfer.

A large company's (name withheld) strategy regarding TPM was to ignore
it. Not too long ago few key engineers from that company decided that
a TPM enabled encrypted vault would be good place to secure their
documents. Somehow they managed to lock themselves out of the
encrypted vaults (maybe forgotten password / or lost keys). Had that
company not ignored the TPM and instituted a key backup/archive
program, the engineers would have been able to recover their
confidential documents. We can blame the engineers, but at the end of
the day it was the whole company that lost money and valuable design
documents.

saqib
http://security-basics.blogspot.com/

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


Re: New DoD encryption mandate

2007-08-19 Thread Ivan Krstić

On Aug 18, 2007, at 3:30 PM, Ali, Saqib wrote:


One of the functions provided by the TPM is to wrap/bind and store the
bulk encryption keys. Now let's us say the mother board or the TPM
goes bad on your notebook or you simply want to upgrade the computer.
You need to be able to restore+transfer the information stored in the
TPM to your new computer. This is where you need TPM management suite
that support key backup/restore and transfer.


I still don't follow. BitLocker explicitly includes a (optionally  
file-based) recovery password. If you want central management, why  
not centrally manage _that_?



Alex Alten wrote:

Agreed, for most requirements.  Sometimes one may need to keep keys
in trusted hardware only.


The reason the TPM is used to wrap the BitLocker key is not because  
people don't want the key to be available outside of hardware -- at  
least I've never heard of that requirement going hand in hand with  
central key backup/migrate. Instead, TPM key wrapping is used so the  
early-boot checks can be enforced. I don't see how a hardware-only  
key that you can migrate to another TPM centrally is any more secure  
than keeping a key in hardware but falling back on a centrally- 
managed spare for enabling data migration.


--
Ivan Krstić [EMAIL PROTECTED] | http://radian.org
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: New DoD encryption mandate

2007-08-19 Thread Ali, Saqib
 I still don't follow. BitLocker explicitly includes a (optionally
 file-based) recovery password. If you want central management, why
 not centrally manage _that_?

On if MS provided some way to manage them centrally. Using a encrypted
DB to manually store the keys in it, is simply not feasible.

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


Re: New DoD encryption mandate

2007-08-19 Thread Ivan Krstić

On Aug 19, 2007, at 12:13 PM, Ali, Saqib wrote:


On if MS provided some way to manage them centrally. Using a encrypted
DB to manually store the keys in it, is simply not feasible.


Your argument just went from TPMs are bad for volume encryption with  
BitLocker because they can't be centrally managed to Microsoft  
should provide tools to centrally manage key recovery files because I  
find doing it myself too hard. Which are you actually arguing? I've  
tried to show you that the first argument is _wrong_; the second  
argument has nothing to do with TPMs. You have a choice when it comes  
to how you approach the recovery keyfile problem. You can build tools  
for it, or any company that perceives a market need can do so.


--
Ivan Krstić [EMAIL PROTECTED] | http://radian.org
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: New DoD encryption mandate

2007-08-17 Thread Ivan Krstić

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.



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?


--
Ivan Krstić [EMAIL PROTECTED] | http://radian.org
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: New DoD encryption mandate

2007-08-17 Thread Alex Alten

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]