Thats not just wrong, its hillariously wrong. "Destroying the earth" would require several hundred thousand very high yield nukes (1MT); there arent more than a bit over 10k in the world and the info I was able to find indicates theyre generally much smaller than 1MT (so, perhaps a million nukes to be sure).
Im not sure exactly how much uranium would be required for "several million 500kt nuclear warheads), but Im quite certain noone has that much.
~1500 multiple warhead weapons is still enough to blow up the world several times over
No, its not, not even remotely close. (figures taken from http://en.wikipedia.org/wiki/E...)
* Nuclear warheads have an area of destruction of some 180mi^2 (1MT, "destruction of buildings" = 6 miles).
* The US is 3,717,813 miles^2
* 3,717,813 / 180 = 20,000 1MT warheads to cover the US in "moderate destruction".
It gets better.
The world's land area is 57.53 million square miles. That means you need a hefty 320,000 1 MT (quite a large warhead, MUCH bigger than the ones we used at Nagasaki) warheads to "destroy the world". And you say we have that, several times over? My goodness, what countries are you supposing has that many? I had understood the US to have the most with some 6000, and other than western europe and Russia I didnt think anyone else had any. Dr Evil, perhaps?
Maybe you're talking about fallout, but thats not really what "destroy" means; a word like "contaminate" would be more accurate, if also much more vague.
Nukes dont actually scorch that big a patch of earth. I think theres some ~12k nukes on the earth, and if all of them were aimed perfectly spaced at the US I think you could take out most of the buildings in the US. Thats a far sight from destroying the world.
Dont know about the fallout though, that'd probably be pretty nasty.
Exactly, those log files you can parse in disaster scenarios are already binary, you just have a plethora of editors that understand a particular breed of binary called ASCII. Heck, a lot of the recovery process involves manipulating binary structures-- bootloader, boot sector, partition table, etc. We just have a lot of tools to handle these scenarios, and noone pays it much mind.
Theres no reason to think the core nix toolset wouldnt come to include tools for this new format.
Not being a primary *nix user I dont really have a horse in this race, but it really gets tiring hearing otherwise intelligent sysadmins complain about something that in technical terms is already the case. The only difference between "binary logs" and what you have now is semantics and a thing called ASCII. There is NO REASON a binary log format could not be as well documented and supported, particularly if it were a standard across all linux distros.
Good lord, mySQL uses "binary formats" but somehow it isnt an issue parsing them. Why do you suppose that is?
The issue is that 71% of RESPONDANTS said it was an issue.
You cant form any conclusion from that without knowing more information-- the size of the poll, whether people responded to other questions but not this one, etc.
I guess you now realize that's wrong. The main purpose of trim is to avoid reading and writing pages that are unused anyway. The SSD doesn't need to reallocate trimmed blocks, because the OS isn't using that data anyway. Less physical reading and writing == more endurance.
Its not wrong.
1) TRIM simply alerts the drive when a block is ready for erasure; its right there in the article I linked. Its primary purpose is not reallocation or anything else; its just garbage collection for performance reasons.
2) The endurance thing is ONLY if the firmware being used is using a hack to implement their own garbage collection which could induce write amplification. It does not, in itself, reduce endurance if the SSD isnt doing anything fancy / out-of-spec.
3) Reads have no impact whatsoever on endurance. Only write / erase cycles do-- hence why they quote 1000 P/E cycles (where P= program and E= erase)
Now that you've agreed with what I said (trim affects endurance, but in an application dependent way), are you ready to admit YOU had forgotten exactly what the tech does?
From the wikipedia article's opening paragraph: A Trim command (commonly typeset as TRIM) allows an operating system to inform a solid-state drive (SSD) which blocks of data are no longer considered in use and can be wiped internally.
From Anandtech....We run into these problems primarily because the drive doesn’t know when a file is deleted, only when one is overwritten. Thus we lose performance when we go to write a new file at the expense of maintaining lightning quick deletion speeds......There’s a command you may have heard of called TRIM. The command would require proper OS and drive support, but with it you could effectively let the OS tell the SSD to wipe invalid pages before they are overwritten.
The purpose of TRIM is performance-- NOT ENDURANCE. It has NOTHING TO DO WITH ENDURANCE except insofar as it replaces a manufacturer's proprietary and amplification-causing garbage collection. Older drives dont HAVE garbage collection, and TRIM does NOTHING for their endurance; all it does is eliminate the eventual performance crash.
You REALLY need to read up on TRIM, as you seem to not understand what it is that it does. To repeat: It does not have any effect on reallocations. It does scheduled erasures. If an erasure would cause a reallocation, that would happen regardless of whether it was during a scheduled TRIM, or during a "on-the-fly erase/write".
In disk encryption schemes, there is generally a header at the start of the disk, containing the disk's encryption key. This header is itself encrypted, with your passphrase.
This works because the actual encryption key never needs to change; if you ever need to change your encryption passphrase, the system will use your current passphrase to decrypt the existing AES key, will use your new passphrase to re-encrypt the AES key, and will write it back into the header. If you did not use this scheme and instead used the passphrase, you would have to reencrypt the entire disk whenever it changed.
Cracking the AES key would thus involve
1) Take an image of the entire disk
2) Pick a new passphrase to check.
a) Hash the passphrase
3) attempt to decrypt the header with the hashed passphrase from 2a
4) attempt to get valid data from the disk using the results of step 3
5) Do you have valid data?
--> Yes: You now have the correct passphrase and Key.
--> No: You have the wrong key, go to step 2 and continue.
A single iteration of steps 2-5 will depend on the exact algorithms and hashing schemes used. If for example no salt is used to generate the hash in step 2, and you use a single round of hashing / encryption, you could perform thousands or millions of attempts per second. I believe on the iPhone they shoot for ~0.2sec per attempt on iPhone hardware, which could mean several thousand attempts on a high-end workstation, and several million attempts on a large cluster.
A double post because I wanted to follow up on something.
I know you guys hate Apple,
I dont hate Apple. I think they are really good at many things, including user interface, and they make some fine products.
What I absolutely hate is the culture around their products that assumes that theyre always doing something new and different, and that anyone who doesnt think their products are magical is a naysayer. Full disk encryption is a problem that has been solved for 15-20 years now and everyone does it the same way, because that way works. The claim that Im getting it wrong when you apparently have NO IDEA what the threat model for attacking FDE is, is mind boggling.
Do you honestly think that Apple understands crypto better than the folks at Truecrypt, or dmcrypt / LUKS? That somehow their magical system makes them immune to attacks on the passphrase? Has it occurred to you that there can be threat models that are entirely dependent on the user, and no magical engineering on the part of Apple can possibly fix?
No, of course not; I point out a real world, well known way of attacking FDE, and clearly Im an Apple hater. Heres a news flash: Its a company that makes devices. I really do not care day to day what devices they make-- just dont try to tell me that theyve solved problems that noone else has managed to solve yet (like weak passphrases in encryption schemes) because they havent.
But do try to use your brain a little bit. Do you honestly believe that the flash storage is encrypted with a 4-digit numeric key? Of course it isn't, it's encrypted with a 256-bit AES key that's generated using a per-device hardware key and the passcode
Which is irrelevant, because that 256-bit AES key is stored ondisk in a header which is encrypted................ WITH THE 4 DIGIT PIN.
This is how EVERY SINGLE FDE WORKS. Apple isnt doing anything new, and if they are, you should be worried because getting security right is very hard. Whatever your PIN or passphrase is, it is fundamentally the thing that unlocks access to the device, no matter how much obfuscation you throw inbetween the input of that PIN and the process of decrypting the data. Any attack on your device will be focused on the PIN, as it will always be the weakest link in the chain.
Having worked with FDE solutions for years, I am well aware of how the "Passphrase-->AES key-->Data" process works, and its not foolproof if you use a weak passphrase. And the fun bit is, if your passphrase is shorter than ~10 characters mixed, you arent keeping law enforcement out.
You would uncouple the storage from the device physically. This could mean unsoldering the chips, or going in through a JTAG interface, or soldering a connection in, or any of a number of other ways.
There is an old axiom that has always been true. If you physically have possession of the hardware, you control the hardware. We learn this every console generation when people try to implement more and more Rube Goldbergesque methods of separating ownership of hardware from control, and fail each time.
Consider the possibility that the passcode protection could actually be enforced right down to the individual chip level,
Theres the controller (which you would remove, or disable said protection on), and theres the actual flash chips (which you would take an image of prior to doing anything whatsoever).
There are forensics tools for all of this, Im a little baffled that this is apparently news to people. If the cops get your hardware, there will be an image of the device and all of their bruteforcing will be done offline against said image-- not on your specially locked down hardware.
Then its a ton of handwaving that accomplishes nothing.
At the end of the day, no matter how many layers of obfuscation you add, there is a single passphrase at the backend that unlocks a primary master key that can get the rest of the directory keys. You accomplish nothing by using additional encryption keys for every directory; any bruteforce attack would focus on attacking the header which contains the master key.
Theres a reason that basically every FDE solution works this way.
If youre attempting to break into it, you wont do it using their input mechanism, you'll do an offline brute force which completely ignores failure wipe limits.
Step 1: Pull the storage Step 2: Image the storage Step 3: Attempt to bruteforce it offline Step 4: Wait 30 seconds Step 5: You now have the 4 digit PIN
There are not different keys for every file, or if there are they are tied to a master key. The only way you can view an encrypted device with a single passphrase is because that single passphrase is tied to a single master key somewhere.
To clarify, 100PB is a number I pulled out of thin air. On reflection, you would not expect your SSD to do 100PB of data; II simply meant that a number IS usually provided, and that those numbers have been validated by multiple parties as generally being ballpark accurate.
Slashdot Mirror
Perhaps you could clarify. Was I wrong in saying that ASCII is binary? Or that bootsectors / bootloaders / partition tables are?
AFAIK even hex-based structures are fundamentally binary, but perhaps you're using a different sort of processor than the rest of us.
Thats not just wrong, its hillariously wrong. "Destroying the earth" would require several hundred thousand very high yield nukes (1MT); there arent more than a bit over 10k in the world and the info I was able to find indicates theyre generally much smaller than 1MT (so, perhaps a million nukes to be sure).
Im not sure exactly how much uranium would be required for "several million 500kt nuclear warheads), but Im quite certain noone has that much.
~1500 multiple warhead weapons is still enough to blow up the world several times over
No, its not, not even remotely close.
(figures taken from http://en.wikipedia.org/wiki/E...)
* Nuclear warheads have an area of destruction of some 180mi^2 (1MT, "destruction of buildings" = 6 miles).
* The US is 3,717,813 miles^2
* 3,717,813 / 180 = 20,000 1MT warheads to cover the US in "moderate destruction".
It gets better.
The world's land area is 57.53 million square miles. That means you need a hefty 320,000 1 MT (quite a large warhead, MUCH bigger than the ones we used at Nagasaki) warheads to "destroy the world". And you say we have that, several times over? My goodness, what countries are you supposing has that many? I had understood the US to have the most with some 6000, and other than western europe and Russia I didnt think anyone else had any. Dr Evil, perhaps?
Maybe you're talking about fallout, but thats not really what "destroy" means; a word like "contaminate" would be more accurate, if also much more vague.
Nukes dont actually scorch that big a patch of earth. I think theres some ~12k nukes on the earth, and if all of them were aimed perfectly spaced at the US I think you could take out most of the buildings in the US. Thats a far sight from destroying the world.
Dont know about the fallout though, that'd probably be pretty nasty.
Exactly, those log files you can parse in disaster scenarios are already binary, you just have a plethora of editors that understand a particular breed of binary called ASCII. Heck, a lot of the recovery process involves manipulating binary structures-- bootloader, boot sector, partition table, etc. We just have a lot of tools to handle these scenarios, and noone pays it much mind.
Theres no reason to think the core nix toolset wouldnt come to include tools for this new format.
Binary logs.
Not being a primary *nix user I dont really have a horse in this race, but it really gets tiring hearing otherwise intelligent sysadmins complain about something that in technical terms is already the case. The only difference between "binary logs" and what you have now is semantics and a thing called ASCII. There is NO REASON a binary log format could not be as well documented and supported, particularly if it were a standard across all linux distros.
Good lord, mySQL uses "binary formats" but somehow it isnt an issue parsing them. Why do you suppose that is?
Luckily Moto G / Moto X / Nexus devices are all quite nice, cheap, unlocked, and will have support for a very long time.
With an Android device, the manufacturer outright abandons updating the phone the moment their next handset is on sale.
And then you say "screw it" and grab AOSP, and evaluate why you didnt get an unlocked non-contract phone like a motoG or nexus to begin with.
The issue is that 71% of RESPONDANTS said it was an issue.
You cant form any conclusion from that without knowing more information-- the size of the poll, whether people responded to other questions but not this one, etc.
I guess you now realize that's wrong. The main purpose of trim is to avoid reading and writing pages that are unused anyway. The SSD doesn't need to reallocate trimmed blocks, because the OS isn't using that data anyway. Less physical reading and writing == more endurance.
Its not wrong.
1) TRIM simply alerts the drive when a block is ready for erasure; its right there in the article I linked. Its primary purpose is not reallocation or anything else; its just garbage collection for performance reasons.
2) The endurance thing is ONLY if the firmware being used is using a hack to implement their own garbage collection which could induce write amplification. It does not, in itself, reduce endurance if the SSD isnt doing anything fancy / out-of-spec.
3) Reads have no impact whatsoever on endurance. Only write / erase cycles do-- hence why they quote 1000 P/E cycles (where P= program and E= erase)
Now that you've agreed with what I said (trim affects endurance, but in an application dependent way), are you ready to admit YOU had forgotten exactly what the tech does?
From the wikipedia article's opening paragraph:
A Trim command (commonly typeset as TRIM) allows an operating system to inform a solid-state drive (SSD) which blocks of data are no longer considered in use and can be wiped internally.
From Anandtech ....We run into these problems primarily because the drive doesn’t know when a file is deleted, only when one is overwritten. Thus we lose performance when we go to write a new file at the expense of maintaining lightning quick deletion speeds. .....There’s a command you may have heard of called TRIM. The command would require proper OS and drive support, but with it you could effectively let the OS tell the SSD to wipe invalid pages before they are overwritten.
The purpose of TRIM is performance-- NOT ENDURANCE. It has NOTHING TO DO WITH ENDURANCE except insofar as it replaces a manufacturer's proprietary and amplification-causing garbage collection. Older drives dont HAVE garbage collection, and TRIM does NOTHING for their endurance; all it does is eliminate the eventual performance crash.
You REALLY need to read up on TRIM, as you seem to not understand what it is that it does. To repeat: It does not have any effect on reallocations. It does scheduled erasures. If an erasure would cause a reallocation, that would happen regardless of whether it was during a scheduled TRIM, or during a "on-the-fly erase/write".
In disk encryption schemes, there is generally a header at the start of the disk, containing the disk's encryption key. This header is itself encrypted, with your passphrase.
This works because the actual encryption key never needs to change; if you ever need to change your encryption passphrase, the system will use your current passphrase to decrypt the existing AES key, will use your new passphrase to re-encrypt the AES key, and will write it back into the header. If you did not use this scheme and instead used the passphrase, you would have to reencrypt the entire disk whenever it changed.
Cracking the AES key would thus involve
1) Take an image of the entire disk
2) Pick a new passphrase to check.
a) Hash the passphrase
3) attempt to decrypt the header with the hashed passphrase from 2a
4) attempt to get valid data from the disk using the results of step 3
5) Do you have valid data?
--> Yes: You now have the correct passphrase and Key.
--> No: You have the wrong key, go to step 2 and continue.
A single iteration of steps 2-5 will depend on the exact algorithms and hashing schemes used. If for example no salt is used to generate the hash in step 2, and you use a single round of hashing / encryption, you could perform thousands or millions of attempts per second. I believe on the iPhone they shoot for ~0.2sec per attempt on iPhone hardware, which could mean several thousand attempts on a high-end workstation, and several million attempts on a large cluster.
A double post because I wanted to follow up on something.
I know you guys hate Apple,
I dont hate Apple. I think they are really good at many things, including user interface, and they make some fine products.
What I absolutely hate is the culture around their products that assumes that theyre always doing something new and different, and that anyone who doesnt think their products are magical is a naysayer. Full disk encryption is a problem that has been solved for 15-20 years now and everyone does it the same way, because that way works. The claim that Im getting it wrong when you apparently have NO IDEA what the threat model for attacking FDE is, is mind boggling.
Do you honestly think that Apple understands crypto better than the folks at Truecrypt, or dmcrypt / LUKS? That somehow their magical system makes them immune to attacks on the passphrase? Has it occurred to you that there can be threat models that are entirely dependent on the user, and no magical engineering on the part of Apple can possibly fix?
No, of course not; I point out a real world, well known way of attacking FDE, and clearly Im an Apple hater. Heres a news flash: Its a company that makes devices. I really do not care day to day what devices they make-- just dont try to tell me that theyve solved problems that noone else has managed to solve yet (like weak passphrases in encryption schemes) because they havent.
But do try to use your brain a little bit. Do you honestly believe that the flash storage is encrypted with a 4-digit numeric key? Of course it isn't, it's encrypted with a 256-bit AES key that's generated using a per-device hardware key and the passcode
Which is irrelevant, because that 256-bit AES key is stored ondisk in a header which is encrypted................ WITH THE 4 DIGIT PIN.
This is how EVERY SINGLE FDE WORKS. Apple isnt doing anything new, and if they are, you should be worried because getting security right is very hard. Whatever your PIN or passphrase is, it is fundamentally the thing that unlocks access to the device, no matter how much obfuscation you throw inbetween the input of that PIN and the process of decrypting the data. Any attack on your device will be focused on the PIN, as it will always be the weakest link in the chain.
Having worked with FDE solutions for years, I am well aware of how the "Passphrase-->AES key-->Data" process works, and its not foolproof if you use a weak passphrase. And the fun bit is, if your passphrase is shorter than ~10 characters mixed, you arent keeping law enforcement out.
You would uncouple the storage from the device physically. This could mean unsoldering the chips, or going in through a JTAG interface, or soldering a connection in, or any of a number of other ways.
There is an old axiom that has always been true. If you physically have possession of the hardware, you control the hardware. We learn this every console generation when people try to implement more and more Rube Goldbergesque methods of separating ownership of hardware from control, and fail each time.
Consider the possibility that the passcode protection could actually be enforced right down to the individual chip level,
Theres the controller (which you would remove, or disable said protection on), and theres the actual flash chips (which you would take an image of prior to doing anything whatsoever).
There are forensics tools for all of this, Im a little baffled that this is apparently news to people. If the cops get your hardware, there will be an image of the device and all of their bruteforcing will be done offline against said image-- not on your specially locked down hardware.
Then its a ton of handwaving that accomplishes nothing.
At the end of the day, no matter how many layers of obfuscation you add, there is a single passphrase at the backend that unlocks a primary master key that can get the rest of the directory keys. You accomplish nothing by using additional encryption keys for every directory; any bruteforce attack would focus on attacking the header which contains the master key.
Theres a reason that basically every FDE solution works this way.
Irrelevant in any case because if served with a warrant they would just capture your password and use it to decrypt your key.
The only way they cant do that is if the data were delivered to you, and the password were entered locally to decrypt the data.
If youre attempting to break into it, you wont do it using their input mechanism, you'll do an offline brute force which completely ignores failure wipe limits.
Step 1: Pull the storage
Step 2: Image the storage
Step 3: Attempt to bruteforce it offline
Step 4: Wait 30 seconds
Step 5: You now have the 4 digit PIN
and you forget the answer to your security question,
The presence of a security question on any service indicates immediately that they almost certainly have access if served with a warrant.
There are not different keys for every file, or if there are they are tied to a master key. The only way you can view an encrypted device with a single passphrase is because that single passphrase is tied to a single master key somewhere.
And I visualize this thread as being filled with more fact and less opinion, but somehow its not changing reality :(
Yea, you gotta be careful. 1 watt of absorbed energy might heat your tissue by up to 0.001 F.
Sadly the Google NFC implementation will eventually be seen as the irrelevant version,
Im not clear how that would work. NFC is NFC. Apple pay / Google wallet should interoperate.
They open offices overseas because theyre global companies, not because the US sucks. If the US sucked they wouldnt be headquartered here.
To clarify, 100PB is a number I pulled out of thin air. On reflection, you would not expect your SSD to do 100PB of data; II simply meant that a number IS usually provided, and that those numbers have been validated by multiple parties as generally being ballpark accurate.