winterdeaf (u/winterdeaf)

winterdeaf commented on Baby is healed with first personalized gene-editing treatment nytimes.com/2025/05/15/he... · Posted by u/jbredeche

alexey-salmin · 7 months ago

Technically lesswrong is about rationalists not effective altruists, but you're right in a sense that it's the same breed.

They think that the key to scientific thinking is to forego the moral limitations, not to study and learn. As soon as you're free from the shackles of tradition you become 100% rational and therefore 100% correct.

winterdeaf · 7 months ago

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.

winterdeaf commented on Apple and Google deliver support for unwanted tracking alerts in iOS and Android apple.com/ca/newsroom/202... · Posted by u/WalterSobchak

throwaway63467 · 2 years ago

Will this work with malicious tags as well? I.e. tags that are designed to not communicate with a given phone but with other devices nearby? Can that be detected? My understanding is that regular tags will communicate with all phones, but maybe there’s a way to differentiate who to respond to or change identity for every ping? Not familiar with the exact protocol but basically many different tags near a phone wouldn’t trigger the warning, so if a tag can produce multiple identifiers that the adversary controls it could still evade detection?

winterdeaf · 2 years ago

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

winterdeaf commented on Apple and Google deliver support for unwanted tracking alerts in iOS and Android apple.com/ca/newsroom/202... · Posted by u/WalterSobchak

winterdeaf · 2 years ago

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

winterdeaf commented on Breaking the Threema Secure Messenger breakingthe3ma.app/... · Posted by u/winterdeaf

tmalsburg2 · 3 years ago

The title of this submission is editorialized and misleading. @dang, please change to the original title "Three Lessons from Threema -- Analysis of a Secure Messenger".

winterdeaf · 3 years ago

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.

winterdeaf commented on MEGA: Malleable Encryption Goes Awry mega-awry.io/... · Posted by u/tptacek

mappu · 4 years ago

I think this level of key management is relatively simple for a production application. There are not really too many pieces and certainly no unnecessary steps (the mitigation recommendation was to add more keys, not fewer).

The interesting part is really just the first step - starting with a user's password, to statically derive a service-authentication key and a data-encryption key that the service provider ostensibly never sees.

At $DAYJOB we independently came up with this same zero-knowledge solution too, using slightly different primitives. Ideally there'd be some well-reviewed zero-footgun nacl.SecretBox()-style thing for this use case, but there simply isn't.

winterdeaf · 4 years ago

> 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.

winterdeaf commented on MEGA: Malleable Encryption Goes Awry mega-awry.io/... · Posted by u/tptacek

taneq · 4 years ago

Interesting! While you're here, is there anything you can add to the general debate about Telegram's crypto design? I see a lot of people here disparaging it, but nothing really from Telegram to explain what choices were made or why.

winterdeaf · 4 years ago

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.

winterdeaf commented on MEGA: Malleable Encryption Goes Awry mega-awry.io/... · Posted by u/tptacek

cperciva · 4 years ago

Resilio, Borg, Tarsnap, EteSync -- yet more protocols, and without clear security analyses.

I did analyse the security of Tarsnap as I was writing it, for what it's worth.

winterdeaf · 4 years ago

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).

winterdeaf commented on MEGA: Malleable Encryption Goes Awry mega-awry.io/... · Posted by u/tptacek

tatersolid · 4 years ago

Reminds me of Telegram’s ad-hoc design with so many primitives lashed together without any engineering or analysis. “More crypto” in your implementation is rarely better for security.

This is a great teaching example for the “don’t roll your own crypto” proponents.

winterdeaf · 4 years ago

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.)

winterdeaf commented on MEGA: Malleable Encryption Goes Awry mega-awry.io/... · Posted by u/tptacek

winterdeaf · 4 years ago

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.