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.

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)

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 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.

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.

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

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.

Im not clear how that would work. NFC is NFC. Apple pay / Google wallet should interoperate.