No let's not, since before that can be done there has to be an understanding of the underlying mathematics.
I hope can help you a little bit in gaining that understanding. We want to know how much information we can store on this piece of paper. None of us know the exact answer, but we really don't care that much as long as we can compute an upper and a lower bound.
The mistake you made was to do some complicated computations on a lower bound, which turned out to be too complicated. What I did was to do some simple computations and achieve an upper bound. Since that upper bound is smaller than your lower bound, one of them has to be wrong. And that is exactly why I aimed for an calculation as simple as possible, not a bound as close to the exact answer as possible. The simple calculation is not as prone to errors.
A bit of common sense also helps here. Knowing how much space a bitmap with the resolution of an ordinary printer and size of a piece of paper will take, common sense will tell you, that you cannot store more than that. Basically if you could do that, there wouldn't be any reason to print it out, since the encoding would already be way smaller than the original, so you might as well store the bitmap on an ordinary floppy disk, that also saves you the trouble of producing a reliable scanner.
You calculations simply doesn't make any sense. Now let's compute an upper bound based on the first few numbers you presented. 85000 blocks of 3*3 dots with 256 possible colours. That is a total of 765000 dots and the 256 possible colours can simply be mapped to the 256 possible values of a byte. In ohter words 765KB is an absolute upper bound on the information you can store on that piece of paper. In practice you might be able to store much less information.
You might not trust the product Seagate are announcing, and you might have good reasons not to trust it. In fact I would not recommend anybody to trust this product unless Seagate have done everything technically possible to make a product that can be verified by third parties. At the very least that would require a complete description of which ciphers and modes are being used. (And I do not consider "AES256-CBC" to be anywhere near a complete description).
To be verifiable, they would also have to offer an interface to read the raw data physically stored on the disk without going through the encryption. Some people might see such an interface as a weakness, I disagree. An interface to read the physical bits from the disk would demonstrate, that they trust their own product. If the vendor does not trust the product, why should we?
There are multiple security aspects of storage encryption that worries me, because so far I haven't seen any product getting it right. It seems no product is designed to be truly secure and consider the potential problems. My number one wory about encryption build into hard drives is the way they handle password changing. The obvious (and flawed) way to do it is to use the password to encrypt the key and just reencrypt the key upon a password change. But how can I be sure nobody has been able to get a copy of the encrypted key? People might try to tell me, that I shouldn't worry because it is encrypted. But it would be encrypted under the old password. If there is supposed to be any point in changing my password, it must be done in such a way, that the old password cannot be used to read data I wrote after changing the password. One case of changing passwords is when you change it from the initial default password to your own choice of password. Of course everybody knows the default password, so a key being encrypted under the default password is not any protection.
There are ways to do this securely, even without reencrypting the entire disk. But reencrypting the entire disk might still be the desired solution, as it only has a performance cost when you are actually changing the password. Other solutions can change the password in a fast and safe way, but have a small performance cost on every read and write. And since the reencryption can happen internally in the drive, it does not require CPU power on the host and does not depend on the bus. In other words reencryption can happen at the full speed which the drive can do sequential reads and writes.
Password changing is not my only worry, but it is by far my greatest worry with storage encryptions that come enabled by default. Another problem is that most products use deterministic encryption (and the only product I know using probabilistic encryption use a flawed pseudorandom number generator). Since Seagate are making the drives they can make a minor change to the way the drive works that would eliminate the worst hurdle to probabilistic encryptions. Probabilistic encryption requires extra disk space, there is no way you can fit 528 bytes of high entropy data into a 512 bytes sector. This means that usually you would have to do some tricky layouts of data, that will introduce additonal performance overhead and the risk of data loss if done incorrectly (and is in fact done incorrectly in the only implementation I know about). The solution Seagate could chose was to simply make the physical sectors slightly larger. Actually the physical sectors might already be larger than 512 bytes and contain multiple logical sectors, that would require some considerations to avoid data loss, but that problem is completely unrelated to encryption and is one which all harddisk vendors have already had to consider. If Seagate use larger physical sectors, it means less space overhead for the encryption, because the overhead is a constant that does not depend on the sector size. In spite of this I fear that Seagate has decided to sacrifice security to be able to make drives with a few percent larger capacity.
But how do you design an API that allows scanners to detect malware, without that API also being useful for the user to intercept "content"?
An API should be useful, at least that is my oppinion, and I believe I share it with some people. I think the right question to be asking is, how can you design an API that can be used by malware scanners, but is not equally usable by malware. My suggestion for a solution to that problem would be to run the scanner in a sandbox. The kernel provides an API through which the virus scanner can register its code. That code needs to be able to read a few files from the disk as well as being given read access to each individual file being attempted executed. It must not be allowed to do communicate anything back to the environment, just provide a simple boolean as return code on exit. That would certainly be possible, and shouldn't be too hard to implement. (Disclaimer: I don't know the internals of Windows, so I cannot say if this is for some reasons impossible to do with Windows. But I'm sure it could be done on other systems where I do know the internals).
An interesting question is, whether the real reason for Microsoft to do this is to improve security or to lock out security software vendors. Another interesting question is, why the security software vendors complain. Do they complain because a secure version of Windows would obsolete their own product, or do they complain because they are really being locked out. The answer to those two questions might be related, except that I'm not sure the security software vendors know the answer to the first question.
If you do have the API, then malware just needs to masquerade as DRMed content.
DRM has been used as excuse to do a lot of bad things. Basically I don't believe in DRM (in much the same way as some people don't believe in Santa Claus). Of course that leads me to consider most changes done to support DRM as being bad, because they will not make DRM possible, but they do cause a lot of problems. In reallity I think the reason for many of those meassures are in fact anticompetitive meassures just using DRM as an excuse.
Hardening a kernel is different. There are legitimate reasons for hardening a kernel. And though hardening a kernel is a hard task, it is not an impossible task.
I suppose one solution to the compatible decryption software issue is to use file encryption on the backups and store uncompressed clear-text of the source code of all the backup/restore/crypt utilities.
OK, now I see what you were trying to say. And I very much agree that it is a good idea to stick the unencrypted source with the backups. I wrote my own software for backup, and I do keep the source in many locations, including three public accessible http servers. Though I don't keep the source for tar and gpg in those locations, even though I do rely on them for restoring backups. Neither do I keep the gzip source even though the other sources are tared and gizped. (gpg also does some compression, I'm not sure which one, I think the ratio is slightly worse than zlib).
My context may differ from yours. I'm an academic in the humanities, and in my field (philosophy) data can remain useful for centuries, indeed sometimes millenia.
If you have data that should be available to other people also in the future, it might be a good idea to make it available to them already now. Even if the data are not encrypted, you can't be sure that anybody will be able to find it on your computer without your help, or that they will even try to do so.
suspend to disk doesn't work with encrypted swap...
True if you do it the way I suggested, suspend to disk will not work. Suspend to disk and disk encryption are not good friends, but it can be done correctly. Though any correct implementation would require you to type a password when waking up.
Well, that's not entirely correct; suspend to disk still works fine. It's just the resume after the reboot that stops working...
Of course if you setup a system in a way that would cause resume to fail, it would be a quite good idea to disable the possibility of suspending in the first place.
You can have both with some sort of hardware encryption with a passphrase and/or dongle, something like those SecureIDE encryption devices you place between your IDE interface and your harddrive.
Can you use SecureIDE on a laptop? Not that I would want to use any encryption that says 40-bit DES in the specs.
But from what I've heard (don't know if this is true, so take with a grain of salt), most consumer encryption hardware solutions use weak encryption anyway.
I think it is true, but I can't know for sure either. SecureIDE looks like the worst one based on the fact that it only uses 40 bit of key. But one thing they all seem to have in common is that they are not well documented and leaves no possibility for third parties to review the security of the implementation. Saying AES-256 is not what I consider documentation, I have seen more flawed ways to apply it than I have seen sound ways to apply it. So if they don't give more documentation, I will have to assume that most likely they used AES in the wrong way.
A similar law was passed in Denmark. I think it will go into effect at new year.
Will the next big thing be an ISP which doesn't give access to the website's of the nations public TV and radio stations' websites?
I think it would be a great idea. But I'm afraid it is not going to happen.
Or will even The Pirate Bay and Google Video be recognized as sites where you can access TV and radio programs, thus making any such attempts from the ISPs worthless?
So now the question will be, can you end up in a situation, where you have to pay for access, because you can download a pirated version from some website, but even though the law requires you to pay for the content, you still don't have access to a legal version of said content?
You said that you were using some third party encryption module whos interface or implementatation apperently changed after you upgraded.
That happens. Earlier cryptoloop implementations had bugs in the way they computed sector numbers, which were later used as IVs. Those bugs could lead to data loss. Later versions fixed the sector numbers, but were incompatible with previous versions. I think it took 3-4 tries to get it right. We probably haven't seen the last case of incompatibility, as there is still not consensus about what is the right compromise between security, speed, etc. In fact I'm pretty sure there is not one solution, which will suit everybody's needs. But maybe we will eventually see some implementation with a few knobs that can be turned without breaking the entire system.
It seems as this could have been solved by seeing what portage was installing at the time, or what kernel / modules you were using, and reproducing that setup.
In principle yes.
Am I missing something?
Could be that the data were originally encrypted with an incorrect IV based on the wrong sector numbers. In that case it would be slightly difficult to decrypt correctly, but not impossible. But then again, if the container was in the exact same location on the disk as when it was created, then it should be possible to read it with the version which had originally created it.
In such a context, given that FDE makes data recovery harder and more time-consuming
Data recovery is only relevant if you didn't do your homework. Have a backup strategy and you'll be safe. If you have important data and no backup, you will get in trouble whether it is encrypted or not.
It might even be worthwhile looking to produce slow but inexpensive RAM just so you could make volatile RAM drives for this purpose.
In many ways a good idea, but unfortunately it is likely that the most feasible approach would be to stick all that cheap RAM in a device which appears to the system as a harddisk. I think such devices already exists, but I don't think they are cheap enough or practical for a laptop. The problems with just sticking RAM of different speeds in a computer are at least the following:
Not all boards allow RAM of multiple speeds, you may limit all RAM to the slow speed.
Even if you did manage to get the RAM working at different speeds, you'd need to inform the OS about the difference, which adds complexity, and would slow down any OS unaware of the difference.
You'd also need to copy data between the slow and the fast memory. A memcpy requires CPU time and will keep the CPU spending most of the time waiting for the slow memory. The solution for this would be seperate busses to the slow and fast memory, and a unit that could copy data using DMA. While this unit access the slow memory, everything else must be able to run at full speed in the fast memory. The harddisk like apperance will provide a DMA interface with these properties, but then it will be the only way to access the slow memory.
there's one thing that I've learned from hard experience about mobile devices and hard drives: they have a very short life span.
My experience says the opposite. So far I have not yet had a problem with a mobile harddrive (laptop and external USB disks). But I have often had internal harddrives failing on me (good thing RAID and backups prevented me from losing data).
So can't it be a serious problem if your data is encrypted and bytes get knocked out here and there?
Hardware failing will be a problem whether your data is encrypted or not. The solution for this is a good backup strategy. The backup will help you in several cases: hardware fault, theft, forgotten password (assuming the backup is unencrypted but kept in a safe location).
Also, mobile devices are usually much slower than stationary ones and will only get slower if it has to apply complex algorithms to all data that goes in and out.
The main bottleneck on my laptop is harddisk I/O. Encrypting everything would require some amount of CPU time, but since in most cases the CPU is much faster than my needs, and the harddisk is slow, the encryption would not be any problem. The CPU would get more work to do, but it will have plenty of time to do so while waiting for the harddisk. Overall I wouldn't expect to see any slowdown for my everyday use. I don't want to spend lots of time benchmarking it though, I don't care if the meassurable slowdown is 1% or 10%
And that would probably also put a real big penalty on your battery life.
Possible. But the biggest energy consume in my laptop is the DVD drive.
If you are using a hardware solution, encryption the whole disk may be the only option. Otherwise, you only need to encrypt those partitions containing sensitive data.
My instinct would be to just encrypt/home,/tmp,
Your instinct is not all bad:-)
maybe/etc and/var,
You really should encrypt/var, it does contain a tmp directory, and also some spools such as mail spool and printer spool./etc is not the most important to encrypt, but still I would encrypt it./usr I wouldn't encrypt unless it just happened to be on the same file system as something I wanted to encrypt. Encrypting just some directories on a file system is less practical. It requires support from the file system, and such encryptions are more complicated and thus more prone to have weaknesses because of bad design or implementation. I'd either encrypt everything but/boot, or maybe put/usr on a seperate unencrypted partition.
and I guess/swap if I was really paranoid.
In fact swap was the first thing I decided to encrypt on my laptop. Encrypting swap is simpler and less intrusive than everything else. Thus there is really not much reason not to encrypt swap. No need for complicated key management, just generate a new random key on every boot.
Just set up an unencrypted kernel+initrd which will prompt you for a passphrase or read a key from a USB dongle.
I haven't actually set up a system like that yet, but I have no doubt, that it would be possible with Linux. From what I have read this is something that would be very difficult (if at all possible) to do with Windows. This is one great thing about Linux, the unencrypted kernel+initrd approach will work with any storage encryption. (And since the kernel and initrd does not contain any of your confidential data, it is no problem leaving it unencrypted). It does sound like on Windows the implementor of each individual storage encryption have to jump through hoops to even make it possible.
Why should be the keys stored in the boot partition? If you have encrypted filesystem, you can only gain acces by entering the password at boot time, that is the whole point.
It is not a good idea to use the password directly to encrypt/decrypt the data on disk. It is more secure to only use the password to decrypt a key, which is then used for encryption/decryption of the rest of the data on the disk.
One reason for this is, that the key can be choosen at random, which means that even if two disks are encrypted under the same password, they will use different keys. The password will only be in memory for a short time while decrypting the key, once the key is decrypted the password is wiped from memory. Thus if somebody grab a copy of your memory through a firewire port, they may be able to decrypt the harddisk on this laptop, but they will not be able to decrypt the other one they stole while it was turned off, eventhough it was using the same password.
Also you may be better protected against some combinations of brute force and slight weaknesses in the encryption. Some attacks simply work better, if the adversary have access to a significant amount of ciphertext. There will be a significant amount of ciphertext encrypted under the key, and maybe the adversary even know some of the cleartext. But that key will be entirely random. Only a small amount of data is encrypted under the password (namely the key), and the adversary will not be able to make a good guess about the cleartext, as it is entirely random. Finally the encryption used to encrypt the key under the password does not need to make any shortcuts, and could thus be much more secure. It does not need high performance, spending one second decrypting the key at bootup is perfectly acceptable, spending one second decrypting a sector would be completely unacceptable.
Lower I/O performance is not an excuse for low or no security, is it?
Seems like many people see I/O performance as a valid excuse for lowering security. Of course I agree with you that the statement about fragmentation impact on performance is nonsense, in particular in this situation. Yes encryption does lower I/O performance, but CPU speed increase faster than disk bandwidth. A few years ago, there would be a noticable slowdown from encryption, but not so much anymore. And guess what, if the fragmentation does lower performance, it will just make the encryption less noticable. Because if the disk needs more time to do the I/O, you will in fact have more CPU time to spend on the encryption before the CPU become the bottleneck.
I think it would be those doing CPU intensive tasks rather than I/O intensive tasks, that would notice the most slowdown to storage encryption. But of course all of these statements only applies as long as the encryption use a 1:1 mapping between physical and logical sectors. But almost every storage encryption does have such a 1:1 mapping, with GBDE being the only exception I know of. With some more complicated schemes, the fragmentation causing extra seeks could actually cause the encryption to require extra CPU and I/O resources. The 1:1 mapping does not have such additional cost.
Deciding, that you will not pay the performance cost in more complicated storage encryption schemes and going with a 1:1 mapping is a valid decission. Of course it should be a decission every company (or user) make themselves, however it seems in most case the designer of the storage encryption has made the decission for us. However the best schemes with a 1:1 mapping are so secure, that the additional security you could get is less important that all the security you already got from using encryption in the first place.
However I do have at least one good reason for encryption not being enabled by default in most systems. And that is the fact, that few systems have a really secure implementation of password change. In fact I don't know any storage encryption with a secure password change. In most cases the password change just reencrypts the same key under a new password, thus knowing the default password and the key which was originally on the disk will enable you to decrypt data even without knowing the new password.
That means the safe way to use storage encryption is to choose a good password, and use that password when enabling storage encryption. You should never change the password. If you have any suspect that somebody got the password or parts of the encrypted version of your data, the safe approach is to create a new encrypted container with a new password and copy all data from the old one to the new one. Finally you destroy the old encryption by overwriting it once or twice. If you encrypted the full disk, that would mean you'd have to copy the data to another media and back again.
For temporary data such as swap I'd recommend generating a random key at startup, and don't use any password at all. It does require a hardware random number generator to be really secure, as during bootup you wouldn't have had enough time to collect enough entropy. And for swap you don't have to worry about the risk of losing data on a reboot. If carefully implemented in the swapping code itself, encryption of swap space can be made very secure and completely transparent to the user. I think this is something that should be in every file system.
The only actual storage encryption mentioned in this comment is GBDE. That does not mean I recommend it. In fact there is a known weakness in GBDE, which would allow an adversary to break the encryption faster than brute force. Besides that there is a minor risk of losing data because of partial writes.
What I don't onderstand is that this is merged into the 2.6 kernel tree today.
When it is just about merging a new file system, there is not much of a risk. Ext4 will be optional like almost every other file system in Linux. Include it in the kernel if you want to, build it as a module, or don't build it at all. As long as you don't include it in your kernel or don't load the module, it will do no harm to your system. And even if you have it in your kernel, it is unlikely to do any harm unless you actually mount something with it.
The main reason Reiser4 didn't go into the kernel as easy as this was, that Reiser wanted to make changes to the VFS layer to support his new file system. So it was not just about adding a new file system, but changing how the kernel handles file system, something that could bite other users who didn't even include Reiser4 in their build.
Does the GPLv3 truly inhibit your control as a developer over your device?
If you sell the device, it is no longer your device. The person who buys a device owns said device. If I buy a device, I own that device, and I want to control it. I think one of the primary purposes of GPLv3 is to ensure my right to control my device once I have bought it.
Once GPLv3 is officially finished, I am going to read it and decide if I think FSF kept its word and made the new license in the same spirit as the old one. And once I have decided, I am going to release a statement on my homepage saying either, that anything I ever released under GPLv2 can be used under GPLv3 as well, or I will (highly unlikely) state that I don't consider GPLv3 to be a successor to GPLv2, and code I have released under GPLv2 cannot be used under the terms of GPLv3.
At first I'll probably allow new code I write to be used under GPLv2 and GPLv3 until I decide which one I like better (which will also depend on what other people do).
The correct way to make a patch is: take the source code, fix the bug, compile it, and ship as many of the executable files as necesarry. But does this third party have the source code? If they do, they probably have signed an agreement forbiding them to use it in this way. In some countries the law gives you an unwaivable right to fix bugs in software, but I'm not sure you would be allowed to share the fix with everybody in this way.
Maybe toss in a couple hundred K of local RAM for each core
This already happens today, it is called L1 cache.
or shared blocks of RAM for every 4 cores
And that might very well be the L2 cache.
Or maybe the core interconnections are arranged in a hypercube.
Now that would probably allow for better performance than the typical hieracical structure otherwise used. Of course it is going to be more complicated. If you want a hypercube structured cache, then coherency is going to be quite tricky. Even the choerency in the hieracical caches is nontrivial.
Of course you could also aim for some message passing rather than using cache for sharing data between cores. But message passing would require more changes in not only the hardware, but also the software you run on the system. But no doubt an efficient message passing in a hypercube is easier to design than a hypercube-cache.
I have- but what part of choose your hardware carefully do you people not understand?
Some people are very carefull about picking hardware with RS-232 ports. Those console ports are often used in cases where reliability is a much higher priority than performance. RS-232 is very simple compared to ethernet and USB, and thus could be expected to be more reliable.
Efficiency is not only about wasting less power, it's about generating less heat!Which is of course exactly the same. In the end all the energy you put into a computer turns into heat. The energy wasted in the power supply turns into heat in the power supply, and all the heating of the power supply is energy wasted rather than used to supply the computer.
Slashdot Mirror
Must be an unusual busines you are in when no document is ever more than 6 characters.
The mistake you made was to do some complicated computations on a lower bound, which turned out to be too complicated. What I did was to do some simple computations and achieve an upper bound. Since that upper bound is smaller than your lower bound, one of them has to be wrong. And that is exactly why I aimed for an calculation as simple as possible, not a bound as close to the exact answer as possible. The simple calculation is not as prone to errors.
A bit of common sense also helps here. Knowing how much space a bitmap with the resolution of an ordinary printer and size of a piece of paper will take, common sense will tell you, that you cannot store more than that. Basically if you could do that, there wouldn't be any reason to print it out, since the encoding would already be way smaller than the original, so you might as well store the bitmap on an ordinary floppy disk, that also saves you the trouble of producing a reliable scanner.
You calculations simply doesn't make any sense. Now let's compute an upper bound based on the first few numbers you presented. 85000 blocks of 3*3 dots with 256 possible colours. That is a total of 765000 dots and the 256 possible colours can simply be mapped to the 256 possible values of a byte. In ohter words 765KB is an absolute upper bound on the information you can store on that piece of paper. In practice you might be able to store much less information.
You might not trust the product Seagate are announcing, and you might have good reasons not to trust it. In fact I would not recommend anybody to trust this product unless Seagate have done everything technically possible to make a product that can be verified by third parties. At the very least that would require a complete description of which ciphers and modes are being used. (And I do not consider "AES256-CBC" to be anywhere near a complete description).
To be verifiable, they would also have to offer an interface to read the raw data physically stored on the disk without going through the encryption. Some people might see such an interface as a weakness, I disagree. An interface to read the physical bits from the disk would demonstrate, that they trust their own product. If the vendor does not trust the product, why should we?
There are multiple security aspects of storage encryption that worries me, because so far I haven't seen any product getting it right. It seems no product is designed to be truly secure and consider the potential problems. My number one wory about encryption build into hard drives is the way they handle password changing. The obvious (and flawed) way to do it is to use the password to encrypt the key and just reencrypt the key upon a password change. But how can I be sure nobody has been able to get a copy of the encrypted key? People might try to tell me, that I shouldn't worry because it is encrypted. But it would be encrypted under the old password. If there is supposed to be any point in changing my password, it must be done in such a way, that the old password cannot be used to read data I wrote after changing the password. One case of changing passwords is when you change it from the initial default password to your own choice of password. Of course everybody knows the default password, so a key being encrypted under the default password is not any protection.
There are ways to do this securely, even without reencrypting the entire disk. But reencrypting the entire disk might still be the desired solution, as it only has a performance cost when you are actually changing the password. Other solutions can change the password in a fast and safe way, but have a small performance cost on every read and write. And since the reencryption can happen internally in the drive, it does not require CPU power on the host and does not depend on the bus. In other words reencryption can happen at the full speed which the drive can do sequential reads and writes.
Password changing is not my only worry, but it is by far my greatest worry with storage encryptions that come enabled by default. Another problem is that most products use deterministic encryption (and the only product I know using probabilistic encryption use a flawed pseudorandom number generator). Since Seagate are making the drives they can make a minor change to the way the drive works that would eliminate the worst hurdle to probabilistic encryptions. Probabilistic encryption requires extra disk space, there is no way you can fit 528 bytes of high entropy data into a 512 bytes sector. This means that usually you would have to do some tricky layouts of data, that will introduce additonal performance overhead and the risk of data loss if done incorrectly (and is in fact done incorrectly in the only implementation I know about). The solution Seagate could chose was to simply make the physical sectors slightly larger. Actually the physical sectors might already be larger than 512 bytes and contain multiple logical sectors, that would require some considerations to avoid data loss, but that problem is completely unrelated to encryption and is one which all harddisk vendors have already had to consider. If Seagate use larger physical sectors, it means less space overhead for the encryption, because the overhead is a constant that does not depend on the sector size. In spite of this I fear that Seagate has decided to sacrifice security to be able to make drives with a few percent larger capacity.
Of cour
An interesting question is, whether the real reason for Microsoft to do this is to improve security or to lock out security software vendors. Another interesting question is, why the security software vendors complain. Do they complain because a secure version of Windows would obsolete their own product, or do they complain because they are really being locked out. The answer to those two questions might be related, except that I'm not sure the security software vendors know the answer to the first question.
DRM has been used as excuse to do a lot of bad things. Basically I don't believe in DRM (in much the same way as some people don't believe in Santa Claus). Of course that leads me to consider most changes done to support DRM as being bad, because they will not make DRM possible, but they do cause a lot of problems. In reallity I think the reason for many of those meassures are in fact anticompetitive meassures just using DRM as an excuse.
Hardening a kernel is different. There are legitimate reasons for hardening a kernel. And though hardening a kernel is a hard task, it is not an impossible task.
If you have data that should be available to other people also in the future, it might be a good idea to make it available to them already now. Even if the data are not encrypted, you can't be sure that anybody will be able to find it on your computer without your help, or that they will even try to do so.
Of course if you setup a system in a way that would cause resume to fail, it would be a quite good idea to disable the possibility of suspending in the first place.
Can you use SecureIDE on a laptop? Not that I would want to use any encryption that says 40-bit DES in the specs.
I think it is true, but I can't know for sure either. SecureIDE looks like the worst one based on the fact that it only uses 40 bit of key. But one thing they all seem to have in common is that they are not well documented and leaves no possibility for third parties to review the security of the implementation. Saying AES-256 is not what I consider documentation, I have seen more flawed ways to apply it than I have seen sound ways to apply it. So if they don't give more documentation, I will have to assume that most likely they used AES in the wrong way.
I think it would be a great idea. But I'm afraid it is not going to happen.
So now the question will be, can you end up in a situation, where you have to pay for access, because you can download a pirated version from some website, but even though the law requires you to pay for the content, you still don't have access to a legal version of said content?
In principle yes.
Could be that the data were originally encrypted with an incorrect IV based on the wrong sector numbers. In that case it would be slightly difficult to decrypt correctly, but not impossible. But then again, if the container was in the exact same location on the disk as when it was created, then it should be possible to read it with the version which had originally created it.
Hardware failing will be a problem whether your data is encrypted or not. The solution for this is a good backup strategy. The backup will help you in several cases: hardware fault, theft, forgotten password (assuming the backup is unencrypted but kept in a safe location).
The main bottleneck on my laptop is harddisk I/O. Encrypting everything would require some amount of CPU time, but since in most cases the CPU is much faster than my needs, and the harddisk is slow, the encryption would not be any problem. The CPU would get more work to do, but it will have plenty of time to do so while waiting for the harddisk. Overall I wouldn't expect to see any slowdown for my everyday use. I don't want to spend lots of time benchmarking it though, I don't care if the meassurable slowdown is 1% or 10%
Possible. But the biggest energy consume in my laptop is the DVD drive.
Your instinct is not all bad
You really should encrypt
In fact swap was the first thing I decided to encrypt on my laptop. Encrypting swap is simpler and less intrusive than everything else. Thus there is really not much reason not to encrypt swap. No need for complicated key management, just generate a new random key on every boot.
One reason for this is, that the key can be choosen at random, which means that even if two disks are encrypted under the same password, they will use different keys. The password will only be in memory for a short time while decrypting the key, once the key is decrypted the password is wiped from memory. Thus if somebody grab a copy of your memory through a firewire port, they may be able to decrypt the harddisk on this laptop, but they will not be able to decrypt the other one they stole while it was turned off, eventhough it was using the same password.
Also you may be better protected against some combinations of brute force and slight weaknesses in the encryption. Some attacks simply work better, if the adversary have access to a significant amount of ciphertext. There will be a significant amount of ciphertext encrypted under the key, and maybe the adversary even know some of the cleartext. But that key will be entirely random. Only a small amount of data is encrypted under the password (namely the key), and the adversary will not be able to make a good guess about the cleartext, as it is entirely random. Finally the encryption used to encrypt the key under the password does not need to make any shortcuts, and could thus be much more secure. It does not need high performance, spending one second decrypting the key at bootup is perfectly acceptable, spending one second decrypting a sector would be completely unacceptable.
I think it would be those doing CPU intensive tasks rather than I/O intensive tasks, that would notice the most slowdown to storage encryption. But of course all of these statements only applies as long as the encryption use a 1:1 mapping between physical and logical sectors. But almost every storage encryption does have such a 1:1 mapping, with GBDE being the only exception I know of. With some more complicated schemes, the fragmentation causing extra seeks could actually cause the encryption to require extra CPU and I/O resources. The 1:1 mapping does not have such additional cost.
Deciding, that you will not pay the performance cost in more complicated storage encryption schemes and going with a 1:1 mapping is a valid decission. Of course it should be a decission every company (or user) make themselves, however it seems in most case the designer of the storage encryption has made the decission for us. However the best schemes with a 1:1 mapping are so secure, that the additional security you could get is less important that all the security you already got from using encryption in the first place.
However I do have at least one good reason for encryption not being enabled by default in most systems. And that is the fact, that few systems have a really secure implementation of password change. In fact I don't know any storage encryption with a secure password change. In most cases the password change just reencrypts the same key under a new password, thus knowing the default password and the key which was originally on the disk will enable you to decrypt data even without knowing the new password.
That means the safe way to use storage encryption is to choose a good password, and use that password when enabling storage encryption. You should never change the password. If you have any suspect that somebody got the password or parts of the encrypted version of your data, the safe approach is to create a new encrypted container with a new password and copy all data from the old one to the new one. Finally you destroy the old encryption by overwriting it once or twice. If you encrypted the full disk, that would mean you'd have to copy the data to another media and back again.
For temporary data such as swap I'd recommend generating a random key at startup, and don't use any password at all. It does require a hardware random number generator to be really secure, as during bootup you wouldn't have had enough time to collect enough entropy. And for swap you don't have to worry about the risk of losing data on a reboot. If carefully implemented in the swapping code itself, encryption of swap space can be made very secure and completely transparent to the user. I think this is something that should be in every file system.
The only actual storage encryption mentioned in this comment is GBDE. That does not mean I recommend it. In fact there is a known weakness in GBDE, which would allow an adversary to break the encryption faster than brute force. Besides that there is a minor risk of losing data because of partial writes.
The main reason Reiser4 didn't go into the kernel as easy as this was, that Reiser wanted to make changes to the VFS layer to support his new file system. So it was not just about adding a new file system, but changing how the kernel handles file system, something that could bite other users who didn't even include Reiser4 in their build.
Once GPLv3 is officially finished, I am going to read it and decide if I think FSF kept its word and made the new license in the same spirit as the old one. And once I have decided, I am going to release a statement on my homepage saying either, that anything I ever released under GPLv2 can be used under GPLv3 as well, or I will (highly unlikely) state that I don't consider GPLv3 to be a successor to GPLv2, and code I have released under GPLv2 cannot be used under the terms of GPLv3.
At first I'll probably allow new code I write to be used under GPLv2 and GPLv3 until I decide which one I like better (which will also depend on what other people do).
The correct way to make a patch is: take the source code, fix the bug, compile it, and ship as many of the executable files as necesarry. But does this third party have the source code? If they do, they probably have signed an agreement forbiding them to use it in this way. In some countries the law gives you an unwaivable right to fix bugs in software, but I'm not sure you would be allowed to share the fix with everybody in this way.
And that might very well be the L2 cache.
Now that would probably allow for better performance than the typical hieracical structure otherwise used. Of course it is going to be more complicated. If you want a hypercube structured cache, then coherency is going to be quite tricky. Even the choerency in the hieracical caches is nontrivial.
Of course you could also aim for some message passing rather than using cache for sharing data between cores. But message passing would require more changes in not only the hardware, but also the software you run on the system. But no doubt an efficient message passing in a hypercube is easier to design than a hypercube-cache.
Efficiency is not only about wasting less power, it's about generating less heat!Which is of course exactly the same. In the end all the energy you put into a computer turns into heat. The energy wasted in the power supply turns into heat in the power supply, and all the heating of the power supply is energy wasted rather than used to supply the computer.