Hírolvasó

Inkább a vakolatot csináltatta volna meg! trey 2025. 06. 06., p – 11:53

A tesztelői szakmát rengeteg friss hatás éri, kifejezetten nehezített pálya ez mostanság.

Az év végén szakíthatnak az Amazon felhőjének európai ügyfelei az amerikai adatközpontokkal.

Megkezdték az amerikai gyártás előkészületeit a legnagyobb bérgyártók, a Pegatron is építhet üzemet Texasban.

In a combined storage and filesystem session at the 2025 Linux Storage, Filesystem, Memory Management, and BPF Summit (LSFMM+BPF), Keith Busch led a discussion about zero-copy operations for the Filesystem in Userspace (FUSE) subsystem. The session was proposed by his colleague, David Wei, who could not make it to the summit, so Busch filled in, though he noted that "I do not really know FUSE so well". The idea is to eliminate data copies in the data path to and from the FUSE server in user space.

The European Union's Cyber Resilience Act (CRA) has caused a stir in the software-development world. Thanks to advocacy by the Eclipse Foundation, Open Source Initiative, Linux Foundation, Mozilla, and others, open-source software projects generally have minimal requirements under the CRA — but nothing to do with law is ever quite so simple. Marta Rybczyńska spoke at Linaro Connect 2025 about the impact of the CRA on the open-source ecosystem, with an emphasis on the importance of understanding a project's role under the CRA. She later participated in a panel discussion with Joakim Bech, Kate Stewart, and Mike Bursell about how the CRA would impact embedded open-source development.

Version 3.0 of the privacy-centric, open-source mobile operating system has been released. Notable changes in this release include improved privacy tools, a "find my device" feature, and more. LWN looked at /e/OS in March.

Version 0.113 of Game of Trees has been released (and the port updated):

• tweak 'got status' and 'got add' ignores handling for better git compatibility
• improve redundant pack detection during 'gotadmin cleanup'
• gotwebd: do not forget to initialize *ngroups argument for getgrouplist()
• fix default access for root and _gotd when gotsysd runs without config file
• fix bogus "unexpected privsep message" from gotsh during 'got send'
• fix a race in gotd notification processing causing notify process to exit

One of the more obscure features provided by Unix-domain sockets is the ability to pass a file descriptor from one process to another. This feature is often used to provide access to a specific file or network connection to a process running in a relatively unprivileged context. But what if the recipient doesn't want a new file descriptor? A feature added for the 6.16 release makes it possible to refuse that offer.

(Edit: Twitter could improve this significantly with very few changes - I wrote about that here. It's unclear why they'd launch without doing that, since it entirely defeats the point of using HSMs)

When Twitter[1] launched encrypted DMs a couple
of years ago, it was the worst kind of end-to-end
encrypted - technically e2ee, but in a way that made it relatively easy for Twitter to inject new encryption keys and get everyone's messages anyway. It was also lacking a whole bunch of features such as "sending pictures", so the entire thing was largely a waste of time. But a couple of days ago, Elon announced the arrival of "XChat", a new encrypted message platform built on Rust with (Bitcoin style) encryption, whole new architecture. Maybe this time they've got it right?

tl;dr - no. Use Signal. Twitter can probably obtain your private keys, and admit that they can MITM you and have full access to your metadata.

The new approach is pretty similar to the old one in that it's based on pretty straightforward and well tested cryptographic primitives, but merely using good cryptography doesn't mean you end up with a good solution. This time they've pivoted away from using the underlying cryptographic primitives directly and into higher level abstractions, which is probably a good thing. They're using Libsodium's boxes for message encryption, which is, well, fine? It doesn't offer forward secrecy (if someone's private key is leaked then all existing messages can be decrypted) so it's a long way from the state of the art for a messaging client (Signal's had forward secrecy for over a decade!), but it's not inherently broken or anything. It is, however, written in C, not Rust[2].

That's about the extent of the good news. Twitter's old implementation involved clients generating keypairs and pushing the public key to Twitter. Each client (a physical device or a browser instance) had its own private key, and messages were simply encrypted to every public key associated with an account. This meant that new devices couldn't decrypt old messages, and also meant there was a maximum number of supported devices and terrible scaling issues and it was pretty bad. The new approach generates a keypair and then stores the private key using the Juicebox protocol. Other devices can then retrieve the private key.

Doesn't this mean Twitter has the private key? Well, no. There's a PIN involved, and the PIN is used to generate an encryption key. The stored copy of the private key is encrypted with that key, so if you don't know the PIN you can't decrypt the key. So we brute force the PIN, right? Juicebox actually protects against that - before the backend will hand over the encrypted key, you have to prove knowledge of the PIN to it (this is done in a clever way that doesn't directly reveal the PIN to the backend). If you ask for the key too many times while providing the wrong PIN, access is locked down.

But this is true only if the Juicebox backend is trustworthy. If the backend is controlled by someone untrustworthy[3] then they're going to be able to obtain the encrypted key material (even if it's in an HSM, they can simply watch what comes out of the HSM when the user authenticates if there's no validation of the HSM's keys). And now all they need is the PIN. Turning the PIN into an encryption key is done using the Argon2id key derivation function, using 32 iterations and a memory cost of 16MB (the Juicebox white paper says 16KB, but (a) that's laughably small and (b) the code says 16 * 1024 in an argument that takes kilobytes), which makes it computationally and moderately memory expensive to generate the encryption key used to decrypt the private key. How expensive? Well, on my (not very fast) laptop, that takes less than 0.2 seconds. How many attempts to I need to crack the PIN? Twitter's chosen to fix that to 4 digits, so a maximum of 10,000. You aren't going to need many machines running in parallel to bring this down to a very small amount of time, at which point private keys can, to a first approximation, be extracted at will.

Juicebox attempts to defend against this by supporting sharding your key over multiple backends, and only requiring a subset of those to recover the original. I can't find any evidence that Twitter's does seem to be making use of this,Twitter uses three backends and requires data from at least two, but all the backends used are under x.com so are presumably under Twitter's direct control. Trusting the keystore without needing to trust whoever's hosting it requires a trustworthy communications mechanism between the client and the keystore. If the device you're talking to can prove that it's an HSM that implements the attempt limiting protocol and has no other mechanism to export the data, this can be made to work. Signal makes use of something along these lines using Intel SGX for contact list and settings storage and recovery, and Google and Apple also have documentation about how they handle this in ways that make it difficult for them to obtain backed up key material. Twitter has no documentation of this, and as far as I can tell does nothing to prove that the backend is in any way trustworthy. (Edit to add: The Juicebox API does support authenticated communication between the client and the HSM, but that relies on you having some way to prove that the public key you're presented with corresponds to a private key that only exists in the HSM. Twitter gives you the public key whenever you communicate with them, so even if they've implemented this properly you can't prove they haven't made up a new key and MITMed you the next time you retrieve your key)

On the plus side, Juicebox is written in Rust, so Elon's not 100% wrong. Just mostly wrong.

But ok, at least you've got viable end-to-end encryption even if someone can put in some (not all that much, really) effort to obtain your private key and render it all pointless? Actually no, since you're still relying on the Twitter server to give you the public key of the other party and there's no out of band mechanism to do that or verify the authenticity of that public key at present. Twitter can simply give you a public key where they control the private key, decrypt the message, and then reencrypt it with the intended recipient's key and pass it on. The support page makes it clear that this is a known shortcoming and that it'll be fixed at some point, but they said that about the original encrypted DM support and it never was, so that's probably dependent on whether Elon gets distracted by something else again. And the server knows who and when you're messaging even if they haven't bothered to break your private key, so there's a lot of metadata leakage.

Signal doesn't have these shortcomings. Use Signal.

[1] I'll respect their name change once Elon respects his daughter

[2] There are implementations written in Rust, but Twitter's using the C one with these JNI bindings

[3] Or someone nominally trustworthy but who's been compelled to act against your interests - even if Elon were absolutely committed to protecting all his users, his overarching goals for Twitter require him to have legal presence in multiple jurisdictions that are not necessarily above placing employees in physical danger if there's a perception that they could obtain someone's encryption keys

comments

Security updates have been issued by Debian (chromium and mariadb-10.5), Oracle (firefox, ghostscript, git, go-toolset:ol8, golang, kernel, krb5, mingw-freetype and spice-client-win, nodejs:20, nodejs:22, perl-CPAN, python36:3.6, rsync, varnish, and varnish:6), Red Hat (firefox, thunderbird, and webkit2gtk3), Slackware (curl and python3), SUSE (apache-commons-beanutils, apache2-mod_security2, avahi, buildkit, ca-certificates-mozilla, cloud-regionsrv-client, cloud-regionsrv-client, python-toml, containerd, containerized-data-importer, cups, curl, dnsmasq, docker, elemental-operator, elemental-toolkit, expat, firefox, freetype2, gdk-pixbuf, git, glib2, glibc, gnuplot, gnutls, gpg2, gstreamer, gstreamer-plugins-base, gtk3, haproxy, helm, java-17-openjdk, java-1_8_0-openjdk, keepalived, kernel, kernel-firmware, krb5, kubevirt, less, libarchive, libcryptopp, libdb-4_8, libndp, libpcap, libsoup, libtasn1, libvirt, libX11, libxml2, libxslt, Mesa, mozilla-nss, nghttp2, nvidia-open-driver-G06-signed, opensc, openssh, openssl-3, openssl-3, libpulp, ulp-macros, orc, pam, pam_pkcs11, pam_u2f, patch, pcp, pcr-oracle, shim, perl-Crypt-OpenSSL-RSA, podman, postgresql16, procps, protobuf, python-dnspython, python-Jinja2, python-requests, python-setuptools, python-tornado6, python-urllib3, python311, python311, python-rpm-macros, qemu, rsync, runc, rust-keylime, selinux-policy, sevctl, skopeo, sssd, SUSE Manager Client Tools, systemd, thunderbird, tiff, tpm2.0-tools, tpm2-0-tss, u-boot, ucode-intel, unbound, util-linux, vim, wget, and wpa_supplicant), and Ubuntu (linux-nvidia, python-django, twitter-bootstrap3, twitter-bootstrap4, and wireshark).

As I wrote in my last post, Twitter's new encrypted DM infrastructure is pretty awful. But the amount of work required to make it somewhat better isn't large.

When Juicebox is used with HSMs, it supports encrypting the communication between the client and the backend. This is handled by generating a unique keypair for each HSM. The public key is provided to the client, while the private key remains within the HSM. Even if you can see the traffic sent to the HSM, it's encrypted using the Noise protocol and so the user's encrypted secret data can't be retrieved.

But this is only useful if you know that the public key corresponds to a private key in the HSM! Right now there's no way to know this, but there's worse - the client doesn't have the public key built into it, it's supplied as a response to an API request made to Twitter's servers. Even if the current keys are associated with the HSMs, Twitter could swap them out with ones that aren't, terminate the encrypted connection at their endpoint, and then fake your query to the HSM and get the encrypted data that way. Worse, this could be done for specific targeted users, without any indication to the user that this has happened, making it almost impossible to detect in general.

This is at least partially fixable. Twitter could prove to a third party that their Juicebox keys were generated in an HSM, and the key material could be moved into clients. This makes attacking individual users more difficult (the backdoor code would need to be shipped in the public client), but can't easily help with the website version[1] even if a framework exists to analyse the clients and verify that the correct public keys are in use.

It's still worse than Signal. Use Signal.

[1] Since they could still just serve backdoored Javascript to specific users. This is, unfortunately, kind of an inherent problem when it comes to web-based clients - we don't have good frameworks to detect whether the site itself is malicious.

comments

Új funkciókkal ünnepli az OpenAI, hogy a ChatGPT átlépte a hárommillió üzleti előfizetőt.

Egy lelkes gyűjtő kikeverte az első olyan 3D-nyomtató filamentet, mely az ikonukus Platinum árnyalatban nyomtat.

Éjfél óta nálunk is kapható a nagysikerű konzol második generációs utódja, amihez 210-230 ezer forint körül lehet hozzájutni.

A cég szerint a Claude és más modellek tanításához az Anthropic illegálisan használta fel a reddites tartalmakat.

A bírói testület elutasította az Apple sürgősségi kérelmét, amely az Epic Games-szel való jogi csata eredményeként létrejött változtatások felfüggesztésére irányult az App Store-ban.

A cél különösen a mesterséges intelligenciával erősített támadásokkal szembeni védelem erősítése.

In a multi-part article, kraileth reviews the installers of various BSD operating systems.

Part 2 covers OpenBSD:

https://eerielinux.wordpress.com/2025/04/27/installing-bsd-in-2025-part-2-a-critical-look-at-openbsds-installer/

That's how it looks from the outside coming in, folks!

"Brüsszel kiverte a biztosítékot az orosz gáz fő vásárlóinál" trey 2025. 06. 05., cs – 08:24