What is current GrapheneOS's security strength compared to iPhone circa 2016?

Intellectual2 The question in your thread title is overly vague and doesn't really make sense. Thread has been unlisted because it started getting answers about different things than what you actually seem to want to know.

Based on the post itself, what you're asking is about the security of encryption for a device that's at rest not security of the OS itself. GrapheneOS provides an auto-reboot feature for getting the device at rest automatically before an attacker has time to exploit it, especially without taking the risk of causing a reboot with a failed/detected exploit.

Please read https://grapheneos.org/faq#encryption which covers how the encryption is implemented. You don't need to worry about an attacker breaking the encryption itself. An attacker has to brute force the PIN/passphrase. For the iPhone case you bring up, the person had a low entropy PIN as their credential, which is not secure against a brute force itself but rather relies on anti-brute-force features provided by the device. Pixels and iPhones provide this with a secure element, requiring a sophisticated exploit to brute force even just a random 6 digit PIN. This is why a random 6 digit PIN provides secure encryption with Pixels and iPhones.

You can do better with a random passphrase. There's also hardware bound key derivation as the final phase of key derivation to prevent easily offloading brute forcing to a server farm instead of only doing it on the phone itself. If an attacker can exploit the secure element to bypass Weaver (aggressive throttling forcing 1 day between attempts after the initial ramp up) and can extract the hardware bound key from the SoC hardware, which is meant to be burned into silicon, then they can do a brute force on a server farm, in which case you want a strong random passphrase. Make it strong enough and it can't be brute forced. If you go as far as using 7 diceware words or 18 lowercase letters + numbers, then that's secure against any brute force itself. You can also go for something more convenient but less secure which relies on the key derivation work factor.

Worth noting encryption keys (derived key encryption keys and random disk encryption keys) are per-user-profile and encrypt the data within the profile. Owner (initial user) is special and sensitive OS data is encrypted inside the Owner profile data. This is the reason you must log into Owner before other users.

Nuttso 128-bit entropy is the standard value for extreme overkill that's secure far into the future. It doesn't really make sense to generate a random passphrase with more than 128-bit entropy. The amount of entropy is a different thing from the size of the derived key encryption key. The useful reason for security levels above 128-bit is because algorithms get broken in ways that substantially reduce their security. 256-bit cipher which experiences a quite extreme break can still end up providing more than 128-bit security, thus still preserving indefinitely overkill security in practice. This is why using AES256 instead of AES128 makes sense, but generating a 256-bit entropy passphrase / seed phrase which just gets fed into a key derivation algorithm to derive arbitrary length keys really doesn't make sense.

Significantly lower than 128-bit security is still considered secure and is just below the standard for extreme overkill that most people have settled on as making sense. Since passphrases go through key derivation adding a substantial work factor, passphrases with 90-bit entropy such as 7 diceword words or 18 lowercase letters/numbers are still highly secure and don't depend on hardware security features to prevent brute forcing. If you really want, you can raise that to 128-bit for extreme overkill but it is substantially more inconvenient and not really giving you real world benefits.

On the other hand, something like a 64-bit entropy passphrase is not secure against brute forcing if the attacker can bypass the hardware security features. Passphrases below around 90-bit entropy can still be secure if the secure element is compromised but if both the secure element and hardware bound key derivation are bypassed, there's a serious problem.

If the secure element isn't compromised, a random 6 digit PIN is secure against brute forcing. This is the kind of scenario in the original post where they exploit the OS and then need to exploit the secure element to bypass the brute forcing, leaving them needing a rare/sophisticated kind of exploit for the secure element firmware.

Graphite unwat

How is this timeout coded? Is it based on system time that can be manipulated with network time (NTP)?
Can law enforcement simply stand up a fake mobile network and spoof the time so that the OS always believes the timeout has not been reached?

It's based on a proper monotonic timer, not real time. Timers for intervals of time should never be based on real time. GrapheneOS also doesn't trust time from the cellular network and doesn't use unauthenticated NTP. One of the features provided by GrapheneOS is that we use HTTPS-based network time which provides authentication and also more precision than the AOSP approach to fetching time despite being HTTPS-based instead of NTP.

https://grapheneos.org/features#other-features

GrapheneOS
Thank you. Found this based on your explanation.
https://developer.android.com/reference/android/os/SystemClock

elapsedRealtime() and elapsedRealtimeNanos() return the time since the system was booted, and include deep sleep. This clock is guaranteed to be monotonic, and continues to tick even when the CPU is in power saving modes, so is the recommend basis for general purpose interval timing

I assume this is the clock used.

matchboxbananasynergy . If your second factor is not just a fingerprint but a combination of both a PIN and a fingerprint, you now have the resilience of an impossible to brute force password for when the phone is in BFU mode (7 word diceware passphrase) as well as a very secure yet easy way to unlock the phone in your everyday usage (6 digit PIN + fingerprint).

Independent of PIN+fingerprint as an option, what about having brief fingerprint-only unlocking with a timeout? So I could unlock with just a fingerprint for 90 seconds, then fingerprint & PIN until the reboot timer goes off.