HackerTrans
TopNewTrendsCommentsPastAskShowJobs

maqp

910 karmajoined 11 năm trước

comments

maqp
·4 ngày trước·discuss
Probably not. It's been ~13 years when Snowden said what the NSA is doing is going around the encryption by hacking endpoints. Post quantum cryptography doesn't change any of that. You can still lift TLS keys with exploits for transparent MITM. I'd imagine it's much better ROI to look for vulnerabilities with Mythos, than to attack the algorithms.
maqp
·29 ngày trước·discuss
PSA: https://dr.loudness-war.info/ is a great place to look for info on dynamic range of releases, and also, a great place to find new music with excellent dynamic range.
maqp
·2 tháng trước·discuss
What are you hinting here? Surely you can make a positive claim with evidence to back it? A CEO of a big project like SimpleX wouldn't stoop as low as Pavel Durov?
maqp
·2 tháng trước·discuss
Same guy, always pretending we've never had the same discussion over and over here, Reddit and privacyguides, for years. You're always running away.

>The protocol is designed to provide packet-level anonymity

Anything you do to harden SimpleX on server side does not matter to user. Unless the client protects the user it's not really helpful. The user only has your word that the server is stripping the IP address from the package.

> so that neither of the servers can see which IP address talks to which IP address

Two computers that could be run by the same entity. Also, the entire public infrastructure is again either Akamai or Runonflux. 50% of SimpleX chats' metadata is accessible by a single company, which is not even you so you have no control over it.

>always choose server operated by another operator, to mitigate collusion risks.

How does Alice, Bob and Charlie choose a third VPS provider when there's only two?

>My problem with Tor is that after all these years it takes zero steps to prevent collusion and data sharing by Tor node operators [...] that independent parties run relays in the circuit - is simply untrue

I don't know how to tell you this, but 10,000 Tor relays is absolutely more diverse than two VPS provider companies.

You're already supporting Tor. You're already running Onion Service servers.

How about you stop running to the mountains once again, go visit what I wrote to you in the PrivacyGuides threads on Cwtch vs SimpleX and actually consider that.

>If people want to use Tor, it's their choice, and the app supports it. But we won't be integrating it.

Then maybe it's time to strip the "no identifiers" bullshit from your marketing language. If you can't be open upfront about the client leaking the IP-address and you're not fixing the leak, I have zero problems referring to you as the snake oil you are.
maqp
·2 tháng trước·discuss
The point is there is no public key capability in BB84 that requires pre-sharing a symmetric key.

You absolutely do get forward secrecy with pre-shared keys. You just need to make the protocol derive the next key with a cryptographic hash function, and deliver the iteration count with the packet so the recipient knows which key is the correct one. This is called a SCMIP or hash ratchet, and it's used e.g. in Signal protocol.

(As implementation details, you'll also want to hash the hash ratchet counter with the key to prevent theoretical loops, and you'll probably want to encrypt the ratchet counter during delivery with static header key, or the very least authenticate it.)
maqp
·2 tháng trước·discuss
QKD is interesting from the PoV of perfect secrecy. But AFAIK with e.g. BB84, the basis orientation communication (used to detect OTP delivery eavesdropping) is done with Wegman-Carter (unconditionally secure) authentication using... a pre-shared key.

So if you're only interested in computational security that is post-quantum, why not pre-share a symmetric key for some AEAD scheme? You'll get forward secrecy with hash ratchet and neither provides future secrecy in principle.

Neither solves the bootstrap and QKD requires a really, really expensive and complex infrastructure just to provide perfect secrecy which we're fine without.
maqp
·2 tháng trước·discuss
In 2006?
maqp
·2 tháng trước·discuss
Plus the company likes to advertise their product as more metadata-private than Tor Onion Service based messaging apps like Cwtch.

They lie by omission when they say that the service doesn't have any user IDs. What they really mean is, the application does not add its own long term identifiers. But by default, the application takes zero steps to anonymize your IP address from the server, meaning the server can very probably tell users apart.

It's also ridiculous that the entire public server infrastructure is hosted under two companies: Akamai and Runonflux. Roughly 50% of your conversations can be end-to-end correlated by a single VPS company.
maqp
·2 tháng trước·discuss
Thank goodness. Finally. Yeah I'm just not comfortable with 80-bit complexity against Grover, even if it's practically infeasible.
maqp
·3 tháng trước·discuss
Could we finally get SHA256 fingerprints. Or BLAKE2, or SHA3-256, or SHAKE256, or BLAKE3, or LITERALLY ANYTHING BUT SHA-1, pretty please?
maqp
·3 tháng trước·discuss
Some DJs use this principle when they need a hacky stage mic. They plug their headphones to the mixer's mic input, and shout to the speaker element.
maqp
·3 tháng trước·discuss
and many LEDs are weak photo-diodes, i.e. you get weak current when you shine a light to them.
maqp
·4 tháng trước·discuss
The sad part is, Instagram is exceptionally damaging to kids for a disjoint set of reasons.
maqp
·4 tháng trước·discuss
A lot of bug fixing relies on some mental model about the code. It manifests as rapid "Oh 100% I know what's causing" -heureka moments. With generated code, that part's gone for good. The "black box written by a black box" is spot on on, you're completely dependent on any LLM to maintain the codebase. Right now it's not a vendor lock thing but I worry it's going to be a monopoly thing. There's going to be 2-3 big companies at most, and with the bubble eventually bursting and investor money dying, running agents might get a lot more expensive. Who's going to propose the rewrite of thousands of LLM-generated features especially after the art of programming dies along with current seniors who burn out or retire.
maqp
·5 tháng trước·discuss
>Loading your messages on Signal can take quite a while.

Yeah if you have to go through hundreds of ratchet steps, yeah it will take time. That's expected. The only way to make it faster than that is to deploy it without privacy. That's cheating.

>Why are you ignoring the fact Signal actively prohibits third-party clients?

Because it's not a problem for security.

>Yes, Telegram is far from perfect, and inferior to Signal when it comes to E2EE.

Telegram's lack of ubiquitous E2EE is a blocking issue. Signal's wait times is a problem that goes away with 5G, 6G etc., and with them nanometers going down.

>But what makes you reject the proprieatry blob claim when it's true?

What blobs? Firebase? I have bad news for you wrt Telegram https://github.com/DrKLO/Telegram?tab=readme-ov-file#compila...

>Because your favorite messenger is being attacked?

Not my favorite messenger. Nor is it my messenger. Signal is the best messenger for day-to-day use though.
maqp
·5 tháng trước·discuss
The server IPs are hard-coded into the Telegram client's source:

https://github.com/DrKLO/Telegram/blob/d7deedfa33ddfa51c72a5...

You know you can just run

$ git clone https://github.com/DrKLO/Telegram.git && cd Telegram && FILE="TMessagesProj/jni/tgnet/ConnectionsManager.cpp" && git log --reverse --format='%ad %h %s' --date=short -S'149.154.175.50' -- "$FILE" | head -n 1 && git log --reverse --format='%ad %h %s' --date=short -S'2001:b28:f23d:f001:0000:0000:0000:000a' -- "$FILE" | head -n 1 && git log --reverse --format='%ad %h %s' --date=short -S'149.154.167.51' -- "$FILE" | head -n 1 && git log --reverse --format='%ad %h %s' --date=short -S'95.161.76.100' -- "$FILE" | head -n 1 && git log --reverse --format='%ad %h %s' --date=short -S'2001:67c:4e8:f002:0000:0000:0000:000a' -- "$FILE" | head -n 1 && git log --reverse --format='%ad %h %s' --date=short -S'149.154.175.100' -- "$FILE" | head -n 1 && git log --reverse --format='%ad %h %s' --date=short -S'2001:b28:f23d:f003:0000:0000:0000:000a' -- "$FILE" | head -n 1 && git log --reverse --format='%ad %h %s' --date=short -S'149.154.167.91' -- "$FILE" | head -n 1 && git log --reverse --format='%ad %h %s' --date=short -S'2001:67c:4e8:f004:0000:0000:0000:000a' -- "$FILE" | head -n 1 && git log --reverse --format='%ad %h %s' --date=short -S'149.154.171.5' -- "$FILE" | head -n 1 && git log --reverse --format='%ad %h %s' --date=short -S'2001:b28:f23f:f005:0000:0000:0000:000a' -- "$FILE" | head -n 1

To get when the IPs first appeared, right? :D

2015-09-24 6bb7547f5 Update to 3.2.2

2015-09-24 6bb7547f5 Update to 3.2.2

2015-09-24 6bb7547f5 Update to 3.2.2

2020-06-04 dceccae0b Update to 6.2.0 (1984)

2015-09-24 6bb7547f5 Update to 3.2.2

2015-09-24 6bb7547f5 Update to 3.2.2

2015-09-24 6bb7547f5 Update to 3.2.2

2015-09-24 6bb7547f5 Update to 3.2.2

2015-09-24 6bb7547f5 Update to 3.2.2

2015-09-24 6bb7547f5 Update to 3.2.2

2015-09-24 6bb7547f5 Update to 3.2.2

They've been the same IP addresses for ELEVEN years, and they precede the article you linked by THREE YEARS.

They're not playing the catch-up with Russian government. Either Russian government is completely incompetent in that they're blocking 3,000,000 IP addresses and failing, or they are LYING about attempting to block it, which would indicate Telegram is a Russian op.
maqp
·5 tháng trước·discuss
Nice touch with the IP :D
maqp
·5 tháng trước·discuss
The ratchets would have different state yes. The MITM would mix in different entropy into the keys' states. It's only detectable if the MITM ever stops. But since the identity key exfiltration only needs to happen once per lifetime of installation (longer if key is backed up), the MITM could just continue forever since it's just a few cycles to run the protocol in the server. You can then choose whether to read the messages or just ignore them.

One interesting way to detect this would be to observe sender's outgoing and recipient's incoming ciphertexts inside the client-to-server TLS that can be MITM'd by users. Since the ratchet state differs, so do the keys, and thus under same plaintext, so do the ciphertexts. That would be really easy way to detect MITM.
maqp
·5 tháng trước·discuss
The real story is, MAX is there to scare people into Telegram. Durov isn't your friend, neither is Putin who doesn't bother blocking connections to the server.

>So I wouldn't count on its E2EE either.

This is the worst way to assses E2EE deployment. 5D-chess.

>Signal still requires a phone number and proprietary Google blobs on mobile.

Telegram also requires a phone number. If you didn't have double standards, I bet you'd have no standards.

>Many third-party Telegram clients exist

The official implementation and default encryption matters. 99.99% just assume Telegram is secure because Putin supposedly tries to block it. They don't know it's not E2EE. And no third party TG desktop client offers cross-platform E2EE or E2EE groups. IIRC there's exactly one desktop client that tries to offer E2EE 1:1 chats but that's not seamless. TG has no idea how to make seamless E2EE like Signal.

You ignoring that Signal is both open source and always E2EE and complaining about it's "proprieatry blobs" yet looking past TG's atrocious E2EE speaks volumes.
maqp
·5 tháng trước·discuss
Yeah it's really hard to block tally count of five IPs. https://telegramplayground.github.io/pyrogram/faq/what-are-t...

No wonder the great Russian firewall is struggling to keep TG at bay. Wake up.