winterdeaf

So much vitriol. I understand it's cool to hate on EA after the SBF fiasco, but this is just smearing.

The key to scientific thinking is empiricism and rationalism. Some people in EA and lesswrong extend this to moral reasoning, but utilitarianism is not a pillar of these communities.

As far as I am aware, there is no way to stop malicious tags without modifying the protocol to authenticate the messages being broadcast as originating form a genuine tag. [1]

Making a tag that is not trackable is currently as easy as flipping a bit in the BLE advertisement. The same message is broadcast to all phones, but yes, a tag could also produce multiple identifiers and evade detection. [2]

[1]: Section 8 of "Abuse-Resistant Location Tracking: Balancing Privacy and Safety in the Offline Finding Ecosystem". https://eprint.iacr.org/2023/1332.pdf

[2]: "Track You: A Deep Dive into Safety Alerts for Apple AirTags". https://petsymposium.org/popets/2023/popets-2023-0102.pdf

This is such a charade. Making "invisible" airtags is trivial [1], and I wouldn't be surprised if such airtags are being manufactured en-masse.

We allowed the creation of a global tracking network under the false pretense of privacy. The entire Find My security model falls apart when considering "malicious" tags, and Apple knew about this from the start.

[1]: https://github.com/Guinn-Partners/esp32-airtag

I would argue that it is not misleading -- the website domain is, after all, "breakingthe3ma.app".

The title of the paper presents a more academic angle, and is intended to highlight what the "learned lessons" are, but let's not forget that Threema was vulnerable to our attacks for 10+ years.

> well-reviewed zero-footgun nacl.SecretBox()-style thing for this use case, but there simply isn't.

You'd be surprised, but I've seen designers who managed to shoot themselves in the feet with SecretBox() calls alone. Anything more complex than using a library that does the crypto for you calls for an external/crypto team review.

To put it in Igor's words, it is like "somebody baked a cake following a recipe, but without ever having tasted or seen a real cake".

The crypto design is brittle, but the practical attacks are somewhat limited. The reason why it's so disparaged by cryptographers it because it ignores several decades of cryptographic advances -- the whole saga of attacks on SSL / TLS<=1.2 taught us that key separation and clear protocol composition boundaries are important, but Telegram fails disastrously at these. Security proofs should be made before a protocol is used, not as an afterthought.

The real reason why I would not recommend Telegram is that chats (by default) and group chats (by necessity) are not encrypted. Telegram's servers will be eventually breached by someone. A malicious actor will be hired as a software engineer, or as an intern. When this happens, all you ever wrote in Telegram will be a plaintext at their disposal -- unacceptable in 2022, and post-Snowden.

Tarsnap does not actually look bad. But any client-to-server protocol that is not TLS1.3 will make cryptographers twitch, and (as noted in the documentation pages) compression is bound to offer a side-channel attack (if only an impractical one, with hundreds of queries per recovered byte).

The same research group working on the Telegram MTProto security analysis is behind these attacks on MEGA!

(I should add: disclosure, I work there too.)

This speaks volumes about the need of standardized encrypted cloud storage protocols.

It always surprises me how fragmented the entire space is: Syncthing "untrusted devices" support is still experimental, Nextcloud does support encryption, but it's hard to judge how trustworthy it is. Gocryptfs and ecryptfs should be solid, but they are hard to use in a browser or on mobile. Resilio, Borg, Tarsnap, EteSync -- yet more protocols, and without clear security analyses.

Same holds for commercial cloud operators: support for client-side encryption is starting to appear (Google Drive), but without an open, standardized client you still need to trust software from the cloud provider, which mostly defies the point of encrypting in the first place.