A Basil Plant

u/ABasilPlant@lemmy.world
20 posts · 147 comments

Recent posts

Recent comments

The problem it's trying to solve is mostly straightforward. I'll provide a high-level overview so as to not complicate things (a lot of this is simplified):

When you create an account on signal, you create a private key and a public key. When you DM someone, you're communicating with your public keys (simplified). Your private keys remain with you. However, this creates a very big problem that's not new to signal, but has existed since TLS (previously SSL):

If you are trying to communicate with Bob over the internet, he's supposed to give you his public key over the internet.

But, how do you know that the person who replies to you with their public key is actually Bob? What if someone else gives you their public key and says they're Bob? The easiest way would be to physically meet Bob, and check whether the public key you received over the internet matches. However, this is impractical (live in different countries?).

TLS solved this with certificates. How do you know that the byte stream of data you're receiving from lemmy.world is really coming from Lemmy.world, and not malicious-lemmy.world? Because of certificates: someone you trust cryptographically said that the byte stream is really from lemmy.world. Your device with which you use to access the internet (phone, laptop, browser) comes with pre-installed certificates. Here's the list Mozilla ships with Firefox: https://ccadb.my.salesforce-sites.com/mozilla/IncludedRootCertificateReport

Solving this with signal isn't that easy. There's problems (users may change numbers / usernames), and general certification is... just not that simple. That's why, when you DM someone on signal, you can "mark safety number as verified" if you can verify that you both see the same number (you do this over a medium that isn't signal).

Signal is now introducing a solution called Key transparency (defined by the IETF: https://datatracker.ietf.org/doc/draft-ietf-keytrans-protocol/), which in essence says that your device periodically checks your own entry on a ledger that signal now hosts, and you can initiate a check of your contact's entry too.

If you notice your key on the ledger is wrong, something bad happened (malicious). If the other person's key on the ledger changed, then you should verify that it was indeed meant to change (new phone? New number? New username?). Because the server that provides the ledger could theoretically show different people different versions of the ledger, independent auditors attest the ledger, making conflicting views detectable (you might pull the wrong ledger from a malicious person, or signal may give you wrong ledgers maliciously). They're entrusting external parties to attest that the data that both parties of a DM get the correct view of the ledger.

This is what I understood after a cursory reading, and I may be wrong. It is also simplified. But I hope that this is mostly correct.

It's solving a very old problem of public-key cryptography: how do you ensure that the person who is talking to you claims who they are? Are you sure you're really talking to Bob, and instead not Mallory who's pretending to be Bob?

Tagging @k0e3@lemmy.ca too.

on Rule · c/linuxmemes · 6 pts · 9d

If you run it with arg1, won't it run them all?

Yes, that is the intention. When you're following some guide online and it requires you use some "software", you may not know how to install that software.

This install.sh script tries package managers, because one of them will probably work. Others will fail.

For example, installing numpy (python package): pip install succeeds and all the other ones (hopefully) fail.

Installing libcurl4-openssl-dev (curl with openssl library file): apt-get install works and all other ones (hopefully) fails.

Longer and more thorough explanation:

https://www.explainxkcd.com/wiki/index.php/1654:_Universal_Install_Script

on Reversing a swastika · c/flippanarchy · 3 pts · 65d

Hello from one Indian Hindu to another 👋

It can be drawn in black.

Hence my italicized "personally". I've just never seen it in black.

on Reversing a swastika · c/flippanarchy · 7 pts · 66d

With two large caveats immediately apparent to anyone familiar with Hinduism:

  • the Hindu Swastika is not at 45° tilt

  • the Hindu Swastika is traditionally also never drawn in black, as far as I've personally seen. It's usually red / saffron.

https://snee.la/posts/the-workings-of-whatsapps-end-to-end-encrypted-backups/

This is my analysis of WhatsApp's backup mechanisms. The best possible thing you can do from a privacy PoV is to enable end-to-end-encrypted backups, which is disabled by default.

As far as I know, WhatsApp's backups don't go to meta's servers, but instead google cloud / icloud. If your wife logged into her google account before, had backups enabled (frequency is weekly afaik), and signed into the google account again on the new phone - WhatsApp will restore the backups from the cloud.

If you enable E2EE backups, then you'll be asked to enter your password, which only you can have. If you fail to supply that, your backups are lost forever. The implantation is a bit scuffed IMO, but still better than nothing. Things may have changed since I analyzed it in 2022.

That's incredible! Makes the transportation nerd in me be fired up with jealousy! And fortunate that no one was hurt, the pilot and the helpers really did a great job jumping your house. Was there any reason they told you why they had to make an emergency landing? Maybe I missed that part.

But it looks like the gondola is lop-sided from the video. Is that it? Seems like the whole neighborhood came out to watch the spectacle :D

on bit rude, innit? · c/lemmyshitpost · 18 pts · 207d

Is this image AI? the reflections in the window, the perfect snowman, that film grain filter... it looks too perfect to me.

I’ll be sure to reach out if I find myself being unable to replicate it.

No worries, and good luck! My email can be found on my website if you want it :D

I wasn’t even talking about tikzplotlib. It’s just that pgf backend is now supported by matplotlib and you can produce pgf files with.

Ah... I've think I've heard of it, but I never really registered that. Thanks for the info :D

I could give you the tikz source of Fig 2 if you'd like. The patterns and colors of the plots took me almost a day to choose. I wanted to go for a color-blind friendly pallette and keep it looking still snazzy. (https://github.com/simon-pfahler/colorblind)

I'm familiar with matplotlib -> PGFplots (using the Python tikzplotlib library). Unfortunately, I've decided against using it for the paper as it produces quite unmanageable outputs. Especially if I rerun experiments + with new data, and later want to change patterns, colors... It was always more of a hassle. I used it for my Master's thesis.

Instead, Python program -> show plot -> if okay, generate CSV.

In LaTeX, have PGFplot code which reads CSV file and generates the data that way. Much, much easier to maintain.

Thanks for the question!

As long as caches have existed, very similar styles of side channels have been demonstrated since the late 90s. A lot of the terminology we use (flush+reload, flush+flush...) are attack techniques that have been already demonstrated on CPU caches, and these demonstrations are at least a decade old.

Flush+Reload: https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/yarom

Flush+Flush: https://gruss.cc/files/flushflush.pdf

Invalidate+Compare (GPU caches, 2024): https://www.usenix.org/conference/usenixsecurity24/presentation/zhang-zhenkai

My colleague, Hannes, found similar styles of attacks existed with the Linux DNS cache too: https://hannesweissteiner.com/pdfs/dmt.pdf (also published at NDSS 26!)

The one really big difference between the page-cache side channel and other side channels is the "monitor" primitive. There are methods that the OS provides which directly report the presence of a page in cache. These are syscalls like mincore (mitigated in 2019), preadv2 + rwf_nowait (unmitigated), and cachestat (mitigated in 2025).

With these syscalls, we don't even have to rely on timing information (is page access fast -> cached; is it slow -> not cached). These syscalls really set the page-cache side channel apart because you can nondestructively figure out whether a page is in cache.

The page-cache side channel was first explored in 2019. It was explored on Linux but also on Windows by my advisor et al.: https://gruss.cc/files/pagecacheattacks.pdf

Hope this answers your question :D