The shutdown is not complete yet, though: Verisign hasn't changed their wildcard DNS entry
Actually that means the shutdown has not started yet. Removing the DNS entry is the only thing that matters. The actual webserver can stay for as long as they want, but the IP address 64.94.110.11 will of course never be usable again. We will have switched to IPv6 before the last filtering of that address is removed.
Sounds way better than just using sector number. But still I'm a litle worried. Actually there is a shortcut to generate those IVs using aproximately half the amount of table data. But what worries me the most is, that the IV is reused every time the same sector is read. With access to a backup of the container, you might be able to abuse this fact.
A better cover would be a hobby/job as a photographer.
Yep, store all original uncompressed images (or lossless compressed). That is a good idea, because if you want to manipulate the images later, you want to maintain the quality as long as possible. Of course you can hide something in the least significant bits. And by hashing the bits you are going to overwrite you also have a great random source for your probabilistic encryption.
that's just some random free space that happens to take up most of my disk
Somebody once told me, that he kept a large file with random bytes on his HD, such that he could delete it if he was in an urgent need for more disk space and couldn't find anything else to delete.
I thought rubber hose was a term for decryption hardware/techniques that work against strong crypto?
It is also the name of a filesystem encryption supposed to be resistant to this kind of attack. The victim provides you with a password, and you can decrypt the filesystem and find a number of files. There will be some free space, which is filled with random bytes. There could be another password, which would reveal that some of the aparantly empty space contains more encrypted files. And so it goes on. No matter how many passwords you have, there is no way to know, if the rest of the space is free space with random bytes or there is another one. (At least that is the explanation I have heard).
Better than a specification, why don't you download the full source to PGPDisk and review it for us?
That is certainly not better than a specification. We are talking about 14MB of compressed source code. Trying to find out how good it is without knowing what it is supposed to do is a lot of work. It would be better to first read a specification to find out if that is secure, and afterwards find out if the implementation actually does what the specification says.
Granted, that's not great (but the risk is mitigated by using a random encryption key anyway).
The key used by cryptoloop is just the hash of the password. But being random or not is not really the point here. The point is, that it is the same key being used for every sector on the disk, and every time that sector is being written.
Note that GBDE uses a static (all zero!) IV - even worse!
I must admit I didn't read all of it yet. (I'll print out the article tomorrow at the university). I have been thinking about it, if a new random key is used every time a sector is encrypted, the IV might not be necesarry. Though in my suggested implementation I do use an IV for every sector, because I have no proof, that the random key is enough.
Additionally, you obviously know nothing about cryptography, otherwise you'd not make such a stupid assumption about Rijndael, an OPEN algorithm developed outside the United States. It's been out for years and many people have failed miserably when trying to cryptanalyze it.
Anybody who actually read and understood the AES proposal would know, that it is highly unlikely there could be any backdoor. Every design decision had a reason. Wherever multiple choices where available and no technical reason made one better than another, the final decission would be the one giving the least possibility for hiding any kind of backdoor. And BTW it was developed in Belgium.
While I agree interoperability is important, there are some more important problems to solve first. You mention the Linux cryptoloop implementation. But cryptoloop doesn't even interoperate with itself. In earlier versions you could copy the file used for actual storage to a different locations, and it would get unreadable. That was a major problem, because it was bound to eventually cause data loss. Newer version has addressed this issue. During the last few years two or three such flaws have been fixed. But each time it caused the new version to be incompatible with the older versions. This has been troubeling for people having data encrypted with the old version trying to migrate to a later version.
Another problem is, that specifications for the different implementations are not easilly available. I for one would very much have liked to read the specification on a product like PGPdisk. Mostly because it is claimed to be great, but mostly by people not knowing much about security properties in disk encryptions. If I could find the specification I could know, if it is as good as people claim or as bad as I fear.
If you want to implement a disk encryption, and you find existing implementations to be insecure in some way, you have a choice to make. Either you make something compatible with existing systems, and as insecure as those. Or you make something more secure, but at the same time incompatible with all existing implementations.
I find security more important than compatibility.
I thought this was a bad idea, since RSA is non probabilistic.
A hash function is not supposed to be probabilistic, a hash function must be deterministic, otherwise it wouldn't work. Of course using RSA for hashing is a bad idea not only because of performance, but also because RSA is not a hash function.
When used as a hash, you've got neither semantic security nor indistinguishability.
Semantic security is a concept used about encryptions not hashes. To get semantic security an encryption needs to be probabilistic. RSA is not probabilistic, neither is any symetric block cipher. But they can be used as building blocks in semantic secure encryptions.
AFAIK rubberhouse works on the filesystem layer, while what is described here work on the block layer. That actually means you can easilly use the two on top of each other (assuming they are available for the same OS). Some of the security properties rubberhose aims for are impossible to do on the block layer. OTOH doing encryption on the block layer is simpler than doing it on the filesystem layer, and you are free to put whatever filesystem you prefer on top of that. Of course even encryption on the block layer can get complicated if you want to make it as secure as possible. Maybe performance can be improved by doing encryption in the filesystem, but proving security gets really tricky.
I have been working on article on disk encryption though it is not quite ready to be published yet. I didn't know anybody else was working seriously on this. I know about cryptoloop in Linux. It is bad, but not the worst I have seen described. It is nice to finally see somebody but me realizing that disk encryption is not as simple as those implementing it think. I don't know how the more "professional" products work. What I have realized is, that good disk encryption has an overhead on disk usage. Those "professional" products I have seen just a few details about doesn't have for too litle overhead for good crypto. The system described by the article only protects cold disks, no protection at all for hot disks. What I describe in my own article actually has some protection for hot disks, not much protection though, because the hot disk naturally limits the protection that is possible.
Doesn't sound like ignorance to me. If the six 200 GB drives make up a 1.2TB logical drive, there cannot be any redundancy. Six IDE drives, and no redundancy - I don't hope he have any important data there. Had he at least used RAID-4 or RAID-5 giving him a 1TB logical drive and one redundant disk, he would have a fair chance of keeping his data (assuming the broken disk gets replaced before the next fails).
Just right click on your CD-ROM device in device manager, go to properites, and uncheck the "Auto Insert Notification" checkbox.
Wrong. That disables detection of disc changes. What you want is disabling just the autorun feature without breaking something else. I really don't know why they make such a broken option so easilly available, while hiding the setting people should be changing instead.
the little.exe that is started by the autorun "feature".
Autorun is and always was a security hole. Microsoft should have known already when they implemented it, that it was a security hole. A similar but more subtle hole was fixed in AmigaOS five years earlier. That hole was used by multiple viruses, and caused the computer to get affected as soon as an infected floppy was inserted in the drive.
It is possible to disable autorun in Windows 9x, the setting is very well hidden, and you need to use regedit to change it. Find the setting named:
"HKEY_CURRENT_USER / Software / Microsoft / Windows / CurrentVersion / Policies / Explorer / NoDriveAutoRun" and change the value to 0x03ffffff
The most suspicious I saw on google was on valentine's day, when they had a special logo linking to a search for information about valentine's day. On that page there was a sponsored link to a company selling penis enlargements. Really!
The danish language is incompatable with your inferior keyboards:)
No, it simply apears to be slashdot, which replaces the last three letters from the Danish alpahabet by AE, O, and A. I guess those who wrote that piece of code doesn't know how much they can change the meaning of a word by doing that. If I for example tried to write "eagels" in Danish, slashdot would replace it by "boar".
some apps don't even support copy/paste.
In my experience they are rare, but there does exist some combinations, where it doesn't work.
Personally, I want to have two clipboard buffers
Maybe you would like Klipper from KDE. It is not exactly what you request, but in some cases it works nicely.
while the copy buffer can be used to keep something until I tell it to go away with a ctrl-C or something.
Except from the ctrl-C part I agree it would be a nice additional feature. Perhaps ctrl+ins and shift+ins would be good choices, if they are not already used.
Slashdot Mirror
The shutdown is not complete yet, though: Verisign hasn't changed their wildcard DNS entry
Actually that means the shutdown has not started yet. Removing the DNS entry is the only thing that matters. The actual webserver can stay for as long as they want, but the IP address 64.94.110.11 will of course never be usable again. We will have switched to IPv6 before the last filtering of that address is removed.
Like the Motorola surfboards does?
scramdisk IV
Sounds way better than just using sector number. But still I'm a litle worried. Actually there is a shortcut to generate those IVs using aproximately half the amount of table data. But what worries me the most is, that the IV is reused every time the same sector is read. With access to a backup of the container, you might be able to abuse this fact.
A better cover would be a hobby/job as a photographer.
Yep, store all original uncompressed images (or lossless compressed). That is a good idea, because if you want to manipulate the images later, you want to maintain the quality as long as possible. Of course you can hide something in the least significant bits. And by hashing the bits you are going to overwrite you also have a great random source for your probabilistic encryption.
and maybe after, since there could always be something worse in the free space.
That would remove every incitement to tell them anything, no matter how much you tell them they could think you are hiding something.
that's just some random free space that happens to take up most of my disk
Somebody once told me, that he kept a large file with random bytes on his HD, such that he could delete it if he was in an urgent need for more disk space and couldn't find anything else to delete.
I thought rubber hose was a term for decryption hardware/techniques that work against strong crypto?
It is also the name of a filesystem encryption supposed to be resistant to this kind of attack. The victim provides you with a password, and you can decrypt the filesystem and find a number of files. There will be some free space, which is filled with random bytes. There could be another password, which would reveal that some of the aparantly empty space contains more encrypted files. And so it goes on. No matter how many passwords you have, there is no way to know, if the rest of the space is free space with random bytes or there is another one. (At least that is the explanation I have heard).
Better than a specification, why don't you download the full source to PGPDisk and review it for us?
That is certainly not better than a specification. We are talking about 14MB of compressed source code. Trying to find out how good it is without knowing what it is supposed to do is a lot of work. It would be better to first read a specification to find out if that is secure, and afterwards find out if the implementation actually does what the specification says.
Granted, that's not great (but the risk is mitigated by using a random encryption key anyway).
The key used by cryptoloop is just the hash of the password. But being random or not is not really the point here. The point is, that it is the same key being used for every sector on the disk, and every time that sector is being written.
Note that GBDE uses a static (all zero!) IV - even worse!
I must admit I didn't read all of it yet. (I'll print out the article tomorrow at the university). I have been thinking about it, if a new random key is used every time a sector is encrypted, the IV might not be necesarry. Though in my suggested implementation I do use an IV for every sector, because I have no proof, that the random key is enough.
Additionally, you obviously know nothing about cryptography, otherwise you'd not make such a stupid assumption about Rijndael, an OPEN algorithm developed outside the United States. It's been out for years and many people have failed miserably when trying to cryptanalyze it.
Anybody who actually read and understood the AES proposal would know, that it is highly unlikely there could be any backdoor. Every design decision had a reason. Wherever multiple choices where available and no technical reason made one better than another, the final decission would be the one giving the least possibility for hiding any kind of backdoor. And BTW it was developed in Belgium.
This is great, but what about interoperability?
While I agree interoperability is important, there are some more important problems to solve first. You mention the Linux cryptoloop implementation. But cryptoloop doesn't even interoperate with itself. In earlier versions you could copy the file used for actual storage to a different locations, and it would get unreadable. That was a major problem, because it was bound to eventually cause data loss. Newer version has addressed this issue. During the last few years two or three such flaws have been fixed. But each time it caused the new version to be incompatible with the older versions. This has been troubeling for people having data encrypted with the old version trying to migrate to a later version.
Another problem is, that specifications for the different implementations are not easilly available. I for one would very much have liked to read the specification on a product like PGPdisk. Mostly because it is claimed to be great, but mostly by people not knowing much about security properties in disk encryptions. If I could find the specification I could know, if it is as good as people claim or as bad as I fear.
If you want to implement a disk encryption, and you find existing implementations to be insecure in some way, you have a choice to make. Either you make something compatible with existing systems, and as insecure as those. Or you make something more secure, but at the same time incompatible with all existing implementations.
I find security more important than compatibility.
I thought this was a bad idea, since RSA is non probabilistic.
A hash function is not supposed to be probabilistic, a hash function must be deterministic, otherwise it wouldn't work. Of course using RSA for hashing is a bad idea not only because of performance, but also because RSA is not a hash function.
When used as a hash, you've got neither semantic security nor indistinguishability.
Semantic security is a concept used about encryptions not hashes. To get semantic security an encryption needs to be probabilistic. RSA is not probabilistic, neither is any symetric block cipher. But they can be used as building blocks in semantic secure encryptions.
How is this like rubberhose?
AFAIK rubberhouse works on the filesystem layer, while what is described here work on the block layer. That actually means you can easilly use the two on top of each other (assuming they are available for the same OS). Some of the security properties rubberhose aims for are impossible to do on the block layer. OTOH doing encryption on the block layer is simpler than doing it on the filesystem layer, and you are free to put whatever filesystem you prefer on top of that. Of course even encryption on the block layer can get complicated if you want to make it as secure as possible. Maybe performance can be improved by doing encryption in the filesystem, but proving security gets really tricky.
Why is it bad?
It use sector numbers as IV.
I have been working on article on disk encryption though it is not quite ready to be published yet. I didn't know anybody else was working seriously on this. I know about cryptoloop in Linux. It is bad, but not the worst I have seen described. It is nice to finally see somebody but me realizing that disk encryption is not as simple as those implementing it think. I don't know how the more "professional" products work. What I have realized is, that good disk encryption has an overhead on disk usage. Those "professional" products I have seen just a few details about doesn't have for too litle overhead for good crypto. The system described by the article only protects cold disks, no protection at all for hot disks. What I describe in my own article actually has some protection for hot disks, not much protection though, because the hot disk naturally limits the protection that is possible.
Do you think he still think so once he realize what you did to his server by posting this on slashdot?
Using analogies on Slashdot is like comparing apples and oranges.
Comparing apples and oranges is not a problem.
why don't I get to be on the front page of slashdot?
You don't have a webpage with a lot of cool pictures of it.
Doesn't sound like ignorance to me. If the six 200 GB drives make up a 1.2TB logical drive, there cannot be any redundancy. Six IDE drives, and no redundancy - I don't hope he have any important data there. Had he at least used RAID-4 or RAID-5 giving him a 1TB logical drive and one redundant disk, he would have a fair chance of keeping his data (assuming the broken disk gets replaced before the next fails).
So you've got a terrabyte of data, but can it handle Slashdot?
Increasing the amount of data without increasing the bandwidth is not the way to avoid slashdoting.
Just right click on your CD-ROM device in device manager, go to properites, and uncheck the "Auto Insert Notification" checkbox.
Wrong. That disables detection of disc changes. What you want is disabling just the autorun feature without breaking something else. I really don't know why they make such a broken option so easilly available, while hiding the setting people should be changing instead.
the little .exe that is started by the autorun "feature".
Autorun is and always was a security hole. Microsoft should have known already when they implemented it, that it was a security hole. A similar but more subtle hole was fixed in AmigaOS five years earlier. That hole was used by multiple viruses, and caused the computer to get affected as soon as an infected floppy was inserted in the drive.
It is possible to disable autorun in Windows 9x, the setting is very well hidden, and you need to use regedit to change it. Find the setting named: "HKEY_CURRENT_USER / Software / Microsoft / Windows / CurrentVersion / Policies / Explorer / NoDriveAutoRun" and change the value to 0x03ffffff
Google had something like this last month.
The most suspicious I saw on google was on valentine's day, when they had a special logo linking to a search for information about valentine's day. On that page there was a sponsored link to a company selling penis enlargements. Really!
The danish language is incompatable with your inferior keyboards :)
No, it simply apears to be slashdot, which replaces the last three letters from the Danish alpahabet by AE, O, and A. I guess those who wrote that piece of code doesn't know how much they can change the meaning of a word by doing that. If I for example tried to write "eagels" in Danish, slashdot would replace it by "boar".
some apps don't even support copy/paste.
In my experience they are rare, but there does exist some combinations, where it doesn't work.
Personally, I want to have two clipboard buffers
Maybe you would like Klipper from KDE. It is not exactly what you request, but in some cases it works nicely.
while the copy buffer can be used to keep something until I tell it to go away with a ctrl-C or something.
Except from the ctrl-C part I agree it would be a nice additional feature. Perhaps ctrl+ins and shift+ins would be good choices, if they are not already used.