GrapheneOS version 2024123000 released

Is this feature included in this release?

We're going to be adding a toggle for blocking the Play Integrity API in a way that acts as if the service is currently down. We've found that many apps do not correctly use it and still allow using the app if it's unavailable because their service only has soft enforcement of the Play Integrity API. It's possible this will be enough to get Revolut working but we don't know at this point. They're going out of the way to try banning using alternate OSes and can upgrade that over time.

https://grapheneos.social/@GrapheneOS/113737931425144006

Thanks

gos-users The method works by rolling dice to select words from a list, typically consisting of 7776 possible words. Examples of Diceware passphrases:

You have a word list with 7776 short simple nouns? Please share a link to it in that case. Because all word lists with 4000+ words I ever seen have adjectives and verbs too, and complicated words, and I found that to make the passphrases hard to visualize and remember.

I made my own prefix-free list with 1024 words, only short simple nouns, so exactly 10 bits of entropy per word. Easier to remember, even if I need to add one or two more words for same security level.

gos-users Mathematically, brute-forcing a 4-word passphrase would take considerable time, but with modern processing power, it’s not impractical. In contrast, a 7-word passphrase, due to its vastly larger keyspace, would be extremely hard to brute-force within a reasonable timeframe, even with a powerful attack.

Another option instead of considering timeframe is to calculate how much in electricity cost alone the attacker would have to pay to brute-force your passphrase. This has the advantage that we don't have to make assumptions about how much hardware the attacker has access to, which is hard in a world where compute power can be easily rented, including specialized hardware like ASICs. But whatever amount of hardware they have, whatever amount of time it takes to brute-force your passphrase, it will still cost them the same amount in electricity bill, because they cannot magically get access to more power-efficient hardware or algorithms than anyone else can get access to, so still consume the same amount of electricity per tried word combination. My impression is this method is preferable for high-risk threat models. You just need to select many words enough that the electricity alone would make it too expensive for your attacker to be able to or willing to pay to break into your specific device. Even for state actors it can get too expensive, tax payers might riot if too much money is "misplaced" to break into a single activist's phone.

https://tails.net/security/argon2id/index.en.html#comparison

Without trusting secure element throttling, GrapheneOS algorithm is comparable to PBKDF2 in that table from the link. GrapheneOS is using scrypt, but with so weak parameters they are comparable to PBKDF2. And their word list gives about 13 bits of entropy per word, so similar to the one you mentioned. Most people could easily afford to break a 4 word passphrase ($1 000), if they believe there is anything of value at all on your phone, but I cannot imagine even a state actor being able to pay the price for breaking a 7 word passphrase ($1 000 000 000 000 000). And these prices do not include rent cost or cost for hardware, it is electricity alone, so already have some margin. I remember having seen how they calculated the cost, but they took into account power consumption for ASIC hardware and powering RAM memory modules of large enough size, and some average cost of electricity at the time. I cannot find that page now.

gos-users The method works by rolling dice to select words from a list

Perfect high-quality dices. Lower quality ones might have bias because of production flaws that makes certain words much likelier to get selected. But better use the cryptographically secure random number generator on your computer, it doesn't have any such flaws. And the security for the encryption relies on it anyway, since the actual encryption key is generated. The passphrase is just used to wrap the encryption key.

https://blog.quarkslab.com/android-data-encryption-in-depth.html

gos-users I had already provided the EFF link, but here is the TXT file

Unfortunately there are adjectives and verbs in there, but thank you for sharing anyway. It is hard for me to visualize "concur" and "freely", but easy for me to visualize "fox" and "student". I keep to my own word list for now. Worst that can happen is if I forget my passphrase and permanently lose access to all my data.

that_guy I have been using https://github.com/passhelp/passhelp to generate passphrases & would be interested in your thoughts -- the wordlist uses 12dicts package's 3esl list and contains approximately 11.5k simple words, according to the documentation.

From src/generators/words.ts:

...,bird,birdseed,birth,birthday,...

This list is not prefix-free and thus not safe for password generation. In the sense that it is not possible to analyze the level of security the list provides. (Unless you yourself add a separator between each word, like a dash or space. But I usually don't have that, so rely on the list being prefix-free)

It also has a lot of adjective and verbs inflected in various ways, so from my perspective it would be hard to memorize passphrases generated using it, because adjectives and verbs cannot easily be visualized, certainly not their tense.

GrapheneOS
Awesome! I can confirm that the second factor PIN works like a charm on my Pixel 6a, Pixel 7 and Pixel tablet on 2024123000.
You have my gratitude!

Also; best wishes for 2025 to the GrapheneOS dev team and the forum members, have a good new year everyone!