It's not extracted from the signature, dumbass, it's extracted from the private key holder - the camera.
The security in the camera was weak. If you can get your hands on the actual private key it doesn't matter how good your hash algorithm is, it can be repeated till the cows come home.
The private key is never shared, and when you generate a hash from the private key, information in the key is lost making it impossible to reproduce.
If that were not true nobody would bother with encryption, because it would be immediately reversible.
You can always brute force decrypt a key, but it is very difficult. The process works by guessing what the private key is and generating a signature, then seeing if it matches the true signature. Do this enough times and you'll eventually find the private key. Since you are looking 3.4^38 possible combinations, though, anything beyond 128bits is impossible to brute force in a practical sense (you could do it, but it would take decades). In a few years that won't be true, which is why we already have 256bit and 512bit encryption algorithms, and work is always being done to create bigger and badder encryption algorithms, but it is true right now.
Again these work by guessing the key, the key itself is not contained in the signature. In fact the public key isn't even in the signature generally, but it is public so of course you have ready access to it (in this case the public key is a hash of the raw image).
The problem in this case is with the security of the camera. They key must be contained on the camera or the camera won't be able to create the initial signature. So these Russian blokes simply broke into the camera and stole the key. They warned Canon before they did this that there were serious flaws with the security of their cameras, but apparently Canon wasn't responsive enough, so they went ahead and broke into the camera, got the key, and generated a half dozen obviously faked photos that Canon's software verifies as legitimate.
you can't give someone else the key and not give them the key at the same time.
You obviously don't know how one-way hashes work (encryption is a two-way or reversible hash, and what you said is true for encryption).
Can you take an MD5 checksum of a file and generate the file? Of course you can't. The checksum does not contain anywhere near the same amount of information as the file contains. But that checksum is a repeatable signature of that file, and you'll notice immediately if it has been tampered with even slightly, because the checksums won't match.
By the same token, if you take a 256bit hash of a photo, multiply it by a 256bit secret key, and take a 256bit hash of the resulting number, then the key does not exist in the resulting hash (we'd call it a signature now, because it is repeatable if you have the key and a copy of the raw image). Parts of the key may exist in the hash (it's quite possible none of the key made it into the final hash), but you took a 256bit hash of a 64kbit number, so 99% of the information wasn't used in the final signature, yet you still got a unique 256bit signature out of the process. In other words, you can't take a ten megabyte file, turn it into a one megabyte file, and expect to reproduce the ten megabyte file using only the one megabyte file and the algorithm used to get it that small. You can take the ten megabyte file and reproduce the one megabyte file all day long, but you can't go backwards. You've permanently lost information, and in the case of signatures, that is by design.
It's easy to take two keys and produce a third key that is unique (can only be generated by the two keys) yet does not actually contain the two keys used to generate it.
What these guys have done is actually get a hold of the private key (the public key is a hash of the image) from the camera. If you have the private key you can break any authentication system, no matter how good your algorithms are.
For verification you need a private key + a public key. The public key is a hash of the photograph itself. The private key is known only to Canon. The private key absolutely must exist on the camera in order for it to generate a signature of the photo (generated from hash + public key).
For verification all the Canon software needs to do is perform the same operation the camera would have: combine a hash of the photo with the private key and generate a signature. If the two signatures match, the photo is verified.
This is pretty much how any verification system of this type will work. There aren't any practical alternatives.
The article didn't come out and say how they did it, but it said they obtained the key from the camera itself. If you can get the key off the camera, the whole system is broken. It doesn't matter what kind of hash function you used, if you have the private key you can generate a valid signature from any image you want - edited or not.
My guess is that the firmware wasn't secured or sufficiently tamper resistant. The key must exist on the camera, so Canon must take steps to ensure the key is inaccessible. They did not do a good enough job of this, and now their verification system is worthless. They'll have to start all over now.
hash functions do not have a key
Somebody doesn't know how hash functions work. For a hash of a file, the key is the file itself. The key is whatever you used to generate the hash - they don't happen by magic. Often for authentication the key itself is a hash - the signature is a hash of a hash. In the case of Canon's image verification, at least half of the key is a hash, the other half is also probably a hash (since they are so nicely random and can be generated from crazy things), but it may not be. Technically just concatenating the public key and the private key is a hash function (albeit an ultra simple one) which generates a new hash, from which a hash function generates the final signature. A hash of a hash of two hashes. That's all these are.
The point here is that hashes do not exist without a key. If it has no key, it's just a random number with no meaning behind it.
It sounds bad, but it really isn't. The vast majority of packets sent are sent at the maximum 1500 MTU. This is because it is hard to get files that are smaller than 1500 bytes, so the only extra overhead for small files vs big files is the tail end of the smaller files.
It's very minor. 1024 1kb files transfers an extra 9kb of data due to overhead compared to a 1mb file. That's about 0.8% waste.
Even a 1gb file doesn't waste much - 1gb worth of 1kb files transfers an extra 8mb of data due to overhead compared to a 1gb file. That's about 0.76% waste (even better than compared to the 1mb file).
Unless you're transferring 100 byte files (which you're not - trust me) there just isn't much waste there.
The network "knows" that these X packets are all going to the same place.
The network knows no such thing. It only knows where each individual packet is going, it has no concept of the entire cluster that is being sent.
Sending a 1mb saves about 9kb (about 6 full packets worth) of data compared to 1024 1kb files. That's 0.8% waste. Not exactly something to write home about.
Here is the breakdown: each packet for the 1mb download will hit the cap of roughly 1500b. With an overhead of 28 bytes per packet, that's 695 packets to transfer a 1mb file vs 1024 1kb files. The extra 28 bytes per packet for 329 packets amounts to just shy of 9kb. Packet loss applies equally to both groups so we can ignore it.
This figure doesn't change much even when you scale it up: for a 1gb file, just under 8mb is wasted. That's still about 0.8% waste (it's actually slightly better here).
Basically unless you are transferring tiny files approaching the 28 byte overhead, you aren't wasting much bandwidth at all - at 100 bytes 28% of your total data is overhead, but for 500 byte files it's about 5.6%, and at 1,000 bytes it's 2.8%.
To get an idea of how hard it is to get files that small, this post is roughly 1.15kb.
If they get together and do that, it's price fixing, and can cost them tens of millions of dollars in fines, and possibly jail time (not likely though). Proving such a thing is difficult, but it has happened before.
However, if there is not enough competition it is fairly easy to come to unspoken agreements on price.
For example*, if there are only two gas stations in town and the price of oil drops, each gas station owner has two options: drop the price of their gas in order to drive more customers to their station and steal customers from his competitor, or he can sit on his current price and wait until his competitor makes a move to lower the price.
If both station owners do the latter, chances are they both make more money than if either of them moved first. They both see the benefits of this, so neither drops the price. They didn't have to get together to agree on a price, they managed to do it without saying a word.
This doesn't usually work with three or four competitors. In that case it isn't a 50/50 split, and it is possible for the first station owner to drop his prices to double or more his number of customers by doing so. That's a very lucrative possibility, and someone always jumps on it (the more competition the quicker it happens). This is the essence of how fair competition seeks the lowest possible price for a given good or service.
In the case of cell phones, you have basically 4 competitors nation wide, and their operating areas don't overlap by more than two competitors in most areas. For large metropolitan areas this isn't the case, but in most non-metropolitan (and even in a number of metropolitan areas) there are only two competitors. Large metropolitan areas tend to have the most competitive plans, too.
This means the pricing takes a long time to get to where it should be, and in some cases it never gets all the way there.
*This example assumes the gas stations in question get most of their money from gas. In reality this is rarely the case, but it's an analogy, deal with it.
Not really. As was noted in the article, the Borings had plastered information similar to that which Google collected all over the internet themselves, including pictures and its address. They clearly weren't concerned about their own privacy, they were just looking for a payday.
It's like telling all your neighbors they can use your driveway to turn around in, and then suing a stranger for turning around in your driveway. Obviously you don't really care if someone turns around in your driveway, so if you sue you'd certainly win, but you would almost certainly only win a dollar.
Frankly, as others have said, I hope the lawyer was working on contingency. He should have known better than to pursue this.
In the case of the Borings, the lawsuit is borderline frivolous (because they obviously don't actually care about their privacy, so no harm was done). However, in many cases it is a big deal, and people really can suffer damages from these kinds of invasions of privacy.
As such, it's important to slap the Borings' hands for bringing a frivolous lawsuit, while producing case-law that says Google's behavior is not acceptable.
A $1 victory for the Borings accomplishes this. It essentially says "What they did was wrong, but you're not going to get a big payday unless they caused damages warranting it."
Nah, that's just a nice round number, and makes the point sufficiently. The peppercorn's relative value hasn't changed in the last two hundred years, it's still practically worthless, but not actually worthless, which is the point the peppercorn principle makes.
The peppercorn principle says that even $0.01 is a fair sum if the circumstances warrant it (i.e. you can make a contract for one cent in payment if you want and it is legally binding).
Essentially what the judge has said here is that the Borings were technically correct, but the lawsuit was a complete waste of everyone's time.
In that case, I'd be more inclined to say the Borings should pay for Google's expenses, but that's obviously unfair given the cost of Google's legal team. So each paying for their own is a-ok with me.
I wouldn't count on that forever. It certainly doesn't work on Hulu - you just get a fresh new ad when the original would have been nearly finished already.
I have a love-hate relationship with Hulu because of the ads. I love it, because there is a lot of high quality video on Hulu. I hate it because I must sit through at least three minutes of advertisements per 20'ish minute show, yet I can skip these ads when watching TV.
Really though, three minutes is better than non-dvr TV, so I still watch Hulu.
I happen to have a birthright to drive two ton machines two hours between work and my gated community, thank you very much.
*shows you his birthright certificate*:D
PS: Just because the number key is there it doesn't mean you should use it any time you want to write a number. Save it for the really big numbers - when you use it for a number with three digits or less your perceived IQ drops by roughly 10-15 points per digit less than four - i.e. typing 300 drops your perceived IQ by ten to fifteen points, typing 30 drops it by twenty to thirty points, and typing 3 drops it by thirty to forty-five points. You should always type out three hundred thirty-three, but for 3,333 it is fine to switch to numerals.
The two come from the same genus and are extremely similar. This is why cassia can be sold as low-grade "cinnamon" - it is nearly identical to the Sri Lanka variety.
For manufacturing purposes I doubt there is any significant difference.
Slashdot Mirror
It's not extracted from the signature, dumbass, it's extracted from the private key holder - the camera.
The security in the camera was weak. If you can get your hands on the actual private key it doesn't matter how good your hash algorithm is, it can be repeated till the cows come home.
Bullshit.
The private key is never shared, and when you generate a hash from the private key, information in the key is lost making it impossible to reproduce.
If that were not true nobody would bother with encryption, because it would be immediately reversible.
You can always brute force decrypt a key, but it is very difficult. The process works by guessing what the private key is and generating a signature, then seeing if it matches the true signature. Do this enough times and you'll eventually find the private key. Since you are looking 3.4^38 possible combinations, though, anything beyond 128bits is impossible to brute force in a practical sense (you could do it, but it would take decades). In a few years that won't be true, which is why we already have 256bit and 512bit encryption algorithms, and work is always being done to create bigger and badder encryption algorithms, but it is true right now.
Again these work by guessing the key, the key itself is not contained in the signature. In fact the public key isn't even in the signature generally, but it is public so of course you have ready access to it (in this case the public key is a hash of the raw image).
The problem in this case is with the security of the camera. They key must be contained on the camera or the camera won't be able to create the initial signature. So these Russian blokes simply broke into the camera and stole the key. They warned Canon before they did this that there were serious flaws with the security of their cameras, but apparently Canon wasn't responsive enough, so they went ahead and broke into the camera, got the key, and generated a half dozen obviously faked photos that Canon's software verifies as legitimate.
you can't give someone else the key and not give them the key at the same time.
You obviously don't know how one-way hashes work (encryption is a two-way or reversible hash, and what you said is true for encryption).
Can you take an MD5 checksum of a file and generate the file? Of course you can't. The checksum does not contain anywhere near the same amount of information as the file contains. But that checksum is a repeatable signature of that file, and you'll notice immediately if it has been tampered with even slightly, because the checksums won't match.
By the same token, if you take a 256bit hash of a photo, multiply it by a 256bit secret key, and take a 256bit hash of the resulting number, then the key does not exist in the resulting hash (we'd call it a signature now, because it is repeatable if you have the key and a copy of the raw image). Parts of the key may exist in the hash (it's quite possible none of the key made it into the final hash), but you took a 256bit hash of a 64kbit number, so 99% of the information wasn't used in the final signature, yet you still got a unique 256bit signature out of the process. In other words, you can't take a ten megabyte file, turn it into a one megabyte file, and expect to reproduce the ten megabyte file using only the one megabyte file and the algorithm used to get it that small. You can take the ten megabyte file and reproduce the one megabyte file all day long, but you can't go backwards. You've permanently lost information, and in the case of signatures, that is by design.
It's easy to take two keys and produce a third key that is unique (can only be generated by the two keys) yet does not actually contain the two keys used to generate it.
What these guys have done is actually get a hold of the private key (the public key is a hash of the image) from the camera. If you have the private key you can break any authentication system, no matter how good your algorithms are.
For verification you need a private key + a public key. The public key is a hash of the photograph itself. The private key is known only to Canon. The private key absolutely must exist on the camera in order for it to generate a signature of the photo (generated from hash + public key).
For verification all the Canon software needs to do is perform the same operation the camera would have: combine a hash of the photo with the private key and generate a signature. If the two signatures match, the photo is verified.
This is pretty much how any verification system of this type will work. There aren't any practical alternatives.
The article didn't come out and say how they did it, but it said they obtained the key from the camera itself. If you can get the key off the camera, the whole system is broken. It doesn't matter what kind of hash function you used, if you have the private key you can generate a valid signature from any image you want - edited or not.
My guess is that the firmware wasn't secured or sufficiently tamper resistant. The key must exist on the camera, so Canon must take steps to ensure the key is inaccessible. They did not do a good enough job of this, and now their verification system is worthless. They'll have to start all over now.
hash functions do not have a key
Somebody doesn't know how hash functions work. For a hash of a file, the key is the file itself. The key is whatever you used to generate the hash - they don't happen by magic. Often for authentication the key itself is a hash - the signature is a hash of a hash. In the case of Canon's image verification, at least half of the key is a hash, the other half is also probably a hash (since they are so nicely random and can be generated from crazy things), but it may not be. Technically just concatenating the public key and the private key is a hash function (albeit an ultra simple one) which generates a new hash, from which a hash function generates the final signature. A hash of a hash of two hashes. That's all these are.
The point here is that hashes do not exist without a key. If it has no key, it's just a random number with no meaning behind it.
It sounds bad, but it really isn't. The vast majority of packets sent are sent at the maximum 1500 MTU. This is because it is hard to get files that are smaller than 1500 bytes, so the only extra overhead for small files vs big files is the tail end of the smaller files.
It's very minor. 1024 1kb files transfers an extra 9kb of data due to overhead compared to a 1mb file. That's about 0.8% waste.
Even a 1gb file doesn't waste much - 1gb worth of 1kb files transfers an extra 8mb of data due to overhead compared to a 1gb file. That's about 0.76% waste (even better than compared to the 1mb file).
Unless you're transferring 100 byte files (which you're not - trust me) there just isn't much waste there.
The network "knows" that these X packets are all going to the same place.
The network knows no such thing. It only knows where each individual packet is going, it has no concept of the entire cluster that is being sent.
Sending a 1mb saves about 9kb (about 6 full packets worth) of data compared to 1024 1kb files. That's 0.8% waste. Not exactly something to write home about.
Here is the breakdown: each packet for the 1mb download will hit the cap of roughly 1500b. With an overhead of 28 bytes per packet, that's 695 packets to transfer a 1mb file vs 1024 1kb files. The extra 28 bytes per packet for 329 packets amounts to just shy of 9kb. Packet loss applies equally to both groups so we can ignore it.
This figure doesn't change much even when you scale it up: for a 1gb file, just under 8mb is wasted. That's still about 0.8% waste (it's actually slightly better here).
Basically unless you are transferring tiny files approaching the 28 byte overhead, you aren't wasting much bandwidth at all - at 100 bytes 28% of your total data is overhead, but for 500 byte files it's about 5.6%, and at 1,000 bytes it's 2.8%.
To get an idea of how hard it is to get files that small, this post is roughly 1.15kb.
If they get together and do that, it's price fixing, and can cost them tens of millions of dollars in fines, and possibly jail time (not likely though). Proving such a thing is difficult, but it has happened before.
However, if there is not enough competition it is fairly easy to come to unspoken agreements on price.
For example*, if there are only two gas stations in town and the price of oil drops, each gas station owner has two options: drop the price of their gas in order to drive more customers to their station and steal customers from his competitor, or he can sit on his current price and wait until his competitor makes a move to lower the price.
If both station owners do the latter, chances are they both make more money than if either of them moved first. They both see the benefits of this, so neither drops the price. They didn't have to get together to agree on a price, they managed to do it without saying a word.
This doesn't usually work with three or four competitors. In that case it isn't a 50/50 split, and it is possible for the first station owner to drop his prices to double or more his number of customers by doing so. That's a very lucrative possibility, and someone always jumps on it (the more competition the quicker it happens). This is the essence of how fair competition seeks the lowest possible price for a given good or service.
In the case of cell phones, you have basically 4 competitors nation wide, and their operating areas don't overlap by more than two competitors in most areas. For large metropolitan areas this isn't the case, but in most non-metropolitan (and even in a number of metropolitan areas) there are only two competitors. Large metropolitan areas tend to have the most competitive plans, too.
This means the pricing takes a long time to get to where it should be, and in some cases it never gets all the way there.
*This example assumes the gas stations in question get most of their money from gas. In reality this is rarely the case, but it's an analogy, deal with it.
If you're downloading at 8mbps (average for LTE according to TFA) you are going to max out Youtube's "HD" h.264 stream.
Realistically you'd get a couple hours of video out of this, maybe a movie and a half worth.
Clearly they are doing good for the purposes of evil!
I found that thread enlightening.
You realize your only proof is speculation that is 10 years and three full OS versions old, right?
That's about as weak as you can get.
It's a frustrating disconnect.
Not really. As was noted in the article, the Borings had plastered information similar to that which Google collected all over the internet themselves, including pictures and its address. They clearly weren't concerned about their own privacy, they were just looking for a payday.
It's like telling all your neighbors they can use your driveway to turn around in, and then suing a stranger for turning around in your driveway. Obviously you don't really care if someone turns around in your driveway, so if you sue you'd certainly win, but you would almost certainly only win a dollar.
Frankly, as others have said, I hope the lawyer was working on contingency. He should have known better than to pursue this.
I think that was the point.
In the case of the Borings, the lawsuit is borderline frivolous (because they obviously don't actually care about their privacy, so no harm was done). However, in many cases it is a big deal, and people really can suffer damages from these kinds of invasions of privacy.
As such, it's important to slap the Borings' hands for bringing a frivolous lawsuit, while producing case-law that says Google's behavior is not acceptable.
A $1 victory for the Borings accomplishes this. It essentially says "What they did was wrong, but you're not going to get a big payday unless they caused damages warranting it."
Nah, that's just a nice round number, and makes the point sufficiently. The peppercorn's relative value hasn't changed in the last two hundred years, it's still practically worthless, but not actually worthless, which is the point the peppercorn principle makes.
The peppercorn principle says that even $0.01 is a fair sum if the circumstances warrant it (i.e. you can make a contract for one cent in payment if you want and it is legally binding).
I disagree in cases like these.
Essentially what the judge has said here is that the Borings were technically correct, but the lawsuit was a complete waste of everyone's time.
In that case, I'd be more inclined to say the Borings should pay for Google's expenses, but that's obviously unfair given the cost of Google's legal team. So each paying for their own is a-ok with me.
In case you always skip, five seconds allows them to grab your attention if it is a product you may be interested in.
I wouldn't count on that forever. It certainly doesn't work on Hulu - you just get a fresh new ad when the original would have been nearly finished already.
I have a love-hate relationship with Hulu because of the ads. I love it, because there is a lot of high quality video on Hulu. I hate it because I must sit through at least three minutes of advertisements per 20'ish minute show, yet I can skip these ads when watching TV.
Really though, three minutes is better than non-dvr TV, so I still watch Hulu.
I can't see how this process uses no electricity. How does the cinnamon and gold particles get together? how is the cinnamon remove?
Jeeze, did you read the damn thing? They mix gold salts and cinnamon in water and get gold nanoparticles.
There is no electricity because there is no electricity. It's a purely chemical process.
I happen to have a birthright to drive two ton machines two hours between work and my gated community, thank you very much.
*shows you his birthright certificate* :D
PS: Just because the number key is there it doesn't mean you should use it any time you want to write a number. Save it for the really big numbers - when you use it for a number with three digits or less your perceived IQ drops by roughly 10-15 points per digit less than four - i.e. typing 300 drops your perceived IQ by ten to fifteen points, typing 30 drops it by twenty to thirty points, and typing 3 drops it by thirty to forty-five points. You should always type out three hundred thirty-three, but for 3,333 it is fine to switch to numerals.
And a one-sentence critique can use the word six.
A bit hypocritical aren't we?
The two come from the same genus and are extremely similar. This is why cassia can be sold as low-grade "cinnamon" - it is nearly identical to the Sri Lanka variety.
For manufacturing purposes I doubt there is any significant difference.
I wonder if there is a practical difference for industrial purposes.
And, of course, he who controls the spice controls the universe!
*buys cinnamon*
I'm not sure I follow, that commercial is a classic.