Egregoros

@rysiek@mstdn.social remote

@rysiek @delta
Bugger, it's not even sending messages. Yikes.

Michał "rysiek" Woźniak · 🇺🇦

@davep I'm sure it's going to come back up sooner rather than later. But it's a good reminder how much we rely on it, and to have a backup plan.

Alexandre Oliva

GNU Jami servers have never gone down on me. how could they? it doesn't need any servers!

CC: @davep@infosec.exchange

feld

@lxo @rysiek @davep You can't send messages over Jami unless the other person is online... which is... kinda useless......

Replying to @feld@friedcheese.us

Alexandre Oliva

of course you can. they just won't get it before they come online. which is kind of duh! for instant messaging, isn't it?

now, if you're concerned about the two of us never being online at the same time, install Jami on your home server, or on a VPS, link your account there, and it will get a copy of your messages whenever you send or receive them, and it will transfer them to your peers or to your own device whenever they come online.

now, if that's not good enough for you, I guess you really prefer to share your conversations with third parties for them to do this for you. me, I prefer my autonomy.

CC: @davep@infosec.exchange @rysiek@mstdn.social

Replies

Replying to @lxo@snac.lx.oliva.nom.br

David Penfold

@lxo @feld @rysiek Are you implying Signal shares your information with third parties? Or that they even can?

I understand your desire for autonomy, which is cool. That doesn't mean you have to throw shade where it's not needed. The issue here yesterday for Signal was resilience, not access to your data.

Replying to @davep@infosec.exchange

Alexandre Oliva

nope. I'm told they don't even have access to data, or even metadata, thanks to some technology indistinguishable from magic in its protocol. but I won't pretend I really understand how that works.

the main problem with signal is their insistence on demanding a snoop phone to get started. that spoils the entire experience, and probably exposes its users' conversations, metadata and even secret keys to third parties. see https://blog.lx.oliva.nom.br/2026-02-01-signal-of-awareness.en.html and https://blog.lx.oliva.nom.br/2026-01-25-compromising-encryption-keys.en.html

the secondary problem with signal is its insistence on centralization. this makes the "not being online at the same time" a problem for all its users, when their centralized servers are not online

CC: @feld@friedcheese.us @rysiek@mstdn.social

Replying to @lxo@snac.lx.oliva.nom.br

David Penfold

@lxo @feld @rysiek
I agree with the centralisation risk. But those articles have nothing to do with needing a telephone number. They're more of an indictment of Windows and tend to back up Signal's worry about LLMs embedded into the OS.

If your endpoint is compromised, anything you read is also compromised.

As for the "magic" comment, it's just that they encrypt basically all the metadata that the likes of WhatsApp don't. And with the double ratchet protocol they can't decrypt that data. They *could* make logs of who called or messaged who, but don't. If this were decentralised, what's to stop a bad actor logging such information? Just curious. It may need a rethink of the whole architecture (I'm not saying that's a bad thing by the way).

Replying to @davep@infosec.exchange

feld

@davep @lxo @rysiek

> If this were decentralised, what's to stop a bad actor logging such information?

From the DeltaChat perspective, it's assumed that the servers may get compromised.

So if you and another contact are using the same server (relay), and the relay is compromised, the attacker will be able to see the IP addresses of the clients. This is not ideal, but it's about all they get. They can measure message sizes and guess what's inside but it's not very useful in most cases unless they're trying to pin down the transfer of a specific file or something.

If each contact is using a different server (relay), then this is trickier. They can only see the IP address of the user that logs directly into the server they've compromised, and they can't even be sure the same contact is sending the surveilled target messages if the other client's email address keeps changing -- even bouncing around and coming from completely different servers (relays). This is a thing you can do now and will be automated in the not too distant future.

Replying to @feld@friedcheese.us

David Penfold

@feld That's really interesting, thanks!

Replying to @davep@infosec.exchange

feld

@davep @rysiek @lxo DeltaChat makes it relatively easy to setup your account on a relay that exists in a different legal jurisdiction than you are in to make it even harder for legal authorities to try to get anything on your account activity. But if your account (email address) can change so easily, they start chasing ghosts.

If you had any concern that you might be surveilled the smart thing to do would be to additionally use proxies/VPNs if possible, and change your DeltaChat relay regularly. Change it, send your contacts a message so their app will automatically learn your new address to contact you at. Much easier than getting new phone numbers!

Replying to @davep@infosec.exchange

David Penfold

@lxo @feld @rysiek
That second article rails against MS stealing your private keys etc. IIRC, Signal now uses the TPM (this wasn't always the case) on Windows, so in theory MS doesn't have access to it. But if you want to reduce your attack surface, just don't install the Windows client.

Replying to @davep@infosec.exchange

Alexandre Oliva

you seem knowledgeable about signal. I hope you don't mind if I shoot you some questions.

does it use TPM features on mobile phones as well?

how does it deal with linking multiple devices to an account? does each device get a separate key generated locally using TPM? or do they all share the keys first generated in a compromised mobile phone?

when you link a new device to an account, does it gain access to past messages, or only to future messages?

is there any way for you to tell in case someone else uses your compromised keys/credentials to gain access to your account, e.g. by linking a device that becomes visible to other devices or somesuch?

thanks in advance,

CC: @feld@friedcheese.us @rysiek@mstdn.social

Replying to @lxo@snac.lx.oliva.nom.br

feld

@lxo @davep @rysiek

> does it use TPM features on mobile phones as well?

yes

> how does it deal with linking multiple devices to an account? does each device get a separate key generated locally using TPM? or do they all share the keys first generated in a compromised mobile phone?

AIUI same keys, there's just a different identifier that tells you which device it is. Someone wrote a tool that can sniff "read receipts" and determine if someone is "at home" based on if it was sent from their phone or desktop.

> when you link a new device to an account, does it gain access to past messages, or only to future messages?

Yes, as of last year you can choose to sync old messages when you link a new device (like your Desktop)

> is there any way for you to tell in case someone else uses your compromised keys/credentials to gain access to your account, e.g. by linking a device that becomes visible to other devices or somesuch?

There is *now* after Russian soldiers were infiltrating Ukrainian military Signal chats by linking their own devices to existing Ukrainian military members accounts through hacks/tricking them into following links, or just taking phones off their dead bodies.

Not mentioned in this thread is that your Signal account key is stored in Signal's cloud as you can recover your account with a PIN which wouldn't be possible if they didn't have your key

Replying to @feld@friedcheese.us

Alexandre Oliva

your Signal account key is stored in Signal's cloud as you can recover your account with a PIN

holy gnu! that's bitlocker all over again 😞

is that at least optional? hopefully there are other means to back up and recover your keys?

this also means that the key is not exclusively held in TPM; in order for it to be possible to upload it, it must have existed outside the TPM

CC: @davep@infosec.exchange @rysiek@mstdn.social

Replying to @lxo@snac.lx.oliva.nom.br

David Penfold

https://signal.org/blog/secure-value-recovery/

@lxo apparently there are secure enclaves behind the pin so your data is protected. It's pretty clever.

@feld @rysiek

Replying to @davep@infosec.exchange

feld

@davep @lxo @rysiek it's clever except the part where SGX is not perfectly secure, so if a determined government wanted to seize those servers and try to crack the SGX enclaves to recover this data, they probably could based on its security track record

https://sgx.fail/

Replying to @feld@friedcheese.us

David Penfold

@feld Oh, indeed. A mutual friend sent me Moxie's original TPM paper in 2016 or 2017 to go over (he had more confidence in my abilities than I do 🤣) and my first thought was "can we trust these things?"

Replying to @davep@infosec.exchange

David Penfold

@feld But having said that, hugely expensive HSMs use shonky old Linux versions and are mainly compliant because they're physically tamper-proof.

Replying to @davep@infosec.exchange

Alexandre Oliva

wow, that is clever indeed: they don't get your key, they get the random part that goes into forming the key, while the other part is derived from the PIN, so they can (i) authenticate the pin without knowing it or ever getting it, and (ii) extract the part they hold from the enclave and send it back to you (if you provided the right authentication within a limited number of attempts) so you can hash it along with a separate key also derived from the PIN they don't know to recover your master and application keys. it feels sound even without the replicated enclaves. even if they retained the random number outside an enclave, they'd still have to brute-force the PIN to recover your key, and IIUC all this would get them would be your social graph. (maybe your backups too?)

but then again, the weakness is the computing device where PIN gets entered and random part gets generated. whoever controls that device gets both, and can thus derive all the keys and gain access to whatever the keys were supposed to protect

CC: @feld@friedcheese.us @rysiek@mstdn.social

Replying to @davep@infosec.exchange

Light

@light@noc.social remote

@davep
Doesn't Intel hold private keys for SGX enclaves or something? I remember hearing something like that. Is that a concern?

Then again, I guess we are trusting chip designers anyway. But Intel has recently been partly bought out by the US gov; which is concerning as all the Minneapolis ICE watchers and similar groups are using Signal.
@lxo @feld @rysiek

Replying to @light@noc.social

David Penfold

@light No idea, to be honest.

@lxo @feld @rysiek

Replying to @davep@infosec.exchange

feld

@davep @light @lxo @rysiek

> Doesn't Intel hold private keys for SGX enclaves or something? I remember hearing something like that. Is that a concern?

I shouldn't think that to be true. What good is an HSM if the vendor has master keys?

Replying to @feld@friedcheese.us

David Penfold

@feld Thanks again! 🫡

Replying to @davep@infosec.exchange

David Penfold