The US government does have storage facilities and secure messaging tools with escrow, all designed for exactly this use-case (secure messaging amongst DoD personnel.) But the whole point of Signal+TeleMessage was to route around that "clunky stuff" by outsourcing it to a vendor.

I understand the point - the point is people who believe the size of their bank account is proportional to their intelligence and aptitude at everything making flat dumb decisions because, if anything, the relationship is none of not inversely proportional. Their arrogance and eschewing of expertise in favor of magical thinking will end up with a lot of people dead.

The DoD obviously has a need to message with people who don't have access to their hardware. Signal can basically do this on its own if you link a Signal account to an Internet-connected PC and back up those messages, I don't see why you would want a third party app involved.

It seems likely to me that this was the "whole point of Signal+TeleMessage" and then in addition to being a bad solution, it got misused for communications that shouldn't have left the DoD's networks anyway.

There are PIV creds for more than just DoD.

The point is that it was supposed to be end-to-end encrypted by this company all the way to the government's archive.

That's what they claimed, but their service did no such thing.

How, in Signal's security model, could there be "end to end encryption all the way to the government archive"?

By saying that chatting and logging are separate processes, and each one has end to end encryption. Only the clients and the archive can see the text.

And that's what the actual quote says. End to end from phone to archive.

The "TeleMessage Archive Server" in the diagram is not the archive. It's a relay that should not have access to the plaintext, but does. And because TeleMessage owns it, they get access too.

The "Archive Destination" is the actual archive and the only thing that should have decryption keys.

This actually seems pretty trivial to me, without a custom Signal client. You link a secure PC with the secure archival software to your Signal account and it will receive all messages E2E encrypted.

We're using words like "should" have access or whatever, but my understanding of the point of these apps is that they allow users to use Signal while keeping compliance archives of messages. They're not cryptographically interesting (or really cryptographic at all). This is more like e-discovery software than secure messaging. If you're using it, cryptography is out the window.

It’s not end-to-end, but that seems a bit exaggerated. An organization will still want encryption in transit, encryption at rest for its archive, and good access control.

In secure messaging as a cryptographic discipline, this is like saying you don't want secure messaging. Secure messaging is end-to-end secure, and the basic core threat modeling of a secure messaging service includes adversaries who defeat transit-only encryption.

All this is to say: it's unremarkable to me that the Signal compliance fork government officials are using, which is premised on the capability of archiving messages, defeats secure messaging. That's literally what it's for.

Hypothetically, wouldn't the best Signal archiving be to make the custom client auto-add an archiving "user" to all chats, with that user only connected from secure archiving machines? Then convert archive user client text to whatever government encrypted form on that machine for long term storage?

Curious what the best way of archiving with Signal's security model would be.

There's a reason Signal doesn't archive, and you have to fork it to make that happen.

My stock, unmodified Signal app does archive: Settings > Chats > Chat backups.

Secure group chat is possible. If saving messages to an archive is what you want, Why isn’t the archive just another endpoint to deliver messages to?

The threat model would cover the risk of intercepting messages on the way to the archive and unauthorized access to the archive.