- cypherpunks - lists.cpunks.org

Coderman - a cloudflare-NSA salesman.
by Punk-BatSoup-Stasi 2.0 11 Jan '21

11 Jan '21

coderman has promoted the use of shitflare DNS servers repeatedly, laughably 'arguing' that a centralized NSA server (which is of course just what shitflare is), is 'better' than the more decentralized ISPs' servers. FURTHERMORE, he is advocating the use of 'dns over https' which means that the connection between the shitflare-NSA global server is 'encrypted' preventing any NSA competitors from spying as well. Which is of course the most basic plan of the US military of which coderman is an agent. So again, the guy wants all DNS queries to go straight to the NSA.

1 0

Re: Where does this ' Coderman ' Jackass get off?
by professor rat 11 Jan '21

11 Jan '21

" Its those who make peaceful change impossible that make violent revolution inevitable " Oliver Tambo I have peacefully requested the USA surrender to the anarchic internet in general and a revived PAM-FutureMaps in particular, every year since 2009. And you have a moral problem? Thank fuck its not a REAL problem! Fuck off C-man.

1 0

Tactical support for anti-trust
by professor rat 11 Jan '21

11 Jan '21

I think this is warranted on the basis that SV companies are the new Robber Barons. Bill Gates is a long time target of ours - continuously deadpooled since 97 ( CJ? ) And he's since been joined by Ellison, Thiel, Bezos, Zuckface, Dorsey, etc The usual suspects. Even Tim Cook, whose crypto annoys the FBI enough for them to embarrass themselves, again, needs killing on the basis that a benign despot can easily be worse than a malign one. Of all tyrannies, a tyranny sincerely exercised for the good of its victims may be the most oppressive. It would be better to live under robber barons than under omnipotent moral busybodies. ..." etc... CS Lewis

1 0

Where does this ' Coderman ' Jackass get off?
by professor rat 11 Jan '21

11 Jan '21

Every revolutionary cypherpunk is in a legit state of violent revolt against every nation-state in general the USSA in particular. " National borders are not even road humps on the information superhighway " And here comes this cuntface " Coderman " is again with the detailed technical bumf that is so boring Perry probably wouldn't print it. Mongo would barf. Fuck Telegram. Cypherpunks is a list for anarchists to discuss how strong-crypto helps ( or hurts in some cases) global anarchism - its treason to this list to do what this ' Coderman ' jackass keeps doing. Statist bores are not welcome here - kindly fuck off and let us get on with the social revolution. Tia.

2 1

Cryptography Dispatches: The Most Backdoor-Looking Bug I’ve Ever Seen
by coderman 11 Jan '21

11 Jan '21

https://buttondown.email/cryptography-dispatches/archive/cryptography-dispa… Cryptography Dispatches: The Most Backdoor-Looking Bug I’ve Ever Seen 2021-01-10 Welcome back to [Cryptography Dispatches](https://buttondown.email/cryptography-dispatches?tag=header), my lightly edited newsletter on cryptography engineering. PSA: I've been doing some [livecoding on my Twitch channel](https://www.twitch.tv/filosottile), working on [age](https://age-encryption.org), check it out! — Filippo This is the story of a bug that was discovered and fixed in Telegram’s self-rolled cryptographic protocol about seven years ago. The bug didn’t get any press, and no one seems to know about it, probably because it was only published in Russian. To this day, it’s the most backdoor-looking bug I’ve ever seen. Google Translate does a good enough job on the [original article](https://habrahabr.ru/post/206900/), which is still available on Habr, but I’m going to walk you through it along with some context. Telegram is a popular chat app that uses its own… bizarre protocol to encrypt chats, called MTProto. The protocol is used both to encrypt all messages to the Telegram server, and to encrypt opt-in 1:1 end-to-end “Secret Chats”. In text I can’t do justice to the facial expressions of cryptographers when you mention Telegram’s protocol, so just believe me that it’sweird. The current consensus seems to be that the latest version is not broken in known ways that are severe or relevant enough to affect end users, assuming the implementation is correct. That is about as safe as leaving exposed wires around your house because they are either not live or placed high enough that no one should touch them. The original version was, however, completely broken, in the most puzzling of ways. End-to-end Telegram chat sessions use [finite-field Diffie-Hellman](https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_ex… to establish a shared key between the two participants. The negotiation happens through messages relayed by the Telegram server. Diffie-Hellman is a fundamental building block of many cryptosystems, and it allows two parties to establish a shared secret that any eavesdroppers can’t derive. It is however only one part of a secure key exchange, because an attacker capable of intercepting the messages could simply establish two separate sessions with the two parties, carrying out a[Person-in-the-Middle](https://en.wikipedia.org/wiki/Person-in-the-middle_… attack. The parties need some way to verify they derived the same secret. In TLS, they use a signature from a certificate. In most secure chat apps, there is a fingerprint (“Safety Numbers” in Signal) that the two parties can compare out-of-band. What’s important is that if the two sides derived the same secret, they can be sure no one else has access to it. The Telegram key exchange is described in [the “Key Generation” section of Telegram’s end-to-end API docs](https://web.archive.org/web/20131220000537/https://core.telegram.org/…. Concretely, Alice requests the DH parameters (p, g) from Telegram, painstakingly verifies them, computes a random a value, and sends g^a mod p to Telegram. Bob receives (p, g, g^a mod p), similarly computes b and g^b mod p, and sends the latter back (along with a truncated hash of the derived key, for some reason). Now, normally the two sides would compute the shared key as (g^a)^b mod p and (g^b)^a mod p. Instead, the original version of MTProto computed it as (g^a)^b mod p XOR nonce where nonce was an arbitrary, supposedly random value sent by the server along with the peer’s public contribution. This was a completely non-standard and useless addition, and all it did was let the server perform an undetected Person-in-the-Middle attack. Let’s see how. In a normal PitM, the server negotiates two separate Diffie-Hellman sessions with Alice and Bob, who end up with different shared keys, which they could detect by comparing fingerprints. Alice Telegram Bob a = random() A = g^a mod p -> t = random() T = g^t mod p -> b = random() <- B = g^b mod p key = T^b mod p <- T key = T^a mod p T^a mod p != T^b mod p With the nonce addition, however, the server could “fix” Alice’s key to match Bob’s by manipulating Alice’s nonce. The two parties would end up with the same fingerprint, and couldn’t tell that an attack happened, but the server (and no one else) would know the shared key, allowing it to decrypt all messages. nonce_bob = random() key_bob = T^b mod p XOR nonce_bob nonce_alice = A^t mod p XOR B^t mod p XOR nonce_bob key_alice = T^a mod p XOR nonce_alice = T^a mod p XOR (A^t mod p XOR B^t mod p XOR nonce_bob) = B^t mod p XOR nonce_bob = key_bob Why do I say this addition was useless? Because it literally had no purpose! Indeed, the vulnerability was [fixed by silently removing the nonce step from the docs](https://web.archive.org/web/diff/20131220000537/20131225140924/http:/…. [A later API revision](https://core.telegram.org/constructor/encryptedChatRequested?laye… removed the nonce parameter with the caption “Improve secret chats”. All [the original API reference](https://web.archive.org/web/20131028041748/http://core.telegram.… said about the nonce is “Random server sequence for calculation of key”. I never heard a plausible explanation for why the designers of MTProto went out of their way to add useless complexity to their protocol, with the only outcome of making undetectable interception possible. Edit (2021-01-11): [@asdofindia linked me on Twitter](https://twitter.com/asdofindia/status/1348491279798128641) to [an official statement by Telegram about this](https://telegram.org/blog/crowdsourcing-a-more-secure-future) that I couldn’t find anymore. It claims the nonce was there to protect clients with weak random number generators. Here’s what I had buried into a footnote when I couldn’t find a citation to attribute that explanation to Telegram: > This doesn’t make sense for a number of reasons: 1) clients with weak randomness are likely to be toast anyway, because Telegram’s bizarro not-a-MAC relies on randomness in the payload to avoid an offline decryption oracle (there is a plaintext hash of the payload on the wire, I told you this was weird!); 2) the API also allows clients to request random bytes from the server to XOR with their secret share; and 3) defending against weak randomness by relying on a server contribution defends against everything but the server, which is the relevant attacker in the end-to-end setting. (Said another way, anyone that can intercept client-server messages can see the extra randomness, making it moot.) Non-practitioners might think this is a reasonable defense in depth, belts and suspenders kind of thing, but in cryptography engineering adding complexity to defend against scenarios that lead to compromise anyway is simply pointless. Anyway, it’s been a while, the world is a different place now, and maybe [Hanlon’s razor](https://en.wikipedia.org/wiki/Hanlon%27s_razor) cuts deeper than I thought. I think there are better reasons not to use Telegram today than this old bug , but it’s still what I think about every time people talk about far-fetched “bugdoors”. The bar is high!

1 0

Welcome to Belmarsh
by professor rat 11 Jan '21

11 Jan '21

https://www.hitc.com/en-gb/2020/01/16/inside-belmarsh-prison-how-many-episo… A likable journalist! We ought to have him stuffed.

1 0

Interesting Engineering: Institute Breaks Record with 125,000 Gbps on an Optical Fiber | IE
by jim bell 11 Jan '21

11 Jan '21

Interesting Engineering: Institute Breaks Record with 125,000 Gbps on an Optical Fiber | IE. https://interestingengineering.com/institute-breaks-transmission-world-reco…

1 0

New York Post : Rein in abusive Big Tech republic
by jim bell 11 Jan '21

11 Jan '21

New York Post : Rein in abusive Big Tech republic. https://nypost.com/2021/01/10/rein-in-abusive-big-tech-republic/ Jim Bell's comment: The article is correct. The acts of these biased media thugs is indeed a violation of Anti-Trust laws.

1 0

BleepingComputer: Hacker used ransomware to lock victims in their IoT chastity belt
by jim bell 11 Jan '21

11 Jan '21

BleepingComputer: Hacker used ransomware to lock victims in their IoT chastity belt. https://www.bleepingcomputer.com/news/security/hacker-used-ransomware-to-lo… Jim Bell's comment: "Come again ?"

1 0

Japanese graffiti next to my home and a curious story
by Cecilia Tanaka 11 Jan '21

11 Jan '21

Tried to send a curious link to you and Juan, but your server rejected my message, so I am trying to wish you a lovely life since then... :D When I was 16 years old, had very long hair and my favorite color was red. Still is red, but I love all the colors... My mom said it was a young version of me in the graffiti and, strangely, I confess I thought the same when I saw it at the first time. O.o Koi fishes brings prosperity. I need to meet Carla, the girl who did these awesome works. Japanese Graffiti Next To My Home <https://imgur.com/gallery/NKW0MPx> And this is the interesting link: < http://unknownmisandry.blogspot.com/2015/11/okato-take-15-year-old-murderes… > The references to myths, gods, and talismans are interesting. Bonus: a child trying to become a serial killer to protect his older brother. I love you , John. Be well, please. Do not dare to die before me! :P Ceci ---------- "Don't let anyone rob you of your imagination, your creativity, or your curiosity. It's your place in the world; it's your life. Go on and do all you can with it, and make it the life you want to live." - Mae Jemison

1 0