Something like Xen or VMWare achieves this virtualization by simulating separate processors, memory, and I/O space hardware.
Erm, no. VMWare does this, but Xen doesn't.
The whole point of Xen was to get rid of the overhead involved in simulating a real processor. Instead, the Linux kernel was ported to Xen, almost as if it were a new chip architecture. Something like VMWare has to check for the kernel trying to manipulate I/O or do paging, and translate those instructions into what VMWare wants them to do. Since Linux is open-source, there is an alternative.
When you are running a Xen kernel, all of the I/O calls replaced in the source code with Xen "hypercalls" which just send a message to the Xen "hypervisor" do check permissions and actually perform the action
Windows didn't offer a journaling ANYTHING up until their latest greatest (does that even offer journals???).
Actually, the NTFS filesystem, which has been around since NT 4.0 (I think), has journals along with a whole bucketload of other features that the rest of the system is barely beginning to use. However, it has this one huge screw-up that makes Reiser, or ext3, or basically anything else better: Defragmenting. No recent Linux/Unix filesystem that I know of requires you to regularly take your machine down for hours to fix the filesystem.
One other important thing about XFS though, it's really bad in cases of power failure. Running ext3 or Reiser, a machine can almost definetly survive a power failure, but if your system crashes with XFS there's a good chance you'll be left with an unmountable disk.
AES/DES/{any other block cipher} break data up into blocks of some fixed size, 128-bits for AES and 64 bits for DES/3DES. Read your sibling poster, he knew more
3Des uses 128-bit, really 112-bit. It's named 3DES because it does 3 DES encryptions with two separate keys (actually encrypt1-decrypt2-encrypt1). Doing it the obvious (enc1,enc2) way is insecure and can be broken in 2^56 steps (one keysearch) if you have a really big amount of memory, so it does EDE. The D part is there so that you can set E1 equal to E2 and use the same subroutines for 3DES and DES.
256-bit anything cannot be brute forced. Brute force requires that you iterate through every possible key. Now, according to thermodynamics, it takes kT energy to set or clear a bit, where k is Boltzmann's constant and T is the ambient temperature of the system. The coldest you can run it at is 2.3Kelvin (the ambient temperature of the universe). Any colder, and you need more energy to run a heat sink. So, merely to iterate a 256-bit counter through all it's values (never mind actually using an encryption algorithm) requires (2.3)x(2^256)x(k), which is a lot more energy than could be gained by blowing up the Sun in a nuclear reactor and converting it all to energy. So, no cracking of 256-bit keys.
The Honeynet Project did a study. They left an unpatched linux box connected to the internet (It was Red Hat 7.2) and waited until it was rooted. The Red Hat box survived for about three months. Then they did the same experiment with a Windows XP box.
No, I downloaded kernel 2.6.10 from AtRPMS and it installed fine. BTW I got my apt from the DagApt repo, which might be a different version to the Fedora Legacy project.
Does Fedora Core 4 still use yum or will it move to apt4rpm? I don't mean to flame the yummers, but in my experience, apt4rpm is far better. And, in terms of GUIs, Synaptic works far better than gyum or yumex. Also, does it have NTFS support out of the box? That seemed to be the biggest complaint about FC3, that anyone dual-booting had to download the kernel module, realise you had downloaded the wrong module, check kernel version, download the right module, and finally modprobe it.
Interestingly enough, I got MS Visual C++.NET recently and read the illegible EULA when waiting for it to install. Apparently, I am forbidden from disclosing the results of any benchmark of the.NET portion of the software to a third party. I don't know about unconstitutional, but it strikes me as very anticompetitive.
It is unfair to go until the first moment of downtime. Who knows, one server might last a month longer than the other before the first bit of downtime, but could still have more total downtime. It would be fairer to count the total amount of downtime for the one-year period. Especially if an important patch is released for one OS which requires a reboot.
That still doesm't protect your data. You will now know for sure that someone has screwed up your data, but nothing will actually protect it when you have physical access to the machine on which it is stored.
Hacking with physical access is not hacking. If you can get close enough to pull the plug out of the wall and stick in some live cd (e.g. knoppix) then you can do whatever you want, no matter what OS it is. If the OS isn't running, it can't do jack to protect your data
This should be done by the programmers. Easiest ways: Salting and Stretching.
Stretching means doing hashing the password repeatedly. Hashing is fairly expensive, so the complete operation should take about 1-1.5 seconds of CPU time. This is fine for a user logging in, but will stop anyone trying to do a dictionary attack with 2^30 different passwords.
Salting is having a, say, 256-bit value stored which is appended to your password when you try to login. The salt is not kept secret, but everyone must have a different one. This means that a dictionary attack will collapse when all the passwords have to be re-hashed in order to test them against a different users hash.
Because people can then afford to use worse passwords, the number of Post-Its will decrease and security will increase.
Slashdot Mirror
Erm, no. VMWare does this, but Xen doesn't.
The whole point of Xen was to get rid of the overhead involved in simulating a real processor. Instead, the Linux kernel was ported to Xen, almost as if it were a new chip architecture. Something like VMWare has to check for the kernel trying to manipulate I/O or do paging, and translate those instructions into what VMWare wants them to do. Since Linux is open-source, there is an alternative.
When you are running a Xen kernel, all of the I/O calls replaced in the source code with Xen "hypercalls" which just send a message to the Xen "hypervisor" do check permissions and actually perform the action
Windows didn't offer a journaling ANYTHING up until their latest greatest (does that even offer journals???).
Actually, the NTFS filesystem, which has been around since NT 4.0 (I think), has journals along with a whole bucketload of other features that the rest of the system is barely beginning to use. However, it has this one huge screw-up that makes Reiser, or ext3, or basically anything else better: Defragmenting. No recent Linux/Unix filesystem that I know of requires you to regularly take your machine down for hours to fix the filesystem.
One other important thing about XFS though, it's really bad in cases of power failure. Running ext3 or Reiser, a machine can almost definetly survive a power failure, but if your system crashes with XFS there's a good chance you'll be left with an unmountable disk.
If you brute force one block, you have acquired the key. That is what it means to "brute force". You then decrypt the rest of the ciphertext normally.
I have read Practical Cryptography, and Neils Ferguson co-wrote it with Schneier.
AES/DES/{any other block cipher} break data up into blocks of some fixed size, 128-bits for AES and 64 bits for DES/3DES. Read your sibling poster, he knew more
Des uses 64-bit, really 56-bit. Correct
3Des uses 128-bit, really 112-bit. It's named 3DES because it does 3 DES encryptions with two separate keys (actually encrypt1-decrypt2-encrypt1). Doing it the obvious (enc1,enc2) way is insecure and can be broken in 2^56 steps (one keysearch) if you have a really big amount of memory, so it does EDE. The D part is there so that you can set E1 equal to E2 and use the same subroutines for 3DES and DES.
256-bit anything cannot be brute forced. Brute force requires that you iterate through every possible key. Now, according to thermodynamics, it takes kT energy to set or clear a bit, where k is Boltzmann's constant and T is the ambient temperature of the system. The coldest you can run it at is 2.3Kelvin (the ambient temperature of the universe). Any colder, and you need more energy to run a heat sink. So, merely to iterate a 256-bit counter through all it's values (never mind actually using an encryption algorithm) requires (2.3)x(2^256)x(k), which is a lot more energy than could be gained by blowing up the Sun in a nuclear reactor and converting it all to energy. So, no cracking of 256-bit keys.
Crappy passwords are another thing, though
Nuclear launch initiated. (...) (Greenpeace finds out) (...) Are you sure you want to cancel the launch? Ok/Cancel
fp
It lasted about four seconds.
What a lot to type! Your fingers must be tired. In future, you can just use the short version of that phrase: SCO
No, I downloaded kernel 2.6.10 from AtRPMS and it installed fine. BTW I got my apt from the DagApt repo, which might be a different version to the Fedora Legacy project.
Does Fedora Core 4 still use yum or will it move to apt4rpm? I don't mean to flame the yummers, but in my experience, apt4rpm is far better. And, in terms of GUIs, Synaptic works far better than gyum or yumex. Also, does it have NTFS support out of the box? That seemed to be the biggest complaint about FC3, that anyone dual-booting had to download the kernel module, realise you had downloaded the wrong module, check kernel version, download the right module, and finally modprobe it.
I haven't heard that since adequacy.org shut down
SourceForge is open to the public, and kicks ass. What has this to offer that sf doesn't?
Interestingly enough, I got MS Visual C++.NET recently and read the illegible EULA when waiting for it to install. Apparently, I am forbidden from disclosing the results of any benchmark of the .NET portion of the software to a third party. I don't know about unconstitutional, but it strikes me as very anticompetitive.
It is unfair to go until the first moment of downtime. Who knows, one server might last a month longer than the other before the first bit of downtime, but could still have more total downtime. It would be fairer to count the total amount of downtime for the one-year period. Especially if an important patch is released for one OS which requires a reboot.
That still doesm't protect your data. You will now know for sure that someone has screwed up your data, but nothing will actually protect it when you have physical access to the machine on which it is stored.
Fair point, but encrypting doesn't protect your data. It stops others from reading it, but not from randomly messing it up
Hacking with physical access is not hacking. If you can get close enough to pull the plug out of the wall and stick in some live cd (e.g. knoppix) then you can do whatever you want, no matter what OS it is. If the OS isn't running, it can't do jack to protect your data
This should be done by the programmers. Easiest ways: Salting and Stretching.
Stretching means doing hashing the password repeatedly. Hashing is fairly expensive, so the complete operation should take about 1-1.5 seconds of CPU time. This is fine for a user logging in, but will stop anyone trying to do a dictionary attack with 2^30 different passwords.
Salting is having a, say, 256-bit value stored which is appended to your password when you try to login. The salt is not kept secret, but everyone must have a different one. This means that a dictionary attack will collapse when all the passwords have to be re-hashed in order to test them against a different users hash.
Because people can then afford to use worse passwords, the number of Post-Its will decrease and security will increase.