Re: [-SPAM-] Re: Can you keep a secret? This encrypted drive can...

2006-12-08 Thread Jon Callas


On 5 Dec 2006, at 3:22 PM, Brian Gladman wrote:



For AES the round function and key scheduling cost per round are
basically the same for both AES-128 and AES-256.  In consequence I  
would
expect the speed ratio to be close to the ratio of the number of  
rounds,

which is 14 / 10 or 40%.

My own figures on AMD64 are 1.35 for encryption and 1.39 for  
decryption.

And on a P4 they are 1.36 and 1.38 respectively. These are hence close
to the expected 40% figure.

This suggests to me that a figure around 20% would apply in  
applications

in which about half the time is spent in encryption and half in other
higher level activities.

Can I hence assume that your benchmark is being run at application  
level

rather than algorithm level?  If not why is the ratio only 22% on the
PPC-32?


That was using pgp --speed-test. It's an algorithm-level test, but  
it's calling the SDK so there's some API-level overhead involved. I  
got the number from a 3.0GHz x86, and it was 1.36 for encryption and  
1.37 for decryption. But I also got the numbers from a 2GHz Core Duo  
laptop and it was 1.12 for encryption and decryption. On the other  
hand, the fast machine was encrypting AES-128 at 66389.45 KB/s and  
the slow one at 22217.39 KB/s, which means that the 3GHz machine is  
running at just shy of 3x the speed of the 2GHz machine!


Obviously, there are other factors, such as cache, memory, and so on  
that are huge differences. I'd take a slowdown of 12% to 40% if I  
was getting a 300% base speedup.


Jon

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


Re: [-SPAM-] Re: Can you keep a secret? This encrypted drive can...

2006-12-06 Thread Brian Gladman
Jon Callas wrote:
 I just ran a speed test on my laptop. Here are some relevant excerpts:
 
 CipherKey Size  Block Size  Enc KB/sec  Dec KB/sec
     --  --  --
 IDEA  128 bits   8 bytes  24032.0924030.66
 3DES  192 bits   8 bytes  10387.6710399.30
 CAST5 128 bits   8 bytes  29331.1729459.49
 Twofish   256 bits  16 bytes  20233.6319185.82
 AES-128   128 bits  16 bytes  44100.2346266.98
 AES-192   192 bits  16 bytes  39731.3341228.87
 AES-256   256 bits  16 bytes  36017.9537302.43
 Blowfish  128 bits   8 bytes  35347.3438311.22
 
 Comparing AES-128 and AES-256, encrypt speed is 1.2243959x and decrypt
 is 1.2403208x. So that makes my
 lick-your-finger-and-stick-it-in-the-wind rule of thumb of 20% slower
 okay. I'll try to say 20-25% in the future.
 
 Of course, though, implementation matters a lot. I'm running a PPC-32
 machine. You'll get different answers on an ia32, and different ones an
 AMD64.

For AES the round function and key scheduling cost per round are
basically the same for both AES-128 and AES-256.  In consequence I would
expect the speed ratio to be close to the ratio of the number of rounds,
which is 14 / 10 or 40%.

My own figures on AMD64 are 1.35 for encryption and 1.39 for decryption.
And on a P4 they are 1.36 and 1.38 respectively. These are hence close
to the expected 40% figure.

This suggests to me that a figure around 20% would apply in applications
in which about half the time is spent in encryption and half in other
higher level activities.

Can I hence assume that your benchmark is being run at application level
rather than algorithm level?  If not why is the ratio only 22% on the
PPC-32?

   Brian Gladman

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


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

2006-12-05 Thread Jon Callas

I just ran a speed test on my laptop. Here are some relevant excerpts:

CipherKey Size  Block Size  Enc KB/sec  Dec KB/sec
    --  --  --
IDEA  128 bits   8 bytes  24032.0924030.66
3DES  192 bits   8 bytes  10387.6710399.30
CAST5 128 bits   8 bytes  29331.1729459.49
Twofish   256 bits  16 bytes  20233.6319185.82
AES-128   128 bits  16 bytes  44100.2346266.98
AES-192   192 bits  16 bytes  39731.3341228.87
AES-256   256 bits  16 bytes  36017.9537302.43
Blowfish  128 bits   8 bytes  35347.3438311.22

Comparing AES-128 and AES-256, encrypt speed is 1.2243959x and  
decrypt is 1.2403208x. So that makes my lick-your-finger-and-stick-it- 
in-the-wind rule of thumb of 20% slower okay. I'll try to say 20-25%  
in the future.


Of course, though, implementation matters a lot. I'm running a PPC-32  
machine. You'll get different answers on an ia32, and different ones  
an AMD64.


Jon

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


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

2006-12-04 Thread Marcos el Ruptor
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.


Excuse me, AES-256 has the same block size as AES-128, that is 128 bits. 
It's in fact slower, not faster, and in hardware it also occupies a 
substantially larger area.


If you are talking about Rijndael with 256-bit blocks, that's not AES and 
its variant with 256-bit keys would still be slower and would also occupy a 
substantially larger area in hardware than its counterpart with 128-bit 
keys.


Ruptor 


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


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

2006-12-04 Thread Alexander Klimov
On Sun, 3 Dec 2006, David Johnston 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 means AES with 128-bit block and 256-bit key, so AES-256
encrypts the same amount of data as AES-128.

As of hardware implementation, one can use several engines in
parallel, although even a single one can be faster than needed,
for example, with 280 MHz there are 2e7 blocks per second, that is
320 Mbyte per second.

-- 
Regards,
ASK

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


Re: [-SPAM-] Re: Can you keep a secret? This encrypted drive can...

2006-12-04 Thread Brian Gladman
David Johnston wrote:
 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 does not encrypt any more data per round than AES-128.

My guess is that you are thinking about Rijndael with a 256 bit block
and a 256 bit key.

  Brian Gladman

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


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

2006-12-04 Thread David Johnston

Leichter, Jerry wrote:

| 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.
AES-256 has a 256-bit key but exactly the same 128-bit block as AES-128
(and AES-192, for that matter).

|   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.
It would, if it were true.
-- Jerry
  
I stand corrected.. The source of my error was reading the rijndael 
spec, not the nist spec.


DJ

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


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

2006-12-03 Thread David Johnston

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 [EMAIL PROTECTED]


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

2006-11-12 Thread bear


On Mon, 6 Nov 2006, Derek Atkins wrote:

Quoting Leichter, Jerry [EMAIL PROTECTED]:

 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 [EMAIL PROTECTED]


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

2006-11-10 Thread Greg Rose

At 17:58  -0500 2006/11/08, Leichter, Jerry wrote:
No, SHA-1 is holding on (by a thread) because of differences in the
details of the algorithm - details it shares with SHA-256.  I
don't think anyone will seriously argue that if SHA-1 is shown to
be as vulnerable as we now know ND5 to be, then SHA-256 can still
be taken to be safe for more than a fairly short time.


Hmm, I disagree with this. Firstly, I don't think SHA-1 *is* holding 
on... while we don't have an example collision yet, there is no real 
doubt that one can be found in about 2^64 operations, which is less 
than the required 2^80. And SHA-2 does have a significantly different 
design in one area; the data expansion part is much stronger than 
SHA-1's, and almost certainly defeats the Wang-style attacks. Our 
paper on eprint gives some justification for why SHA-2 would appear 
to be resistant to these kinds of attacks.


Greg.

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


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

2006-11-10 Thread Alexander Klimov
On Wed, 8 Nov 2006, Travis H. wrote:

 On Wed, Nov 08, 2006 at 05:58:41PM -0500, Leichter, Jerry wrote:
  Sorry, that doesn't make any sense.  If your HWRNG leaks 64 bits,
  you might as well assume it leaks 256.  When it comes to leaks of
  this sort, the only interesting numbers are 0 and all.

 I can cite numerous examples of such happening in real life. [...]
 Not having to rely on perfectly unpredictable numbers coming from
 your RNG is a valid design principle.

Looks like you are doing a common mistake of using ``entropy source''
(or, probably, even``source of entropy input'') as output of your
generator (see NIST SP 800-90 for details). With such attitude, the
next step is to use identity mapping as a block cipher :-)

-- 
Regards,
ASK

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


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

2006-11-08 Thread Jon Callas

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 [EMAIL PROTECTED]


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

2006-11-08 Thread Leichter, Jerry
|  |  Just wondering about this little piece.  How did we get to 256-bit
|  |  AES as a requirement?  Just what threat out there justifies it? ...
| 
| I can see it as useful if some bits of the key got leaked somehow.
| For example, if you're using a HWRNG to generate keys, and it's
| bits are not uniformly distributed; if half were predictable and
| half not, you're using AES-128.  If you were using 128, now you're
| using 64 bits.
Sorry, that doesn't make any sense.  If your HWRNG leaks 64 bits,
you might as well assume it leaks 256.  When it comes to leaks of
this sort, the only interesting numbers are 0 and all.

| Seems like hashes have been failing gracefully lately; the reaction
| appears to be increasing key sizes (MD5-SHA-1-SHA-256)...
No, SHA-1 is holding on (by a thread) because of differences in the
details of the algorithm - details it shares with SHA-256.  I
don't think anyone will seriously argue that if SHA-1 is shown to
be as vulnerable as we now know ND5 to be, then SHA-256 can still
be taken to be safe for more than a fairly short time.

| Is there any reason to believe that AES can't weaken gradually
| in the same manner, but only in a catastrophic attack against the
| structure not related to keysize?
Anything *could* happen, but you haven't actually shown that this
particular pattern has been playing itself out in the hash function
space.

| Incidentally, calculations based on Moore's law require one new bit
| every 2 years to maintain the same level of security against brute
| force.
Such calculations are nonsense.  Moore's Law stops working at some
point, as you start to run out of electrons to run through all your
gates.  2^128 isn't just out of our current range; it's out of range
of any technology we have any inkling of today.

BTW, if you really want to push this to the ultimate, there is a
QM result that bounds that number of bit flips that can take
place within a given volume of space-time.  Suppose you start a
brute force attack, and want a result in 100 years.  The computation
must occur within a sphere of space time with spatial radius of
100 light years, and a time extension of 100 years.  (Of course,
this is a gross overestimate, since you presumably want the answer
to come back to you, which means the radius had better be at most
half that.  But this is all very rough anyway.)  When I saw some
results in this direction - sorry, I don't have a reference - I
did a *rough* computation of how many bit flips would fit into
that volume.  It turns out that you can just barely, in principle,
do a 128-bit brute force search - counting only the bit flips to
generate all the possible keys.  By 256 bits, this is completely
out of the question.
-- Jerry

| -- 
| Cryptography is nothing more than a mathematical framework for
| discussing various paranoid delusions. -- Don Alvarez
| URL:http://www.subspacefield.org/~travis/ --
| 
| 

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


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

2006-11-08 Thread Leichter, Jerry
| On Wed, Nov 08, 2006 at 05:58:41PM -0500, Leichter, Jerry wrote:
|  Sorry, that doesn't make any sense.  If your HWRNG leaks 64 bits,
|  you might as well assume it leaks 256.  When it comes to leaks of
|  this sort, the only interesting numbers are 0 and all.
| 
| Nonsense. I can cite numerous examples of such happening in real life.
| [Miscellaneous examples elided]
OK, so what argument will you make that, given one of these leaky,
partially predictable, generators, 128 bits are too few but by some
magic 256 are enough?  If they really are enough, why not generate
256 bits and mash them together into 128?

|  Such calculations are nonsense.  Moore's Law stops working at some
|  point, as you start to run out of electrons to run through all your
|  gates.  2^128 isn't just out of our current range; it's out of range
|  of any technology we have any inkling of today.
| 
| The death of Moore's law, like the end of the world, has been
| predicted many times, with the same result.
Funny thing about exponential curves in the real world:  They stop
being exponential eventually.
-- Jerry

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


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

2006-11-07 Thread Derek Atkins

Quoting Leichter, Jerry [EMAIL PROTECTED]:


| ...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/warlord/PP-ASEL-IA N1NWH
  [EMAIL PROTECTED]PGP key available


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


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

2006-11-07 Thread Peter Gutmann
Saqib Ali [EMAIL PROTECTED] 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 [EMAIL PROTECTED]


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

2006-11-07 Thread Alexander Klimov
On Tue, 7 Nov 2006, Peter Gutmann wrote:

 Saqib Ali [EMAIL PROTECTED] 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 [EMAIL PROTECTED]


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

2006-11-07 Thread Saqib Ali

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-disk-encryption.net

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


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

2006-11-07 Thread Peter Gutmann
Saqib Ali [EMAIL PROTECTED] 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?

HKLM\System\CurrentControlSet\Control\FileSystem\NtfsDisableLastAccessUpdate =
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 [EMAIL PROTECTED]


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

2006-11-07 Thread Leichter, Jerry
|  | ...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 [EMAIL PROTECTED]


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

2006-11-07 Thread dave kleiman
  -Original Message-
 From: Saqib Ali [mailto:[EMAIL PROTECTED] 
 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 [EMAIL PROTECTED]


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

2006-11-06 Thread Saqib Ali

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=viewtopicid=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 [EMAIL PROTECTED]


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

2006-11-06 Thread Peter Gutmann
Alexander Klimov [EMAIL PROTECTED] 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 [EMAIL PROTECTED]


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

2006-11-06 Thread Ralf Senderek


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?


Yes and no!

I use dm-crypt on a Linux laptop with FC5.

On the encrypted filesystem:

#  df
/dev/mapper/secure  309895213342 80553  73% /secure

#  time dd if=/dev/zero of=cryptogram bs=1MB count=50
50+0 records in
50+0 records out
5000 bytes (50 MB) copied, 1.96366 seconds, 25.5 MB/s
dd if=/dev/zero of=cryptogram bs=1MB count=50  0.00s user 0.52s system 25%
cpu 2.023 total

On the unencrypted filesystem:

#  time dd if=/dev/zero of=cryptogram bs=1MB count=50
50+0 records in
50+0 records out
5000 bytes (50 MB) copied, 0.216106 seconds, 231 MB/s

real0m0.257s
user0m0.000s
sys 0m0.252s

The factor 9.05 making the the unencrypted filesystem faster than the
encrypted one really does not make a difference for me for anything I do.
I'd be happy with 1 MB/s and I got 25! (using AES-256)

Regards

Ralf Senderek

*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*
* Ralf Senderek  [EMAIL PROTECTED] http://senderek.com*  What is privacy  *
* Sandstr. 60   D-41849 Wassenberg  +49 2432-3960   *  without  *
* PGP: AB 2C 85 AB DB D3 10 E7  CD A4 F8 AC 52 FC A9 ED *Pure Crypto?   *
49466008763407508762442876812634724277805553224967086648493733366295231438448


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


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

2006-11-06 Thread Jonathan Thornburg
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 [EMAIL PROTECTED]
   Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
   Golm, Germany, Old Europe http://www.aei.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 [EMAIL PROTECTED]


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

2006-11-06 Thread Leichter, Jerry
| ...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 [EMAIL PROTECTED]


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

2006-11-06 Thread Jason Holt


On Sat, 4 Nov 2006, Ralf Senderek wrote:


On the unencrypted filesystem:

#  time dd if=/dev/zero of=cryptogram bs=1MB count=50
50+0 records in
50+0 records out
5000 bytes (50 MB) copied, 0.216106 seconds, 231 MB/s

real0m0.257s
user0m0.000s
sys 0m0.252s


Unless you have a disk array in your laptop, that performance is an artifact 
of buffering.  Here are unbuffered and buffered numbers for my rather new 
desktop machine:


$ hdparm -t /dev/sda

/dev/sda:
 Timing buffered disk reads:  174 MB in  3.01 seconds =  57.79 MB/sec


$ hdparm -T /dev/sda

/dev/sda:
 Timing cached reads:   5188 MB in  2.00 seconds = 2595.82 MB/sec

The 25MB/sec number for your encrypted partition looks like it's probably 
right, though:


$ openssl speed aes-256-cbc
[...]
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes256 bytes   1024 bytes   8192 bytes
aes-256 cbc  52071.66k55008.98k55609.83k55984.13k55776.36k


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


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

2006-11-03 Thread Alexander Klimov
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 [EMAIL PROTECTED]


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

2006-11-03 Thread Steven M. Bellovin
On Thu, 02 Nov 2006 10:42:29 -0500, Ivan Krsti?
[EMAIL PROTECTED] wrote:

 Adam Shostack wrote:
  Just a nit:  as I understand things, Bitlocker is available, but not
  on, by default.  Someone needs to actively flip a switch to make it
  go.
 
 Ah, okay. The notes I jotted down from MacIver's talk at HITB in
 Malaysia indicate he said it was on by default in the upper versions,
 but I could well have written it down incorrectly. Thanks for the
 correction.
 
My understanding is that that was the plan, but concern about lost
passwords made them change their minds.


--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

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


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

2006-11-02 Thread Saqib Ali

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=viewtopicid=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-disk-encryption.net

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


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

2006-11-02 Thread Adam Shostack
On Tue, Oct 31, 2006 at 06:50:20PM -0500, Ivan Krsti?? wrote:
| On the other hand, Vista is shipping with BitLocker enabled by default
| in the upper editions (Enterprise or somesuch), and doesn't rely on

Just a nit:  as I understand things, Bitlocker is available, but not
on, by default.  Someone needs to actively flip a switch to make it
go.

Adam
(Speaking for me.)

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


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

2006-11-02 Thread Ivan Krstić
Adam Shostack wrote:
 Just a nit:  as I understand things, Bitlocker is available, but not
 on, by default.  Someone needs to actively flip a switch to make it
 go.

Ah, okay. The notes I jotted down from MacIver's talk at HITB in
Malaysia indicate he said it was on by default in the upper versions,
but I could well have written it down incorrectly. Thanks for the
correction.

-- 
Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D

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


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

2006-11-01 Thread Ivan Krstić
Saqib Ali wrote:
 http://www.infoworld.com/article/06/10/30/HNseagateagain_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ć [EMAIL PROTECTED] | GPG: 0x147C722D

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


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

2006-11-01 Thread Damien Miller
On Mon, 30 Oct 2006, Saqib Ali wrote:

 http://www.sfgate.com/cgi-bin/article.cgi?file=/chronicle/archive/2006/10/30/BUGU2M1ETT1.DTLtype=printable
 http://www.theglobeandmail.com/servlet/story/RTGAM.20061030.wharddrive1029/BNStory/Front/?page=rssid=RTGAM.20061030.wharddrive1029
 http://www.infoworld.com/article/06/10/30/HNseagateagain_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/osdsim2.pdf

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