cross-posted from: https://community.hackliberty.org/post/4425 >"Just over a week ago, we announced that Iranian censors had started blocking all Signal traffic in the country. As an interim solution to help people in Iran get connected again, we’ve added support in Signal for a simple TLS proxy that is easy to set up, can be used to bypass the network block, and will securely route traffic to the Signal service."

cross-posted from: https://community.hackliberty.org/post/2113 These repositories contain an archival fork of the Tornado Cash and Tornado Cash Nova source code base. They are maintained on Github by Matthew D. Green of Johns Hopkins for teaching and research purposes. Tornado Cash and Tornado Nova are open-source coin mixing tools that were developed by an independent team of software developers and deployed onto Ethereum and several other blockchains. On August 8, 2022 the Office of Foreign Assets Control (OFAC), a division of the US Treasury, declared "Tornado Cash" and "Tornado Cash Nova" to be Specially Designated Nationals (SDNs): the result was to effectively sanction the Tornado Cash organization, its software development repositories, and the main smart contract deployment on Ethereum. This move to sanction Tornado Cash represents the first instance in which the US government has applied economic sanctions to an open source software project. As a result of this announcement, several cryptocurrency exchanges have banned users who interact with the Tornado Cash smart contract address on Ethereum. Within hours of the OFAC announcement, Github shut down the user accounts of all known Tornado Cash developers and removed the source code repositories owned by Tornado's Github organization. While Github succeeded in removing the original copies of all Tornado source code repositories, they did not remove all "forks" of the code made by GitHub users. Several of these forks were recently collected and (further) forked by contributors to the tornadocash-community organization. Those folks did the hard work. The current repository is simply another fork of the repositories they collected. If you want a copy of the code on a more durable decentralized medium, there are copies of (limited) repositories on IPFS. I certainly don't warranty these (or any of this code), and you should carefully check hashes against the repositories on Github and in the Wayback Machine just in case: - Tornado Nova: `ipfs://bafybeiho72nozeq2mi6egptem77omhujt5ovpx4jjskg5sz2ti57zlunmm` - Tornado Cash Classic: `ipfs://bafybeicu2anhh7cxbeeakzqjfy3pisok2nakyiemm3jxd66ng35ib6y5ri`

cross-posted from: https://community.hackliberty.org/post/309

cross-posted from: https://community.hackliberty.org/post/18 > I put together a short paper on understanding the underlying mathematics of RSA encryption. I hope it helps others to understand what is happening at a fundamental level with RSA

cross-posted from: https://community.hackliberty.org/post/17

cross-posted from: https://community.hackliberty.org/post/25302

cross-posted from: https://community.hackliberty.org/post/20087 Earlier this year, [Cendyne](https://cendyne.dev/) published [A Deep Dive into Ed25519 Signatures](https://cendyne.dev/posts/2022-03-06-ed25519-signatures.html), which covered some of the different types of digital signature algorithms, but mostly delved into the Ed25519 algorithm. Truth in advertising. This got me thinking, “Why isn’t there a better comparison of different elliptic curve signature algorithms available online?” Most people just defer to SafeCurves, but it’s a little dated: We have complete addition formulas for Weierstrass curves now, but SafeCurves doesn’t reflect that. For the purpose of simplicity, I’m not going to focus on a general treatment of Elliptic Curve Cryptography (ECC), which includes pairing-based cryptography, Elliptic-Curve Diffie-Hellman, and (arguably) isogeny cryptography. Instead, I’m going to focus entirely on elliptic curve digital signature algorithms.

cross-posted from: https://community.hackliberty.org/post/12439 This post is about running Rocket.Chat on Constellation, which gives, well, "always encrypted" Rocket.Chat 🙂 This is cool, because "always encrypted" Rocket.Chat shields the entire server-side of Rocket.Chat from the (cloud) infrastructure and ensures that all data is always encrypted - even during processing in memory.

cross-posted from: https://community.hackliberty.org/post/10450 Join the discussion at GitHub - net4people/bbs

cross-posted from: https://community.hackliberty.org/post/8851

cross-posted from: https://links.hackliberty.org/post/136 > cross-posted from: https://community.hackliberty.org/post/77 > > An entity controlling MEGA’s core infrastructure can tamper with the encrypted RSA private key and deceive the client into leaking information about one of the prime factors of the RSA modulus during the session ID exchange. More specifically, the session ID that the client decrypts with the mauled private key and sends to the server will reveal whether the prime is smaller or greater than an adversarially chosen value. This information enables a binary search for the prime factor, with one comparison per client login attempt, allowing the adversary to recover the private RSA key after 1023 client logins. Using lattice cryptanalysis, the number of login attempts required for the attack can be reduced to 512.