No, the point is for the government to have access the plaintext after it is securely delivered to an approved archive location, not TeleMessage having access on AWS-hosted servers exposed to the public internet.

TeleMessage pitched their service as using end-to-end encryption of the message into the corporate archive.

> End-to-End encryption from the mobile phone through to the corporate archive

Apparently the plaintext messages were going to a TeleMessage server on AWS (not an approved government archive location) that was publicly accessible. Naturally it was hacked.

I doubt that’s the point either. The government should have cipher text they are able to decrypt in an approved archive location with rigorously managed key material and a careful cryptographically variable chain of custody from its inception. Plain text should never factor into this.

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.

Why would they need to hire a foreign Israeli firm for that?

Through this procurement decision, the government has displayed gross incompetence.

US owned since Feb 2024

By the federal government? Owned by whom?

Presumably, in the spectrum of secure network protocols, something exists between "delete the message before it can leave this machine" and "send this message to a cloud provider and have them email it in plain text to another cloud provider".

And Email protocol backbone itself was not designed to be secure.

It's worse than internet packets over HTTPS -- the secure connection is established between client and server, so man-in-the-middle cannot decrypt it. In email, connections are only secure between relays, so any relay can decrypt read your email. You cannot guarantee what relays are used. Similar to SMS.

This might have been the case back in the day - in the 90s, young me would get a kick out of seeing just how many SMTP servers my email passed through. But now, email communication is "essentially" point-to-point, and relays in use are configured/whitelisted.

My SMTP server will pull up your MX and talk directly to it. It might be your Exchange server, a Google server, or a third-party scanner that then sends on to your "real" MX.

But gone are the days of "Hey, I only know a few places to send this message, so I'll send to one of them and they'll forward it". Nor can you do anything akin to route poisoning or other things to try to insert yourself into the message flow.

That's good to hear, however, as a compliance officer, what evidence I can provide to an auditor that our email communications are indeed encrypted?

It's not a secure messaging system. It's explicitly the opposite.

If you're sending plaintext out of an ostensible e2ee system, it's not an e2ee system. You have an 'end' that's not, you know, end-to-end.

The end that's relaying the plaintext is the user agent itself, not a third component in the system.

There is no 'relaying plaintext' in an e2ee system.

Sure, 100% agreed. But the way you phrased the earlier post implied that there was a third "end" to the system that was doing the plaintext leaking, and that's not the case (assuming I understood the description correctly, and it's accurate).

It's supposed to be available in plaintext to the end customer (government), at their secured archive, but not available in plaintext to TeleMessage.

>TeleMessage lies about this in their marketing material, claiming that TM SGNL supports "End-to-End encryption from the mobile phone through to the corporate archive."

Surely someone of your expertise and renown recognizes this difference.

The point is for the program TeleMessage to have access.

On top of that the company TeleMessage has access, and that is bad.

> Isn't that the point?

The point is making SecDef's communications, including scramble orders, available to whoever can find a TeleMessage employee who will cave to a bribe or blackmail?