Can you keep a secret? This encrypted drive can...

h
ttp://www.sfgate.com/cgi-bin/article.cgi?file=/chronicle/arc
hive/2006/10/30/BUGU2M1ETT1.DTL&type=printable
http://www.theglobeandmail.com/servle
t/story/RTGAM.20061030.wharddrive1029/BNStory/Front/?page=rs
s&id=RTGAM.20061030.wharddrive1029
http://www.infoworld.com/article/06/10/30/HNseaga
teagain_1.html

-- 
Saqib Ali, CISSP, ISSAP
http://www.full-d
isk-encryption.net

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

h
ttp://www.sfgate.com/cgi-bin/article.cgi?file=/chronicle/arc
hive/2006/10/30/BUGU2M1ETT1.DTL&type=printable
http://www.theglobeandmail.com/servle
t/story/RTGAM.20061030.wharddrive1029/BNStory/Front/?page=rs
s&id=RTGAM.20061030.wharddrive1029
http://www.infoworld.com/article/06/10/30/HNseaga
teagain_1.html

-- 
Saqib Ali, CISSP, ISSAP
http://www.full-d
isk-encryption.net

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

Saqib Ali wrote:
> http://www.infoworld.com/article/06/10/30/HNseaga
teagain_1.html

Notably, none of the three articles mention Vista's
BitLocker, which
provides FDE in software and establishes trust via a TPM
chip. (For
those who haven't heard about it, BitLocker also uses a
clever diffuser
that Niels Ferguson designed specifically for the FDE
scenario.)

The problem I see with hardware FDE is the same one that
prompted
Poul-Henning Kamp to design GBDE some time back: the
"lose a password,
game over" model doesn't work in corporate
environments. People forget
passwords all the time. They don't see this as an
irrecoverable failure;
it's something that the IT people are supposed to be able to
fix with a
wave of their tricorder. Once that assumption flies out the
window, the
cost of a lost password becomes so high that it's more
convenient to
disable the encryption altogether.

On the other hand, Vista is shipping with BitLocker enabled
by default
in the upper editions (Enterprise or somesuch), and doesn't
rely on
passwords at all; it actually brings the user, without any
interaction,
to the standard Windows login prompt, where the user can
reach for a
smart card, or use a fingerprint reader, or do any other
kind of
authentication Windows supports. Optionally, a hardware
token or USB key
can be required during boot, and those can be made rekeyable
by the IT
department, if I understood one of the engineers who worked
on it correctly.

Seagate's technical solution isn't compatible with the
social problem
it's trying to solve. I think Microsoft's is, surprisingly
enough.

As a sidenote, I wonder if Seagate will release full details
and code
for their FDE (and AES) implementation, or if we're supposed
to take the
"no backdoors" clause on faith, as we do with
TPMs.

-- 
Ivan Krstić <krsticsolarsail.hcs.harvard.edu> | GPG:
0x147C722D

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

Well for one thing, any software based FDE is extremely
slow, doubles
the file access times, and is a serious drain on the laptop
battery.
See the URL below for a software based FDE
benchmark/analysis:
http://www.xml-dev.com/blog/index.php?action=vi
ewtopic&id=250

What if the encryption key for the Seagate's HDD can be
managed using
TPM, i.e. wrapped, bound and stored on the TPM. The user
will just
have to authenticate to the TPM, using a Token or a static
password,
then the FDE encryption key will be available to the HDD....
Will this
solve the problem?

saqib
http://www.full-d
isk-encryption.net

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

On Wed, 1 Nov 2006, Saqib Ali wrote:
> Well for one thing, any software based FDE is extremely
slow, doubles
> the file access times, and is a serious drain on the
laptop battery.

If a PC is used by an interactive user, it is irrelevant how
much
access time is increased, as far as the user cannot see a
difference
without a timer. Several times I have read that disk
encryption is not
noticeable. My own experience shows that I cannot notice any
difference: emacs and pine respond immediately to every
key-press if I
use encrypted disk or not; firefox waits for data from
network the
same amount of time; mplayer does not drop frames with or
without disk
encryption; compilation of kernel takes some noticeable time
with or
without encryption, but I don't know how much exactly since
I spend
this time in some other program.

I don't want to say that the difference is irrelevant for
all uses,
e.g., if one edits video with 2k resolution or hosts a busy
database,
they can see very real difference, but such use-cases are
minority and
they are not done on portable computers anyway.

I guess many people here have tried full disk encryption for
themselves, do you notice any difference in performance or
not?

-- 
Regards,
ASK

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

On Mon, 30 Oct 2006, Saqib Ali wrote:

> h
ttp://www.sfgate.com/cgi-bin/article.cgi?file=/chronicle/arc
hive/2006/10/30/BUGU2M1ETT1.DTL&type=printable
> http://www.theglobeandmail.com/servle
t/story/RTGAM.20061030.wharddrive1029/BNStory/Front/?page=rs
s&id=RTGAM.20061030.wharddrive1029
> http://www.infoworld.com/article/06/10/30/HNseaga
teagain_1.html

Who's secrets will they be keeping? Disk encryption and
Object-based
storage (where the filesystem is basically pushed down
closer to the
storage device, cf [1]) could be used to provide building
blocks for
stronger DRM.

-d

[1] http://dl.alphaworks.ibm.com/technologies/osdsim/osd
sim2.pdf

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

I compile a lot of software on my laptop, and I *certainly
notice* the
difference between my office laptop (no encryption) and my
travel
laptop (with FDE). The laptops are exactly the same, with
the same
image loaded. The only difference is the FDE software that
is
installed on the travel laptop.

That is why I did an analysis of various FDE solutions to
find the
best one for my needs. The key thing I was interested was
that it must
be AES 256, reasonably fast, inexpensive, and offer key
recovery in
case of password loss.

The final outcome of the analysis is available 
http://www.xml-dev.com/blog/index.php?action=vi
ewtopic&id=250

Compusec is great for home / personal use. It is cheap i.e.
$0.00
(Free), and does not slow down the computer as much as the
other
products. But that is because it only support 128 bit AES,
which is a
major drawback as most enterprise settings require at least
256 bit
AES. Compusec also has a great online support forum where
you can get
your questions answered by Compusec employees and other
experienced
users.

I ended up purchasing both Utimaco and Pointsec. They are
excellent
products. They both support AES 256. The downside is that
they are
little bit expensive (Pointsec:$170 ; Utimaco:$200) and
slow.

The best thing is they both offer great password /
encryption key
recovery capabilities. You can create a recovery disk with
both
products.

They also offer password recovery using Challenge / Response
sequence,
where the IT Helpdesk can perform a Challenge/Response
sequence with
the user to help them recover the password or reset it to a
new one.
Off course Challenge/Response password recovery is the NOT
most
secure, especially if the user is remote, but you have the
option to
disable it on the laptop if you want.
------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

Alexander Klimov <alserkliinbox.ru> writes:

>If a PC is used by an interactive user, it is irrelevant
how much access time
>is increased, as far as the user cannot see a difference
without a timer.
>Several times I have read that disk encryption is not
noticeable.

I agree that in most cases the access-time argument is a red
herring.  Back
when I wrote SFS (DOS-based FDE that ran on 386's), I got
plenty of feedback
from users that the slowdown was barely or not at all
noticeable.  The only
time I've really noticed it (using current FDE software, not
on a 25 MHz 386)
is when copying large amounts of data onto an encrypted
partition, but that's
(a) a very rare event and (b) somewhat slow anyway even for
an unencrypted
copy.

Peter.

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

On Thu, 2 Nov 2006, Alexander Klimov wrote:
> I guess many people here have tried full disk
encryption for
> themselves, do you notice any difference in performance
or not?

I've been using Matt Blaze's CFS (cryptographic file system)
to encrypt
personal E-mail archives since 1994 or so.  CFS is about the
slowest
cryptographic file system around: it's implemented outside
the kernel
(via an NFS loopback mount), so there are lots of userland
<--> kernel
transitions and data copies going on.  And it uses 3DES,
which is a
lot slower than (eg) AES.

Despite all that, CFS performance is just fine.  Back when I
started
using CFS, on a 33 MHz SPARC, the performance hit was
noticable but
tolerable.  Now, when multi-GHz laptops abound, the CFS
performance
hit is really a drop in the bucket for normal interactive
use on
moderate-sized files.

As a test, I just tried
   time dd if=/dev/arandom bs=65536 count=512 of=32m
(to time writing 32 MB of random data to disk) on my laptop
(Lenovo/IBM Thinkpad T43P, OpenBSD 3.9-stable).  I ran the
command
three times (with different file names each time) on each
of:
(a) a CFS directory backed by my laptop's /home file system,
(b) my laptop's /home file system (BSD FFS with soft
dependencies), and
(c) my laptop's /tmp file system (a memory file system)
I was careless/lazy, so these trials all started with the
system at
its "idling" clock rate (600 MHz), and let the
system ramp up the
clock rate as needed once it noticed the CPU usage.

The times (wall-clock seconds from the 'time' command) were
pretty
consistent for each of the 3 trials:
(a) 10.33 10.75  9.69
(b)  2.12  2.08  2.05
(c)  1.84  1.89  1.85

So... even for 32-MB files, CFS only takes about 8 seconds
for the
encryption.  For smaller files the hit is truly negligible
-- when
I tried this test on 64K files there was no difference in
times between
(a), (b), and (c) within the timing noise.

ciao,

-- 
-- "Jonathan Thornburg -- remove -animal to reply"
<jthornaei.mpg-zebra.de>
   Max-Planck-Institut fuer Gravitationsphysik
(Albert-Einstein-Institut),
   Golm, Germany, "Old Europe"     http://www.ae
i.mpg.de/~jthorn/home.html      
   "Washing one's hands of the conflict between the
powerful and the
    powerless means to side with the powerful, not to be
neutral."
                                      -- quote by Freire /
poster by Oxfam



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

| ...Compusec is great for home / personal use. It is cheap
i.e. $0.00
| (Free), and does not slow down the computer as much as the
other
| products. But that is because it only support 128 bit AES,
which is a
| major drawback as most enterprise settings require at
least 256 bit
| AES....
Just wondering about this little piece.  How did we get to
256-bit
AES as a requirement?  Just what threat out there justifies
it?
There's no conceivable brute-force attack against 128-bit
AES as far
out as we can see, so we're presumably begin paranoid about
an analytic
attack.  But is there even the hint of an analytic attack
against AES
that would (a) provide a practical way in to AES-128; (b)
would not
provide a practical way into AES-256?  What little I've seen
in the
way of proposed attacks on AES all go after the algebraic
structure
(with no real success), and that structure is the same in
both
AES-128 and AES-256.
							-- Jerry

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

Quoting "Leichter, Jerry" <leichter_jerroldemc.com>:

> | ...Compusec is great for home / personal use. It is
cheap i.e. $0.00
> | (Free), and does not slow down the computer as much
as the other
> | products. But that is because it only support 128 bit
AES, which is a
> | major drawback as most enterprise settings require at
least 256 bit
> | AES....
> Just wondering about this little piece.  How did we get
to 256-bit
> AES as a requirement?  Just what threat out there
justifies it?
> There's no conceivable brute-force attack against
128-bit AES as far
> out as we can see, so we're presumably begin paranoid
about an analytic
> attack.  But is there even the hint of an analytic
attack against AES
> that would (a) provide a practical way in to AES-128;
(b) would not
> provide a practical way into AES-256?  What little I've
seen in the
> way of proposed attacks on AES all go after the
algebraic structure
> (with no real success), and that structure is the same
in both
> AES-128 and AES-256.

It's a management requirement.  The manager sees
"AES128" and "AES256"
and thinks "256 must be better than 128" and
therefore the edict comes
down that AES256 must be used.  It's not a technical
decision.  It's
not a decision made by analyzing the threats.  It's made
purely
by assertion, but it's a decision that can't easily be
refuted.

> 							-- Jerry

-derek
-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media
Laboratory
       Member, MIT Student Information Processing Board 
(SIPB)
       URL: http://web.mit.edu/warlor
d/    PP-ASEL-IA     N1NWH
       warlordMIT.EDU                        PGP key
available


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

"Saqib Ali" <docbook.xmlgmail.com> writes:

>I compile a lot of software on my laptop, and I
*certainly notice* the
>difference between my office laptop (no encryption) and
my travel laptop
>(with FDE). The laptops are exactly the same, with the
same image loaded. The
>only difference is the FDE software that is installed on
the travel laptop.

That's because you're doing something that produces
worst-case behaviour.  The
(obvious) solution is the standard "don't do that,
then".  My main development
machine builds to a RAM drive, and for some odd reason I
don't notice any disk
access latency at all.

>But that is because it only support 128 bit AES, which
is a major drawback as
>most enterprise settings require at least 256 bit AES. 

"Realising the importance of the case, my men are
applying twice the usual
 amount of tinfoil".

Peter.

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

On Tue, 7 Nov 2006, Peter Gutmann wrote:

> "Saqib Ali" <docbook.xmlgmail.com> writes:
>
> >I compile a lot of software on my laptop, and I
*certainly notice* the
> >difference between my office laptop (no encryption)
and my travel laptop
> >(with FDE). The laptops are exactly the same, with
the same image loaded. The
> >only difference is the FDE software that is
installed on the travel laptop.
>
> That's because you're doing something that produces
worst-case
> behaviour.  The (obvious) solution is the standard
"don't do that,
> then".  My main development machine builds to a
RAM drive, and for
> some odd reason I don't notice any disk access latency
at all.

I am not sure that compilation is worst case for disk
performance:
once system compiled the first file, the compiler and most
of .h files
are in RAM and should not be fetched from disk. Note that
RAM of
modern computers is large enough to store all the source
code of a
project (except, maybe, openoffice.org).

My guess is that slow compilation is a result of access time
misconfiguration: if a filesystem has access time enabled,
then each
time a file is read, the file system updates access time on
disk. A
solution is to set noatime option on the filesystem used for
compilation. A better approach is to mount tmpfs as /tmp,
and build in
/tmp (for openoffice.org compilation increase size and
number of
inodes with size and nr_inodes options).

-- 
Regards,
ASK

P.S. Probably of interest for disk benchmarker: disk
performance
depends on which cylinders are used, so if one has two
partitions (one
near the center and another one near the outer edge of the
disk)
performance on these partitions can be different.



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

Hello Alexander,

> My guess is that slow compilation is a result of access
time
> misconfiguration: if a filesystem has access time
enabled, then each
> time a file is read, the file system updates access
time on disk. A
> solution is to set noatime option on the filesystem
used for
> compilation.

This is a good info. Do you how this can be done on windows?


> P.S. Probably of interest for disk benchmarker: disk
performance
> depends on which cylinders are used, so if one has two
partitions (one
> near the center and another one near the outer edge of
the disk)
> performance on these partitions can be different.

Good point. That is why I made sure that I had only 1
partition, and i
used the fasted drive in the market available for laptops.


saqib
http://www.full-d
isk-encryption.net

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

"Saqib Ali" <docbook.xmlgmail.com> writes:

>> My guess is that slow compilation is a result of
access time
>> misconfiguration: if a filesystem has access time
enabled, then each
>> time a file is read, the file system updates access
time on disk. A
>> solution is to set noatime option on the filesystem
used for
>> compilation.
>
>This is a good info. Do you how this can be done on
windows?

HKLMSystemCurrentControlSetControlFileSystemNtfsDisable
LastAccessUpdate =
1, but this probably shouldn't be necessary because for temp
files Windows
will try to avoid creating the file on disk unless it runs
out of file buffer
memory.

Peter.

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

| > | ...Compusec is great for home / personal use. It is
cheap i.e. $0.00
| > | (Free), and does not slow down the computer as much
as the other
| > | products. But that is because it only support 128
bit AES, which is a
| > | major drawback as most enterprise settings require
at least 256 bit
| > | AES....
| > Just wondering about this little piece.  How did we
get to 256-bit
| > AES as a requirement?  Just what threat out there
justifies it? ...
| 
| It's a management requirement.  The manager sees
"AES128" and "AES256"
| and thinks "256 must be better than 128" and
therefore the edict comes
| down that AES256 must be used.  It's not a technical
decision.  It's
| not a decision made by analyzing the threats.  It's made
purely
| by assertion, but it's a decision that can't easily be
refuted.
Well, there's a very easy answer to that one:  Tell the
manager
involved that the number is the price.  "You can have
the industrial
grade one for 128 bucks, or the one done to MIL specs with
gold plating
for 256 bucks."  

							-- Jerry

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

      -----Original Message-----
     From: Saqib Ali [mailto:docbook.xmlgmail.com] 
     Sent: Tuesday, November 07, 2006 08:16
   
     Hello Alexander,
     
     > My guess is that slow compilation is a result of
access time
     > misconfiguration: if a filesystem has access time 
     enabled, then each 
     > time a file is read, the file system updates
access time 
     on disk. A 
     > solution is to set noatime option on the
filesystem used for 
     > compilation.
     
     This is a good info. Do you how this can be done on
windows?
     
     
It is on page 43 and 44 of a class I did at the last
CyberCrime Summit:
http://davekleiman.com/Files/HTCIACyberCrimeSummit_
For_CD.zip
Additionally, I talk about using Log Parser to retrieve
information from the
filesystem and log files without causing access updates


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

> Just wondering about this little piece.  How did we get
to 256-bit
> AES as a requirement?  Just what threat out there
justifies it?
> There's no conceivable brute-force attack against
128-bit AES as far
> out as we can see, so we're presumably begin paranoid
about an  
> analytic
> attack.  But is there even the hint of an analytic
attack against AES
> that would (a) provide a practical way in to AES-128;
(b) would not
> provide a practical way into AES-256?  What little I've
seen in the
> way of proposed attacks on AES all go after the
algebraic structure
> (with no real success), and that structure is the same
in both
> AES-128 and AES-256.

There is no requirement for it. However, as others have
noticed, to  
the casual observer, 256 is twice as good as 128. You don't
want to  
end up with a product review saying, "Product X is
solid with 128-bit  
encryption, but for the ultra-paranoid, product Y is using
256!"

Moreover, AES-256 is 20-ish percent slower than AES-128.
That  
difference can be completely irrelevant in the context of
the entire  
system. That means that there is coolness pressure pushing
to 256,  
and relatively little performance backpressure. The result
is that  
you use AES-256 except where the performance is so tetchy
that you  
really need to back off to 128.

I've been spouting off about how 128 is enough, but not
fighting the  
trend even an iota. It's not worth the bother. Besides, I
find the  
irony that AES is pushing us from debates about how 56
oughta be good  
enough to why 256 is just inevitable in less than a decade
to be  
amusing.

	Jon


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

On Mon, 6 Nov 2006, Derek Atkins wrote:

>Quoting "Leichter, Jerry"
<leichter_jerroldemc.com>:

>> Just wondering about this little piece.  How did we
get to 256-bit
>> AES as a requirement?  Just what threat out there
justifies it?

> It's a management requirement.  The manager sees
"AES128" and "AES256"
> and thinks "256 must be better than 128" and
therefore the edict comes
> down that AES256 must be used.  It's not a technical
decision.  It's
> not a decision made by analyzing the threats.  It's
made purely
> by assertion, but it's a decision that can't easily be
refuted.

Yep.  When costs are equal (and in this case computing power
is so
cheap as to make that approximately true) any competent
manager will
always pick the method which is "superior" to the
other in any way.

The facts are that with AES128 or AES256, the cipher itself
will *NOT*
be the weakest link in security, so the theoretical
superiority of
AES256 doesn't matter much.

Anybody who is making a serious attack will have to do
pretty much
exactly the same thing -- social engineering, rubberhose
attack,
subpoena, password guess, protocol flaw exploit, Van Eck
monitor
exploit, keyboard monitor, software backdoor exploit, DLL
substitution
attack,  mem device exploit by a trojan running at the same
time as
the encryption software, audio interferometry to determine
keystroke
sequences, audio-frequency carrier wave interference from
some metal
thing in the same office as the transmitter vibrating to the
voice
that's being encrypted, etc...  There's a million different
links
all weaker than the cipher itself.

Conversely, it harms nothing to have them pick the stronger
cipher,
given that both ciphers are sufficiently strong that their
strength
has nothing to do with the mimimum effort required to attack
their
application.

				Bear

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

Jon Callas wrote:
>
>
> Moreover, AES-256 is 20-ish percent slower than
AES-128. 
Compared to AES-128, AES-256 is 140% of the rounds to
encrypt 200% as 
much data. So when implemented in hardware, AES-256 is
substantially faster.

AES-256 - 18.26 bits per round
AES-128 - 12.8 bits per round

I imagine that this would matter when the implementation is
in a hard 
disk or disk interface.





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