Re: [-SPAM-] Re: Can you keep a secret? This encrypted drive can...
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...
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...
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...
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...
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...
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...
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...
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...
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...
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...
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...
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...
| | 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...
| 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...
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...
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...
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...
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...
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...
| | ...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...
-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...
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...
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...
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...
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...
| ...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...
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...
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...
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...
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...
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...
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...
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]
Can you keep a secret? This encrypted drive can...
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 -- Saqib Ali, CISSP, ISSAP http://www.full-disk-encryption.net - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
