A New HOPE
The “Mathematical Mesh” is an open standard using JOSE to carry encrypted, signed payloads. It’s designed to unify both document encryption and key management.
The idea is that all encrypted data and associated keys are tied to a single “mesh account”.
This extends the idea of “threshold cryptography” that Phillip Hallam-Baker presented during HOPE 2020; to recap, the idea here is to have multiple device coordinate in the generation of a private key such that a key is only insecure if all cooperating devices defect. All devices then get a copy of this key.
(These talks continue to be annoyingly/worryingly light on details.)
The mesh provides a personal PKI, with trust relationships between PKIs established in what looks to be a TOFU fashion. Traditional CAs can still act as “trusted” brokers. Cryptographic identities can contain contact information (so a bit like vCards), and can persist long-term despite changes in this metadata.
Encryption keys can also be added to groups, which can be administered in an m/n fashion. Groups keys are split, such that the “mesh service provider” holds half of the associated private key while users hold the other half of the key (key halves are per user, with the split depending on their public key in a fashion that can only be reversed with the user’s private key).
Hallam-Baker has an interesting take on MFA - that what’s important isn’t multiple factors, but that devices be notified when sensitive actions occur and have the ability to accept/reject those actions.
It sounds like mesh service providers are required to have domain names. So this is not decentralized in the same way that DIDs are. Hallam-Baker is looking to get anti-virus, VPN, and similar security-focused vendors offer mesh accounts.
Mesh service providers are trusted - not to decrypt data, but to grant and withdraw the right to encrypt/decrypt data.
There are no threshold-ready quantum-resistant algorithms, though some of NIST’s finalists could potentially be adapted.
Beyond End-to-End (Archive.org)
Library: An accessible and organized collection of materials.
The “accessible” is important here, as otherwise it’s just someone’s collection. And the killer feature of “accessibility” is “free”.
Interesting tradition from Thailand - the day someone dies, their friends preserve their memories and thoughts about the departed in a book.
A significant amount of writing in Bali is done on palm leaf strips!
Physical and digital materials have almost opposite, and thus complimentary, affordances.
Reasons why (free) digital libraries are important:
An interesting vision of the future: The ability of libraries to print books - or parts of books - on demand.
Libraries a source of trust for untampered, original materials.
Apparently Wikipedia is starting to deep link into books stored on the Internet Archive. Cool!
Knowledge accumulation is a fundamental part of how society functions. If we want to have functional societies, we have to have functional libraries.
- Davide Semenzin, “Why Building Digital Libraries Matters”
There is an open source DIY book scanner that people can use to digitize their own books. This is slower - but much cheaper - than the system the Internet Archive uses.
Archive.org’s digital lending system works in an analogous way to ordinary libraries, in that books can only be accessed by a single account at a time.
BitPay is essentially a currency conversion platform - it accepts cryptocurrency from users but then settles with merchants with fiat currency.
All three speakers talk about privacy not in terms of secrecy, but rather in terms of selective disclosure - the control of what information is disclosed to which people/entities. While all of the speakers are circling around the same idea of what privacy is, they all take this approach to varying extremes.
A good point: By correlating where and when a transaction appears on a blockchain, general information about the location of the machine originating this transaction can be determined. This can be guarded against by using proxychains or Tor when reaching out to blockchain RPC endpoints.
That said, before even thinking about proxychains and Tor you should practice account/identity segmentation. Two of the speakers recommend using a different account/identity/keypair for every application.
Interesting difference between Bitcoin and Ethereum - Bitcoin is a transaction-centric network, while Ethereum is account-centric. Pseudonymity is easier in the Bitcoin model.
When using a mixer, it’s important to:
Mixers are very expensive - upwards of $100 or more in gas fees to transact in/out of the pool!
The idea here is to create a consensual botnet (similar to the idea behind BOINC). Each client runs a sandboxed bot that fires up a selenium-controlled browser during system idle time. Clients poll a central server looking for new studies (rather than using server push; this approach is easier to implement and more privacy-preserving); users can ask the bot for a “ride along” that will show them what the bot is doing and will give them the option (in some studies) to offer their own judgements about what the bot is experiencing.
An APK is just a renamed zip file with a specified directory/file structure. Supplemental, app-specific OBB files can also be split out for apps that require a large quantity (100+ MB) of assets.
APKs can be split by locale/device/DPI, etc. to reduce download size.
Some third-party app stores have introduced their own variants of the APK format (mostly these seem to be about bundling multiple APKs into a single file).
The same app is sometimes served up with different permissions depending on whether they’re hosted on the Google Play Store or Huawei App Gallery. Mostly, but not always, these appear to be specific Huawei-specific permissions (sometimes these permissions will also appear in apps from the Google Play Store).
The canonical F-Droid repos use a reproducible build system (this setup doesn’t apply to non-canonical F-Droid repos).
This defines the app’s required permission, the hardware access it needs, the services it uses, and the classes it wants to load/run (Android limits what classes an app can load based on what’s defined in the manifest).
jadx tool can be used to decompile Dalvik bytecode back to Java. It’s error-prone, but does produce very readable code).
apktool reverses Dalvik bytecode into smali (an intermediate representation). This works perfectly, but smali is basically assembly…
The general methodology here is to use
jadx to determine interesting code areas, and then switch to
apktool to view a more accurate code representation. While
jadx decompilations can’t be recompiled,
apktool smali representation can, so this approach also allows you to insert breakpoints.
adb logcat -pid=$APP_PID to monitor app execution (including library loading via
strace -p $APP_PID command can be used to see raw system commands. Useful for seeing what Android malware is really doing.
A call out to
frida. Particularly useful abilities:
file.delete()calls (so you can read app temporary files after its run is complete).
The Tor Hydra manifest defines a lot of classes/scenes that don’t exist in the original APK; this indicates code that is dynamically downloaded/loaded after application install.
You can actually get
mitmproxy running on a rooted Android phone using a local Debian installation set up using Linux Deploy (the provided demonstration uses LineageOS). A second phone then runs the app being audited, with the rooted phone being used as a proxy. This allows dynamic analysis to be taken out of the lab and into the field!
Android only allows apps to be upgraded to new versions that are signed with the same key as the currently installed version.
VPNs and proxies offer no protection from a network-level adversary (read: NSA). Even Tor is breakable in this model (though it’s more difficult to do so).
Layering services can provide additional obfuscation, however.:
Client -> VPN -> Tor -> Hidden Service -> VPN
Basically, using the hidden service as a second VPN hop.
The tricky part here is bootstrapping the server running the hidden service, since the process of doing that can be linked back to you. You need to do this in an anonymous/pseudonymous way (including payments!), which really limits your options!
TLS v1.3 makes it much harder to do bulk data harvesting with later decryption. On the other hand, there’s been an increased deployment of Netflow monitoring, which makes VPN (and Tor) deanonymization much easier to do now. Advances in machine learning also make correlation attacks more efficient.
Netflow is using small variations in packet behavior (jitter, etc.) to correlate packets.
(Apparently, a lot of undersea cables that come onshore in New York City. So many so that the NSA actually maintains a tap there.)
It’s very easy to write proxies in Go; there’s more code in Python, but it’s generally harder to adapt.
But Netflow analysis allows these protocols to be easily distinguished from normal traffic (well, maybe not Nym, but that still hasn’t had a usable release). Ideally you want your traffic to look like a more innocuous protocol (like RDP).
Obviously, if you use the same wallet for two transactions, those transactions are linkable. But there are less obvious ways to leak data.
Many wallets, like MetaMask, use central RPC services (like Infura). Using one of these wallets allows wallets to be correlated. This can be avoided by using different copies of MetaMask in different VMs. But that’s not enough - you also need to randomize where (VPNs, etc.), when, and for what (identity separation) you do with these different wallets.
Air gapped hardware wallets are good (just transfer data using QR codes). Plug here for Keystone - not only is it air gapped, it’s able to display all of the transaction metadata (which Ledger and Trezor can’t do).
Always double-check the transaction data on the hardware wallet before confirming the transaction. This might mean checking the transaction hash, which can be laborious.
For masking IP addresses, use a VPN or Tor.
A plug for Qubes OS here.
Also, a shout-out to Michael Bazzell’s “Extreme Privacy” book (and other works).
Interesting… Ethereum is making moves towards anonymizing/encrypting transactions. It’s not clear from the presentation what this looks like.
The Brave Wallet is based on an older version of MetaMask.
The default Uniswap platform bans a set of tokens and has a lot of tracking. Uniswap.ninja is an alternative front-end without these restrictions.
Shout out for Arweave as a storage protocol. Libgen is now hosted on Arweave.
The standard for granting a subpoena is simply relevancy. You can only assert the 5th Amendment if you’re a first party - third parties that simply hold someone else’s data have no protection here.
Nym is an overlay network similar to Tor. The big difference is that it’s a mixnet, which routes equally-sized, regularly spaced traffic amongst multiple machines. There packets are mixed in with packets for other users as well as randomly generated cover traffic.
Nym is an incentivized network, unlike Tor. This works similar to how incentivization works on blockchains, except rather than proof-of-work Nym uses proof-of-mixing.
Wasabi is a Bitcoin wallet with a number of privacy-preserving features. Wasabi automatically uses mixer services; note that there’s a trade-off here between speed and privacy, as the longer your coins remain within the mixer the harder it is to “demix” your transactions. (“Longer” here means days-to-months.) The mixer feature in Wasabi is called “coin join”, and works identically to network mixers like Nym (except it’s routing transactions in the blockchain rather than packets over the Internet).
Wasabi can connect a local Bitcoin node (Bitcoin nodes are much lighter than Ethereum nodes) or to external nodes via Tor.
Zcash offers “shielded” (non-public) and “transparent” transactions. Shielded transactions are accomplished using zero-knowledge proofs.
Tornado Cash provides mixing between Ethereum accounts. In the background what you’re actually doing is generating and then “redeeming” a zero-knowledge proof from a pool managed by a smart contract. This is anonymous unless you send cryptocurrency through Tornado Cash back to yourself, which is obviously deanonymizing. Ideally, you want to use Tornado Cash to send from one wallet to another, and these wallets should (appear) to have different IP addresses, time zones, geographic locations, etc.
That said, more than 50% of the transactions flowing through Tornado Cash are from large hacks, which has led to some services banning accounts that can be associated with the service. The IRS also looks for this; using Tornado Cash drastically increases your chance of being audited.
zkSync is an L2 Ethereum chain that is also powered by zero knowledge proofs, and more-or-less automatically provides the same anonymity benefits as Tornado Cash.
That said… Chain analysis firms are essentially network attackers. With enough data covering enough time, it becomes very easy to deanonymize anything.