A quick search found "SHA-1 hashing algorithm could succumb to $75K attack, researchers say" (08 Oct 15)
http://www.pcadvisor.co.uk/new...
"... US$75,000 and $120,000 to mount a viable attack using freely available cloud-computing services"
"... someone can create two different files that have the same hash, it's possible to digitally sign one"
Try searching for 75K or $75,000 by date and see what other public news can be found:)
Which doesn't allow a web site's certificate to be "cracked". The article is bogus.
The $75K-$120K figure is the estimated cost to find a SHA-1 hash collision. That is, to find two inputs that hash to the same value. The inputs will be random byte strings. Researchers have demonstrated that with such a collision it is possible to create two certificates that have the same signature, but in order to do that they also have to construct the RSA signing keys in a particular way.
But collisions do not enable the construction of fake certificates that appear to be signed by an arbitrary, unknown, private key. For that, you'd need to be able to find an input that hashes to a specific value. This is a completely different -- and dramatically harder -- problem than finding two inputs that hash to the same value. In addition, you'd probably need to find an input with a particular structure that hashes to a particular value, which is harder yet.
Good cryptographic hash functions have both "collision resistance" and "second pre-image resistance". SHA-1's collision resistance has been broken, which does make it insecure for certain uses, in algorithms that depend on collision resistance, but doesn't directly affect other uses -- like digital certificates -- that depend only on second pre-image resistance. It does hint that perhaps there is a weakness that may someday allow a second pre-image attack, which makes moving away from SHA-1 a good idea. But it has no direct impact on the security of CA certificates.
Tell you what though.... When the fin comes up near you when you are in the surf it doesn't matter how much you academically know it probably isn't interested in you it's terrifying.
I suppose. I've been swimming with sharks lots of times and didn't find it frightening, but I've always been under the water, not on the surface.
The reason those arguments don't work on actual people is based around what they can control.
Actually, I think that's just part of what makes the shark attack narrative compelling and "spectacular", to use the word I used before.
The other reason the argument from statistics fails is the same reason it fails with playing the lottery. Statistically, you shouldn't be afraid of sharks in "non-sharky" waters (you know, away from seal colonies, etc), and statistically, you shouldn't play the lottery, but you are and you do.
You do? I don't. Not unless the expected value exceeds the ticket price (which does occasionally happen in the big cumulative lotteries).
The shark defense field will serve the same purpose the TSA does today, giving people the false sense that humans have some modicum of control of the world around them.
But it won't, because in this case it will just reveal that there are more sharks out there than they realized.
The reason that shark attacks are rare isn't that sharks are rare, it's that they rarely attack people. So any properly-functioning shark detector is going to be sounding the alarm multiple times per day, at least. That's not going to make people feel safer about getting into the water.
In an ideal world the solution would be education. If people understand statistics they'll realize that they should be far more afraid of the drive to the beach or of drowning while swimming or surfing than of being attacked by a shark. The risks are orders of magnitude higher... and it's not like many far more common forms of death aren't equally gruesome and painful. They just aren't as newsworthy and our cavemen brains are wired to judge probability by the frequency with which we hear a story, and how spectacular it is.
A few years ago I saw a comedian on TV who was talking about watching Dr. Doolittle with his wife who happened to be a lawyer. When Dr. Doolittle's wife offered to defend him in a court case, the lawyer wife said "That would never happen in real life, the court would never let a spouse represent a defendant". The comedian responded with "Did you miss the part 5 minutes ago where they had a talking alligator?"
That makes for a good comedy sketch, but it's not a good counterargument to the wife's complaint.
Many stories include selected unlikely/impossible elements about which we intentionally suspend disbelief, but which we expect to be realistic in every other respect. We also accept other changes to reality that logically follow from the one we're choosing to accept, but there's no reason why the existence of a man who can talk to animals would be expected to affect a court's decision about conflicts of interest that arise from allowing a spouse to represent a defendant. So, the objection to the story is completely valid.
I'm sure there's a pithy phrase on TVTropes that describes this issue, but I'm not foolish enough to go looking for it. I have to get some work done today.
While the situation you describe sucks, and is a sleazy cost-saving meausure, it's completely different from what's being discussed. In your case, people were told to call 911, not security, but to do it with their cellphones rather than the office phones.
Learning to program really doesn't teach you anything about either how computers actually work, or what their limitations are.
It teaches you a lot about how they work.
Maybe we have different definitions of "how they work".
It's much better than a class that teaches Excel or Word
We're in complete agreement there. Teaching specific tools is pointless and a waste of everyone's time.
and not unreasonable
That I'm not so sure about, unless you're talking about really, really basic programming. My experience teaching kids to program has shown me that there is a non-trivial minority that really, really struggle with being able to think through a problem and write a program. It's not because they're stupid, either, it's just a certain form of difficulty with abstract reasoning. I don't know that there's any value in forcing them all through that.
I agree with you that programmers should know some EE stuff, and computability and information theory. I feel that is too advanced for high-school though.....if you wanted to teach CS in high school, it could be an AP class or something.
I don't think it is. Not the basic concepts, anyway. Broad strokes is all I'm looking for, not the details.
After more reflection, I don't think teaching programming is either necessary or sufficient.
Learning to program really doesn't teach you anything about either how computers actually work, or what their limitations are. I think a little bit of exposure to the EE stuff is needed, and some exposure to key bits of information theory and computability theory. With respect to information theory, I think everyone should have at least a basic understanding of encoding, entropy and compressibility, and of limits on information transfer (Shannon, Nyquist, etc.), though it needn't be presented in its fully theoretical glory. With respect to computability, I think everyone should understand the idea that some problems are infeasible because they would require impossibly enormous amounts of computation, and that some problems are impossible, period.
I think teaching some basic programming constructs is necessary, to explain how complex logic can be constructed from arithmetic plus conditional branching. But I think the visual programming with blocks provided by the Hour of Code site is good enough for that.
My guess is that if given a directive to teach "computer science" to all students, many schools will interpret that as "teach kids how to use a computer", meaning teach them to use e-mail, a spreadsheet, etc., plus maybe some "coding" (HTML). This seems to be what is in the "computer technology" classes my kids were forced into.
Those seem like garbage classes to me.
But... what should all people with a basic general education know about computer science?
Programming? It wouldn't be bad, I suppose, but it seems overkill. The fundamentals of how a computer works seems like a good idea, the major pieces and parts. What I think would be really valuable is a basic understanding of what computers cannot do. A little information theory, maybe? Should that be part of a math class? As a security guy, I'd really like the general populace to understand entropy and randomness as they relate to passwords and other user authenticators, and something about how computer security really works... what a vulnerability, what is an exploit, what is a virus, what is malware, etc.
What do you think an average high school graduate know about computer science and technology?
Note that I'm not calling you crazy; I like the 9mm, and in fact my everyday carry is a 9mm (XD9SC). But I can't see any way that the 9mm can do more damage than a.45. The.45 is only slightly bigger, but it *is* bigger, and so should produce a larger wound channel. It's slower, but with FMJ it still has plenty of penetration; like the 9mm in FMJ it's prone to overpenetration.
So, I'd really like to see the numbers. Googling turns up lots of flamewars but precious little data.
If the password is weak enough that you can search the space just by entering values, then there's really not much that can be done at present. My "dump the flash" approach is for when that can't work because the space is too large for it to be practical and you need something faster. Prior to Lollipop you could simply obtain the crypto footer then fire up a whole bunch of machines to search the password space in parallel.
The new TEE-based Gatekeepr password authentication app (introduced in M) offers a better way. It implements exponentially-increasing delays between allowed password attempts. I think the slope is too gentle, but it's steep enough that you're unlikely to get more than a couple hundred attempts, and that will take you months. Unfortunately it's not used to protect disk encryption in M (long story).
Thanks for taking the time to reply with such a reply response.
> Actually, I wrote chunks of that code, and work with the guys who wrote the rest, so I know *exactly* how the key is generated.
In that case perhaps you can clarify whether I'm misunderstanding or just didn't communicate clearly. My understanding is:
The symmetric AES key is generated ~once, then that key is encrypted based on the password or pattern.
It's generated once when the file system is first encrypted, yes.
By the time an end-user is using the device, the key has -already- been generated (or may have been).
May have been, but generally isn't. Usually the first time a device is booted is when the customer turns it on. Key generation and encryption happens at that point in time. This used to be a usability problem because dm-crypt didn't distinguish between in-use and unused blocks, which meant that when the user first turned on a device with on-by-default encryption, they immediately had to wait several minutes for the device to encrypt a whole bunch of empty space before they could use it. We fixed that so it only encrypts in-use blocks, and since there are very few of those on a new device, it's fast.
A related problem is the fact that the key is generated very early during first boot, when/dev/random's pool hasn't accumulated much entropy. So we do in fact end up leaning more heavily on the hardware RNG than I'd like.
Therefore the binary will not generate a new key, because it's already there in the footer.
Therefore even if the binary matches the source - it won't generate a key from/dev/urandom because the key is already there.
Therefore even if we knew that the binary matches the source, we don't know how the (pre-existing) key was generated.
In other words, everything about generating the key is conditional on there not already being a key. IF an OEM put a bad key in the footer, it would stay there.
I suppose, though I've never seen any evidence of OEMs shipping devices with keys in the footer at all.
If you want to fix this, though, there's a very easy way: Just factory-reset the device. That wipes all user data, including the crypto footer, so on next boot a new key will be generated. You can validate that this happened by looking at logcat.
On a somewhat different topic, it's nice to meet someone will similar interests. I don't really remember names on Slashdot, don't remember who said what. I don't know if you've noticed I post a lot on information security since that's what I've been doing for fifteen years.
I don't notice names so much, either. I post quite a bit on topics related to information security, and especially crypto. Though lately it seems like I post more corrections of erroneous assumptions/beliefs about Google than anything else. I should probably stop doing that.
Feel free to shoot me a message sometime if you ever care to - if you're looking for a job in the Dallas, Houston, Denver, or Cardfiff areas,
I'm quite happy at Google, but thanks.
or if you have an open source project that could use an extra hand.
Keyczar could use some assistance. https://github.com/google/keyc.... Theoretically I'm the lead maintainer, though I cringe to say that given how little time I put into it.
So, the ad blocker would have to actually recognize ad content in order to block it. Including in images.
Ah, yes? That is what I was talking about? You think this is in any way difficult to do? (Caveat: I have specific experience in that area. It is not.)
I notice you deleted my captcha-ad notion. No response to that? I'm also skeptical that it's as easy as you claim to recognize advertising content.
Then, there's the ultimate option: Forget advertising and just paywall.
That has worked well in the past. Because it usually makes customers just go nuclear on the site and decide that they do not need it after all.
Sure, because there have been advertising-supported alternatives, and people prefer to pay with their eyeballs rather than money. But if everyone uses ad blockers, that won't be happening, so there won't be quality free alternatives.
Can be blocked, but needs some coordination. My AV updates every few hours, why not my ad-blocker too? _That_ service I would pay for.
It would be easy to make every single ad URL unique, one-time, and to make patterns of real page/image URLs be indistinguishable. It'd be harder -- but possible -- to have the page rearrange content and ads rearranged on every page load.
So, the ad blocker would have to actually recognize ad content in order to block it. Including in images.
Oh, and then there's also the option of interstitial ads which require user interaction, perhaps clicking on a certain region of an image map. Captcha combined with advertising.
There are lots of other options, up to and including what is effectively DRM for web content, which serves not to protect copying but to ensure that the site can't be shown in anything but an authorized non-ad-blocking browser. Like all DRM, it could be broken, but it could be made hard enough and changed often enough so that ad blockers always lag.
Then, there's the ultimate option: Forget advertising and just paywall.
What you say is only true if ads include Javascript, and are not validated to ensure they don't access cookies. Google won't do it, but not because it's not possible to do safely.
There is absolutely no way Google or anyone else can change that
Smaller ad networks might not be able to, but Google probably could. Imagine if Google ran their ads, with encoded scripts and links, through their other domains at random. Your only choice then would be to completely block Google, which would break many sites that use their hosted scripts and content, or put up with some ads. Google hasn't done this yet because an anti-adblock arms race would be both costly and a public relations disaster. It's not yet worth it for Google to push the nuclear button on ad blockers, but that day may yet come if things keep going the way that they are.
Nah, there's a better option, if the ad networks (any of them, not just Google) wanted to go nuclear. The nuclear option is to serve the ads from the same site serving the content. Visit the NY Times? All of the ads are served from their servers. It would take a little work to allow the ad network to still do the targeting, and some to make it difficult for sites to misreport impression counts, or clicks if the ad target URL is also a redirect hosted on the same site, to avoid ad blockers filtering based on target. But it could be done.
They have published some code which they say is used to generate the initial master key. They are probably telling the truth, but there's no way to know - they master key looks like random bits.
Actually, I wrote chunks of that code, and work with the guys who wrote the rest, so I know *exactly* how the key is generated. The master key is generated on line 1497, by reading 32 bytes from/dev/urandom. If you'd like, you can also go verify that the Android random number generator is the standard Linux RNG, unmodified (I have, but don't trust me). Then you can verify that the RNG is fed the normal stuff... network packets, user input data, etc. On devices that have one (most, these days), it's also fed by the CPU's hardware random number generator. We're careful not to trust the hardware too much, though.
Of course, as with any software delivered in binary form, it's always possible that the binary wasn't actually built from the provided source. For that matter, excepting Nexus devices, even Google can't know for sure that the OEMs didn't modify the code before building it. However, you can compile the source yourself and then compare the resulting binaries with the shipped binaries... it's not that hard, and it's been done. Or if you want to work a little harder, you can take the shipped binaries and decompile them to compare with the source.
Verification isn't trivial, but it has been done, and I'm sure you'll note the distinct lack of security conference talks on the differences between the source and shipped binaries. That's because there's no interesting story there.
Or if you only care about protecting yourself, you can simply buy an unlockable phone and compile the binaries yourself. To be really certain, I recommend that you modify the source so that rather than generating a random master key on-device you hard-code one that you generated elsewhere (perhaps by rolling dice). Then, after you've got that key installed in the crypto footer, you can swap out the binary for one that won't generate a new key (and doesn't contain your hand-rolled key). Oh, and you should probably not install radio firmware. That makes the "phone" significantly less useful, but the radio firmware is a big binary blob with deep access in the system. In Lollipop and Marshmallow it's fairly strongly walled off with SELinux, but while that's useful, it's not a guarantee.
Please note the existing vulnerabilities in the encryption process, though. Conveniently enough, I wrote about them just this morning: http://slashdot.org/comments.p.... The upshot is that if you want security you should use a good password, otherwise no matter how nicely random the master key is, your password could still be brute forced.
Also note that a sufficiently-capable attacker (like a nation state's intelligence agencies) can still get through all of it, unless your password is really, really long. If the NSA is your adversary, I recommend using a password with at least 70 bits of entropy, and keeping your phone turned off most of the time. I also recommend not knowing your password, to defeat rubber-hose cryptanalysis.
That's odd, because LG has their DRM stuff right where anyone can find it using something like Total Commander. It isn't hidden in some secret OS, it is right in the root directory of Android. Ditto on Samsung devices. It's probably not wise to muck with said files, but there they sit.
No, they don't. Those are only the Android components that communicate with the trusted OS to do the actual decryption, using keys that are not available to the Android OS. If you remove or muck with the Android components, you'll make DRM-protected video undecryptable, but that doesn't mean they're what is actually doing the decryption.
This is technically possible IF Apple and Google are lying about how the symmetric key itself is generated and stored.
The passcode is used to secure the "real" key, which is used for data encryption. This symmetric key is supposedly not predictable or retrievable. However, it could in fact be the output of crypt('$1$hfgfydhjd$', imei + masterkey)
That would allow anyone who knows the imei and master key to derive the symmetric key.
One of the conditions that Google should be forcing RIGHT NOW is that manufacturers (and carriers) must provide a mechanism to allow updating the operating system (or to replace it entirely).
That mechanism exists, and has existed, and has been mandated, for years.
The challenge is getting manufacturers and carriers to use it.
Slashdot Mirror
A quick search found "SHA-1 hashing algorithm could succumb to $75K attack, researchers say" (08 Oct 15) http://www.pcadvisor.co.uk/new... "... US$75,000 and $120,000 to mount a viable attack using freely available cloud-computing services" "... someone can create two different files that have the same hash, it's possible to digitally sign one" Try searching for 75K or $75,000 by date and see what other public news can be found :)
Which doesn't allow a web site's certificate to be "cracked". The article is bogus.
The $75K-$120K figure is the estimated cost to find a SHA-1 hash collision. That is, to find two inputs that hash to the same value. The inputs will be random byte strings. Researchers have demonstrated that with such a collision it is possible to create two certificates that have the same signature, but in order to do that they also have to construct the RSA signing keys in a particular way.
But collisions do not enable the construction of fake certificates that appear to be signed by an arbitrary, unknown, private key. For that, you'd need to be able to find an input that hashes to a specific value. This is a completely different -- and dramatically harder -- problem than finding two inputs that hash to the same value. In addition, you'd probably need to find an input with a particular structure that hashes to a particular value, which is harder yet.
Good cryptographic hash functions have both "collision resistance" and "second pre-image resistance". SHA-1's collision resistance has been broken, which does make it insecure for certain uses, in algorithms that depend on collision resistance, but doesn't directly affect other uses -- like digital certificates -- that depend only on second pre-image resistance. It does hint that perhaps there is a weakness that may someday allow a second pre-image attack, which makes moving away from SHA-1 a good idea. But it has no direct impact on the security of CA certificates.
Tell you what though.... When the fin comes up near you when you are in the surf it doesn't matter how much you academically know it probably isn't interested in you it's terrifying.
I suppose. I've been swimming with sharks lots of times and didn't find it frightening, but I've always been under the water, not on the surface.
The reason those arguments don't work on actual people is based around what they can control.
Actually, I think that's just part of what makes the shark attack narrative compelling and "spectacular", to use the word I used before.
The other reason the argument from statistics fails is the same reason it fails with playing the lottery. Statistically, you shouldn't be afraid of sharks in "non-sharky" waters (you know, away from seal colonies, etc), and statistically, you shouldn't play the lottery, but you are and you do.
You do? I don't. Not unless the expected value exceeds the ticket price (which does occasionally happen in the big cumulative lotteries).
The shark defense field will serve the same purpose the TSA does today, giving people the false sense that humans have some modicum of control of the world around them.
But it won't, because in this case it will just reveal that there are more sharks out there than they realized.
Must. Not. Click.
The reason that shark attacks are rare isn't that sharks are rare, it's that they rarely attack people. So any properly-functioning shark detector is going to be sounding the alarm multiple times per day, at least. That's not going to make people feel safer about getting into the water.
In an ideal world the solution would be education. If people understand statistics they'll realize that they should be far more afraid of the drive to the beach or of drowning while swimming or surfing than of being attacked by a shark. The risks are orders of magnitude higher... and it's not like many far more common forms of death aren't equally gruesome and painful. They just aren't as newsworthy and our cavemen brains are wired to judge probability by the frequency with which we hear a story, and how spectacular it is.
A few years ago I saw a comedian on TV who was talking about watching Dr. Doolittle with his wife who happened to be a lawyer. When Dr. Doolittle's wife offered to defend him in a court case, the lawyer wife said "That would never happen in real life, the court would never let a spouse represent a defendant". The comedian responded with "Did you miss the part 5 minutes ago where they had a talking alligator?"
That makes for a good comedy sketch, but it's not a good counterargument to the wife's complaint.
Many stories include selected unlikely/impossible elements about which we intentionally suspend disbelief, but which we expect to be realistic in every other respect. We also accept other changes to reality that logically follow from the one we're choosing to accept, but there's no reason why the existence of a man who can talk to animals would be expected to affect a court's decision about conflicts of interest that arise from allowing a spouse to represent a defendant. So, the objection to the story is completely valid.
I'm sure there's a pithy phrase on TVTropes that describes this issue, but I'm not foolish enough to go looking for it. I have to get some work done today.
It can be.
While the situation you describe sucks, and is a sleazy cost-saving meausure, it's completely different from what's being discussed. In your case, people were told to call 911, not security, but to do it with their cellphones rather than the office phones.
Learning to program really doesn't teach you anything about either how computers actually work, or what their limitations are.
It teaches you a lot about how they work.
Maybe we have different definitions of "how they work".
It's much better than a class that teaches Excel or Word
We're in complete agreement there. Teaching specific tools is pointless and a waste of everyone's time.
and not unreasonable
That I'm not so sure about, unless you're talking about really, really basic programming. My experience teaching kids to program has shown me that there is a non-trivial minority that really, really struggle with being able to think through a problem and write a program. It's not because they're stupid, either, it's just a certain form of difficulty with abstract reasoning. I don't know that there's any value in forcing them all through that.
I agree with you that programmers should know some EE stuff, and computability and information theory. I feel that is too advanced for high-school though.....if you wanted to teach CS in high school, it could be an AP class or something.
I don't think it is. Not the basic concepts, anyway. Broad strokes is all I'm looking for, not the details.
After more reflection, I don't think teaching programming is either necessary or sufficient.
Learning to program really doesn't teach you anything about either how computers actually work, or what their limitations are. I think a little bit of exposure to the EE stuff is needed, and some exposure to key bits of information theory and computability theory. With respect to information theory, I think everyone should have at least a basic understanding of encoding, entropy and compressibility, and of limits on information transfer (Shannon, Nyquist, etc.), though it needn't be presented in its fully theoretical glory. With respect to computability, I think everyone should understand the idea that some problems are infeasible because they would require impossibly enormous amounts of computation, and that some problems are impossible, period.
I think teaching some basic programming constructs is necessary, to explain how complex logic can be constructed from arithmetic plus conditional branching. But I think the visual programming with blocks provided by the Hour of Code site is good enough for that.
There's no better way to understand how a computer works, and its limitations, than actually programming it.
Sure, programming is sufficient, but is it necessary?
Why should an average high school graduate know how to program?
My guess is that if given a directive to teach "computer science" to all students, many schools will interpret that as "teach kids how to use a computer", meaning teach them to use e-mail, a spreadsheet, etc., plus maybe some "coding" (HTML). This seems to be what is in the "computer technology" classes my kids were forced into.
Those seem like garbage classes to me.
But... what should all people with a basic general education know about computer science?
Programming? It wouldn't be bad, I suppose, but it seems overkill. The fundamentals of how a computer works seems like a good idea, the major pieces and parts. What I think would be really valuable is a basic understanding of what computers cannot do. A little information theory, maybe? Should that be part of a math class? As a security guy, I'd really like the general populace to understand entropy and randomness as they relate to passwords and other user authenticators, and something about how computer security really works... what a vulnerability, what is an exploit, what is a virus, what is malware, etc.
What do you think an average high school graduate know about computer science and technology?
Cite? Note that FBI and law enforcement tests don't address the military's needs, since the military uses ball ammo, not hollowpoints.
Cite?
Note that I'm not calling you crazy; I like the 9mm, and in fact my everyday carry is a 9mm (XD9SC). But I can't see any way that the 9mm can do more damage than a .45. The .45 is only slightly bigger, but it *is* bigger, and so should produce a larger wound channel. It's slower, but with FMJ it still has plenty of penetration; like the 9mm in FMJ it's prone to overpenetration.
So, I'd really like to see the numbers. Googling turns up lots of flamewars but precious little data.
If the password is weak enough that you can search the space just by entering values, then there's really not much that can be done at present. My "dump the flash" approach is for when that can't work because the space is too large for it to be practical and you need something faster. Prior to Lollipop you could simply obtain the crypto footer then fire up a whole bunch of machines to search the password space in parallel.
The new TEE-based Gatekeepr password authentication app (introduced in M) offers a better way. It implements exponentially-increasing delays between allowed password attempts. I think the slope is too gentle, but it's steep enough that you're unlikely to get more than a couple hundred attempts, and that will take you months. Unfortunately it's not used to protect disk encryption in M (long story).
Thanks for taking the time to reply with such a reply response.
> Actually, I wrote chunks of that code, and work with the guys who wrote the rest, so I know *exactly* how the key is generated.
In that case perhaps you can clarify whether I'm misunderstanding or just didn't communicate clearly. My understanding is:
The symmetric AES key is generated ~once, then that key is encrypted based on the password or pattern.
It's generated once when the file system is first encrypted, yes.
By the time an end-user is using the device, the key has -already- been generated (or may have been).
May have been, but generally isn't. Usually the first time a device is booted is when the customer turns it on. Key generation and encryption happens at that point in time. This used to be a usability problem because dm-crypt didn't distinguish between in-use and unused blocks, which meant that when the user first turned on a device with on-by-default encryption, they immediately had to wait several minutes for the device to encrypt a whole bunch of empty space before they could use it. We fixed that so it only encrypts in-use blocks, and since there are very few of those on a new device, it's fast.
A related problem is the fact that the key is generated very early during first boot, when /dev/random's pool hasn't accumulated much entropy. So we do in fact end up leaning more heavily on the hardware RNG than I'd like.
Therefore the binary will not generate a new key, because it's already there in the footer.
Therefore even if the binary matches the source - it won't generate a key from /dev/urandom because the key is already there.
Therefore even if we knew that the binary matches the source, we don't know how the (pre-existing) key was generated.
In other words, everything about generating the key is conditional on there not already being a key. IF an OEM put a bad key in the footer, it would stay there.
I suppose, though I've never seen any evidence of OEMs shipping devices with keys in the footer at all.
If you want to fix this, though, there's a very easy way: Just factory-reset the device. That wipes all user data, including the crypto footer, so on next boot a new key will be generated. You can validate that this happened by looking at logcat.
On a somewhat different topic, it's nice to meet someone will similar interests. I don't really remember names on Slashdot, don't remember who said what. I don't know if you've noticed I post a lot on information security since that's what I've been doing for fifteen years.
I don't notice names so much, either. I post quite a bit on topics related to information security, and especially crypto. Though lately it seems like I post more corrections of erroneous assumptions/beliefs about Google than anything else. I should probably stop doing that.
Feel free to shoot me a message sometime if you ever care to - if you're looking for a job in the Dallas, Houston, Denver, or Cardfiff areas,
I'm quite happy at Google, but thanks.
or if you have an open source project that could use an extra hand.
Keyczar could use some assistance. https://github.com/google/keyc.... Theoretically I'm the lead maintainer, though I cringe to say that given how little time I put into it.
So, the ad blocker would have to actually recognize ad content in order to block it. Including in images.
Ah, yes? That is what I was talking about? You think this is in any way difficult to do? (Caveat: I have specific experience in that area. It is not.)
I notice you deleted my captcha-ad notion. No response to that? I'm also skeptical that it's as easy as you claim to recognize advertising content.
Then, there's the ultimate option: Forget advertising and just paywall.
That has worked well in the past. Because it usually makes customers just go nuclear on the site and decide that they do not need it after all.
Sure, because there have been advertising-supported alternatives, and people prefer to pay with their eyeballs rather than money. But if everyone uses ad blockers, that won't be happening, so there won't be quality free alternatives.
Can be blocked, but needs some coordination. My AV updates every few hours, why not my ad-blocker too? _That_ service I would pay for.
It would be easy to make every single ad URL unique, one-time, and to make patterns of real page/image URLs be indistinguishable. It'd be harder -- but possible -- to have the page rearrange content and ads rearranged on every page load.
So, the ad blocker would have to actually recognize ad content in order to block it. Including in images.
Oh, and then there's also the option of interstitial ads which require user interaction, perhaps clicking on a certain region of an image map. Captcha combined with advertising.
There are lots of other options, up to and including what is effectively DRM for web content, which serves not to protect copying but to ensure that the site can't be shown in anything but an authorized non-ad-blocking browser. Like all DRM, it could be broken, but it could be made hard enough and changed often enough so that ad blockers always lag.
Then, there's the ultimate option: Forget advertising and just paywall.
What you say is only true if ads include Javascript, and are not validated to ensure they don't access cookies. Google won't do it, but not because it's not possible to do safely.
There is absolutely no way Google or anyone else can change that
Smaller ad networks might not be able to, but Google probably could. Imagine if Google ran their ads, with encoded scripts and links, through their other domains at random. Your only choice then would be to completely block Google, which would break many sites that use their hosted scripts and content, or put up with some ads. Google hasn't done this yet because an anti-adblock arms race would be both costly and a public relations disaster. It's not yet worth it for Google to push the nuclear button on ad blockers, but that day may yet come if things keep going the way that they are.
Nah, there's a better option, if the ad networks (any of them, not just Google) wanted to go nuclear. The nuclear option is to serve the ads from the same site serving the content. Visit the NY Times? All of the ads are served from their servers. It would take a little work to allow the ad network to still do the targeting, and some to make it difficult for sites to misreport impression counts, or clicks if the ad target URL is also a redirect hosted on the same site, to avoid ad blockers filtering based on target. But it could be done.
They have published some code which they say is used to generate the initial master key. They are probably telling the truth, but there's no way to know - they master key looks like random bits.
Actually, I wrote chunks of that code, and work with the guys who wrote the rest, so I know *exactly* how the key is generated. The master key is generated on line 1497, by reading 32 bytes from /dev/urandom. If you'd like, you can also go verify that the Android random number generator is the standard Linux RNG, unmodified (I have, but don't trust me). Then you can verify that the RNG is fed the normal stuff... network packets, user input data, etc. On devices that have one (most, these days), it's also fed by the CPU's hardware random number generator. We're careful not to trust the hardware too much, though.
Of course, as with any software delivered in binary form, it's always possible that the binary wasn't actually built from the provided source. For that matter, excepting Nexus devices, even Google can't know for sure that the OEMs didn't modify the code before building it. However, you can compile the source yourself and then compare the resulting binaries with the shipped binaries... it's not that hard, and it's been done. Or if you want to work a little harder, you can take the shipped binaries and decompile them to compare with the source.
Verification isn't trivial, but it has been done, and I'm sure you'll note the distinct lack of security conference talks on the differences between the source and shipped binaries. That's because there's no interesting story there.
Or if you only care about protecting yourself, you can simply buy an unlockable phone and compile the binaries yourself. To be really certain, I recommend that you modify the source so that rather than generating a random master key on-device you hard-code one that you generated elsewhere (perhaps by rolling dice). Then, after you've got that key installed in the crypto footer, you can swap out the binary for one that won't generate a new key (and doesn't contain your hand-rolled key). Oh, and you should probably not install radio firmware. That makes the "phone" significantly less useful, but the radio firmware is a big binary blob with deep access in the system. In Lollipop and Marshmallow it's fairly strongly walled off with SELinux, but while that's useful, it's not a guarantee.
Please note the existing vulnerabilities in the encryption process, though. Conveniently enough, I wrote about them just this morning: http://slashdot.org/comments.p.... The upshot is that if you want security you should use a good password, otherwise no matter how nicely random the master key is, your password could still be brute forced.
Also note that a sufficiently-capable attacker (like a nation state's intelligence agencies) can still get through all of it, unless your password is really, really long. If the NSA is your adversary, I recommend using a password with at least 70 bits of entropy, and keeping your phone turned off most of the time. I also recommend not knowing your password, to defeat rubber-hose cryptanalysis.
That's odd, because LG has their DRM stuff right where anyone can find it using something like Total Commander. It isn't hidden in some secret OS, it is right in the root directory of Android. Ditto on Samsung devices. It's probably not wise to muck with said files, but there they sit.
No, they don't. Those are only the Android components that communicate with the trusted OS to do the actual decryption, using keys that are not available to the Android OS. If you remove or muck with the Android components, you'll make DRM-protected video undecryptable, but that doesn't mean they're what is actually doing the decryption.
The "simulated universe" "theory" is a joke. Real computers occupy 3 dimensions
At least, simulated real computers occupy 3 simulated dimensions.
This is technically possible IF Apple and Google are lying about how the symmetric key itself is generated and stored.
The passcode is used to secure the "real" key, which is used for data encryption. This symmetric key is supposedly not predictable or retrievable. However, it could in fact be the output of crypt('$1$hfgfydhjd$', imei + masterkey)
That would allow anyone who knows the imei and master key to derive the symmetric key.
For Android, the code you're wondering about is all open source. Go take a look: https://android.googlesource.c...
One of the conditions that Google should be forcing RIGHT NOW is that manufacturers (and carriers) must provide a mechanism to allow updating the operating system (or to replace it entirely).
That mechanism exists, and has existed, and has been mandated, for years.
The challenge is getting manufacturers and carriers to use it.