“Next, even were these miracle workers able to find the HASH, it’s a one-way calculation. It is impossible to start with the HASH and, even if you have the algorithm that created it, to work it backwards, arrive at the seed value, the User’s passcode, from which it was created”
If you have the calculation the you could build a data base of pass codes to hashed results. Then reverse the hash to a pass code that works.
This is what Apple is fighting. Because the calculation would have to be released for any data used as evidence.
The algorithm(s), and I understand there are more than just one for making the HASHes, are burned into the silicon of the Encryption Engine and are also, like the HASH itself, not readable from outside the engine.
So, first you not only have to find a way to read the hidden, unreadable HASH, but you also have to figure which one of several top-secret and unknowable algorithms is the one randomly that was randomly burned onto the silicon of the that particular Encryption Engine when it was made—and Apple says like the Unique ID also burned onto the silicon, no records are kept anywhere of these data—then you have to use that unknowable algorithm(s) to build a data set of all possible passcode HASHes so you can compare the impossible to read one hidden inside a locked, unreadable secure location which you cannot probe or find to see if it matches? OK, I Got it. Pardon me if I snicker a bit.
No, Apple is fighting the idea that the FBI wants them to remove the passcode trial counter which after the fourth try, puts an ever increasing time between passcode tries, up to an hour before you can try again, and on the tenth failed passcode, erases the comparison HASH making it impossible to unlock the iPhone. The owner would then be required to restore his or her data from an iTunes or iCloud backup using their AppleID and password. . . and put in a new passcode.
You are correct that any method that gets around the barricades Apple has erected to prevent access would be subject to defense discovery if the evidence gained from cracking into an iOS device were used in trial. I posted that objection to being able to keeping the method secret two weeks ago on FreeRepublic and as far as I can tell I was first to point it out anywhere. Others picked it up from here days later.
I won't nit-pick with "reverse the hash", but effectively you are right. If you know the algorithm (generally published quite publicly, and for very good reason) and the hash, you can figure out the password that needs to be entered to match the hash though a "dictionary attack". Programs such as "cracklib" have been available for decades to do this, however this type of attack has become much less useful in the last 15-20 years (I hate being able to say such things, I'm NOT THAT OLD!) as we have stopped making the hash values so publicly available.
Swordmaker posted some very useful information on the internals of APPL's implementation here, last night
To be fair, this is not what Apple is fighting. Apple is fighting the creation of an OS that turns off the "ten tries then brick" option while the phone is still locked. The FBI also wants this new OS to also eliminate the wait period between three failed tries.
The FBI will then take this dumbed-down phone and just start at 0000 and work their way up until the phone unlocks. No need to reverse engineer the HASH.