Yeah, I suppose you wouldn't worry about somebody showing up to be beat the hell out of your PO box. But it doesn't give you a better case when you are being sued for fraud (or whatever is the legal term for this). I also suspect the malaysian may think twice before sending the cheque to a PO box, they might actually realize that if the address is a PO box, they are dealing with somebody who has got a clue. Then again, not all scammers are too bright.
So, how about the example of say, an adult taking a 12 year old to Vatican City, having sex with them and filming it, then returning home and distributing the video on the internet. As the age of consent in Vatican City is 12, a crime has not been committed there.
Age of consent doesn't mean that it is legal to produce porn from that age. There are countries where age of consent is 15, but any porn involving people under 18 is illegal. How old do you have to be to legally take part in porn in the Vatican? Is porn even legal there?
The laws as they stand now means that in some countries it is legal for a grown man to have sex with a 16 year old girl, but it is illegal for a grown man watching a video with a 16 year old girl having sex. Getting back to the difference between the different age of consent in different countries, I think that is problematic, and the problem doesn't have anything to do with porn at all. Taking a minor to a country with a lower age of consent to have sex there could happen without any porn being produced. This raises the question about whether a country should try to make its laws apply to what happens in other countries. While most people in western countries would argue that the law should prevent doing things like that, I think the same people would argue that the laws of for example Asian countries shouldn't apply to those countries citizens when they are in a western country.
And indeed, that point is probably what's behind this move: do we want all children growing up with unrestricted access to any kind of legal-in-some-other-nation porn?
I think it is perfectly fine if parents can limit what their children look at on the internet. But that doesn't mean internet access providers should filter it by default. Finding out what should be filtered and what not, is tricky regardless of where you want to put the filter. The filtering could be implemented in the internet providers equipment or on the customer's own computer. I think it would be ok for the access provider to offer the filtering as a service, I just don't think it should be mandatory, and it definitely shouldn't be enabled by default. Asking each customer if they want it is fine.
They send him a cheque, they know where he lives. For all he knows a group of big Malaysian men could show up at his door. If he kept the money it would also be harder to argue that he was not deliberately taking part in fraud.
I think in some cases it is not because they cannot see through the scam, but rather because they think they are safe. Consider that they receive all the money first, and then they transfer part of it on. It is not like they are paying somebody money before receiving their own share. But then after they have received money (possibly from a victim from internet banking phishing) and transferred part of that money to an account abroad, the original transfer is reverted.
Somebody who is in that position where they thought part of it through but forgot the part about the first transaction being reverted will have to play stupid. They cannot admit that they had some idea what was going on, because then they would admit to have deliberately taken part in the crime. Playing stupid may be unlikely to get your money back, but with a bit of luck it may save them from a sentence.
Not saying this is necessarily saying this is what happened in this case, just saying that these people may not be as stupid as it looks. One saying goes: "Never attribute to malice what can adequately be explained by incompetence", another saying goes: "Any sufficiently advanced incompetence is indistinguishable from malice". But in some cases it may actually be a combination of malice and stupidity, and it can be hard to tell how much of each.
but where there is a demand there are people who are willing to supply.
For that reason I think it would make sense to focus on those who trade child pornography. I think the trading it should be considered an entirely different crime from distribution and possession. Do you think a demand where there is nothing to get in return will also get people to supply it?
I think you've just forgotten how broad they've made the definition of CP.
You have got a point there. I had not forgotten about how broad the definition was there, but when I said there might not have been a lot to begin with, I was thinking about the kind where there would be no doubt whether it was pornographic or not. Some of the moves to make the definition very broad are part of the reason I get the feeling it is about taste rather than about stopping abuse.
If you're hinting that most moves suggest the former, consider the comparative lack of concern for scat porn, beast porn (also illegal I think?), furry porn, and fatty porn.
I don't think that is evidence in either direction. I think most people when asked would say they find child porn to be a lot more distasteful than scat porn. As such either of the two reasons could explain it. Consider that many attempts are made to stop distribution without at the same time attempting to find the source. Also consider that some countries are trying to extend the definition to also cover drawings and prose. And now this where a country want to extend the filtering to cover all porn.
Have you got any evidence to back up that statement? More likely there wasn't tons of it to begin with, and most of the blocked sites are legitimate. Recently there was news about a group that audited the sites in the Danish and Norwegian lists, and of the hundreds of sites they audited only three were found to have illegal content. They managed to get those three sites taken down in a couple of days. They were not just filtered, they were completely taken down. (Which would then leave the filter in a state where everything filtered was legitimate content).
the ISPs have only managed to hide it from plain sight.
That is true. Instead of filtering, they could work on getting every one of those sites taken down, that would bring them one step closer to the source. Even better would be to prosecute the site operators. The best would be to go after the people who produce it in the first place.
Sometimes you have to stop and wonder why they are fighting it to begin with. Are they fighting it because they think it is distasteful? If that is the only reason to fight it, then it is nothing but censorship. But that of course isn't the reason we should fight against it, the reason we should fight against it is to stop the abuse of children which is happening to produce it.
If you accept that the real crime we want to prevent is child abuse, then distribution of child pornography is really not a major crime. The child porn however is evidence of a major crime. Seen in that light, fighting distribution of child porn is really just hiding the problem. Even if they succeed in stopping all distribution of child porn on the internet, it still means they have done nothing to stop the real problem, they have just hidden it very well.
Now go back and think about some of the moves that have been done in the fight against child pornography. How many of the moves suggest the fight is because people find it distasteful? How many of the moves suggest the fight is to stop child abuse?
I've read some time ago something about quantum encryption being already cracked.
Some implementations have been flawed, but quantum encryption itself is not broken, and cannot be broken without finding some changes to the laws of physics. One example of a flawed implementation was one where you could send a bright light in the opposite direction of the communication and get enough light reflected to measure the exact orientation of the filter producing the outgoing qubits. The sender only intended to send just one qubit with the specific orientation but by sending lots of additional photons and have them bounce back, there would be more than enough identical qubits to measure in both bases. As soon as you have done that you can pass on the bit by using your own qubit generator. The sending device needed to be fixed such that you cannot amplify the signal by shining a bright light into it.
There are some quantum encryption algorithms that are supposed to be safe from decryption by quantum computers.
Hash functions and symmetric ciphers are somewhat safe against quantum computers. A quantum computer can give a significant speedup, but only to the point of reducing the strength to half the number of bits it would otherwise have. So, just design the algorithms to work with twice as many bits as needed to break them on a classical computer, and they will most likely be secured against a quantum computer as well.
However public key encryption schemes (especially those built on factorization like RSA) can be broken much faster on a quantum computer. For those just increasing the key length isn't sufficient to give you the edge you need to protect against quantum computers. Research is happening in the field of developing public key schemes that are secure against quantum computers, but I don't know what the current state of that is.
But quantum computers are required to do the quantum encryption, so there will be a kind of race to install enough of the new machines, before those who get the first few of them, misuse them
There is a major difference. You don't need a quantum computer to do quantum cryptography. You need a device that can send single qubits, and a device that can receive and measure them. But these devices don't need to work on more than one bit at a time, so they are not really quantum computers. The algorithms do involve a lot of computation, but that computation happens on a classical computer which is doing computation on the data before and after it has been in the state of qubits.
There is a method to increase the range at which quantum encryption can work, which involve quantum computers. You cannot use a classical repeater with qubits because the repeater would collapse the quantum state in pretty much the same way an eavesdropper would. Instead you would use devices that takes advantage of entanglement of qubits. Each such device will require a 2-bit quantum computer in order to work. But a 2-bit quantum computer is no use for breaking any sort of encryption. The encryptions that you could break using a 2-bit quantum computer are much easier to break using a classical computer and a lookup table of all the possible keys.
It was supposed to show why a salt is so important, which you obviously understand, yet you missed the point of the article..
If that is really the point of the article, then whoever wrote the summary on slashdot didn't get the point of the article. Yes, even though it is possible to go and read the article, the summary should still give you an idea of what the point of the article is. If the summary contains just random ramblings how are you supposed to know if the article is worth reading.
The summary just states that this password could be broken in 160 seconds, without giving any context. The password in the example consists of one upper case letter, six lower case letters, and six digits. If those were random, then to break it in 160 seconds you would have to do 25 billion per second, which translates to several thousand per clockcycle. Obviously not feasible on a single CPU.
The summary makes it sound like this password isn't strong enough to withstand brute force. But if the article really mentions that this was due to a weakness in the way the password was stored, then that information would have been much more appropriate for the summary than a random example of how a strong password can be broken in 160 seconds.
Complaining about people not reading the article does have its places, but this is not one of them. If the summary is actually sensible, and comments ask about more detail, that happens to be in the article, then it is appropriate to point out that the article is there.
Maybe I'm wrong, but as far as I know the padding is merely to make sure the input is an even multiple of the number of bits in the hash.
That is the main purpose of the padding, but the padding ends with a 64 bit field containing the length of the full message. The padding between the message and the length field is a one bit followed by all zeros. This way you can always find out how long the padding was by looking for the last one bit. So it is guaranteed that two different messages will always be different after padding as well, and there are two different ways to reverse the padding operation.
I admit that I'm not a cryptographer, but I'm fairly certain that there is no requirement for the objects to be identical in size in order for a collision to occur.
Correct, but all the methods faster than brute force produce collisions of identical length. The best attack on MD5 produces a collision by taking two chosen prefixes and then adding some blocks to bring the hash state to the same for the two strings. Once the hash state is identical for both you can add the same suffix to both and have the same resulting hash. The first part of this attack doesn't depend on the message length. You could start with two prefixes of different length and use the attack to get the same state of the hash except for the length counter. Once the final padding was added they would most likely end up with different hash values.
It is not proven that there exist collisions of messages of different size. However, it is highly likely that there does. If you were to perform a brute force attack, it would not be much harder to find a collision of two messages of different length. You could take 2^64 messages of one length and 2^65 messages of a different length, and you have a good chance that one message of one length collides with a message of the other length.
But why would you want to use a slower method of generating a collision of messages of different length, when that is also less useful since the layer above the hash might check length and hash value.
Also, it would be easy to assume that if the hash collides that the all higher level hashes (e.g. Tree hash of a branch which includes the file) would be identical
The next level up the tree doesn't hash the file contents, it hashes the hash of the file contents. And since both of those hashes are identical, the next level will produce identical hashes because it is hashing identical inputs.
but I am actually leaning in the direction that it won't be for SHA-1 while it will be for MD5.
First of all the tree structure is not part of the hash definition itself, it is just a way to use the hash function. Second, SHA1 and MD5 are very similar. The round function is different, and SHA1 has a state of 5 32 bit words where MD5 only has 4 32 bit words. Everything else is identical. And this similarity is actually not a problem since as long as the round function is collision resistant, then the full hash will be as well. You cannot produce a collision for the full hash without doing it at least once for the round function. However this similarity does mean that most arguments about behaviour of the hash will be exactly the same for both hashes.
It is this "nested hash" feature that people seem to be missing.
I'm not familiar with that term. A quick search for it found me information about some perl library, which did not seem to have anything to do with cryptographic hashes. I am assuming the term you wanted to use was a hash tree. In a hash tree you just have to produce a collision in one node of the tree, and it will propagate up all the way to the root as a collision.
and because it is not a CRC type hash like MD5 it is impossible.
MD5 is not a CRC. MD5 and SHA1 are both very different from a CRC, MD5 and SHA1 are however very similar.
If you plug your new object in I believe it will break the hashes of the other objects. For example a directory is an object with a hash that includes the size of the object.
All the collision attacks demonstrated against md5 would produce collisions where the inputs had identical size. Due to the way the padding to make the input an integral number of blocks works, none of the attacks can be used to construct collisions with different size inputs.
Since sha1 use the exact same padding as md5, it seems quite likely, that any attack against sha1 will produce collisions of identical size. So, if you do replace an object with another one with same hash, it will also be of the same size.
Assuming a chosen prefix attack against sha1 (similar to what has been demonstrated against md5), you can choose two prefixes of identical length, then have the attack generate a few blocks of "random" data to line of the hashes, and then finally choose a suffix for both files.
Producing something that compiles and do what you want it to is easy. The random garbage in the middle can be put inside a comment. The hard part is to get a file with a block of random garbage in the middle accepted. For a C source file it is easy to recognize. Maybe the attack could be performed in a way that it only has to tweak the low order bits of some bytes, then you could produce a hex encoding of some binary data that you may be able to argue servers some purpose. Notice that for the malicious version, the prefix could end by starting a comment, such that the attack part and anything after that until the first comment is ignored.
That is just a practical application of the weakness that was demonstrated in 2004. The original demonstration of the weakness just got people saying that it would be easy to tell the difference between a legitimate file and a file crafted to have the same hash value. The article you mention seems to have been a reaction to this demonstrating how it can be applied. Such applications should have been obvious to everyone from the original result.
A stronger attack was demonstrated later. In the original attack the only part of the inputs that differed would be chosen by the attack, so you would have no control over them. The stronger attack would take any two prefixes of identical length and add a few blocks to each to line up the intermediate state of the hash. That way it would produce a collision where you had a lot more control over the contents. And the attack could be repeated to produce many files with identical hash. They used that method to predict the outcome of an election in a large North American country. They published the md5sum of a file with the name of the winner a long time before the election. They had produced a sequence of files with the names of each candidate (I think they were pdf files), all of which had same md5sum.
A similar attack was later used to construct a pair of SSL certificates with identical md5sums, and they got a CA to sign one of them which was a valid signature for the other. Even this was not enough to get browsers to stop accepting certificates signed with md5.
at the cost of using the AES round
>function, which is a bit like putting your eggs in one possibly dodgy basket).
If you have a system that uses both a block cipher and a hash function, it is probably because it needs both, and a weakness in either would result in a weakness in the system as a whole. So, it isn't really much of a problem that they are similar.
it is possible to combine two block ciphers to produce a system that is secure even if one of the ciphers is broken. If they use the same block size, then you can just apply one hash after the other, using two independent keys. It doesn't make brute force harder, but it does mean you don't have to worry if one of the two is broken. Of course this reduces performance to half.
It is surprisingly difficult to combine two hash functions in a similar way. The most obvious ways to combine two hash functions won't be secure in the typical security models. Try to design a way to combine two hash functions, where you assume one of them is secure in the random oracle model, and the other is designed by an adversary to be as insecure as possible. The aim then is to make a hash function out of those two, which will be secure in the random oracle model without knowing which of the two hash functions is secure.
Keccak has no relation to AES except for one of the authors, and is a new design. I think you are confusing it with another hash.
You may be thinking of Grøstl. It uses some constructions from AES. They have been modified a bit, but there is still a lot of similarity, and they can reuse some of the hardware designed for accelerating AES.
You often have a cryptographically secure and reasonably fast hash algorithm available in some library
If you want a hash function to use as a checksum to protect against random data corruption, then md5 is actually a quite good choice. It is much faster than sha1 and sha2. The output is large enough to make the risk of random collisions small. The design that aimed to make it resilient to an adversarial modification of the data means that it is totally unlikely that some pattern in the data corruptions could by chance cause changes to the hash to cancel out. And there are portable implementations available. If you try to write something that works on different byte orderings it is actually hard to write something that is simple and faster than md5.
OpenBSD slowed an internal hash function down to slow possible brute force attacks against the passwd file
A slower implementation of the same hash doesn't add any security. You should expect the attackers to use the fastest possible implementation of the hash. Some uses of hashes for passwords will apply the hash multiple times (each iteration should use both the output from the previous iteration and the password itself). This makes the calculation equally slower for both the system using it and the attackers. The purpose of this is not to protect against weaknesses in the hash, but rather to protect against weak passwords. This is a very special use case for a hash function, and the requirements are quite different from what hash functions are usually used for.
That only matters if the hashes output is perfectly distributed. Unless they have some proof of that, a 256 bit hash is actually much less than 256 bits of security.
That's part of what this whole process is about. If anybody can show that one of the hashes has a skewed distribution of the outputs, then that hash is very likely to leave the competition. However giving a proof that a hash has a uniform output is not easy unless it has a very simple structure, that is likely to suffer from other weaknesses. Even proving that all 2^256 combinations are possible is difficult, because if there was a constructive proof for that, then you would have given a preimage attack.
Now if you start from a 4K hash, I'd stop worrying about brute force.
That large a hash value would make a lot of the use cases totally impractical. And increasing the size doesn't guarantee you a better hash. I think the current peer review process does more for the security than increasing the size would.
Sure, if the same people would go through the same process to design a hash with a 4K output, then it probably would also end up being very collision resistant, but also very slow. Most people think it is more useful to spend the time on designing a hash with a smaller output.
Iterating a hash is surely equivalent to increasing the number of rounds in a modern block cipher primitive, which absolutely does increase its security.
Not exactly. The multiple rounds for a typical hash is not for the full hash, but rather for each individual block. And after running all the rounds for a block usually the input from before all these rounds is merged back with the output of all these rounds. Also, when running these rounds the input to the next round is not just the output of the previous round, but also the block you are hashing.
Even if you do full connection tracking you will still get a better result if you just use that tracking to filter traffic rather than modify the packets.
There isn't any current restriction on connectivity and odds are that any transition, even a forced one, will be more of a gradual process than a col turkey cutoff.
There is no doubt it will be a gradual process. And large parts of the network will be running IPv4 and IPv6 in parallel for some time. If you decide to keep your part of the network IPv4 only for a long time, then falling off the network will also be a very gradual process. It is going to start with a few people on the Internet being unable to communicate with you. As time goes on the parts of the Internet you won't be able to communicate with will keep growing. You might not notice as the number of people you can communicate with might still be growing. (A smaller and smaller percentage of a growing Internet may still be growing in absolute terms). It will be a very long time before a major part of the networks that already have IPv4 will go IPv6 only.
0000::/96 was previously defined as the "IPv4-compatible IPv6
address" prefix. This definition has been deprecated by [RFC4291].
There is also::ffff:0:0/96 which is used locally to provide a single API that applications can use to talk IPv4 using IPv6 addresses. But on the network it is still IPv4 with all the restrictions you get from that, the only purpose of this address format is for applications to not have to support both APIs simultaneously.
How much will that "IPV6 Migration" project save or return?
That's the wrong question. You are going to need IPv6 at some point because your business need to communicate with somebody who was not lucky enough to get an IPv4 address. Of course you may not be able to predict if this will happen in one year or in five years, but it will happen. The real questions to ask are:
How much resources will you save by starting the migration now compared to later?
How much will it cost if you are too late with deploying it?
You might not even realize that you are too late. How will you measure the money you lost due to a potential customer who could not access your website because he only had IPv6 access?
Even better forget about NAT and run your recursive DNS server on an OS that properly supports a dual stack configuration. Your DNS server can do lookups over IPv4 or IPv6 as needed. Clients can contact the DNS server over IPv4 or IPv6 as needed. Since the client and DNS server are on the same network, you don't need NAT between them. The DNS server of course needs a public IPv4 addresses. At least one RIR have decided to keep a small pool of IPv4 addresses for such cases.
ipv6.google.com doesn't work anymore. Your ISP needs to partner with Google so google's DNS serves will return IPv6 addresses to hosts in those networks.
This is not correct. No matter which DNS server you use, Google will provide an AAAA record for ipv6.google.com (and no A record).
For google.com, www.google.com, and many other google domain names there currently is a whitelist of DNS servers among ISPs that have an agreement with Google about the service level of the IPv6 connectivity. DNS servers on the whitelist gets both A and AAAA records for those domains, DNS servers not on the whitelist only gets A records.
Of course they're not going to put IPv6 on their main domain, but that's only because most OSs and hosts have a broken implementation
Saying most is not accurate. There has been at least one number published, and it was less than 1%. However compared to the number of people who actually have IPv6 connectivity, and compared to the reliability that Google wants, 1% is a lot.
they ask for an AAAA record first, timeout, and ask for an A record then. They don't check if IPv6 is working first and fall-back to all-IPv4
It's correct that most ask for AAAA first, but only if they think they have a working IPv6 connection. In some cases AAAA lookups don't work, in other cases AAAA lookup works, but there is no working IPv6 connectivity, and there is a long delay before the TCP connection times out.
Slashdot Mirror
Yeah, I suppose you wouldn't worry about somebody showing up to be beat the hell out of your PO box. But it doesn't give you a better case when you are being sued for fraud (or whatever is the legal term for this). I also suspect the malaysian may think twice before sending the cheque to a PO box, they might actually realize that if the address is a PO box, they are dealing with somebody who has got a clue. Then again, not all scammers are too bright.
Age of consent doesn't mean that it is legal to produce porn from that age. There are countries where age of consent is 15, but any porn involving people under 18 is illegal. How old do you have to be to legally take part in porn in the Vatican? Is porn even legal there?
The laws as they stand now means that in some countries it is legal for a grown man to have sex with a 16 year old girl, but it is illegal for a grown man watching a video with a 16 year old girl having sex. Getting back to the difference between the different age of consent in different countries, I think that is problematic, and the problem doesn't have anything to do with porn at all. Taking a minor to a country with a lower age of consent to have sex there could happen without any porn being produced. This raises the question about whether a country should try to make its laws apply to what happens in other countries. While most people in western countries would argue that the law should prevent doing things like that, I think the same people would argue that the laws of for example Asian countries shouldn't apply to those countries citizens when they are in a western country.
I think it is perfectly fine if parents can limit what their children look at on the internet. But that doesn't mean internet access providers should filter it by default. Finding out what should be filtered and what not, is tricky regardless of where you want to put the filter. The filtering could be implemented in the internet providers equipment or on the customer's own computer. I think it would be ok for the access provider to offer the filtering as a service, I just don't think it should be mandatory, and it definitely shouldn't be enabled by default. Asking each customer if they want it is fine.
They send him a cheque, they know where he lives. For all he knows a group of big Malaysian men could show up at his door. If he kept the money it would also be harder to argue that he was not deliberately taking part in fraud.
I think in some cases it is not because they cannot see through the scam, but rather because they think they are safe. Consider that they receive all the money first, and then they transfer part of it on. It is not like they are paying somebody money before receiving their own share. But then after they have received money (possibly from a victim from internet banking phishing) and transferred part of that money to an account abroad, the original transfer is reverted.
Somebody who is in that position where they thought part of it through but forgot the part about the first transaction being reverted will have to play stupid. They cannot admit that they had some idea what was going on, because then they would admit to have deliberately taken part in the crime. Playing stupid may be unlikely to get your money back, but with a bit of luck it may save them from a sentence.
Not saying this is necessarily saying this is what happened in this case, just saying that these people may not be as stupid as it looks. One saying goes: "Never attribute to malice what can adequately be explained by incompetence", another saying goes: "Any sufficiently advanced incompetence is indistinguishable from malice". But in some cases it may actually be a combination of malice and stupidity, and it can be hard to tell how much of each.
For that reason I think it would make sense to focus on those who trade child pornography. I think the trading it should be considered an entirely different crime from distribution and possession. Do you think a demand where there is nothing to get in return will also get people to supply it?
You have got a point there. I had not forgotten about how broad the definition was there, but when I said there might not have been a lot to begin with, I was thinking about the kind where there would be no doubt whether it was pornographic or not. Some of the moves to make the definition very broad are part of the reason I get the feeling it is about taste rather than about stopping abuse.
I don't think that is evidence in either direction. I think most people when asked would say they find child porn to be a lot more distasteful than scat porn. As such either of the two reasons could explain it. Consider that many attempts are made to stop distribution without at the same time attempting to find the source. Also consider that some countries are trying to extend the definition to also cover drawings and prose. And now this where a country want to extend the filtering to cover all porn.
Have you got any evidence to back up that statement? More likely there wasn't tons of it to begin with, and most of the blocked sites are legitimate. Recently there was news about a group that audited the sites in the Danish and Norwegian lists, and of the hundreds of sites they audited only three were found to have illegal content. They managed to get those three sites taken down in a couple of days. They were not just filtered, they were completely taken down. (Which would then leave the filter in a state where everything filtered was legitimate content).
That is true. Instead of filtering, they could work on getting every one of those sites taken down, that would bring them one step closer to the source. Even better would be to prosecute the site operators. The best would be to go after the people who produce it in the first place.
Sometimes you have to stop and wonder why they are fighting it to begin with. Are they fighting it because they think it is distasteful? If that is the only reason to fight it, then it is nothing but censorship. But that of course isn't the reason we should fight against it, the reason we should fight against it is to stop the abuse of children which is happening to produce it.
If you accept that the real crime we want to prevent is child abuse, then distribution of child pornography is really not a major crime. The child porn however is evidence of a major crime. Seen in that light, fighting distribution of child porn is really just hiding the problem. Even if they succeed in stopping all distribution of child porn on the internet, it still means they have done nothing to stop the real problem, they have just hidden it very well.
Now go back and think about some of the moves that have been done in the fight against child pornography. How many of the moves suggest the fight is because people find it distasteful? How many of the moves suggest the fight is to stop child abuse?
Some implementations have been flawed, but quantum encryption itself is not broken, and cannot be broken without finding some changes to the laws of physics. One example of a flawed implementation was one where you could send a bright light in the opposite direction of the communication and get enough light reflected to measure the exact orientation of the filter producing the outgoing qubits. The sender only intended to send just one qubit with the specific orientation but by sending lots of additional photons and have them bounce back, there would be more than enough identical qubits to measure in both bases. As soon as you have done that you can pass on the bit by using your own qubit generator. The sending device needed to be fixed such that you cannot amplify the signal by shining a bright light into it.
Hash functions and symmetric ciphers are somewhat safe against quantum computers. A quantum computer can give a significant speedup, but only to the point of reducing the strength to half the number of bits it would otherwise have. So, just design the algorithms to work with twice as many bits as needed to break them on a classical computer, and they will most likely be secured against a quantum computer as well.
However public key encryption schemes (especially those built on factorization like RSA) can be broken much faster on a quantum computer. For those just increasing the key length isn't sufficient to give you the edge you need to protect against quantum computers. Research is happening in the field of developing public key schemes that are secure against quantum computers, but I don't know what the current state of that is.
There is a major difference. You don't need a quantum computer to do quantum cryptography. You need a device that can send single qubits, and a device that can receive and measure them. But these devices don't need to work on more than one bit at a time, so they are not really quantum computers. The algorithms do involve a lot of computation, but that computation happens on a classical computer which is doing computation on the data before and after it has been in the state of qubits.
There is a method to increase the range at which quantum encryption can work, which involve quantum computers. You cannot use a classical repeater with qubits because the repeater would collapse the quantum state in pretty much the same way an eavesdropper would. Instead you would use devices that takes advantage of entanglement of qubits. Each such device will require a 2-bit quantum computer in order to work. But a 2-bit quantum computer is no use for breaking any sort of encryption. The encryptions that you could break using a 2-bit quantum computer are much easier to break using a classical computer and a lookup table of all the possible keys.
If that is really the point of the article, then whoever wrote the summary on slashdot didn't get the point of the article. Yes, even though it is possible to go and read the article, the summary should still give you an idea of what the point of the article is. If the summary contains just random ramblings how are you supposed to know if the article is worth reading.
The summary just states that this password could be broken in 160 seconds, without giving any context. The password in the example consists of one upper case letter, six lower case letters, and six digits. If those were random, then to break it in 160 seconds you would have to do 25 billion per second, which translates to several thousand per clockcycle. Obviously not feasible on a single CPU.
The summary makes it sound like this password isn't strong enough to withstand brute force. But if the article really mentions that this was due to a weakness in the way the password was stored, then that information would have been much more appropriate for the summary than a random example of how a strong password can be broken in 160 seconds.
Complaining about people not reading the article does have its places, but this is not one of them. If the summary is actually sensible, and comments ask about more detail, that happens to be in the article, then it is appropriate to point out that the article is there.
That is the main purpose of the padding, but the padding ends with a 64 bit field containing the length of the full message. The padding between the message and the length field is a one bit followed by all zeros. This way you can always find out how long the padding was by looking for the last one bit. So it is guaranteed that two different messages will always be different after padding as well, and there are two different ways to reverse the padding operation.
Correct, but all the methods faster than brute force produce collisions of identical length. The best attack on MD5 produces a collision by taking two chosen prefixes and then adding some blocks to bring the hash state to the same for the two strings. Once the hash state is identical for both you can add the same suffix to both and have the same resulting hash. The first part of this attack doesn't depend on the message length. You could start with two prefixes of different length and use the attack to get the same state of the hash except for the length counter. Once the final padding was added they would most likely end up with different hash values.
It is not proven that there exist collisions of messages of different size. However, it is highly likely that there does. If you were to perform a brute force attack, it would not be much harder to find a collision of two messages of different length. You could take 2^64 messages of one length and 2^65 messages of a different length, and you have a good chance that one message of one length collides with a message of the other length.
But why would you want to use a slower method of generating a collision of messages of different length, when that is also less useful since the layer above the hash might check length and hash value.
The next level up the tree doesn't hash the file contents, it hashes the hash of the file contents. And since both of those hashes are identical, the next level will produce identical hashes because it is hashing identical inputs.
First of all the tree structure is not part of the hash definition itself, it is just a way to use the hash function. Second, SHA1 and MD5 are very similar. The round function is different, and SHA1 has a state of 5 32 bit words where MD5 only has 4 32 bit words. Everything else is identical. And this similarity is actually not a problem since as long as the round function is collision resistant, then the full hash will be as well. You cannot produce a collision for the full hash without doing it at least once for the round function. However this similarity does mean that most arguments about behaviour of the hash will be exactly the same for both hashes.
I'm not familiar with that term. A quick search for it found me information about some perl library, which did not seem to have anything to do with cryptographic hashes. I am assuming the term you wanted to use was a hash tree. In a hash tree you just have to produce a collision in one node of the tree, and it will propagate up all the way to the root as a collision.
MD5 is not a CRC. MD5 and SHA1 are both very different from a CRC, MD5 and SHA1 are however very similar.
All the collision attacks demonstrated against md5 would produce collisions where the inputs had identical size. Due to the way the padding to make the input an integral number of blocks works, none of the attacks can be used to construct collisions with different size inputs.
Since sha1 use the exact same padding as md5, it seems quite likely, that any attack against sha1 will produce collisions of identical size. So, if you do replace an object with another one with same hash, it will also be of the same size.
Assuming a chosen prefix attack against sha1 (similar to what has been demonstrated against md5), you can choose two prefixes of identical length, then have the attack generate a few blocks of "random" data to line of the hashes, and then finally choose a suffix for both files.
Producing something that compiles and do what you want it to is easy. The random garbage in the middle can be put inside a comment. The hard part is to get a file with a block of random garbage in the middle accepted. For a C source file it is easy to recognize. Maybe the attack could be performed in a way that it only has to tweak the low order bits of some bytes, then you could produce a hex encoding of some binary data that you may be able to argue servers some purpose. Notice that for the malicious version, the prefix could end by starting a comment, such that the attack part and anything after that until the first comment is ignored.
That is just a practical application of the weakness that was demonstrated in 2004. The original demonstration of the weakness just got people saying that it would be easy to tell the difference between a legitimate file and a file crafted to have the same hash value. The article you mention seems to have been a reaction to this demonstrating how it can be applied. Such applications should have been obvious to everyone from the original result.
A stronger attack was demonstrated later. In the original attack the only part of the inputs that differed would be chosen by the attack, so you would have no control over them. The stronger attack would take any two prefixes of identical length and add a few blocks to each to line up the intermediate state of the hash. That way it would produce a collision where you had a lot more control over the contents. And the attack could be repeated to produce many files with identical hash. They used that method to predict the outcome of an election in a large North American country. They published the md5sum of a file with the name of the winner a long time before the election. They had produced a sequence of files with the names of each candidate (I think they were pdf files), all of which had same md5sum.
A similar attack was later used to construct a pair of SSL certificates with identical md5sums, and they got a CA to sign one of them which was a valid signature for the other. Even this was not enough to get browsers to stop accepting certificates signed with md5.
If you have a system that uses both a block cipher and a hash function, it is probably because it needs both, and a weakness in either would result in a weakness in the system as a whole. So, it isn't really much of a problem that they are similar.
it is possible to combine two block ciphers to produce a system that is secure even if one of the ciphers is broken. If they use the same block size, then you can just apply one hash after the other, using two independent keys. It doesn't make brute force harder, but it does mean you don't have to worry if one of the two is broken. Of course this reduces performance to half.
It is surprisingly difficult to combine two hash functions in a similar way. The most obvious ways to combine two hash functions won't be secure in the typical security models. Try to design a way to combine two hash functions, where you assume one of them is secure in the random oracle model, and the other is designed by an adversary to be as insecure as possible. The aim then is to make a hash function out of those two, which will be secure in the random oracle model without knowing which of the two hash functions is secure.
You may be thinking of Grøstl. It uses some constructions from AES. They have been modified a bit, but there is still a lot of similarity, and they can reuse some of the hardware designed for accelerating AES.
If you want a hash function to use as a checksum to protect against random data corruption, then md5 is actually a quite good choice. It is much faster than sha1 and sha2. The output is large enough to make the risk of random collisions small. The design that aimed to make it resilient to an adversarial modification of the data means that it is totally unlikely that some pattern in the data corruptions could by chance cause changes to the hash to cancel out. And there are portable implementations available. If you try to write something that works on different byte orderings it is actually hard to write something that is simple and faster than md5.
A slower implementation of the same hash doesn't add any security. You should expect the attackers to use the fastest possible implementation of the hash. Some uses of hashes for passwords will apply the hash multiple times (each iteration should use both the output from the previous iteration and the password itself). This makes the calculation equally slower for both the system using it and the attackers. The purpose of this is not to protect against weaknesses in the hash, but rather to protect against weak passwords. This is a very special use case for a hash function, and the requirements are quite different from what hash functions are usually used for.
That's part of what this whole process is about. If anybody can show that one of the hashes has a skewed distribution of the outputs, then that hash is very likely to leave the competition. However giving a proof that a hash has a uniform output is not easy unless it has a very simple structure, that is likely to suffer from other weaknesses. Even proving that all 2^256 combinations are possible is difficult, because if there was a constructive proof for that, then you would have given a preimage attack.
That large a hash value would make a lot of the use cases totally impractical. And increasing the size doesn't guarantee you a better hash. I think the current peer review process does more for the security than increasing the size would.
Sure, if the same people would go through the same process to design a hash with a 4K output, then it probably would also end up being very collision resistant, but also very slow. Most people think it is more useful to spend the time on designing a hash with a smaller output.
Not exactly. The multiple rounds for a typical hash is not for the full hash, but rather for each individual block. And after running all the rounds for a block usually the input from before all these rounds is merged back with the output of all these rounds. Also, when running these rounds the input to the next round is not just the output of the previous round, but also the block you are hashing.
Even if you do full connection tracking you will still get a better result if you just use that tracking to filter traffic rather than modify the packets.
There is no doubt it will be a gradual process. And large parts of the network will be running IPv4 and IPv6 in parallel for some time. If you decide to keep your part of the network IPv4 only for a long time, then falling off the network will also be a very gradual process. It is going to start with a few people on the Internet being unable to communicate with you. As time goes on the parts of the Internet you won't be able to communicate with will keep growing. You might not notice as the number of people you can communicate with might still be growing. (A smaller and smaller percentage of a growing Internet may still be growing in absolute terms). It will be a very long time before a major part of the networks that already have IPv4 will go IPv6 only.
There is also ::ffff:0:0/96 which is used locally to provide a single API that applications can use to talk IPv4 using IPv6 addresses. But on the network it is still IPv4 with all the restrictions you get from that, the only purpose of this address format is for applications to not have to support both APIs simultaneously.
That's the wrong question. You are going to need IPv6 at some point because your business need to communicate with somebody who was not lucky enough to get an IPv4 address. Of course you may not be able to predict if this will happen in one year or in five years, but it will happen. The real questions to ask are:
You might not even realize that you are too late. How will you measure the money you lost due to a potential customer who could not access your website because he only had IPv6 access?
Even better forget about NAT and run your recursive DNS server on an OS that properly supports a dual stack configuration. Your DNS server can do lookups over IPv4 or IPv6 as needed. Clients can contact the DNS server over IPv4 or IPv6 as needed. Since the client and DNS server are on the same network, you don't need NAT between them. The DNS server of course needs a public IPv4 addresses. At least one RIR have decided to keep a small pool of IPv4 addresses for such cases.
This is not correct. No matter which DNS server you use, Google will provide an AAAA record for ipv6.google.com (and no A record).
For google.com, www.google.com, and many other google domain names there currently is a whitelist of DNS servers among ISPs that have an agreement with Google about the service level of the IPv6 connectivity. DNS servers on the whitelist gets both A and AAAA records for those domains, DNS servers not on the whitelist only gets A records.
Saying most is not accurate. There has been at least one number published, and it was less than 1%. However compared to the number of people who actually have IPv6 connectivity, and compared to the reliability that Google wants, 1% is a lot.
It's correct that most ask for AAAA first, but only if they think they have a working IPv6 connection. In some cases AAAA lookups don't work, in other cases AAAA lookup works, but there is no working IPv6 connectivity, and there is a long delay before the TCP connection times out.