Couldn't they just have two profile settings, country and currency?
I was wondering about that as well. Might be they just couldn't add that feature to their system at such short notice. Alternatively it might be they are worried about the legal ramifications of such a change.
If the problem is caused by Google not being able to buy the correct kind of currency, couldn't they have offered to pay the developers in a different currency?
That is so true. It takes less than one minute to write a scanner, which never produces a false negative. But of course in that case it would produce false positives all the time.
The comment I was replying to, was implying it was a fact. Others have implied that as well, and I haven't seen anybody deny it. If you think they are wrong, you are welcome to present your argument, then I'll watch from the sideline until I know which side to believe.
How would one readily tell whether a transaction has come from, say, a Silk Road wallet?
Silk Road run a mixing service? I have only seen it presented as a market place for trading goods using bitcoins.
Unless they refuse to honor any bitcoins that have passed through a money-laundering service recently
The fact that they can even tell the difference makes bitcoin less anonymous than physical money. Maybe the anonymity wasn't the selling point for bitcoin, maybe it rather was that they can be used without any regulation. Bitcoins can be used without regulation, but what you trade with bitcoins can still be regulated. That holds regardless if that something is goods or real currency. (The large focus on being able to exchange between bitcoin and real currency is a symptom telling us, that bitcoin is not yet a real currency. With a real currency you can have your income in that currency, and you don't worry about exchanging because you can also pay your expenses with that currency.)
Didn't Token ring evolve into a star topology just like Ethernet did? If things had turned out differently, and we had all been using Token ring today, the only notable difference might very well have been the name. How many people actually remember, what Ethernet looked like back when the technology had any resemblance with the name?
There are many problems with searches for missing people using facebook. The most important problem is the lack of a trustworthy source. I would never take part in such a search, if the source is a person, I don't know. If you want me to take it serious, then link to the police' official page on the search. If the police doesn't want to put up such a page, then don't expect my participation.
Harm can be done by spreading such a search on facebook, if it isn't legitimate.
The person may already have been found, in which case you are just spamming. And you are decreasing the value of what could otherwise have been a useful communication channel.
The person may never have been missing in the first place, and the entire search is nothing but harassment.
The person may be hiding from abusive relatives, and you may inadvertently lead those abusive relatives directly to the victim.
Most importantly, we may finally get a break from the forced permanence of the Facebook and Google world, where everything you do and share is a data point to be monetized and re-sold to the highest bidder.
I would be much more willing to trust Google with my data than any new company showing up. Regardless of what the Internets are claiming, Google does not sell users' data.
Google earned my trust through their actual actions. If a new company want to earn my trust, they have to do the same. It is not hard to create a system, that I would rather trust with my data, than any of Google's systems. All it requires is a system, where it is technically impossible for the company behind to snoop my data. And the system has to be open enough, that those security properties can be independently verified by any third party, who wishes to do so.
It would be great to be able to swap out a dead drive without have to wait for a person to be available to do the same job.
I wouldn't trust a robot to do that job. On one occasion I have had to send a person to repair a drive, that was broken by a robot. A tape robot had literally ripped the front off a tape drive. Not only did that leave us with a broken drive, the piece was now stuck in the robots hand, and it wasn't able to get it out of its hand. So the robot gave up and drove up to the service area, waiting for a human to come and repair it.
This is not even the most spectacular robot problem I have experienced. Four years of dealing with real robots in data centers have made me realize, what a long way to go we have before robots can take over jobs we let humans do today.
That's all nice and everything, but the real issue here is that people expect to receive preferential treatment by calling themselves "reporters".
I have never implied the press should receive special treatment. Anybody who finds a security problem should be free to publish it as they see fit (unless they have entered an agreement about confidentiality, before they found the problem). Of course the right thing to do is to tell the responsible people about it in private, such that they have a chance of fixing the issue before you go public. But that is a matter of ethical conduct, and should not be part of the law.
Companies who want time to fix issues before they become public should give something in return to those who find the problems.
The law of course should impose some limits on how you can legally abuse a security hole. Finding an SQL injection and dropping all tables from the database should not be legal. But perhaps finding an SQL injection and shutting down the database server before somebody else starts dropping tables should be legal. Using an SQL injection to have the database add up two numbers (just so you can verify that there is truly an SQL injection) should definitely be legal.
there needs to be an outside agency or association which rewards those who expose these security holes and maybe even funds the court case against those targeting the messenger.
The law should be modified to ensure the following three properties:
It should be illegal to deploy a system, which stores personal data in an insecure way. But as long as security holes are only left open accidentally, and are patched when pointed out, violations should only be punishable by fine.
It should be legal for an outsider to take the necessary steps in order to verify the existence of a security problem in the system, as long as such action cannot be expected to damage data in the system.
Any attempt by the owner of the system to persuade the finder of a security problem to keep it secret should be illegal. Such action should be punishable, plus the finder should receive compencation.
All of this is only applicable when the security problem is found by an outsider. It is reasonable to apply different rules when the security hole is found by an insider. If the security problem is found by an insider, it is acceptable if the company try to keep the problem secret indefinitely. But it is still not acceptable to leave the vulnerability unpatched.
But the reporter can't be anonymous and trustworthy.
Sometimes the evidence itself is more important than the source. In the particular case, it sounds like the evidence was strong enough that it wouldn't matter which source it came from.
But the trend with threats and lawsuits against those, who discover security holes, must stop. That trend is a major threat against data security across the entire IT industry.
People will keep finding security holes. Sometimes you just stumple upon them, without even looking. What are you going to do, once you have found a security hole? Report it and try to get it fixed? Ignore it? Abuse it? If those who do the right thing are going to be the target of threats and lawsuits, that certainly removes incentive to do the right thing. So fewer people will report security holes. And some of those who would have reported it, might instead decide to abuse it.
If we ever get to the point where doing the right thing is more likely to get you into a lawsuit than abusing the security hole for personal gain is, then the industry is in big trouble.
Luckily a few companies are taking steps in the opposite direction and are offering cash rewards to those who find security holes. At some point users will have to start taking that into account when deciding what software to trust. But it is a very real problem, when the systems you don't trust are those used by any branch of government. You can't just go somewhere else. And the lack of competition has lead to situations where security concerns are just ignored.
I guess it could replace a command and control channel, I want my dodos to start at 8pm so have everyone's phone listen for the television themes for "the orrifice" or "CSI Newark"
Malware triggering on a specific time and date was common back in the days where the keyboard was the only input device on a typical PC, and even the fastest CPUs could not do signal processing in real time.
Back t hen It wasn't hard to trigger at a specific time, all it had to do was check the clock, which all PCs were equipped with. This sort of trigger was probably the first sort of trigger anybody came up with for a piece of malware.
There is no reason to come up with convoluted solutions involving signal processing, if what you want to do is trigger at a specific time.
There's no government (i.e. no fire department and no building codes) to speak of, so pretty much any house fire is going to be a "burn to the ground" situation.
But that doesn't influence the probability of the fire starting in the first place. It isn't due to the fire department, that most people don't experience their house burning to the ground. Rather it is because a house being on fire doesn't happen that often. (For some reason this reminds me of a story involving a staple gun and 500kg of fireworks).
We can be almost certain, it was no coincidence. But at this point any statements about who was behind it is nothing more than speculation. Perhaps we'll never know for sure.
Earlier you claimed this was "absolute proof", and that's the problem.
Yep. A proof would require a demonstration, that they actually extracted data from a phone, which was protected by a password with more entropy than can be brute forced. Moreover, it would not be sufficient that somebody said, they did it. There need to be multiple credible sources indicating, Apple has decrypted phones protected by strong passwords. Without that, it couldn't be considered proof.
with the on die regulator, won't that area of the chip be a tad warmer than the rest of the chip, or will the heat be a moot point?
The summary says 76% efficiency. That would mean 24% of the energy you put into the chip is turned into heat by the voltage regulator. Sounds like a valid concern to me.
Since the default passcode is only 4 digits I would expect about 99% of users to be brute forcible in a few seconds to someone with the capability to image the device and identify the key storage block.
Sounds plausible. Someone in this thread said the number of iterations in the computation needed to get the key was chosen such that it takes 100ms for the phone. If we guess it can be done 10 times faster on a computer, it takes about a couple of minutes to try all 4 digit combinations. That is fast enough, that you wouldn't even bother with submitting it to a computing cluster.
A 4 digit pin is not completely worthless in scenarios, where limiting the number of attempts is possible. But once the pin can be attacked off-line, you need a lot more digits to justify the time spent implementing the encryption in the first place.
I don't know about the iPhone but Android lets you enter a password for encryption, not just a PIN.
If you were to go from just digits to alphanumeric characters you could reduce the number needed from 39 to 25 or even only 22, if it was case sensitive. But entering case sensitive passwords on a touch screen is annoying. So it would be much more convenient to enter the 25 characters needed to avoid that requirement. But seriously, typing such a long password is hard to get right every time, even if you are using a keyboard. Those small on screen keyboards do increase the error rate.
On my computer I do use a password with 130 bits of entropy. I made the password a bit longer than strictly needed, such that I could throw in a bit of error correcting code. That way a typo or two in the password doesn't prevent it from being recognized. It does mean I have 32 characters to type though, but typing 32 characters, where a couple of typos are allowed, seems easier than typing 22 where no errors are allowed.
I don't see myself using anything like that on my phone.
Apple claims that it uses AES with a 128 bit key, so if they can unlock it that quickly they MUST have a backdoor to the encryption key.
The input provided by the legitimate user for decrypting the content has way less than 128 bits of entropy. So they just need to brute force that input. What Apple can do, which the forensics people might not know how to do, is to extract the encrypted data and put it on a computer, where brute forcing can happen without each input having to be entered through a touch screen. Any security one might think this adds, is nothing but security-through-obscurity. Real security of the encryption could only be achieved by the user entering some sort of password with sufficient entropy. A 39 digit pin code would be sufficient to make AES be the weakest point. But would anybody use a 39 digit pin on their phone? Anything less would make the pin be easier to brute force than AES.
You can shift the balance a bit by iterating the calculation which produces a key from the pin code. A million iterations would probably be acceptable from a user experience perspective, but that would only reduce the required number of digits from 39 to 33. A milliard iterations would not be good for the user experience, since they now have to wait quite some time after entering a pin. And with the pin still needing to be 30 digits in length, they'll often need to re-enter it multiple times, before they get it right.
Slashdot Mirror
I was wondering about that as well. Might be they just couldn't add that feature to their system at such short notice. Alternatively it might be they are worried about the legal ramifications of such a change.
Turns out they are sort of doing that. You just have to change which country the account is registered in.
If the problem is caused by Google not being able to buy the correct kind of currency, couldn't they have offered to pay the developers in a different currency?
That is so true. It takes less than one minute to write a scanner, which never produces a false negative. But of course in that case it would produce false positives all the time.
The comment I was replying to, was implying it was a fact. Others have implied that as well, and I haven't seen anybody deny it. If you think they are wrong, you are welcome to present your argument, then I'll watch from the sideline until I know which side to believe.
Silk Road run a mixing service? I have only seen it presented as a market place for trading goods using bitcoins.
The fact that they can even tell the difference makes bitcoin less anonymous than physical money. Maybe the anonymity wasn't the selling point for bitcoin, maybe it rather was that they can be used without any regulation. Bitcoins can be used without regulation, but what you trade with bitcoins can still be regulated. That holds regardless if that something is goods or real currency. (The large focus on being able to exchange between bitcoin and real currency is a symptom telling us, that bitcoin is not yet a real currency. With a real currency you can have your income in that currency, and you don't worry about exchanging because you can also pay your expenses with that currency.)
The police aren't banning 3D printing. They're not banning the material used in 3D printing. They are banning 3D printed guns.
I see a problem with the police banning anything in the first place. That decision should be made by democratically elected lawmakers, not the police.
Didn't Token ring evolve into a star topology just like Ethernet did? If things had turned out differently, and we had all been using Token ring today, the only notable difference might very well have been the name. How many people actually remember, what Ethernet looked like back when the technology had any resemblance with the name?
Harm can be done by spreading such a search on facebook, if it isn't legitimate.
I would be much more willing to trust Google with my data than any new company showing up. Regardless of what the Internets are claiming, Google does not sell users' data.
Google earned my trust through their actual actions. If a new company want to earn my trust, they have to do the same. It is not hard to create a system, that I would rather trust with my data, than any of Google's systems. All it requires is a system, where it is technically impossible for the company behind to snoop my data. And the system has to be open enough, that those security properties can be independently verified by any third party, who wishes to do so.
I wouldn't trust a robot to do that job. On one occasion I have had to send a person to repair a drive, that was broken by a robot. A tape robot had literally ripped the front off a tape drive. Not only did that leave us with a broken drive, the piece was now stuck in the robots hand, and it wasn't able to get it out of its hand. So the robot gave up and drove up to the service area, waiting for a human to come and repair it.
This is not even the most spectacular robot problem I have experienced. Four years of dealing with real robots in data centers have made me realize, what a long way to go we have before robots can take over jobs we let humans do today.
I have never implied the press should receive special treatment. Anybody who finds a security problem should be free to publish it as they see fit (unless they have entered an agreement about confidentiality, before they found the problem). Of course the right thing to do is to tell the responsible people about it in private, such that they have a chance of fixing the issue before you go public. But that is a matter of ethical conduct, and should not be part of the law.
Companies who want time to fix issues before they become public should give something in return to those who find the problems.
The law of course should impose some limits on how you can legally abuse a security hole. Finding an SQL injection and dropping all tables from the database should not be legal. But perhaps finding an SQL injection and shutting down the database server before somebody else starts dropping tables should be legal. Using an SQL injection to have the database add up two numbers (just so you can verify that there is truly an SQL injection) should definitely be legal.
The law should be modified to ensure the following three properties:
All of this is only applicable when the security problem is found by an outsider. It is reasonable to apply different rules when the security hole is found by an insider. If the security problem is found by an insider, it is acceptable if the company try to keep the problem secret indefinitely. But it is still not acceptable to leave the vulnerability unpatched.
Sometimes the evidence itself is more important than the source. In the particular case, it sounds like the evidence was strong enough that it wouldn't matter which source it came from.
But the trend with threats and lawsuits against those, who discover security holes, must stop. That trend is a major threat against data security across the entire IT industry.
People will keep finding security holes. Sometimes you just stumple upon them, without even looking. What are you going to do, once you have found a security hole? Report it and try to get it fixed? Ignore it? Abuse it? If those who do the right thing are going to be the target of threats and lawsuits, that certainly removes incentive to do the right thing. So fewer people will report security holes. And some of those who would have reported it, might instead decide to abuse it.
If we ever get to the point where doing the right thing is more likely to get you into a lawsuit than abusing the security hole for personal gain is, then the industry is in big trouble.
Luckily a few companies are taking steps in the opposite direction and are offering cash rewards to those who find security holes. At some point users will have to start taking that into account when deciding what software to trust. But it is a very real problem, when the systems you don't trust are those used by any branch of government. You can't just go somewhere else. And the lack of competition has lead to situations where security concerns are just ignored.
Malware triggering on a specific time and date was common back in the days where the keyboard was the only input device on a typical PC, and even the fastest CPUs could not do signal processing in real time.
Back t hen It wasn't hard to trigger at a specific time, all it had to do was check the clock, which all PCs were equipped with. This sort of trigger was probably the first sort of trigger anybody came up with for a piece of malware.
There is no reason to come up with convoluted solutions involving signal processing, if what you want to do is trigger at a specific time.
How about 244 of them?
But that doesn't influence the probability of the fire starting in the first place. It isn't due to the fire department, that most people don't experience their house burning to the ground. Rather it is because a house being on fire doesn't happen that often. (For some reason this reminds me of a story involving a staple gun and 500kg of fireworks).
We can be almost certain, it was no coincidence. But at this point any statements about who was behind it is nothing more than speculation. Perhaps we'll never know for sure.
Yep. A proof would require a demonstration, that they actually extracted data from a phone, which was protected by a password with more entropy than can be brute forced. Moreover, it would not be sufficient that somebody said, they did it. There need to be multiple credible sources indicating, Apple has decrypted phones protected by strong passwords. Without that, it couldn't be considered proof.
What sort of construction reduce waste by adding cells?
The summary says 76% efficiency. That would mean 24% of the energy you put into the chip is turned into heat by the voltage regulator. Sounds like a valid concern to me.
Sounds plausible. Someone in this thread said the number of iterations in the computation needed to get the key was chosen such that it takes 100ms for the phone. If we guess it can be done 10 times faster on a computer, it takes about a couple of minutes to try all 4 digit combinations. That is fast enough, that you wouldn't even bother with submitting it to a computing cluster.
A 4 digit pin is not completely worthless in scenarios, where limiting the number of attempts is possible. But once the pin can be attacked off-line, you need a lot more digits to justify the time spent implementing the encryption in the first place.
If you were to go from just digits to alphanumeric characters you could reduce the number needed from 39 to 25 or even only 22, if it was case sensitive. But entering case sensitive passwords on a touch screen is annoying. So it would be much more convenient to enter the 25 characters needed to avoid that requirement. But seriously, typing such a long password is hard to get right every time, even if you are using a keyboard. Those small on screen keyboards do increase the error rate.
On my computer I do use a password with 130 bits of entropy. I made the password a bit longer than strictly needed, such that I could throw in a bit of error correcting code. That way a typo or two in the password doesn't prevent it from being recognized. It does mean I have 32 characters to type though, but typing 32 characters, where a couple of typos are allowed, seems easier than typing 22 where no errors are allowed.
I don't see myself using anything like that on my phone.
The input provided by the legitimate user for decrypting the content has way less than 128 bits of entropy. So they just need to brute force that input. What Apple can do, which the forensics people might not know how to do, is to extract the encrypted data and put it on a computer, where brute forcing can happen without each input having to be entered through a touch screen. Any security one might think this adds, is nothing but security-through-obscurity. Real security of the encryption could only be achieved by the user entering some sort of password with sufficient entropy. A 39 digit pin code would be sufficient to make AES be the weakest point. But would anybody use a 39 digit pin on their phone? Anything less would make the pin be easier to brute force than AES.
You can shift the balance a bit by iterating the calculation which produces a key from the pin code. A million iterations would probably be acceptable from a user experience perspective, but that would only reduce the required number of digits from 39 to 33. A milliard iterations would not be good for the user experience, since they now have to wait quite some time after entering a pin. And with the pin still needing to be 30 digits in length, they'll often need to re-enter it multiple times, before they get it right.
Might this mean we'd soon see an identd variant designed for helping with this issue?