It's a GOOD thing. Outgoing connection blocking can easily be bypassed by worms or malware, it adds complexity to the firewall
I agree. Complex firewalls have been responsible for lots of security holes. I know of one case, where such a security hole was used by a worm. Other firewall software have had equally serious holes, that could have been abused by a worm.
You can secure a Windows machine without any firewall at all. Just shut down all the services listening for connections from the internet, which should have been the default anyway. If a machine have been secured that way, in most cases installing a third party firewall would actually make the computer less secure.
Microsoft could have removen the need for a firewall by changing the default configuration. Instead Microsoft have chosen to include a firewall, and now turn it on by default. And apparently it is so simple, that there is a chance, the firewall doesn't create any security holes on its own.
It is very uncommon in an IPO to get even half of the bidded shares.
But it is also very uncommon for an IPO to be done by a dutch auction. The way a dutch auction is supposed to work, you either get all you bidded for or nothing. So in the end this wasn't really a dutch auction anyway. And a lot of people got shares cheaper than they would have in a dutch auction. I still don't understand why somebody deliberately sell stocks underpriced. I mean you make more money by selling them at the right price. And as long as you don't sell stocks overpriced, I really don't think making money by selling stocks is evil.
why couldn't you use the original code and generate collisions?
I can see two different ways to interpret your question, so I'll try to answer both. Why didn't the authors use an existing MD5 implementation? Good question. I guess most MD5 implementations out there are optimized for performance rather than readability. And probably they would have to modify the code quite a bit to efficiently find a collision. This is not a brute force attack, so they definitely must have relied on some of the structure of MD5 in their code. Publishing the result without verifying the collision against existing MD5 implementations is plain sloppiness. Why don't somebody take the breaking code and fix the minor bug to produce a real MD5 collision? The answer to that question, they didn't publish the code, they didn't even explain how it worked. They only provided the resulting collision.
why not do both a md5sum and a sha-0 on the same data?
What you suggest is essentially just a 288 bit hash (128+160). The question is, would you rather trust this 288 bit hash created from two weak hash functions, or one of the 256 bit hash functions designed to replace SHA-1 and MD5?
The problem with that article is, that they made a bug in their MD5 implementation. They got the byte ordering of the IV wrong. Which means that the collisions they provide is not for MD5, but rather collisions for a very similar hash function. They say they can produce collisions for an arbitrary IV, and why wouldn't that be true? There is no reason to believe the one IV would be easier or more difficult than the other. But the article doesn't give enough details for others to reproduce. So this article give very strong evidence that MD5 is broken, but no actual proof.
For instance, by patching the appropriate microcode lines, it may be possible to catch an opcode that would normally be illegal, and instead handle it by tricking the TLB into thinking we're in kernel mode when in fact the attacker has only compromised a userspace process.
But you could make some very similar backdoors by only changing the kernel. For instance somebody wrote a patch for Linux, where some illegal combination of parameters for the wait system call would result in the process getting root permissions.
I still wish everybody would dump the backward compatability with the 8086 though. The CPU still has to bootstrap in 16bit real mode FFS!!!!
I agree. But at least AMD did something right when designing the AMD64 architecture. Virtual 86 mode and segmentation was eliminated from the 64 bit mode, but they still exist in 32 bit mode of course. Completely eliminating 8086 compatibility was not really so much of an option. Backward compatibility is part of the reason for the AMD64 success. But it would have been nice, if they had at least offered a way to boot the CPU in 64 bit mode. As it is now, the CPU boots in 16 bit real mode, then you switch to 32 bit protected mode, and only after that have been done you can switch the CPU into 64 bit mode.
I have a Compaq Presario 2166EA laptop, and I have a self assembled stationary computer with four harddisks and fans for both CPU and PSU. Even when the fan in the laptop is spining on the lowest speed, it makes more noise than the stationary computer. And on work I have a thinkpad where the harddisk is even more noisy than my Presario.
Sure the article is a joke, but actually there is some serious stuff in it as well. If you made it all the way to page 6 and read the section about ExecShield and PaX, you would notice, that this section is not a joke. It actually explains about some real security meassures that exists in Linux. Of course there are large parts of the article, where I'm not sure if it is a joke or just talking about some stuff I don't know about.
I don't want antivirus on my phone. Because antivirus is an attempt to cure the symptoms rather than the disease. The solution to the virus problem is first of all to avoid dangerous features. That is number one reason why so many viruses target outlook. The rest of the email clients don't have all the dangerous features. The same should hold for phones. Some code I download from an arbitrary location should not have uncontrolled access to all of the phones features. That means it shouldn't be able to send an SMS without the users acknowledge, and it should not be able to make phone calls, neither should it be able to prevent the user from making phone calls.
But security is more than just that. It also means they have to carefully review their code so most bugs gets squashed before the software is released. And a layered design would be a good idea. At one of the lower layers you put basic functionality that controls making and receiving calls and likewise messages. This layer must also ensure, that you can always get access to those features. So a program I download just may not be able to take complete control over the user interface. This shouldn't prevent anybody from for example creating a phonebook with some fancy features, that you can download from the net. But it may never be able to actually perform the calls, it can provide the numbers, and the user will actually see the number and have to press the dial button himself to make the call.
Parent's "Doom Tweak Guide" link is nasty-fake. Don't click.
Just a short moment after I read your comment, I noticed that 264228 changed his signature and replaced the link with a different one. (Yes changing your signature also applies to older comments).
Now I read the full raw drive once a week, so bad blocks are caught before another drive goes bad.
That is really a good idea. For some time I have done daily checksums of all my files to catch any file that changes without the timestamp being changed. That should protect me against some cases of silent data corruption, and I guess also to some extent against the problem you describe. But I think a daily run is overkill, so I will switch to a weekly run and add some reading similar to your suggestion.
Are you suggesting raid-5 would be any safer than mirroring? It is not. In fact if you have only two drives there will be absolutely no difference between mirroring, raid-1, raid-4, and raid-5. (If I'm not mistaken raid-1 and mirroring are by definition the same). It is only on systems with more than two disks there will be a difference. But the problem about a drive returning wrong data exists for all of them. A drive is expected to either return the data that was written, or return no data at all.
Of course there are ways to improve on the situation. You could read from all disks to detect bad data being returned, but it would give you a performance penalty. And what do you do when you have data from all disks, and don't know which one is wrong? You could also use cryptographic approaches like hashes and/or signatures. In that case you might avoid reading all disks, and in case one returned wrong data you would know which one. But you would still need CPU time to compute hashes, you would need extra storage space for the integrity, and logical writes would become more expensive as they need to touch more physical sectors.
But in the case of raid-4 and raid-5 it is even worse. Any logical write must write to at least two physical disks, between the writes the data are in an inconsistent state. If you lose a disk at this point recovery could produce incorrect data for a sector that was not even modified. With raid-1 at least only the sector actually being written is at danger, and the working disk will contain either the old or the new data, so no corruption happens.
In spite of these problems the chance of damage to a raid-5 array is considered smaller than a single disk failing. I think some clever journaling can avoid the problems of the array being taken down just at the wrong moment. If you are very clever you might even be able to integrate this with the filesystem journaling to avoid an additional performance penalty.
But if you worry about silent data corruption, you should take it further. I think undetected errors are much more common in RAM than on disk. How do you protect against errors in RAM, cache, or CPU? I believe you have to consider secure multiparty computations. but how many people want to run a cluster of maybe 10 computers to protect against silent corruptions?
The state that's being used has to be told to the recieving
party.
No, not the entire state, only the basis. If you know the basis you can perform a meassurement that will tell you the rest of information about the state. But what is important to notice here is, that the sender tell what basis was used after the intended recipient have acknowledged that the bits were received and meassured. If the adversary passed the right qubit to the receiver, he doesn't have it anymore at this point, so it cannot be meassured. If it wasn't passed on the the receiver, the receiver must have been meassuring on a wrong qubit, which will be detected.
Or simply observe only a few of the particles.
That is one of the reasons privacy amplification is applied to the common bitstring as the very last step to produce the common key. An adversary might get a few qubits right. But either the adversary meassure too few bits to learn anything about the outcome after privacy amplification, or the adversary meassure too many bits to do so undetected.
If you can't create a quantum state then how is data even encrypted?
You can create a quantum state, but you cannot create a copy of an existing quantum state. You can create a qubit and decide which state you want it to be in. For quantum cryptograhpy only 4 states are used. But an adversary cannot find out which of the 4 states you used. The adversary can chose a state and create a qubit in that state, but he cannot know if it was the same state as the qubit he got from the channel.
Encryption is a litle more than just using a cipher. You need some mode of operation. ECB mode where you just split your message into 64 bit blocks and apply the cipher to each is weak. The problem is, that an attacker can easilly see which blocks contains the same cleartext, because they will all result in the same ciphertext. I once saw this illustrated by encrypting some black and white image where each 8x8 pixels where encrypted using DES in ECB mode. In the encrypted version you could still faintly see the outline of the original picture.
We have a definition of semantic security, that handles this and other problems. It is impossible to achieve semantic security with a deterministic encryption, you need a probabilistic encryption, where a litle randomness is added to the message. The encrypted message will then be larger than the original, and if the same cleartext is encrypted twice, you will get different ciphertexts. Typically you would use modes like CBC or CFB where the encrypted version is just one block longer than the original. So a 1000 bytes cleartext would be 1008 bytes encrypted. What happens in CBC mode is that each cleartext block is XORed with a random bitstring before being encrypted. Actually you only chose a random bitstring for the first block, for the remaining blocks you use the encrypted version of the previous block, but that is actually random because the cleartext was XORed with a random bitstring before being encrypted.
So in CBC mode you will not be encrypting your cleartext, but rather a sequence of random blocks. As long as you don't encrypt the same block more than once, the adversary cannot learn anything about your message, without actually performing an attack against the cipher. But if you keep using the same key for a long time, eventually two random blocks will be the same, and the adversary will be able to see this, and can use it to compute some information about the cleartext.
I wonder.
That is because you don't understand why a one time pad is secure. As soon as you understand the proof, you don't have to worry no more. A one time pad is unconditionally secure. Formally that means an adversary learns no information about the message by seeing the encryption.
Before seeing the encryption the adversary could make some guess about the contents of the message. Not all messages are equially likely, we assume the adversary know some probability distribution over possible messages. Now what happens is that a message and a key are chosen, the key is chosen uniformly random over the possible keys, and the message is encrypted. Now we have a probability distribution over pairs of message and keys. Of course as soon as we give the adversary the encrypted message, a lot of these pairs become impossible, as they don't result in that encrypted message. Now the adversary can compute a probability distribution of messages given this encrypted message (formally defined in probability theory). And unconditional security means this probability distribution is the same as the adversary started with. Which means after seeing the encryption the adversary cannot make a guess any better than he could have done without seeing the encrypted message.
If the message is some text (as opposed to binary information), then a sufficiently powerful computer (whatever that means) can try out all possible combinations of bits in all possible positions given the length of the message to try to extract the information. Combine this with a dictionary and grammar rules, and eventually the message pops out.
I knew somebody was going to say that. It happens every time it is stated that OTP is unconditionally secure. Yes, you can try every possible key, and every possible message of that length will eventually come out. You could have done exactly the same without seeing the encryption. Just write down all possible plain texts of a given length, and the right one will be somewhere. But you still don't know which one is the right one. Given an encryption and a plaintext, there is exactly one key that will decrypt the message to that plaintext.
a measurement disturbs the state of the system that is then detectable by the true receiver
That is exactly where the integrity is required. Without the integrity between the two communicating parties, quantum cryptography is obviously vulnurable. A man in the middle could simply perform two completely independent instances of the quantum protocol to exchange the key. Neither party would realize, that they were talking with an adversary rather than the intended peer. In the end they would have two different keys, but the adversary knows both keys, and can decrypt and reencrypt the message as it passes by.
First of all it should be explained why they came up with 3-DES instead of just 2-DES. The reason is, that 2-DES would be vulnurable to a meet in the middle attack. If you knew just one plaintext/ciphertext pair you could efficiently compute a small set of possible keys. It would require a lot of disk space, but in the end you would be down to approximately 2^48 keys, and it would require only 2^57 cipher block operations. Another plaintext/ciphertext pair can easilly be tested against the remaining 2^48 keys to find the right one.
In other words 2-DES is not significantly more secure than DES, but 3-DES makes the meet in the middle attack more difficult. You can no longer meet exactly in the middle, but you could meet with 1 cipher on one side and 2 ciphers on the other side. That way you have to brute force the 2 ciphers and that way 3-DES presumably give you the security of a 112 bit key. This is also why you normally only use two different keys for 3-DES. The third key would add no extra security.
But 3-DES have inherited one of the weaknesses of DES. The block size is still only 64 bits. That makes you vulnurable to birthday attacks. For this reason I always advice against using the same 3-DES key for more than 512KB of data. With a 128 bit block like AES uses, a key can be safe for use for longer time, I would say 64GB should be secure.
Then we can use it forever.
You mean a one time pad?
You cannot use a one time pad forever. The name should be a pretty good hint about that. Unfortunately reusing a one time pad is suggested again and again by people not fully understanding what it is all about. In many cases a one time pad is unrealistic because you have to exchange new keys over a secure channel. And usually you want to use the one time pad because you don't have a secure channel. But actually some secure channels exists that can be used to exchange the key, but cannot be used for the data transfer. One such example is seen in quantum cryptography.
However though a one time pad is unconditionally secure, it only guarantees secrecy. Integrity is an interely different matter. Luckily there also exist unconditionally secure MACs for that, and they are a lot more realistic than a one time pad, because the key is smaller and most of the key can be reused. This is very important because without integrity over a clasical channel, even quantum cryptography would have been vulnurable to a man in the midle attack.
But quantum cryptography is not the only way to exchange a one time pad. Other unrealistic ways to exchange a one time pad is using either noisy channels or assumptions about memory bounded adversaries. I call them unrealistic because they are both based on somewhat unrealistic assumptions and require extreme amounts of data to be transfered to create a small one time pad. The most realistic way to exchange a one time pad probably still is to do it in advance. In some cases the exchange in advance makes a lot of sense. Think for example wireless equipment. You'd consider a wire to be secure, but it is inconvenient. But you still have to connect a wire occationally to recharge your battery, at the same time a one time pad could be tranfered over a faster and more secure wired link.
A good filesystem should be capable of handling all potential applications
I absolutely agree. And I actually think the current interface to filesystems is good. I don't want any major changes. Because major changes would most likely lead to all new kinds of metadata that no applications know how to deal with. And whenever your files get handled by a program without this knowledge, you are losing metadata which again means new applications that makes use of the metadata get screwed. So most of this inovation will just give us lots of compatibility problems. If anybody really want to inovate, and produce something good, then they should implement a clever implementation of the existing interface, that works well for different cases, that is both small and large files, deep trees, many files per directory, few files per directory. AFAIK reiserfs and XFS are doing quite well.
(for example, FAT32 has found its way into grandmother's desktop and production web servers).
FAT is a horrible example, because it didn't become this widely used because of quality. Minix' FS is simpler than FAT, it have more features, and it is a lot faster for random access to large files. FAT-16 had problems with small files, because on large partitions you were forced to use large clusters, which means lots of disk space wasted (I have seen 30% waste in real life cases). FAT-32 did improve on the problem with small files, because now you could have much larger partitions with 4KB clusters. But since FAT-32 still use linked lists to find data sectors (like previous FAT versions), FAT-32 is worse at handling large files than any previous filesystem. For example seeking to the end of a 625MB file in 4KB clusters requires following 160000 pointers. Most other filesystems use a tree structure, which means you can typically index the entire file with at most 3 or 4 levels of indirection, which means you need to follow 4 or 5 pointers. Would you try to cache the FAT table to speed up the access? Good luck, you would need 4 bytes of FAT table per 4KB cluster on the disk, so for a 160GB disk you would need to use 160MB of your RAM just to cache the FAT. And this doesn't get rid of the CPU time required to traverse the linked list.
Guess according to yor standards, only open-source is acceptable from a security standpoint.
You certainly can have some very reasonable security standards, that can only be met by open source software. You can also come up with security standards that not only require open source software, but even requires each user to review and compile the source on their own. That would be a bit too unrealistic. Somebody should come up with ways to verify that available binaries are really build from sources they claim to be, and ways to know who have reviewed which parts of the code. If all relevant parts of the source have been reviewed by people you trust, and correct building also has been verified, you don't want to do that on your own.
Slashdot Mirror
I did a WebCrawler search and can't find anything about it.
It is easy. Just go to http://webcrawler.com/ and then search for the best search engine. And take a closer look on the first search result.
It's a GOOD thing. Outgoing connection blocking can easily be bypassed by worms or malware, it adds complexity to the firewall
I agree. Complex firewalls have been responsible for lots of security holes. I know of one case, where such a security hole was used by a worm. Other firewall software have had equally serious holes, that could have been abused by a worm.
You can secure a Windows machine without any firewall at all. Just shut down all the services listening for connections from the internet, which should have been the default anyway. If a machine have been secured that way, in most cases installing a third party firewall would actually make the computer less secure.
Microsoft could have removen the need for a firewall by changing the default configuration. Instead Microsoft have chosen to include a firewall, and now turn it on by default. And apparently it is so simple, that there is a chance, the firewall doesn't create any security holes on its own.
It is very uncommon in an IPO to get even half of the bidded shares.
But it is also very uncommon for an IPO to be done by a dutch auction. The way a dutch auction is supposed to work, you either get all you bidded for or nothing. So in the end this wasn't really a dutch auction anyway. And a lot of people got shares cheaper than they would have in a dutch auction. I still don't understand why somebody deliberately sell stocks underpriced. I mean you make more money by selling them at the right price. And as long as you don't sell stocks overpriced, I really don't think making money by selling stocks is evil.
This will then hurt those holding class B stock as well as class A.
If you don't have any plans to sell, how could a falling stock price hurt you?
why couldn't you use the original code and generate collisions?
I can see two different ways to interpret your question, so I'll try to answer both. Why didn't the authors use an existing MD5 implementation? Good question. I guess most MD5 implementations out there are optimized for performance rather than readability. And probably they would have to modify the code quite a bit to efficiently find a collision. This is not a brute force attack, so they definitely must have relied on some of the structure of MD5 in their code. Publishing the result without verifying the collision against existing MD5 implementations is plain sloppiness. Why don't somebody take the breaking code and fix the minor bug to produce a real MD5 collision? The answer to that question, they didn't publish the code, they didn't even explain how it worked. They only provided the resulting collision.
why not do both a md5sum and a sha-0 on the same data?
What you suggest is essentially just a 288 bit hash (128+160). The question is, would you rather trust this 288 bit hash created from two weak hash functions, or one of the 256 bit hash functions designed to replace SHA-1 and MD5?
Pretty big rumor!
The problem with that article is, that they made a bug in their MD5 implementation. They got the byte ordering of the IV wrong. Which means that the collisions they provide is not for MD5, but rather collisions for a very similar hash function. They say they can produce collisions for an arbitrary IV, and why wouldn't that be true? There is no reason to believe the one IV would be easier or more difficult than the other. But the article doesn't give enough details for others to reproduce. So this article give very strong evidence that MD5 is broken, but no actual proof.
For instance, by patching the appropriate microcode lines, it may be possible to catch an opcode that would normally be illegal, and instead handle it by tricking the TLB into thinking we're in kernel mode when in fact the attacker has only compromised a userspace process.
But you could make some very similar backdoors by only changing the kernel. For instance somebody wrote a patch for Linux, where some illegal combination of parameters for the wait system call would result in the process getting root permissions.
I still wish everybody would dump the backward compatability with the 8086 though. The CPU still has to bootstrap in 16bit real mode FFS!!!!
I agree. But at least AMD did something right when designing the AMD64 architecture. Virtual 86 mode and segmentation was eliminated from the 64 bit mode, but they still exist in 32 bit mode of course. Completely eliminating 8086 compatibility was not really so much of an option. Backward compatibility is part of the reason for the AMD64 success. But it would have been nice, if they had at least offered a way to boot the CPU in 64 bit mode. As it is now, the CPU boots in 16 bit real mode, then you switch to 32 bit protected mode, and only after that have been done you can switch the CPU into 64 bit mode.
Too bad I have to leave Zürich one week before.
I have a Compaq Presario 2166EA laptop, and I have a self assembled stationary computer with four harddisks and fans for both CPU and PSU. Even when the fan in the laptop is spining on the lowest speed, it makes more noise than the stationary computer. And on work I have a thinkpad where the harddisk is even more noisy than my Presario.
Sure the article is a joke, but actually there is some serious stuff in it as well. If you made it all the way to page 6 and read the section about ExecShield and PaX, you would notice, that this section is not a joke. It actually explains about some real security meassures that exists in Linux. Of course there are large parts of the article, where I'm not sure if it is a joke or just talking about some stuff I don't know about.
I don't want antivirus on my phone. Because antivirus is an attempt to cure the symptoms rather than the disease. The solution to the virus problem is first of all to avoid dangerous features. That is number one reason why so many viruses target outlook. The rest of the email clients don't have all the dangerous features. The same should hold for phones. Some code I download from an arbitrary location should not have uncontrolled access to all of the phones features. That means it shouldn't be able to send an SMS without the users acknowledge, and it should not be able to make phone calls, neither should it be able to prevent the user from making phone calls.
But security is more than just that. It also means they have to carefully review their code so most bugs gets squashed before the software is released. And a layered design would be a good idea. At one of the lower layers you put basic functionality that controls making and receiving calls and likewise messages. This layer must also ensure, that you can always get access to those features. So a program I download just may not be able to take complete control over the user interface. This shouldn't prevent anybody from for example creating a phonebook with some fancy features, that you can download from the net. But it may never be able to actually perform the calls, it can provide the numbers, and the user will actually see the number and have to press the dial button himself to make the call.
Parent's "Doom Tweak Guide" link is nasty-fake. Don't click.
Just a short moment after I read your comment, I noticed that 264228 changed his signature and replaced the link with a different one. (Yes changing your signature also applies to older comments).
Now I read the full raw drive once a week, so bad blocks are caught before another drive goes bad.
That is really a good idea. For some time I have done daily checksums of all my files to catch any file that changes without the timestamp being changed. That should protect me against some cases of silent data corruption, and I guess also to some extent against the problem you describe. But I think a daily run is overkill, so I will switch to a weekly run and add some reading similar to your suggestion.
The "safe" setup is Raid-5
Are you suggesting raid-5 would be any safer than mirroring? It is not. In fact if you have only two drives there will be absolutely no difference between mirroring, raid-1, raid-4, and raid-5. (If I'm not mistaken raid-1 and mirroring are by definition the same). It is only on systems with more than two disks there will be a difference. But the problem about a drive returning wrong data exists for all of them. A drive is expected to either return the data that was written, or return no data at all.
Of course there are ways to improve on the situation. You could read from all disks to detect bad data being returned, but it would give you a performance penalty. And what do you do when you have data from all disks, and don't know which one is wrong? You could also use cryptographic approaches like hashes and/or signatures. In that case you might avoid reading all disks, and in case one returned wrong data you would know which one. But you would still need CPU time to compute hashes, you would need extra storage space for the integrity, and logical writes would become more expensive as they need to touch more physical sectors.
But in the case of raid-4 and raid-5 it is even worse. Any logical write must write to at least two physical disks, between the writes the data are in an inconsistent state. If you lose a disk at this point recovery could produce incorrect data for a sector that was not even modified. With raid-1 at least only the sector actually being written is at danger, and the working disk will contain either the old or the new data, so no corruption happens.
In spite of these problems the chance of damage to a raid-5 array is considered smaller than a single disk failing. I think some clever journaling can avoid the problems of the array being taken down just at the wrong moment. If you are very clever you might even be able to integrate this with the filesystem journaling to avoid an additional performance penalty.
But if you worry about silent data corruption, you should take it further. I think undetected errors are much more common in RAM than on disk. How do you protect against errors in RAM, cache, or CPU? I believe you have to consider secure multiparty computations. but how many people want to run a cluster of maybe 10 computers to protect against silent corruptions?
The state that's being used has to be told to the recieving party.
No, not the entire state, only the basis. If you know the basis you can perform a meassurement that will tell you the rest of information about the state. But what is important to notice here is, that the sender tell what basis was used after the intended recipient have acknowledged that the bits were received and meassured. If the adversary passed the right qubit to the receiver, he doesn't have it anymore at this point, so it cannot be meassured. If it wasn't passed on the the receiver, the receiver must have been meassuring on a wrong qubit, which will be detected.
Or simply observe only a few of the particles.
That is one of the reasons privacy amplification is applied to the common bitstring as the very last step to produce the common key. An adversary might get a few qubits right. But either the adversary meassure too few bits to learn anything about the outcome after privacy amplification, or the adversary meassure too many bits to do so undetected.
If you can't create a quantum state then how is data even encrypted?
You can create a quantum state, but you cannot create a copy of an existing quantum state. You can create a qubit and decide which state you want it to be in. For quantum cryptograhpy only 4 states are used. But an adversary cannot find out which of the 4 states you used. The adversary can chose a state and create a qubit in that state, but he cannot know if it was the same state as the qubit he got from the channel.
but you can't get collisions with a cipher...?
Encryption is a litle more than just using a cipher. You need some mode of operation. ECB mode where you just split your message into 64 bit blocks and apply the cipher to each is weak. The problem is, that an attacker can easilly see which blocks contains the same cleartext, because they will all result in the same ciphertext. I once saw this illustrated by encrypting some black and white image where each 8x8 pixels where encrypted using DES in ECB mode. In the encrypted version you could still faintly see the outline of the original picture.
We have a definition of semantic security, that handles this and other problems. It is impossible to achieve semantic security with a deterministic encryption, you need a probabilistic encryption, where a litle randomness is added to the message. The encrypted message will then be larger than the original, and if the same cleartext is encrypted twice, you will get different ciphertexts. Typically you would use modes like CBC or CFB where the encrypted version is just one block longer than the original. So a 1000 bytes cleartext would be 1008 bytes encrypted. What happens in CBC mode is that each cleartext block is XORed with a random bitstring before being encrypted. Actually you only chose a random bitstring for the first block, for the remaining blocks you use the encrypted version of the previous block, but that is actually random because the cleartext was XORed with a random bitstring before being encrypted.
So in CBC mode you will not be encrypting your cleartext, but rather a sequence of random blocks. As long as you don't encrypt the same block more than once, the adversary cannot learn anything about your message, without actually performing an attack against the cipher. But if you keep using the same key for a long time, eventually two random blocks will be the same, and the adversary will be able to see this, and can use it to compute some information about the cleartext.
I wonder.
That is because you don't understand why a one time pad is secure. As soon as you understand the proof, you don't have to worry no more. A one time pad is unconditionally secure. Formally that means an adversary learns no information about the message by seeing the encryption.
Before seeing the encryption the adversary could make some guess about the contents of the message. Not all messages are equially likely, we assume the adversary know some probability distribution over possible messages. Now what happens is that a message and a key are chosen, the key is chosen uniformly random over the possible keys, and the message is encrypted. Now we have a probability distribution over pairs of message and keys. Of course as soon as we give the adversary the encrypted message, a lot of these pairs become impossible, as they don't result in that encrypted message. Now the adversary can compute a probability distribution of messages given this encrypted message (formally defined in probability theory). And unconditional security means this probability distribution is the same as the adversary started with. Which means after seeing the encryption the adversary cannot make a guess any better than he could have done without seeing the encrypted message.
If the message is some text (as opposed to binary information), then a sufficiently powerful computer (whatever that means) can try out all possible combinations of bits in all possible positions given the length of the message to try to extract the information. Combine this with a dictionary and grammar rules, and eventually the message pops out.
I knew somebody was going to say that. It happens every time it is stated that OTP is unconditionally secure. Yes, you can try every possible key, and every possible message of that length will eventually come out. You could have done exactly the same without seeing the encryption. Just write down all possible plain texts of a given length, and the right one will be somewhere. But you still don't know which one is the right one. Given an encryption and a plaintext, there is exactly one key that will decrypt the message to that plaintext.
a measurement disturbs the state of the system that is then detectable by the true receiver
That is exactly where the integrity is required. Without the integrity between the two communicating parties, quantum cryptography is obviously vulnurable. A man in the middle could simply perform two completely independent instances of the quantum protocol to exchange the key. Neither party would realize, that they were talking with an adversary rather than the intended peer. In the end they would have two different keys, but the adversary knows both keys, and can decrypt and reencrypt the message as it passes by.
First of all it should be explained why they came up with 3-DES instead of just 2-DES. The reason is, that 2-DES would be vulnurable to a meet in the middle attack. If you knew just one plaintext/ciphertext pair you could efficiently compute a small set of possible keys. It would require a lot of disk space, but in the end you would be down to approximately 2^48 keys, and it would require only 2^57 cipher block operations. Another plaintext/ciphertext pair can easilly be tested against the remaining 2^48 keys to find the right one.
In other words 2-DES is not significantly more secure than DES, but 3-DES makes the meet in the middle attack more difficult. You can no longer meet exactly in the middle, but you could meet with 1 cipher on one side and 2 ciphers on the other side. That way you have to brute force the 2 ciphers and that way 3-DES presumably give you the security of a 112 bit key. This is also why you normally only use two different keys for 3-DES. The third key would add no extra security.
But 3-DES have inherited one of the weaknesses of DES. The block size is still only 64 bits. That makes you vulnurable to birthday attacks. For this reason I always advice against using the same 3-DES key for more than 512KB of data. With a 128 bit block like AES uses, a key can be safe for use for longer time, I would say 64GB should be secure.
Then we can use it forever.
You mean a one time pad?
You cannot use a one time pad forever. The name should be a pretty good hint about that. Unfortunately reusing a one time pad is suggested again and again by people not fully understanding what it is all about. In many cases a one time pad is unrealistic because you have to exchange new keys over a secure channel. And usually you want to use the one time pad because you don't have a secure channel. But actually some secure channels exists that can be used to exchange the key, but cannot be used for the data transfer. One such example is seen in quantum cryptography.
However though a one time pad is unconditionally secure, it only guarantees secrecy. Integrity is an interely different matter. Luckily there also exist unconditionally secure MACs for that, and they are a lot more realistic than a one time pad, because the key is smaller and most of the key can be reused. This is very important because without integrity over a clasical channel, even quantum cryptography would have been vulnurable to a man in the midle attack.
But quantum cryptography is not the only way to exchange a one time pad. Other unrealistic ways to exchange a one time pad is using either noisy channels or assumptions about memory bounded adversaries. I call them unrealistic because they are both based on somewhat unrealistic assumptions and require extreme amounts of data to be transfered to create a small one time pad. The most realistic way to exchange a one time pad probably still is to do it in advance. In some cases the exchange in advance makes a lot of sense. Think for example wireless equipment. You'd consider a wire to be secure, but it is inconvenient. But you still have to connect a wire occationally to recharge your battery, at the same time a one time pad could be tranfered over a faster and more secure wired link.
A good filesystem should be capable of handling all potential applications
I absolutely agree. And I actually think the current interface to filesystems is good. I don't want any major changes. Because major changes would most likely lead to all new kinds of metadata that no applications know how to deal with. And whenever your files get handled by a program without this knowledge, you are losing metadata which again means new applications that makes use of the metadata get screwed. So most of this inovation will just give us lots of compatibility problems. If anybody really want to inovate, and produce something good, then they should implement a clever implementation of the existing interface, that works well for different cases, that is both small and large files, deep trees, many files per directory, few files per directory. AFAIK reiserfs and XFS are doing quite well.
(for example, FAT32 has found its way into grandmother's desktop and production web servers).
FAT is a horrible example, because it didn't become this widely used because of quality. Minix' FS is simpler than FAT, it have more features, and it is a lot faster for random access to large files. FAT-16 had problems with small files, because on large partitions you were forced to use large clusters, which means lots of disk space wasted (I have seen 30% waste in real life cases). FAT-32 did improve on the problem with small files, because now you could have much larger partitions with 4KB clusters. But since FAT-32 still use linked lists to find data sectors (like previous FAT versions), FAT-32 is worse at handling large files than any previous filesystem. For example seeking to the end of a 625MB file in 4KB clusters requires following 160000 pointers. Most other filesystems use a tree structure, which means you can typically index the entire file with at most 3 or 4 levels of indirection, which means you need to follow 4 or 5 pointers. Would you try to cache the FAT table to speed up the access? Good luck, you would need 4 bytes of FAT table per 4KB cluster on the disk, so for a 160GB disk you would need to use 160MB of your RAM just to cache the FAT. And this doesn't get rid of the CPU time required to traverse the linked list.
Guess according to yor standards, only open-source is acceptable from a security standpoint.
You certainly can have some very reasonable security standards, that can only be met by open source software. You can also come up with security standards that not only require open source software, but even requires each user to review and compile the source on their own. That would be a bit too unrealistic. Somebody should come up with ways to verify that available binaries are really build from sources they claim to be, and ways to know who have reviewed which parts of the code. If all relevant parts of the source have been reviewed by people you trust, and correct building also has been verified, you don't want to do that on your own.