To quote Ron Rivest, it's easy to make a secure hash function, it's hard to make a secure hash function that is also fast.
You can trivially wrap AES to make a secure hash function, but it would have a 128-bit output, which is not wide enough. It would also be slow. The trick is to make a wide hash function that runs fast.
What you suggest is a fine thing to do. However, the advantage of UBI is that the tweak is used throughout the hash function and thus has better anti-collision properties. They're so good that we have proofs of them.
In the late '90s, when I was at Counterpane, John Kelsey and I created a series of Blowfish variants. The goal was that they were intentionally non-interoperable so we could have SSL that only Counterpane machines would have the code for.
I referred to this as a "you must be at least this tall to hack this system" measure.
They were:
Blackfish, brownfish, redfish, orangefish, yellowfish, greenfish, bluefish, indigofish, violetfish, goldfish, whitefish, silverfish, plaidfish, and octarinefish.
Maybe someday those names will be reused, but I think Fourfish is also a great name.
You know, we didn't stop being Niels's friend when he went to work for Microsoft. We thought about, but when it was put to a vote, our touch-screen voting machine said it was unanimous that we'd keep him.
I think it must also be said that they didn't suck out his brain when he went to work there, except for that one small part of the left temporal lobe, his pineal gland, and that extra defibrillator they installed. He's fine. Really.
Alaederach, I'm Jon Callas, CTO at PGP Corporation. I want to address a few of the issues you brought up.
First, the article that you link to is not about the current products.
The article is about "PGP Disk" which is now what we call "PGP Virtual Disk." That is a container-disk encryption system. It is still offered along with PGP WDE, as it's nice to have both. There have been many improvements to it since that article was written.
My guess is that article is over ten years old. There's no date on it, but based upon what he says -- he installed it on Windows 95 running an AMD K6 200-MHz computer with 9 GB of Ultra DMA EIDE drives and 64 MB of SDRAM memory -- my guess is that it dates from late 1997.
If you want to do a fair comparison, let's also test against the experimental Linux 1.2 kernel, too, which also dates from about that time. That article also talks about CAST (which is still an option in Virtual Disk, but WDE uses AES). I can go on, but you're not asking about that, you're asking about WDE. My point is that if you research our present products and reference an article about a different product from last century, it's not going to tell you what you want.
I want to talk about the three main issues I see here: partitioning, compression, and performance.
When it comes to partitioning, PGP WDE operates below the partitions. We think that this is a huge benefit. We do not presently support dynamic repartitioning. It's a goal, as our long-term plan is to support Windows, Mac OS X, and Linux on the same disk with multiple partitions. We're not there yet. My personal opinion is that partitioning made sense when disks had megabytes. It doesn't make sense when they have terabytes, except for some obvious exceptions, like that you want to have a triple-boot disk. Your situation seems to be different, and I'd love to hear your views and needs for dynamic partitioning.
There are no issues with compression with WDE or Virtual Disk. I don't even understand what the issue could be. An encrypting driver writes blocks of ones and zeros. It's below the file system as well as below the partitioning system. It all just works. I'm using WDE on all my computers, and it just works.
The last issue, which you didn't bring up, but is important, is performance. When you measure *any* WDE system, not just ours, there is obviously a performance loss -- because you're adding the encryption. This is even true with hardware encryption.
Nearly any number between "essentially zero" and 100% are true, given what you measure. On a steady-state running system doing normal tasks, the WDE overhead is essentially zero. Users won't notice it at all.
At the other end of the scale, we've done some performance measurement, and compared the real WDE driver against one that no-oped the encryption. The result is that the encryption takes about 1/2 the time of the total driver throughput. You can call this 50% or 100% depending on how you like to count.
In a real-world situation, the real factor is how much time you are spending in the disk driver. If you have a heavily IO-bound system that's spending 30% of its time in the driver, then WDE is costing you 15% of your CPU. But if you're compute-bound, then WDE is costing you literally nothing.
However, if you get a hardware encrypting disk, you don't improve the situation. We've benchmarked some of the new encrypting spindles against their non-encrypting versions. The performance overhead is much worse for those than for our WDE. It adds zero to your CPU, but it's a huge latency issue, up to nearly a one-quarter drop. This shouldn't be a surprise -- we're doing the encryption on a 64-bit Intel or AMD processor, and they're doing it on an embedded CPU on the controller. Which one do you think is going to be faster?
There are a set of advantages and disadvantages to doing encryption on the CPU or on the disk, but speed goes to doing it in software. The speed advantage of software is only to shift even more to t
Slashdot Mirror
To quote Ron Rivest, it's easy to make a secure hash function, it's hard to make a secure hash function that is also fast. You can trivially wrap AES to make a secure hash function, but it would have a 128-bit output, which is not wide enough. It would also be slow. The trick is to make a wide hash function that runs fast.
What you suggest is a fine thing to do. However, the advantage of UBI is that the tweak is used throughout the hash function and thus has better anti-collision properties. They're so good that we have proofs of them.
In the late '90s, when I was at Counterpane, John Kelsey and I created a series of Blowfish variants. The goal was that they were intentionally non-interoperable so we could have SSL that only Counterpane machines would have the code for. I referred to this as a "you must be at least this tall to hack this system" measure. They were: Blackfish, brownfish, redfish, orangefish, yellowfish, greenfish, bluefish, indigofish, violetfish, goldfish, whitefish, silverfish, plaidfish, and octarinefish. Maybe someday those names will be reused, but I think Fourfish is also a great name.
You know, we didn't stop being Niels's friend when he went to work for Microsoft. We thought about, but when it was put to a vote, our touch-screen voting machine said it was unanimous that we'd keep him. I think it must also be said that they didn't suck out his brain when he went to work there, except for that one small part of the left temporal lobe, his pineal gland, and that extra defibrillator they installed. He's fine. Really.
First, the article that you link to is not about the current products.
The article is about "PGP Disk" which is now what we call "PGP Virtual Disk." That is a container-disk encryption system. It is still offered along with PGP WDE, as it's nice to have both. There have been many improvements to it since that article was written.
My guess is that article is over ten years old. There's no date on it, but based upon what he says -- he installed it on Windows 95 running an AMD K6 200-MHz computer with 9 GB of Ultra DMA EIDE drives and 64 MB of SDRAM memory -- my guess is that it dates from late 1997.
If you want to do a fair comparison, let's also test against the experimental Linux 1.2 kernel, too, which also dates from about that time. That article also talks about CAST (which is still an option in Virtual Disk, but WDE uses AES). I can go on, but you're not asking about that, you're asking about WDE. My point is that if you research our present products and reference an article about a different product from last century, it's not going to tell you what you want.
I want to talk about the three main issues I see here: partitioning, compression, and performance.
When it comes to partitioning, PGP WDE operates below the partitions. We think that this is a huge benefit. We do not presently support dynamic repartitioning. It's a goal, as our long-term plan is to support Windows, Mac OS X, and Linux on the same disk with multiple partitions. We're not there yet. My personal opinion is that partitioning made sense when disks had megabytes. It doesn't make sense when they have terabytes, except for some obvious exceptions, like that you want to have a triple-boot disk. Your situation seems to be different, and I'd love to hear your views and needs for dynamic partitioning.
There are no issues with compression with WDE or Virtual Disk. I don't even understand what the issue could be. An encrypting driver writes blocks of ones and zeros. It's below the file system as well as below the partitioning system. It all just works. I'm using WDE on all my computers, and it just works.
The last issue, which you didn't bring up, but is important, is performance. When you measure *any* WDE system, not just ours, there is obviously a performance loss -- because you're adding the encryption. This is even true with hardware encryption.
Nearly any number between "essentially zero" and 100% are true, given what you measure. On a steady-state running system doing normal tasks, the WDE overhead is essentially zero. Users won't notice it at all.
At the other end of the scale, we've done some performance measurement, and compared the real WDE driver against one that no-oped the encryption. The result is that the encryption takes about 1/2 the time of the total driver throughput. You can call this 50% or 100% depending on how you like to count.
In a real-world situation, the real factor is how much time you are spending in the disk driver. If you have a heavily IO-bound system that's spending 30% of its time in the driver, then WDE is costing you 15% of your CPU. But if you're compute-bound, then WDE is costing you literally nothing.
However, if you get a hardware encrypting disk, you don't improve the situation. We've benchmarked some of the new encrypting spindles against their non-encrypting versions. The performance overhead is much worse for those than for our WDE. It adds zero to your CPU, but it's a huge latency issue, up to nearly a one-quarter drop. This shouldn't be a surprise -- we're doing the encryption on a 64-bit Intel or AMD processor, and they're doing it on an embedded CPU on the controller. Which one do you think is going to be faster?
There are a set of advantages and disadvantages to doing encryption on the CPU or on the disk, but speed goes to doing it in software. The speed advantage of software is only to shift even more to t