Molly.im

Nuttso

Molly’s remote attestation concept

At its core, Molly’s remote attestation is about verifying the person on the other end by verifying their device. When both people turn it on, each phone proves that Molly is running on that device with the operating system in a known-good state. It’s built on Android’s hardware-backed key attestation and Verified Boot, the same chain of trust that controls whether a Pixel will even start if the system has been tampered with. In plain terms: we’re not just trusting a phone number or a safety code, we’re getting a cryptographic statement from the device’s secure chip about its own integrity.

What does that actually check? The phone proves its bootloader is locked and reports the verified boot state, along with data that lets Molly “pin” the device’s boot key and a fingerprint of the OS image. The attestation includes Molly’s package/signing identity, so a modified or fake client will show up as Not Molly and the badge fails. In short: unlocks, downgrades, OS tampering—or using anything other than genuine Molly—get caught.

The attestation includes the android version and security patch levels, so Molly can show a clear status like “verified device / patch level: 2025-10” and warn if a phone falls behind, for example, if the patch level is older than a month. This turns abstract security posture into something we can actually act on: keep chatting with confidence when it’s green; nudge your contact to update when it’s stale; pause if the device has drifted from what you both pinned.

The proof is exchanged device-to-device inside the existing end-to-end encryption; there’s no server and no third-party metadata. Android treats hardware key attestation and “ID attestation” as separate things; we don’t need to include serial numbers or IMEIs to verify device integrity, and GrapheneOS is designed with this model in mind. In other words, you gain a strong signal about device state without exposing personal identifiers or who’s talking to whom.

Why this is a game changer? It upgrades trust from “the keys match today” to “the right app on a verified device that is up to date, every time.” It catches silent compromises (unlocking, tampering, downgrades), it supports GrapheneOS by allowing us to pin its official boot keys, and it’s anchored in the same hardware security android itself depends on to protect the platform.

Joe-FastFeet

Nuttso Thank you for such a detailed explanation of a very useful feature. Its implementation would indeed be extremely necessary and in demand. Tell me, how soon will it appear in the application?

Joe-FastFeet

Nuttso However, to be honest, I was saddened by the fact that your team did not have sufficient funds to resolve the issue of an independent audit. Are you planning to make your app on a paid subscription? This would allow you to have funds in the operational management of the project and ensure its stable development.

I managed to read a few complaints from users on the project's github page, and just like them I was quite annoyed by several cases of strange activity and a brisk increase in data traffic when the application was not used explicitly. It was about several hundred megabytes, I think about 700, which is simply bewildering. You've managed to figure it out and solve this problem What was the reason for such a sharp jump in traffic at a time when the user was practically not using it? https://github.com/mollyim/mollyim-android/issues/590 I would also be interested in your opinion about the requested function of hiding the number when managing https://github.com/mollyim/mollyim-android/issues/606 settings Thank you in advance for your answer.

Sorry, I forgot to discuss another important issue with you. Do you think Signal intentionally stopped encrypting the database, thereby allowing forensics to seize all application data, but at the everyday level allowing the user to believe that their Signal data is reliably protected? At the same time, the use of the application does not allow either attackers or governments to intercept and decrypt the application's traffic. That is, such deliberate assistance to criminologists precisely in cases when required by the courts, and sufficiently protected use in all other cases.

Well, there is also a funny story about how the developer of Telegram, comparing his application with Signal, was exorbitantly proud that his source code was open, and Signal, at that time, did not declare its source code as open source. Although, at the same time, we are all well aware that Telegram's servers, and its almost open cooperation with the Russian government, does not give the slightest reason to trust this messenger, regardless of encryption algorithms and everything else, since the owner of the project himself is absolutely compromised by an obvious game on the side of the Russian authorities. And whatever the encryption algorithms, the authorities have open access to the database itself on the servers, which absolutely negates all other privacy claims.

argante

Nuttso Molly’s remote attestation concept

Could we perhaps partner with GOS here? Molly could be offered as a trusted app, installed directly from the GOS App Store. Such a partnership would be beneficial for both GOS and Molly.

schklom

Nuttso

along with data that lets Molly “pin” the device’s boot key and a fingerprint of the OS image

it supports GrapheneOS by allowing us to pin its official boot keys

Just to be clear: does it mean it will support all 3rd-party OSes with bootloader locked, not just official GrapheneOS?
What happens with e.g. LineageOS with (very likely) bootloader unlocked?

Nuttso

Joe-FastFeet Thank you for such a detailed explanation of a very useful feature. Its implementation would indeed be extremely necessary and in demand. Tell me, how soon will it appear in the application?

There is no specific timeline.

Joe-FastFeet However, to be honest, I was saddened by the fact that your team did not have sufficient funds to resolve the issue of an independent audit. Are you planning to make your app on a paid subscription? This would allow you to have funds in the operational management of the project and ensure its stable development.

We are currently running solely on donations and have no intention of operating this as an enterprise.

Joe-FastFeet Sorry, I forgot to discuss another important issue with you. Do you think Signal intentionally stopped encrypting the database, thereby allowing forensics to seize all application data, but at the everyday level allowing the user to believe that their Signal data is reliably protected? At the same time, the use of the application does not allow either attackers or governments to intercept and decrypt the application's traffic. That is, such deliberate assistance to criminologists precisely in cases when required by the courts, and sufficiently protected use in all other cases.

Signal was never interested in Endpoint security. Moxie said himself the old implementation was a useless screenlock.

Joe-FastFeet managed to read a few complaints from users on the project's github page, and just like them I was quite annoyed by several cases of strange activity and a brisk increase in data traffic when the application was not used explicitly. It was about several hundred megabytes, I think about 700, which is simply bewildering. You've managed to figure it out and solve this problem What was the reason for such a sharp jump in traffic at a time when the user was practically not using it? https://github.com/mollyim/mollyim-android/issues/590 I would also be interested in your opinion about the requested function of hiding the number when managing https://github.com/mollyim/mollyim-android/issues/606 settings Thank you in advance for your answer.

The 700MB was not reproducible. That's why it's still an open issue.

I can tell you that some institutions use Molly on their platforms and monitor what data goes where 24/7.

Finally, I must make it clear that I am not here to defend Molly or convince you to use it. I can only tell you that there are some reports in certain circles that clearly show that not a single investigative authority is able to access the encrypted data.

de0u

Joe-FastFeet However, to be honest, I was saddened by the fact that your team did not have sufficient funds to resolve the issue of an independent audit. Are you planning to make your app on a paid subscription?

In a sense that would result in an audit being paid for by Molly users who are not excited about paying for one. An alternative might be a GoFundMe by which people who really want an audit could collaboratively fund one. Two hundred users could contribute $100, or two thousand users could contribute $10.

Nuttso

Dear friends,

Please don't get me wrong. We would be very happy to have our system tested by srlabs or cure53. I have already spoken to them and asked them to do this free of charge. But they refused. I would like to reiterate at this point that this would be a snapshot. We cannot have every update independently verified.

argante

Nuttso From what you're writing, you have very big plans to change how Signal currently works. I think you're moving more toward federalization, something like the XMPP model. Next year, you plan to release a Molly server (for self-hosting). An audit makes sense once the product is stabilized. Of course, you could organize a fundraiser for such an audit, and I'm sure many people, with @Joe-FastFeet as the first donor, would be happy to co-fund such an audit. It's definitely too early for that right now.

Joe-FastFeet

argante @Joe-FastFeet as the first donor

I will definitely not be the first donor of funds for the audit, since I am not a Molly user, as I said earlier, but I use and will use only Signal. I'm sorry. And even more so, I will not donate $100. I apologize again. But in terms of how to raise the right amount, I think it would be wise to put a special notice on the GOS page, where you could inform Molly users who want to join the audit funding event, and give everyone the opportunity to put their name on the general list of donors, and once there are 2000 people on the list, they could support the idea of the audit with their $10. I think it is quite possible to collect the required number of donators within 3-5 months.

mod note: edited to fix formatting so the quote and new content are separate.

gta3

argante good idea
It should receive more publicity in all fairness

What can be done to expedite molly into the GOS app store?

argante

gta3 This is a question for the GOS and Molly developers. Accrescent has been added to the GOS App Store. Of course, I'm basing my opinion on what @Nuttso wrote earlier about the chain of trust for boot process and apps.

Nuttso

schklom The feature will be optional. You can either restrict communicating to a device that is considered insecure or allow it and just stay informed. Both chat participants would need to enable it either way. Like read status. If only one enables it, it will not work.

schklom

Nuttso What I meant was: what will be considered secure and insecure?
I imagine all OSes with bootloader unlocked would be insecure, right?
But assuming the bootloader is locked and the OS is properly signed:

would custom GOS builds show as insecure?
what about other custom Android builds, e.g. e/OS or a non-public build?

I'm just a bit confused since you mentioned pinning GOS keys, which could mean that GOS keys and custom OS keys are treated differently.

Also, will builds based on public test-keys (like what Fairphones did for a while IIRC) be shown as secure?

In any case, this sounds like a great feature, thanks for all the work you put in, I love Molly and its devs :)

gta3

Nuttso

Has there been interest in having both sender and reciever message previews set to off?

I have mine off, therefore my screen shows "message received"

However i can't guarentee recievers device doesn't show any phone holder the message contents...

If not, is this possible to implement

Nuttso

schklom

Roughly speaking, a device will be considered secure if:

The bootloader is locked and Verified Boot reports a good (green) state.
The OS is signed with trusted production keys (for example: stock Pixel images signed by Google, or official GrapheneOS builds signed by the GrapheneOS keys).
The system is on a recent security patch level and not obviously abandoned.
There is no root, no test-keys, no engineering build, and no obvious tampering like userdebug builds or public signing keys.
We can verify all of this via hardware-backed key attestation and pin the corresponding OS/boot keys.

In practice that means:

Official stock Pixel and official GrapheneOS builds that meet the above will be shown as secure.

Custom GrapheneOS builds, other custom ROMs (e.g. e/OS), non-public/private builds, or anything signed with public test-keys will not be treated as “secure” in the UI. That doesn’t mean they’re automatically bad, it just means we can’t reliably verify their security properties or update policy, so they won’t get the same high-assurance rating.

The exact list of trusted keys / configurations will be documented, but the core idea is: locked bootloader, verified boot, current security patches, and OS images signed by keys we explicitly trust, without root or dev/test builds.

Joe-FastFeet

Nuttso

But I want to wish you every success, and I will definitely become a supporter of Molly as soon as the project passes an independent audit by reputable experts. And I'll probably even become one of the regular donators, although I'd prefer a paid subscription with additional features.

gta3

What i mean to say : is it possible to ENFORCE both sender + reciever have message notifications set to off?

Otherwise a bad actor holding the phone can see message previews that the sender was not aware of

23Sha-ger

other8026
Actually, to keep this topic clean, the only "actual" advantage
of Molly against Signal, in terms of forensics only, is the DB
encryption and alternative package name.

I will not be talking about UnifiedPush and other enhancements.
See, the way it works now, Cellebrite has an automated script
for messengers, Signal included. Obviously Molly is making the
extra effort to also counter measure AFU, so even if you provide
the passphrase to the adversary, and your Molly icon looks like a Music app, it can fly. Things can change. I talk about present.
Unless your examiner knows about Molly, there doesn't appear
to be any presense of Signal app installed. That's an advantage.

Joe-FastFeet

23Sha-ger Obviously Molly is making the
extra effort to also counter measure AFU

Yes, it's very interesting! But where can you learn about the results of these efforts to date? I have been looking for material on this topic for a long time, but, unfortunately, I could not find it.

23Sha-ger

Joe-FastFeet
You should get the latest Cellebrite Premium and run it
against AFU device, both with Signal and Molly. Simple.
Since I know how extraction works, Molly is not even on
the roadmap. Because most users of Molly will use GOS.
And that's a minority of a minority. You can fork Molly and
call it Smally. Change icon and package name. No automated
tool will ever correlate that this app DB is your Signal app.

Joe-FastFeet

23Sha-ger You should get the latest Cellebrite Premium

Alas, I don't have Cellebrite Premium. Can you tell me where I can read about how this comparison between Signal and Molly was made, using the Cellebrite Premium software you mentioned?

« Previous Page Next Page »