Monero Observer

CT-017: Rethinking the Monero CCS: A cypherpunk proposal

Thu, 23 Nov 2023 UTC

This is the 17th report in the Cypherpunk Transmission series.

WiP: contact me (escapethe3RA) to propose edits.

Motivation

The recent Monero CCS incident¹ has highlighted the real need to restructure the existing community crowdfunding system. Reaching consensus and fixing this outstanding issue sooner rather than later is important for the Monero project as a whole.

Assumptions

Any community is built upon certain ideals. Monero is powered by a cypherpunk ‘engine’: our permissionless meetings and funding systems are key as they help us reach consensus and fuel our ecosystem. Anonymity is our strength and we can leverage it to create and maintain robust projects.

1. The status quo

Let’s look at an overview of the current CCS² system first, with its flaws and fortes:

Ideas stage: anyone can submit a proposal to do some work related to Monero.
Consensus stage: anyone can participate in the consensus mechanism by joining regular meetings focused on discussing proposals at the ideas stage.
- A proposal can be discussed in multiple meetings if consensus is that revisions are necessary.
- Previous contributors and/or proposers that have already completed proposal milestones pre-funding usually attract more support from the community.
- New, unknown proposers without any previous work or reputation usually attract more scrutiny and might be asked to complete some of their proposed milestones in advance in order to prove their skills.
- If consensus cannot be reached, proposals will be closed eventually.
- Proposers can decide to temporarily or permanently cancel their proposals at this stage.
- Proposers can resubmit new/revised proposals at any time.
Proposals move to the funding stage when consensus is reached.
- Anyone can donate anonymously to proposals listed on the funding page.
  - Funds donated for each proposal are held in wallets that are in the custody of Core members.
  - Excess funds are either reallocated to other proposals or moved to the General Fund wallet.
- It is very rare that proposals are not fully funded once they are listed on the funding page.
  - Core can occasionally step in to fund some ‘critical’ proposals from the General Fund wallet.
Proposals move to the work started stage some time after fully funded.
- Proposers can post status updates for each milestone.
- Community reviewers discuss proposal updates in regular meetings.
- Proposers can request funds to be released after completing milestones.
Proposals move to the completed stage after all milestones are completed/paid.
- If proposers do not request funds after completing proposals, funds remain in Core wallets indefinitely.

Here is how the process might look like from the perspective of all involved parties - proposers, reviewers, donors, and custodians:

<CCS>
Proposers:
	- Anon: Yes.
	- Receiving funds: Easy. 
	- Funding guaranteed: No.
	- Liability: Not if anon.
Reviewers/Community:
	- Anon: Yes.
	- Liability: No.
Donors: 
	- Anon: Yes.
	- Donating: Easy.
	- Delivery guaranteed: No.
	- Liability: Not if anon.
Custodians: 
	- Anon: No/Pseudo.
	- Custody: Hard.
	- Liability: Yes.

It is pretty clear why the CCS has been working ‘fine’ for years with its current architecture: anyone can participate anonymously, no need for proposers to set up and maintain funding systems, and there’s a quick and easy private donation path for everyone without the need to attend meetings - if it’s on the funding page, consensus has already been reached and the proposal was vetted by the community.

It is also obvious why the system was doomed to eventually fail: centralized 3rd party custody of funds. The CCS incident affected the public image of Monero negatively and also exposed the custodians, which are not anonymous, to further unnecessary personal risks.

2. Possible ways forward

Since the recent public disclosure, several ideas³ on the future of the CCS started floating around in the community. Unfortunately, most of them involve some kind of custody system, increased architectural complexity, and even some privacy sacrifices.

Although not full proposals, I believe it is important to briefly mention those ideas in this section and add my comments in bold:

buddy system / adopt a dev - a trusted third party will custody the funds and every proposal would have a different wallet (which is basically direct funding) [-3rd party custodians, -Extra complexity]

direct funding - advertise indivudual crowdfunding pages on the CCS funding required page (e..g kuno/btcpayserver/xmrstarter/monerofund/wishlist) [-Burden on proposers to maintain self-hosted payment systems]

multisig - 2/7 main wallet with a smaller hot wallet for convenient payouts. (hot wallet would require upwards of 600 xmr , possibly >1500xmr if payments are delayed by 2~3 months) [-MultiSig is experimental, -3rd party custodians, -Extra complexity]

many multisig wallets - using RINO for convenience, multisig wallets can be cycled once their balance reaches a certain amount so we never have 2600 xmr in one pot (if we ignore 9000~ sitting in the general fund) [-MultiSig is experimental, -3rd party custodians, -Extra complexity]

same setup as before but better - the main wallet is offline / never hot. file transfer method being the main attack vector, so optical data transfer is preferred e.g. via animated QR codes but we need to know if the implementation is secure. the “hot wallet” used for convenient payouts is now a hardware wallet. - [-MultiSig is experimental, -3rd party custody, -Extra complexity]

security through obscurity to protect against physical attacks - an unknown contributor(s) will custody the funds to reduce the threats on the individual and/or exact details of the security are kept hidden and certified “better than what we where doing before” [-3rd party custodians]

pledges systems [-Burden on donors and potentially on proposers, -Extra complexity]

keep status quo but w/ ‘better’ custodian setups (OPSEC/MS) [-3rd party custodians, -MultiSig is experimental]

These are just ideas, incomplete thoughts, and without further details and perhaps some systematic proposals, it is unclear if they would work in real life and how long it would realistically take to implement them.

3. A cypherpunk proposal

Note that this is a draft and feedback is encouraged.

A single alteration in how we view the system could push us forward in a cypherpunk direction: make proposers the ‘custodians’ without forcing them to self-host any payment systems.

Here’s how the new CCS would look like (changes in bold/strike):

Ideas stage: anyone can submit a proposal to do some work related to Monero.
Consensus stage: anyone can participate in the consensus mechanism by joining regular meetings focused on discussing proposals at the ideas stage.
- A proposal can be discussed in multiple meetings if consensus is that revisions are necessary.
- Previous contributors and/or proposers that have already completed proposal milestones pre-funding usually attract more support from the community.
- New, unknown proposers without any previous work or reputation usually attract more scrutiny and might be asked to complete some of their proposed milestones in advance in order to prove their skills.
- If consensus cannot be reached, proposals will be closed eventually.
- Proposers can decide to temporarily or permanently cancel their proposals at this stage.
- Proposers can resubmit new/revised proposals at any time.
Proposals move to the funding stage when consensus is reached.
- Anyone can donate to proposals listed on the funding page.
  - ~~Funds donated for each proposal are held in wallets that are in the custody of Core members.~~
  - Funds donated for each proposal are sent directly to the wallets of the proposers.
  - ~~Excess funds are either reallocated to other proposals or moved to the General Fund wallet.~~
  - Excess funds are considered a bonus for the already underpaid proposers.
- It is very rare that proposals are not fully funded once they are listed on the funding page.
  - Proposals remain on the funding page only for a preset number of days [~14/consensus] before being moved to the work started stage.
  - Proposers have the option to ask for a relisting on the funding page within a preset number of days after being moved to work started stage if they are not fully funded. This can be verified by the community using the viewkey provided by proposers.
  - Core can occasionally step in to fund some ‘critical’ proposals from the General Fund wallet.
Proposals move to the work started stage after the preset number of days [~14 days/consensus].
- Proposers can post status updates for each milestone.
- Community reviewers discuss proposal updates in regular meetings.
- ~~Proposers can request funds to be released after completing milestones.~~
Proposals move to the completed stage after all milestones are completed.
- ~~If proposers do not request funds after completing proposals, funds remain in Core wallets indefinitely.~~

Just by removing intermediaries, the attack surface has contracted considerably:

<CCSv2>
[NEW]
Proposers = Custodians:
	- Anon: Yes. (proposers are custodians)
	- Liability: Not if anon. (no extra burdens)
	- Custody: Easy. (decentralized)
	- Funding guaranteed: No. (same as before)
	- Receiving funds: Easy. (same as before)
[UNCHANGED]
Reviewers/Community:
	- Anon: Yes. (same as before)
	- Liability: No. (same as before)
Donors: 
	- Anon: Yes. (same as before)
	- Donating: Easy. (same as before)
	- Delivery guaranteed: No. (same as before)
	- Liability: Not if anon. (same as before)

Here are some of the pros of this version of the CCS:

easy, fast implementation due to a simplified architecture - proposers just need to include an XMR address in their proposals, backend changes should be minimal to the existing CCS (no reliance on experimental multisig, no reputation systems, no viewkey scans, no need to build complex platforms/features)
no 3rd party custodians, no centralization of funds - not adding any extra attack vectors by holding most funds in a single wallet, or recruiting extra people and exposing them to personal risks
no extra burden of any type on donors or proposers - everyone can easily work and donate anonymously without worrying about anything really (management, legal, etc)
no centralized security worries for the project - everyone is responsible for securing their own wallets, like in real life, which most of us are already doing anyway
no forced privacy loss - everyone is private by default, but proposers can opt to share their viewkey in order to prove their proposals were not fully funded during the first round (fits perfectly with how Monero works: private by default, optionally transparent)

And here are some of the potential (perceived) cons:

proposers could ‘run with the funds’ before completing proposals
there is no donation progress bar on the funding required page

The first point does not really apply to known contributrs and could be easily solved for new/unknown proposers by adding slightly more scrutiny to their proposals at the consensus stage. Totally anonymous new proposers without any previous work and street cred could easily prove themselves by completing one or more of their project milestones in advance. Even if they do decide to disappear after funded, the community still gets something in return.

Assuming a simple scenario:

Proposer A (anonymous, new, no previous work) submits proposal to develop X functionality in 3 milestones for 150 XMR (50x3).
Community could ask for milestone 1/3 to be completed first (before funding).
Proposer A agrees and completes milestone 1.
Community reviews work and greenlights the proposal for funding but only for milestone 2 (50 XMR).
Proposer A edits minimum funding required (only for milestone 2).
Proposal is moved to funding required stage for [~14 days/consensus] and then to work started stage.
Proposer does not ask for extra funding within [~7 days/consensus] and community considers proposal fully funded.
Proposer A completes milestone 2.
Community reviews work and greenlights the proposal for funding for the final milestone 3 (50 XMR). [..]
Proposer A returns with a new similar proposal after some time, but is now considered a ‘known contributor’ due to previous work that was completed successfully.
Community could agree to greenlight this second proposal for funding for 1 milestone (or more). [..]

Note that the proposer can only run with a maximum 1/3 of funds at any point, which is 50 XMR. However, the community still gets >50 XMR worth of work: if proposer quits before shipping M2, community gets to keep M1 work (50 XMR worth); if proposer quits before delivering M3, community gets to keep M1+M2 work (100 XMR worth).

The second point is really only a change in perspective and should not influence the process any. All donors contribute mainly because they want to help Monero and if they see 100 XMR minimum funding goal, they might donate once or more than once, the full amount, or less. It’s up to them. Some bigger donors might ask themselves why the project was not yet moved to the work started stage after they donated 100% of the goal. A simple explainer sentence and a timer [Proposal will be moved to Work Started in X days] replacing the progress bar should suffice.

The fact that any extra funds would go to the original proposers could also help solve our ongoing ‘starving devs’ situation and potentially encourage others to start contributing.

The proposal essentially removes the necessity for big centralized wallets which are primary targets to protect, fixes our ‘unclaimed funds’ issue, all without requiring the whole bureaucracy that other ideas demand by introducing unnecessary extra cogs and third parties into the system.

This revised CCSv2 could fit perfectly in the middle of our existing systems, somewhere between fully decentralized self-hosted funding systems and KYC/fiat/legal foundations a la MAGIC Monero Fund. As before, this can not be the perfect fit for all, but it’s an option which should at least be tested for a period of time. More choices is usually a good thing. Let’s not push the CCS on either extreme ends of the spectrum.

4. Comparison table

Note: this is sorted from ‘best’ to ‘worst’ options in my view (3RA).

System	Pros	Cons
CCSv2 (3RA)	+easy, no 3rd party, security, privacy by default	-shift in perception
Direct funding	+no 3rd party, security, privacy minus viewkey	-burden on proposers, backend
CCSv1 (multisig)	+potential security, privacy minus intermediary	-experimental, hard, custodians
Close CCS	+easy, no 3rd party, security, privacy by default	-shift in perception
CCSv1 (new custody)	+easy, privacy minus intermediary	-hard to secure, custodians
Pledge systems	+potential security, privacy	-burden on donors/proposers, hard

Observations

credits to: plowsof for compiling and sharing the list of ideas floating around in the community for the past few weeks, everyone for suggesting/discussing them on various channels, and the anons for encouraging me to publish this report
luigi has more than once publicly expressed his desire to move away from Core responsibilities
fluffypony recently resigned⁴ from Core after several threats of physical harm, underlining the importance of having anonymous contributors
bF has repeatedly asked the community to put forward ideas, plans and proposals for solving issues related to the existence of Core (centralization of funds, liabilities legal and otherwise), hinting at the permissionless nature of the project
note that this is just a draft proposal and I expect edits, suggestions, feedback, counterproposals, and for this to be discussed in future community meetings⁵

Onward.

Feedback

Let me know if you find this helpful and, depending on interest, I will do my best to create more Cypherpunk Transmission reports in the future.

Questions, edits and suggestions are always appreciated @ /about/.

-3RA

PS: apologies for not making this report more compact and for any potential errors - did not have time to quadruple check as I usually do, but considered that the timing is important in this case (please send edits).

CT-016: Using 1vyrain to 'soft disable' the dreaded Intel ME on xx30 ThinkPads

Tue, 11 Apr 2023 UTC

This is the 16th report in the Cypherpunk Transmission series.

Motivation

According to Intel, it’s Management Engine (ME) was designed for allowing businesses to remotely manage computers via Active Management Technology (AMT). The low-power computer subsystem consisting of mostly proprietary firmware is built into virtually all Intel chipsets since 2008.

Intel ME is known for security vulnerabilities and most privacy-aware users think it’s a backdoor.

Although impossible to remove completely, it can be turned off. This guide shows how 1vyrain¹ can be used to soft disable Intel ME without any specialized hardware on ThinkPad xx30 machines.

Assumptions

your system is supported² (any xx30 series: X230/X230t/X330/T430/T430s/T530/W530)
1 USB flash drive
your machine is plugged into power at all times (with a healthy battery connected)
you have access to a Windows 64-bit install (to downgrade BIOS with IVprep if necessary)
basic terminal knowledge
15-30 mins free time
you have read and understood all of the warnings below
you still have the guts to try this risky operation

0. WARNINGS!

Normally these kind of messages would go under Observations at the bottom of the report, but this is a special CT.

Please read this section several times, very carefully, before proceeding with this guide.

0.1 The good news

Although it is impossible to permanently brick a device with this method, you will require a hardware programmer to flash a backup or fresh BIOS after bricking.

0.2 The bad news

Losing power while flashing == 100% BRICK, guaranteed.

Before flashing, make 100% sure you know the password to your machine, even if you’ve cleared it. If you are unsure, try clearing, enabling then disabling the supervisor/BIOS password.

Setting your RAM to 1066MHz == BRICK.

There is no warranty or support guaranteed. You are THE ONLY ONE that is responsible for broken devices.

1. Check BIOS compatibility³

Reboot your machine and go into your BIOS setup by pressing the appropriate key for your model. Now find out if your ThinkPad has a BIOS version that’s vulnerable enough to be exploited with 1vyrain.

Example: for X230 machines, your BIOS should display version 2.60 or lower.

Model		BIOS version
X230 		2.60
X230t		2.58
T430 		2.64
T430s		2.59
T530 		2.60
W530 		2.58

If your machine has a newer BIOS version, you will have to downgrade to a compatible version using IVprep (Step 2).

If your BIOS version is old enough, you can skip directly to Step 3.

2. Downgrade BIOS using IVprep

2.1 Prepare BIOS settings

Enter your BIOS setup and update the following:

Set Security > UEFI Bios Update Options > Flash Bios Updating by End-Users: Enabled
Set Security > UEFI Bios Update Options > Secure RollBack Prevention > Disabled

2.2 Download IVprep

Make sure you are plugged into power while running this. You WILL brick if you lose power while flashing, guaranteed.

Boot into your Windows 64-bit install, download the latest IVprep⁴ version from Github, extract the archive and run downgrade.bat (NOT as admin!) by double clicking the file.

You should see a message similar to this in command prompt:

Press Enter to downgrade your ThinkPad to an 1vyrain compatible BIOS version.

Press Enter to proceed. Press Yes if asked by User Account Control to allow the app to make changes to your device.

Your system should reboot in 5 seconds and you should see this:

Begin Flashing....

The system will beep repeatedly for around 30 seconds. Don’t panic, that is expected behavior.

The last message should be:

Image flashing done.

The system will automatically reboot again.

Done.

Confirm the downgrade was successful by going into your BIOS and checking the version.

If all went well, you are now hopefully looking at a BIOS version that is compatible with 1vyrain (listed in Step 1) and you can proceed to the next step.

3. Exploit BIOS using 1vyrain

3.1 Download 1vyrain

Download the latest 1vyrain version (currently Revision 5⁵).

Check to see if hashes match:

md5sum 1vyrain.iso

Output should be exactly dd30313a8665e870360920b00cec55c4.

3.2 Create live USB

We need to burn the 1vyrain image (260 MiB) onto a flash drive.

3.2.1 On Linux

Run lsblk before plugging in the USB to display your devices.

Plug in the USB and run lsblk again. You should easily spot which one your USB is.

Note: double check to make sure you don’t erase the wrong device.

Run dd:

sudo dd if=path/to/1vyrain.iso of=/dev/sdX status=progress

Note: replace path/to/1vyrain.iso and /dev/sdX with the appropriate values.

3.2.2 On Windows

On Windows you can use Rufus⁶ in DD mode. No special configuration is necessary.

3.3 Prepare BIOS settings

Enter your BIOS setup and update the following:

Set Startup > UEFI/Legacy Boot > UEFI only
Set Security > Secure Boot > Off

Note: make sure your machine is set to boot from your USB (move it at the top of the list).

3.4 Exploit BIOS!

RE: Make sure you are plugged into power while running this. You WILL brick if you lose power while flashing, guaranteed.

Boot from the USB and follow the on-screen instructions.

You should be greeted with the following message:

Press Enter key to attempt BIOS exploit. Your Thinkpad will suspend as part of the process. Press the power buttong to wake it up!

Press Enter.

When your machine suspends, press the power button.

At the Please enter a choice: prompt, press 1 and Enter.

You should see this:

Press Enter key to begin flashing your jailbroken BIOS! Do NOT let the ThinkPad shut off during the process, you will need a hardware programmer to fix it!

Cross your fingers and press Enter.

You will probably have to wait for 30-60 seconds (at the Erasing and writing flash chip... status).

Finally you will see a success message:

All done! Press enter key to restart your ThinkPad or CTRL+C to exit to shell.

Press Enter.

You will get some CRC errors and reboots. All normal.

When prompted, press the appropriate key to enter your BIOS setup. Hopefully you can see a brand new Advanced tab.

4. Disable Intel ME

We can finally disable the Intel ME. I know you’ve already spotted it under:

Advanced > ME configuration > Intel(R) ME > set to Disabled

Note: you may get a ‘Configuration Changed. Restart the system’ message. That is normal and your machine will probably restart before booting into the OS.

Observations

X330 machines are supported but detected as normal X230 machines (the flashing menu has an additional option to flash a BIOS with the LVDS patch for machines detected as an X230)
disabling Intel ME might not fit your own threat model⁷ (Intel considers disabling ME to be a security vulnerability, but it is also possible for malicious actors to use the ME to remotely compromise a system)
it is possible (but untested and potentially riskier) to use Linux instead of Windows for IVprep (might write a new CT for this topic if there is enough interest)
the Soft Temporary Disable Mode means the BIOS is only asking (not forcing) Intel ME to disable itself on the next boot, and this mode is preserved between reboots and poweroffs⁸
1vyrain comes with additional BIOS mod features: Overclocking support (35xx, 37xx, 38xx, 39xx CPUs), Whitelist removal to use any WLAN/WWAN adapter, and Advanced menu (custom fan curve, TDP, etc)
you can also flash custom bios images (coreboot, skulls, heads) with 1vyrain
advanced users can attempt to build 1vyrain from source⁹
Dig deeper: 1vyrain longform FAQ¹⁰, Disabling Intel ME 11 via undocumented mode¹¹, Ivy Bridge Lenovo ThinkPad Internal Flashing¹², me_cleaner¹³, tripcode!Q/7’s coreboot(skulls) video¹⁴

Feedback

Let me know if you find this helpful and, depending on interest, I will do my best to create more Cypherpunk Transmission reports in the future.

You might have noticed that this wasn’t posted on Monday. Creating CTs is very time consuming (research and testing can take days at times). The fixed schedule is incompatible with the format and puts unencessary pressure on the quality, which I can’t sacrifice for the sake of quota. Consider future CTs on-demand (unscheduled, like meeting summaries).

Questions, edits and suggestions are always appreciated @ /about/.

-3RA

Credit goes to gnuteardrops from monero.graphics for the amazing xkcd graphic. Work and xkcd Script font licensed under CC BY-NC 3.0.

CT-015: Monero lore compendium

Mon, 27 Mar 2023 UTC

This is the 15th report in the Cypherpunk Transmission series.

WiP: contact me (escapethe3RA) to propose edits and new entries.

Motivation

Monero knowledge, although plentiful, is currently scattered across the web in various places: FAQs, weekly Reddit threads, books, papers, wikis and other sites.

This transmission aims to help new users find relevant and succinct answers, and offer veterans an up-to-date resource they can quickly reference.

Assumptions

you want to learn more about Monero, or help others learn about the project

1. Questions

Where can I buy and sell XMR without KYC?
What are the best Monero wallets for desktop?
Does Monero have hidden inflation bugs?
What is Monero’s maximum supply?
Where can I find XMR remote nodes to connect to?
How can I build Monero CLI from source?
Can ‘Mordinals’ still affect Monero’s fungibility if ‘tx_extra’ size is limited?
How does BTC Lightning Network compare with Monero in terms of privacy?
Did Monero have a premine?
When does Monero celebrate its birthday?
What are the best Monero mobile wallets?
What’s the recommended way to mine Monero?

2. Answers

Where can I buy and sell XMR without KYC?

Popular platforms include LocalMonero, Bisq, HodlHodl, and Sideshift. Visit Getmonero.org, kycnot.me, and the MO Resources section for a more complete list. DYOR.

^{^}

What is the best Monero wallet for desktop?

The ‘official’ Monero wallets (Monero GUI Wallet & Monero CLI Wallet). Feather Wallet is probably the best alternative. Visit the MO Resources section for a more complete list.

^{^}

Does Monero have hidden inflation bugs?

No inflation bugs have ever been detected. Review DangerousFreedom1984’s CCS to learn more about ongoing research efforts.

^{^}

What is Monero’s maximum supply?

Monero has a fixed emission rate, not a set maximum supply. Monero entered its ‘tail emission era’ in June 2022, which permanently set the miner block reward to 0.6 XMR, forever. The current annual inflation rate is ~0.86% and will approach 0% in future years.

^{^}

Where can I find XMR remote nodes to connect to?

lalanza808’s Monero.fail public node aggregator is probably the most well-known resource. ditatompel and tobtoht also maintain lists of Monero remote nodes (clearnet/onions).

^{^}

How can I build Monero CLI from source?

To compile the official Monero CLI wallet from source consult the instructions on Github. A step-by-step guide is also available on Monero Observer (CT-002).

^{^}

Can ‘Mordinals’ still affect Monero’s fungibility if the ‘tx_extra’ field is reduced in size?

Yes. MRL researcher Isthmus explains: ‘Even with the soft reduction in tx_extra size the ordinals will not blend in’. Consult PRs #8733 and #6668 to learn more about the ongoing debate about Monero and arbitrary data storage.

^{^}

How does BTC Lightning Network compare with Monero in terms of privacy?

LN has privacy enhancing features, while Monero is private by default. Chainalysis started offering customers a ‘transaction monitoring solution’ for the Lightning Network in December 2021, but did not mention Monero. Read An Empirical Analysis of Privacy in the Lightning Network to learn ‘how a passive adversary can infer payments’ endpoints with very high probability’.

^{^}

Did Monero have a premine?

No. Monero was ‘fairly’ distributed and there was no secret premine, instamine, ICO or token of any kind. While some people may have had an unfair advantage, everybody was able to mine from the very beginning of the project.

^{^}

When does Monero celebrate its birthday?

The Monero blockchain went live on 18 April 2014. See how the community celebrated its 8th birthday in 2022.

^{^}

What are the best Monero mobile wallets?

Cake Wallet (iOS/Android/APK) and Monerujo (Android/F-droid) are usually recommended by the community. Visit the MO Resources section for a more complete list.

^{^}

What’s the recommended way to mine Monero?

The consensus is to avoid centralized mining pools and either solo mine XMR using the Monero GUI / CLI wallets, or use a decentralized Monero mining pool like P2Pool.

^{^}

Observations

always do your own research and never blindly trust any resource listed anywhere on the internet, including on MO
this list is a work in progress and I plan to update it regularly

That’s it (for now). Please share this transmission with other inquisitive moneranoj.

Feedback

Let me know if you find this helpful and, depending on interest, I will do my best to post new Cypherpunk Transmission reports every other Monday.

Questions, edits and suggestions are always appreciated @ /about/.

-3RA

Credit goes to gnuteardrops from monero.graphics for the amazing xkcd graphic. Work and xkcd Script font licensed under CC BY-NC 3.0.

CT-014: Whonix virtual machines on Debian using KVM

Mon, 06 Mar 2023 UTC

This is the 14th report in the Cypherpunk Transmission series.

Motivation

Users that need advanced security and privacy can benefit from the principle of security by isolation by running Whonix¹ virtual machines.

Whonix on the Qubes platform is probably the most extreme security setup, but it has relatively poor hardware support. This guide focuses on installing Whonix on a Debian host OS using the KVM² (Kernel-based Virtual Machine) full virtualization solution.

Note: if at all possible, avoid using VirtualBox due to Oracle’s lack of transparency, known vulnerabilities, and licensing issues³.

Assumptions

you’re logged in with a user that’s part of the sudoer’s group on a machine running Debian 11 (Bullseye)
HW requirements: CPU with AMD-V or Intel VT-x, recommended 4+ GB RAM, 20+ GB free space (SSD)
internet connection
basic terminal knowledge
~60 mins free time

0. Check virtualization support

Run lscpu | grep "Virtualization" to check if your hardware supports virtualization.

Hopefully, you should get one of the outputs below:

Virtualization: VT-x

Virtualization: AMD-V

1. KVM

1.1 Install

Open up a terminal on your host operating system, update the packages list, and install the required packages:

sudo apt update && sudo apt install --no-install-recommends qemu-kvm qemu-system-x86 libvirt-daemon-system libvirt-clients virt-manager gir1.2-spiceclientgtk-3.0 dnsmasq qemu-utils

1.2 Configure

Your regular user should be able to manage virtual machines without root. Add it to the libvirt and kvm groups:

sudo addgroup "$(whoami)" libvirt && sudo addgroup "$(whoami)" kvm

Reboot the machine with sudo reboot.

We can now enable and start KVM’s default networking:

sudo virsh -c qemu:///system net-autostart default && sudo virsh -c qemu:///system net-start default

2. Whonix

2.1 Download

Download the latest image file from the Whonix website (currently 16.0.9.0)⁴ and the associated signature:

wget https://download.whonix.org/libvirt/16.0.9.0/Whonix-XFCE-16.0.9.0.Intel_AMD64.qcow2.libvirt.xz && wget https://download.whonix.org/libvirt/16.0.9.0/Whonix-XFCE-16.0.9.0.Intel_AMD64.qcow2.libvirt.xz.asc

Note: you can alternatively download from the onionsite with torsocks wget http://download.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/libvirt/16.0.9.0/Whonix-XFCE-16.0.9.0.Intel_AMD64.qcow2.libvirt.xz && torsocks wget http://download.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/libvirt/16.0.9.0/Whonix-XFCE-16.0.9.0.Intel_AMD64.qcow2.libvirt.xz.asc

2.2 Verify

To verify the image, we need the maintainer’s signing key:

wget https://www.whonix.org/keys/hulahoop.asc

Check the key’s fingerprint before importing it:

gpg --keyid-format long --import --import-options show-only --with-fingerprint hulahoop.asc

Only import the key if its fingerprint matches 04EF 2F66 6D36 C354 058B 9DD4 50C7 8B6F 9FF2 EC85:

gpg --import hulahoop.asc

Finally, we can start the cryptographic verification:

gpg --verify-options show-notations --verify Whonix*.libvirt.xz.asc Whonix*.libvirt.xz

You should see a gpg: Good signature from “HulaHoop” message.

Note: if you get a BAD signature output, restart from step 2.

2.3 Decompress

Decompress the .xz archive:

tar -xvf Whonix*.libvirt.xz

2.4 License Agreement

Read and agree to the Whonix ToS/license:

more WHONIX_BINARY_LICENSE_AGREEMENT

touch WHONIX_BINARY_LICENSE_AGREEMENT_accepted

2.5 Import VM Templates

Add the virtual networks:

sudo virsh -c qemu:///system net-define Whonix_external*.xml && sudo virsh -c qemu:///system net-define Whonix_internal*.xml

Note: if the virtual bridge “virbrX” already exists, edit the Whonix_external*.xml and Whonix_internal*.xml files and change the name to something new (ie. virbr3).

Activate them:

sudo virsh -c qemu:///system net-autostart Whonix-External && sudo virsh -c qemu:///system net-start Whonix-External

sudo virsh -c qemu:///system net-autostart Whonix-Internal && sudo virsh -c qemu:///system net-start Whonix-Internal

Import the Gateway and Workstation images:

sudo virsh -c qemu:///system define Whonix-Gateway*.xml && sudo virsh -c qemu:///system define Whonix-Workstation*.xml

2.6 Copy Image Files

sudo cp --sparse=always Whonix-Gateway*.qcow2 /var/lib/libvirt/images/Whonix-Gateway.qcow2

sudo cp --sparse=always Whonix-Workstation*.qcow2 /var/lib/libvirt/images/Whonix-Workstation.qcow2

2.7 (optional) Cleanup

Remove archive files and temporary folders:

rm Whonix* && rm -r WHONIX*

2.8 (optional) Increase memory

Note: Whonix-Gateway virtual machine needs to be given at least 1 GB of RAM to be able to start the Xfce desktop environment.

Before starting the machines, we can increase the maximum memory with:

virsh setmaxmem <vm_name> <memsize> --config

Set the actual memory:

virsh setmem <vm_name> <memsize> --config

Restart the VM:

virsh -c qemu:///system start <vm_name>

Note: replace <vm_name> with the virtual machine’s name and <memsize> with the desired memory size; vCPU and memory allocation can also be set from the Virtual Machine Manager GUI.

2.9 Start Whonix

We first need to start Whonix-Gateway and then the Workstation-Workstation.

2.9.1 CLI

Start the Gateway:

sudo virsh start Whonix-Gateway

And the Workstation:

sudo virsh start Whonix-Workstation

2.9.2 GUI

Alternatively, start the Virtual Machine Manager from Start Menu > Applications > System > Virtual Machine Manager.

Start the Gateway and Workstation by clicking on Whonix-Gateway > Open > Play and then Whonix-Workstation > Open > Play.

3. Post install

Finalize the installation by running sudo setup-dist in a Whonix-Gateway terminal.

Next, change the default changeme password for user in both Whonix-Gateway and Whonix-Workstation:

sudo passwd user

Use upgrade-nonroot to keep your systems up-to-date.

Observations

this setup might not be compatible with your threat model (CT-001⁵)
the Whonix Virtual Machine Images can be built from source for more security⁶
XML configuration can still be edited after the Machine was imported⁷
if available, add extra RAM and CPUs to VMs for better performance (2048+ MiB, 2 x vCPU)
at all times ensure the host clock has an accuracy of up to +/- 30 minutes to avoid Time Attacks⁸
dig deeper: post installation security advice⁹, common CLI commands¹⁰, advanced docs¹¹, and the Whonix forums¹²

That’s it, you can now use Whonix on Debian with KVM.

Feedback

Let me know if you find this helpful and, depending on interest, I will do my best to post a new Cypherpunk Transmission report every (other?) Monday.

Questions, edits and suggestions are always appreciated @ /about/.

-3RA

Credit goes to gnuteardrops from monero.graphics for the amazing xkcd graphic. Work and xkcd Script font licensed under CC BY-NC 3.0.

https://www.whonix.org/ ↩
https://www.linux-kvm.org/ ↩
https://seclists.org/fulldisclosure/2012/Apr/343, https://www.oracle.com/corporate/security-practices/assurance/vulnerability/disclosure.html, https://forums.virtualbox.org/viewtopic.php?f=7&t=89395 ↩
https://www.whonix.org/wiki/About#Whonix_Version ↩
/cypherpunk-transmission-001-threat-modeling-demystified/ ↩
https://www.whonix.org/wiki/KVM#Build_from_Scratch ↩
https://www.whonix.org/wiki/KVM#Editing_an_Imported_Machine’s_XML_Configuration ↩
https://www.whonix.org/wiki/Time_Attacks ↩
https://www.whonix.org/wiki/Post_Install_Advice ↩
https://www.kicksecure.com/wiki/Common_CLI_Commands ↩
https://www.whonix.org/wiki/Advanced_Documentation ↩
https://forums.whonix.org/ ↩

CT-013: Moneranoj: Unite or 'curb your cypherpunk'

Mon, 13 Feb 2023 UTC

This is the 13th report in the Cypherpunk Transmission series.

\Mon-er-an-o-j\ (eo) [n,pl]: members of the Monero community

Motivation

This special transmission offers a big picture view of current Monero research & development efforts and it should be perceived as an invitation for astute non-devs to get more involved and help the project grow and become more resilient.

Assumptions

you are not a dev, but you believe in the cypherpunk movement and want Monero to succeed
you are an independent, open-minded critical thinker
you can find and dedicate a portion of your free time to this effort

1. A big picture view

1.1 State of affairs

One could attempt to visualize Monero as a bag of nuts:

the kernel (0.1% population: core devs, researchers;)
the nutshell (0.9%: helpers, maintainers and contributors;)
the nut bag (99%: users, thinkers, everyone else spectating;)

Let’s take a closer look at those numbers: assuming a total population of 300,000, do we actually have 300 devs and researchers working on the project’s kernel and a group of 2,700 extra helpers and contributors?

Keen observers of weekly workgroup meetings and dev activity, know that the answer is clearly no. Unfortunately, we are off by at least an order of magnitude.

1.2 The issues

If it is not yet clear why that can be a key issue for Monero, we can go into it.

The handful of industrious people working on Monero are doing their best to steer the project down the path they perceive to be the right one. That’s what anyone in their position would do. But are we still on the original cypherpunk path? Or are we slowly sacrificing user privacy for extra features and in the name of adoption?

How could users really tell? By looking at the price and market cap? By reading mainstream FUD articles? By watching adoption metrics? By simply using the digital cash and hoping for the best? Could that be good enough?

The default reaction is to delegate all responsibility to the devs, cheer for the companies that are building around the project, and whenever something goes wrong just turn around and blame the same devs and companies. Is that fair and productive?

A rare and extraordinary decision would be to accept some of that responsibility and get more involved, learn and eventually work with the experts, become one, build and maintain more cypherpunk projects.

Even if you’re not a cryptography expert, you don’t know C++, and you can’t even work with a terminal, you could still come help us strengthen the nutshell. There are ways.

2. Getting involved

To contribute, one needs to first understand some of the challenges Monero is facing today, and the solutions proposed by our devs and researchers.

Let’s look at a few examples that are still relevant today, try and ask valid questions, and explore some learning options:

Monero might get flexible multi-tier address schemes thanks to Seraphis/JAMTIS.
- Q: Could the introduction of view-only wallets that can see spent outputs potentially become a privacy issue for users as more and more parties start using those kind of wallets?
- Tip: Read the Seraphis wiki¹, participate in weekly Seraphis meetings² (or read the meeting logs/summaries³) and learn how to formulate and ask the right, tough questions.
Monero currently still has the tx_extra field, but it is a known fact that using it is likely to decrease privacy.
- Q: What is it used for? Should we remove the field, or try and ‘fix’ it somehow?
- Tip: Learn more about the topic⁴, maybe test the feature yourself, join MRL meetings⁵ and get involved in the ongoing debate on Github⁶’⁷’⁸ when you are ready to ask a constructive question or suggest an efficient solution.
Eliminating Monero’s 10-block-lock could considerably improve usability, but it could also harm privacy.
- Q: Is there a way to accomplish this without sacrificing any privacy? At what resource cost? If not, how much privacy are we willing to sacrifice for the UX gain, if any?
- Tip: Explore the issue deeper⁹ and consult Github issues #95¹⁰ & #102¹¹.

I could go on, but you probably get the point by now. Just keep an eye on dev activity¹² (merged PR’s and new issues) to get in the loop.

It might take some time before you write a single insightful comment on a relevant issue, or contribute something of value to a research meeting, but that’s okay. Just be persistent, question everything, and never stop learning.

You don’t have to be a developer to do this and it is unnecessary to ask for permission from anyone. Monero’s future is not set in stone and your voice can indeed be important.

Remember that Monero is not a company, and we move forward by reaching loose consensus. The more eyes on the issues, code, and proposed solutions, the stronger the process becomes: 50 people agreeing on something is much more reliable than 5.

Observations

always do your own research before asking questions and wait for feedback, don’t spam
this is just an introduction, it’s my big picture, and you need to find yours
if you don’t feel prepared for this kind of leap, read my Ultimate guide for new Monero contributors¹³ and start with other constructive tasks instead
there is always a need for more Gitian builders¹⁴, see if you can help with that
watch the Breaking Monero¹⁵ video series and read CT-008: Mitigating dusting attacks in Monero CLI¹⁶ to learn more about attack vectors and potential mitigations
for more technical users that are ready to push some code, do it anonymously (CT-005: Contributing to Monero anonymously¹⁷); new researchers consult Rucknium’s Open Research Questions¹⁸ and join the #monero-recruitment Matrix room (instructions¹⁹)
learn the art of asking tough questions politely and respectfully interact with other Monero contributors - they are doing the best they can, just like you
suggested reading: Mastering Monero²⁰, Zero to Monero - First Edition²¹, Zero to Monero - Second Edition²², The Monero Standard²³, Rucknium’s OSPEAD²⁴, tevador’s JAMTIS paper²⁵, UkoeHB’s Preliminary Seraphis Design Overview²⁶

That’s it. Share this transmission with others that might be interested in helping Monero stay true to its original values so we don’t have to curb our cypherpunk any time soon.

Feedback

Let me know if you find this helpful and, depending on interest, I will do my best to post a new Cypherpunk Transmission report every (other?) Monday.

Questions, edits and suggestions are always appreciated @ /about/.

-3RA

Credit goes to gnuteardrops from monero.graphics for the amazing xkcd graphic. Work and xkcd Script font licensed under CC BY-NC 3.0.

CT-012: Plausible deniability with VeraCrypt hidden volumes in Tails

Mon, 30 Jan 2023 UTC

This is the 12th report in the Cypherpunk Transmission series.

Motivation

The VeraCrypt disk encryption tool can provide plausible deniability via hidden volumes and hidden operating systems.

This guide focuses on creating hidden volumes within file-hosted encrypted containers using VeraCrypt Console¹ in Tails².

Provided adequate security precautions³ are followed, an adversary should not be able to prove the existence of a hidden VC volume inside the file.

Assumptions

you’re on a machine with 2 GB+ RAM
1 USB stick with Tails OS installed⁴
basic terminal knowledge
internet connection
30-60 mins free time

1. Configure Tails

1.1 Set up admininstration password

Restart your machine with the Tails USB plugged in.

At the Welcome to Tails! prompt click on + at the bottom of the screen to bring up the Additional Settings panel.

Turn the Administration Password ON and add a password. Click on Start Tails.

1.2 (Optional) Create exFat partition

This partition is useful for moving the VC encrypted volumes between Tails and other operating systems.

If you need this feature, do this before creating the persistent storage, which takes up all the free space on your device.

Navigate to Applications > Utilities > Disks.

Select the USB flash drive > click on Free Space and +.

Make sure to leave some free space for the persistent storage and click on Next > enter a Volume Name > Other > Next > select exFAT > Create and enter your admin password from step 1.1.

1.3 Create encrypted persistent storage

We can now allow Tails to use all the free space left on the USB stick to create the encrypted persistent storage partition.

Go to Applications > Favorites > Persistent Storage.

Choose a passphrase that will be used to unlock the encryption of the persistent storage (5-7 random words).

Click on Create and make sure the Persistent Folder and Additional Software switches are on/enabled. Close the window by pressing the top right x.

1.4 Establish network connection

If the network connection window didn’t pop up during the previous steps, we can manually enable Wi-Fi/ethernet by following the simple wizard in Applications > Tor Connection. Select Connect to tor automatically > and click on Connect to tor.

The output should be: Connected to tor successfully.

Note: if you want to use a bridge (CT-009⁵), configure it during this step.

2. Install VeraCrypt on persistent storage

2.1 Download VC Console

First check to see what the latest version of the VC Console Debian/Ubuntu package is:

torsocks curl https://launchpad.net/veracrypt/trunk/ | grep 'Latest version is'

Note: if the command fails, visit the downloads page on veracrypt.fr⁶.

You should get something like this: Latest version is 1.25.9.

Let’s set the release as an environment variable with:

VERACRYPT_RELEASE=1.25.9

Note: replace the number with the actual latest version.

Download the .deb package and associated PGP signature file to the persistent folder:

cd ~/Persistent/ && torsocks wget https://launchpad.net/veracrypt/trunk/$VERACRYPT_RELEASE/+download/veracrypt-console-$VERACRYPT_RELEASE-Debian-11-amd64.deb && torsocks wget https://launchpad.net/veracrypt/trunk/$VERACRYPT_RELEASE/+download/veracrypt-console-$VERACRYPT_RELEASE-Debian-11-amd64.deb.sig

2.2 Verify the download

Fetch the VC PGP public key:

torsocks wget https://www.idrix.fr/Veracrypt/Veracrypt_PGP_public_key.asc

Display the key’s fingerprint before importing it:

gpg --show-keys --with-fingerprint Veracrypt_PGP_public_key.asc

Output should be:

Key fingerpring = 5069 A233 D55A 0EEB 174A 5FC3 821A CD02 680D 16DE

Now display the fingerprint from the official website:

torsocks curl https://www.veracrypt.fr/en/Downloads.html | grep 'Fingerprint='

Only if the two fingerprints match, import the key:

gpg --import Veracrypt_PGP_public_key.asc

Output should confirm that you imported the key successfully: imported: 1.

Note: if any command fails, open the website in the tor browser and d/l the files manually.

Next we need to verify the release:

gpg --verify veracrypt-console-$VERACRYPT_RELEASE-Debian-11-amd64.deb.sig

Unless you get Good signature, stop and repeat the process from step 2.

2.3 Install VeraCrypt Console

sudo dpkg -i veracrypt-console-$VERACRYPT_RELEASE-Debian-11-amd64.deb

You can check the version with:

veracrypt --version

Note: .deb packages cannot be installed in persistent mode in Tails; copy the veracrypt binary from /usr/bin/ to your persistent folder if you want to use it later and don’t want to run dpkg after each reboot (ie. copy with cp /usr/bin/veracrypt ~/Persistent and run with ./veracrypt).

3. Create standard VeraCrypt outer volume

Note: in the command below, replace [OUTER_CONTAINER_PASSWORD] with the password for your outer volume and [VOLUME_PATH] with the path to your file container (file name and extension can be anything).

veracrypt -t -c -k '' --pim=0 --encryption=aes --hash=sha-512 --random-source=/dev/urandom --volume-type=normal --filesystem=ext4 -p [OUTER_CONTAINER_PASSWORD] --size=500M [VOLUME_PATH]

Enter the Tails admin password if/when asked.

You should see a new file created in your ~/Persistent folder named [OUTER_VOLUME_PATH]. That’s the outer encrypted volume that will contain the inner hidden volume.

4. Create hidden VeraCrypt inner volume

Note: replace [INNER_CONTAINER_PASSWORD] with the password for your inner volume and [VOLUME_PATH] with the path to your outer file container (same as the previous step).

veracrypt -t -c -k '' --pim=0 --encryption=aes --hash=sha-512 --random-source=/dev/urandom --volume-type=hidden --filesystem=ext4 -p [INNER_CONTAINER_PASSWORD] --size=100M [VOLUME_PATH]

You can modify the size of the volumes by passing a different value to the --size= flag.

5. Mounting and dismounting volumes

5.1 VC Console method

5.1.1 Mounting only the outer volume

veracrypt --mount [VOLUME_PATH] [VOLUME_MOUNT_LOCATION] --password [OUTER_CONTAINER_PASSWORD] --pim=0 -k '' --protect-hidden=no

note: replace [VOLUME_PATH] with the path to the encrypted VC file, [VOLUME_MOUNT_LOCATION] with the mount directory (ie. /media/veracrypt1), and [OUTER_CONTAINER_PASSWORD] with the password to the outer volume; if you run it with protect-hidden=yes you will be asked to provide the password to the inner container as well.

5.1.2 Mounting the hidden inner volume

veracrypt --mount [VOLUME_PATH] [VOLUME_MOUNT_LOCATION] --password [INNER_CONTAINER_PASSWORD] --pim=0 -k '' --protect-hidden=no

note: replace [INNER_CONTAINER_PASSWORD] with the password to the hidden inner volume; if you run into issues, try running veracrypt --mount with no additional parameters and follow the prompts.

5.1.3 Dismounting VC volumes

Perhaps the most convenient way is to dismount all mounted VC volumes:

veracrypt --dismount

Consult the output of veracrypt --help for the complete list of commands.

5.2 Tails VC GUI method

VeraCrypt volumes can also be unlocked using the built-in Unlock VeraCrypt Volumes Tails utility.

Access it via Applications > Utilities > Add > select encrypted VC file container and enter the password for the outer volume before clicking on Unlock.

To unlock the hidden volume, check the appropriate box and enter the hidden volume password instead.

That’s it.

Observations

review your threat model(CT-001⁷) when deciding if and how to best use the tools described in this guide
remember to do secure backups⁸ of your VC encrypted containers
choose strong passwords/passphrases(CT-010⁹) for your VC volumes
you could optionally use key files and a PIM (Personal Iterations Multiplier)¹⁰ for some added protection for your encrypted VC containers
instead of file-hosted volumes, VC can also be used to create partition/device-hosted volumes
if you have trouble with the console version of VC, you can alternatively download the Linux generic installer from the official website⁶
to access your VC containers in other operating systems, copy the files to the exfat partition that you created at step 1.2
plausible deniability tips¹¹: populate the outer volume with decoy files (be careful not to overwrite the hidden volume¹²); if forced to unlock a VC encrypted volume, enter the outer volume pass instead of the hidden one
dig deeper to learn more about VeraCrypt: forums¹³, breaking VC¹⁴, hidden volume security considerations¹⁵

You should now be able to achieve some plausible deniability by creating hidden volumes inside file-hosted VeraCrypt encrypted containers.

Feedback

Let me know if you find this helpful and, depending on interest, I will do my best to post a new Cypherpunk Transmission report every (other?) Monday.

Questions, edits and suggestions are always appreciated @ /about/.

-3RA

Credit goes to gnuteardrops from monero.graphics for the amazing xkcd graphic. Work and xkcd Script font licensed under CC BY-NC 3.0.

CT-011: Decoy wallets with seed offset passphrase in Monero CLI

Mon, 16 Jan 2023 UTC

This is the 11th report in the Cypherpunk Transmission series.

Motivation

There is a rather simple, yet underrated method of adding some basic Evil Maid protection to your wallet seeds while gaining some plausible deniability in the process.

This short practical guide uses encrypted_seed in Monero CLI to create a decoy XMR wallet.

Assumptions

Monero CLI Wallet is installed (CT-002¹’²)
~10 mins free time (+sync time)

1. Access Monero wallet

In a terminal, open any Monero wallet, and display the seed:

seed

That command should display your wallet’s 25-word seed on the screen:

exit daily below pockets biweekly unsafe winter copy sickness glass ferry sleepless code fibula mobile tether system hacksaw tail winter innocent sowed haunted irony ferry

2. Add offset passphrase

Let’s add an offset passphrase by running:

encrypted_seed

After entering your wallet password, you will be prompted to Enter optional seed offset passphrase, empty to see raw seed:

I am going to use a random passphrase:

skylabelroundgrade

Note: it is recommended to use a 6 to 8 (english) words as a seed offset passphrase.

Enter your seed offset again, to confirm.

The new transformed seed will be displayed:

woozy kangaroo darted lordship governing mighty cocoa emulate value economics gang oyster upgrade sowed cuisine innocent gusts bakery mirror vague highway apex afoot algebra value

This is your decoy wallet. The passphrase offsets the original seed in a reproducible way and you will need both the new seed and the passphrase to decrypt the original seed.

Make sure to securely store (CT-10³) both the transformed seed and the passphrase (separately if possible).

Note: the second seed is valid, but worthless to anybody who doesn’t also know that passphrase.

3. Restore original wallet

To access the real wallet, type in:

monero-wallet-cli --restore-deterministic-wallet

When asked to Specify Electrum seed:, paste in your transformed seed and press Enter.

Next, enter your seed offset when the Enter seed offset passphrase, empty if none: prompt appears.

Input a new password for the wallet and confirm it. Optionally, also enter the restore height and wait for the sync.

You now have access to your original seed. Delete the wallet, restore it, and test everything thoroughly before using with larger amounts.

Anyone that tries to restore the wallet from the second, transformed seed, without knowing the offset passphrase will just get access to the empty (decoy) wallet.

Observations

if you forget or lose your offset passphrase, your seed alone won’t be enough to recover your funds
note that this is not true encryption for seeds
consider your own threat model (CT-001⁴) before using this functionality
it is possible to create multiple decoy wallets
optionally you could transfer some XMR to the decoy wallets for some extra blackmail protection
the feature is also available in Monero GUI Wallet, Monerujo (CryptSeed)⁵, MyNero Wallet⁶
test adding and subtracting seed offset passphrases by using the Transform Seed functionality on monerotech.info⁷’⁸

That’s it. I am very interested to know if you find this method useful.

Feedback

Let me know if you find this helpful and, depending on interest, I will do my best to post a new Cypherpunk Transmission report every (other?) Monday.

Questions, edits and suggestions are always appreciated @ /about/.

-3RA

Credit goes to gnuteardrops from monero.graphics for the amazing xkcd graphic. Work and xkcd Script font licensed under CC BY-NC 3.0.

CT-010: Managing passwords, keys, and seeds

Mon, 26 Dec 2022 UTC

This is the 10th report in the Cypherpunk Transmission series.

Motivation

Passwords, PGP keys, SSH keys, onion service private keys, XMR wallet seeds, addresses, contacts and encrypted messages - it can be a daunting task to securely create, store, and maintain all of that private data.

This guide suggests a solution that is potentially compatible with most threat models.

Assumptions

you’re on a GNU/Linux machine (Debian/-based)
basic terminal knowledge
a five dice set
~15 mins free time

1. Install KeepassXC

Let’s first install the KeepassXC¹ open-source password manager:

sudo apt install keepassxc

2. Create database

Open up KeepassXC and hit CTRL+SHIFT+N to create a new database. The default Decryption Time, Database format and Encryption settings should be fine.

A dice-generated passphrase should be perfect for the master password.

Download any good word list file²’³’⁴’⁵. We will use EFF’s new large word list file eff_large_wordlist.txt (5 dice, 7,776 words):

curl -O https://www.eff.org/files/2016/07/18/eff_large_wordlist.txt

Roll a set of five dice all at once and write the numbers down.

Example roll:
1, 1, 6, 5, 3

Find the corresponding word for the roll with:

grep "11653" eff_large_wordlist.txt

This should output:

11653	animation

We now have the first word of our master password: animation.

Keep rolling until you generate at least 6 words (77 bits of entropy).

Example six-word passphrase:
animation approach corral stoneware blinked hardcore

Use this as your KeepassXC master password and save the encrypted database file (ie. Passwords.kdbx).

Note: you could optionally disguise the file by saving it with a random name and a more common extension (ie. styles.css).

Memorize the passphrase.

Note: if you don’t have a dice set, you can generate random passwords and passphrases in KeepassXC by clicking on the ‘dice’ icon.

3. Workflow

KeepassXC is very easy to use.

Create entries with CTRL+N or use the + icon, generate new passwords with the dice icon, copy and paste passwords from KeepassXC to websites and applications, edit entries with CTRL+E, lock the database with CTRL+L or by pressing the lock icon.

Remember to backup your database files regularly by using the Save Database Backup.. option under the Database menu.

Observations

review your threat model⁶ when deciding if and how to best use the tools described in this guide
store database backups on separate machines/devices
whenever possible, opt for more entropy; go for 8+ word count for passphrases and 20+ characters for passwords (100+ bits of entropy)
do not reuse passwords
also saving passwords down on paper/metal might not fit your threat model
consider additional security risks before using any online password managers
it is recommended to build KeepassXC from source⁷
KeepassXC can generate 2FA codes
avoid using KeepassXC browser extensions; copy/paste instead
a viable alternative to KeepassXC might be pass⁸, the Unix command-line password manager
dig deeper: EFF⁹, Kicksecure/Whonix¹⁰’¹¹

That’s it. Now you can securely create, store and maintain your private data.

Feedback

Let me know if you find this helpful and, depending on interest, I will do my best to post a new Cypherpunk Transmission report every (other?) Monday.

Questions, edits and suggestions are always appreciated @ /about/.

-3RA

Credit goes to gnuteardrops from monero.graphics for the amazing xkcd graphic. Work and xkcd Script font licensed under CC BY-NC 3.0.

CT-009: Running Tor obfs4 bridge relays

Mon, 12 Dec 2022 UTC

This is the 9th report in the Cypherpunk Transmission series.

Motivation

Tor’s presence, when used in the default configuration, can be discovered by any observer. It is no secret that advanced adversaries are indeed actively denying private access to the open internet to many around the world.

Private bridge relays with Pluggable Transports support (like obfs4) are key to circumventing sophisticated censorship.

This guide shows how easy it actually is to become a PT obfs4 bridge relay operator and help increase the currently available number of Tor bridges (~2K).

Assumptions

you have ssh access to a secured (CT-003¹) VPS (Debian 11.5)
box should have 24/7 internet connectivity & >1 MBit/s available bandwidth
basic terminal knowledge
~30 mins free time

1. Install Tor

SSH into your server, update the packages database, and install tor:

sudo apt update && sudo apt install tor

2. Install obfs4

The obfs4proxy package is available in stable-backports, so we need to make a few modifications to the default configuration.

2.1 Create obfs4proxy.pref

Let’s create a new obfs4proxy.pref file in the /etc/apt/preferences.d/ directory:

sudo nano /etc/apt/preferences.d/obfs4proxy.pref

Paste the following lines in the empty file:

Explanation: tor meta, always run latest version of obfs4proxy
Package: obfs4proxy
Pin: release a=bullseye-backports
Pin-Priority: 500

2.2 Enable backports

Now let’s enable backports in sources.list:

sudo nano /etc/apt/sources.list

Add this new line to the file:

deb http://deb.debian.org/debian bullseye-backports main

2.3 Install obfs4proxy

Finally we can install obfs4:

sudo apt install obfs4proxy

Check the version with obfs4proxy --version. It should be at least 0.0.14.

Note: you can alternatively skip 2.1 and run (at 2.3) sudo apt install -t bullseye-backports obfs4proxy; if you have any issues, consider building obfs4 from source instead².

3. Configure the bridge

Open the Tor config file with sudo nano /etc/tor/torrc and replace its content with this:

BridgeRelay 1

# Replace "TODO1" with a Tor port of your choice.
# This port must be externally reachable.
# Avoid port 9001 because it's commonly associated with Tor and censors may be scanning the Internet for this port.
ORPort TODO1

ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy

# Replace "TODO2" with an obfs4 port of your choice.
# This port must be externally reachable and must be different from the one specified for ORPort.
# Avoid port 9001 because it's commonly associated with Tor and censors may be scanning the Internet for this port.
ServerTransportListenAddr obfs4 0.0.0.0:TODO2

# Local communication port between Tor and obfs4.  Always set this to "auto".
# "Ext" means "extended", not "external".  Don't try to set a specific port number, nor listen on 0.0.0.0.
ExtORPort auto

# Replace "<address@email.com>" with your email address so we can contact you if there are problems with your bridge.
# This is optional but encouraged.
ContactInfo <address@email.com>

# Pick a nickname that you like for your bridge.  This is optional.
Nickname PickANickname

Modify at least TODO1, TODO2, and optionally <address@email.com> and PickANickname.

I recommend setting ORPort and the ServerTransportListenAddr port to something >1024, like this:

ORPort 11043
ServerTransportListenAddr obfs4 0.0.0.0:10232

Save the file and exit with CTRL+X and Y + Enter.

Note: if you want to use ports smaller than 1024, consult Tor issue #18356³.

Open up the two ports:

sudo ufw allow 11043 && sudo ufw allow 10232

We can now enable and start tor with systemctl enable --now tor.service. If it was already running, use systemctl restart tor.service to restart the service instead.

To confirm the bridge is operational, monitor the logs:

sudo journalctl -e -u tor@default

The output should be similar to this:

[notice] Your Tor server's identity key fingerprint is '<NICKNAME> <FINGERPRINT>'
[notice] Your Tor bridge's hashed identity key fingerprint is '<NICKNAME> <HASHED FINGERPRINT>'
[notice] Registered server transport 'obfs4' at '[::]:46396'
[notice] Tor has successfully opened a circuit. Looks like client functionality is working.
[notice] Bootstrapped 100%: Done
[notice] Now checking whether ORPort <redacted>:3818 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
[notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.

To test if your obfs4 bridge port is reachable to the rest of the world, do a TCP reachability test⁴.

Output should be:

TCP port is reachable!

Done.

Note: if you get a different, unexpected output, check your firewall configuration.

Observations

keep your relay secure by installing (automatic) security updates
your bridge should appear on Relay Search in a few hours⁵
running and using bridges might not be compatible with your own threat model (CT-001⁶)
bridges only make it harder (not impossible) for adversaries (ie. ISPs, govs) to determine if a user is connecting to Tor
when compared to other Tor relay admins (ie. exit relays), bridge operators are probably the least exposed to legal troubles, but the risks are not inexistent
bridge distribution can be changed⁷
recommended reading: Tor dev manual⁸, Pluggable Transports⁹, and Whonix docs¹⁰
number of bridges and relays are available on Tor Metrics¹¹
if you’re not using Debian, consult Tor’s bridge setup guide for other platforms¹²
to connect to your own bridge manually, read Tor’s bridge post-install instructions¹³

That’s it, you are now a bridge operator, a valuable Tor contributor. Thank you for helping censored users connect to the Tor network. Resistance is not futile.

Feedback

Let me know if you find this helpful and, depending on interest, I will do my best to post a new Cypherpunk Transmission report every (other?) Monday.

Questions, edits and suggestions are always appreciated @ /about/.

-3RA

Credit goes to gnuteardrops from monero.graphics for the amazing xkcd graphic. Work and xkcd Script font licensed under CC BY-NC 3.0.

CT-008: Mitigating dusting attacks in Monero CLI

Mon, 05 Dec 2022 UTC

This is the 8th report in the Cypherpunk Transmission series.

Motivation

Monero addresses are not publicly recorded on the blockchain and ring signatures do provide plausible deniability, but they aren’t perfect.

Although Monero is less vulnerable than public chains, rings can still be targeted and weakened by dusting attacks, which could lead to indirect linkage of outputs and user deanonymization.

This guide suggests a few simple ways to deal with poisoned outputs from dusting/EAE attacks.

Assumptions

Monero CLI installed (CT-002¹)’²
~5 mins free time (+sync time)

1. Identifying dusting attacks

To determine if you are under attack, simply check for suspicious incoming transactions that are small (usually under 0.01 XMR) and which are being periodically transferred to your addresses.

The show_transfers incoming command in your Monero CLI lists all incoming transactions.

Use unspent_outputs and unspent_outputs index=1 to confirm which addresses are being targeted by the dusting attack.

Note: replace index number to see unspent outputs in other addresses; type in address all to list all addresses and associated index numbers.

You should be able to identify something similar to this, with a high number of keys:

Amount: 0.001, number of keys: 24
2683490

Let’s assume we spot 24 x 0.001 XMR transactions hitting index 1. Now we are fully aware of the attack.

2. Mitigations

You might want to consider your own theat model (CT-001³) when deciding on the best course of action.

2.1 Manage

We could try combining only the poisoned outputs (not churning the entire balance with sweep_all).

Let’s grab all unlocked poisoned outputs with sweep_below and send them to a new subaddress:

sweep_below 0.002 index=1 <address>

Note: replace amount, index number and address accordingly; repeat the process as needed; generate a new subaddress with address new.

2.2 Ignore

Alternatively, we could simply choose not to touch/spend those poisoned outputs.

Let’s ignore outputs below a certain threshold with:

set ignore-outputs-below 0.002

Note: replace amount accordingly; if there are other ‘safe’ outputs on that index, they could be linked with the poisoned ones.

Observations

if you need help with any command, use help <command> and help all
not all dusting attack victims are directly targeted
churning can increase user privacy, but it is not easy to provide an optimal churn frequency recommendation
successful EAE attacks require colluding adversaries on both sides with access to external correlating metadata (ie. IP addresses, KYC data, timing)
Seraphis should bring an increase in the ring size, which could reduce dusting attacks efficiency
watch Breaking Monero’s Poisoned Outputs (EAE Attack) video⁴ to learn more about these types of attacks

That’s it. Nothing is perfect, not even Monero, but I do believe we are moving in the right direction. If you are under attack, don’t panic: sweep / ignore and take that as a compliment instead.

Feedback

Let me know if you find this helpful and, depending on interest, I will do my best to post a new Cypherpunk Transmission report every (other?) Monday.

Questions, edits and suggestions are always appreciated @ /about/.

-3RA

Credit goes to gnuteardrops from monero.graphics for the amazing xkcd graphic. Work and xkcd Script font licensed under CC BY-NC 3.0.

/cypherpunk-transmission-002-building-from-source-monero-cli/ ↩
/verify-install-update-monero-cli-wallet-linux-guide/ ↩
/cypherpunk-transmission-001-threat-modeling-demystified/ ↩
https://redirect.invidious.io/watch?v=iABIcsDJKyM ↩

CT-007: Monero view-only wallets

Mon, 28 Nov 2022 UTC

This is the 7th report in the Cypherpunk Transmission series.

Motivation

Although private by default, Monero can be optionally transparent via its private viewkey system.

The best way to learn about that is by actually setting up a view-only XMR wallet.

In this guide we are going to peek inside the Monero General Fund donation address.

Assumptions

Linux machine with Monero CLI installed¹’²
~5 mins free time (+sync time)

1. Get address and private view key

The GF base XMR address³ and the associated view key⁴ have always been public⁵, but if you want to test this with your own address instead, open your wallet and type in address and viewkey.

2. Create Monero view-only wallet

In a terminal:

monero-wallet-cli --generate-from-view-key general-fund

Note: replace ‘general-fund’ with the name you want for your wallet file; if connecting to a remote node, include the necessary flag --daemon-address <host:port>.

Paste in the address when prompted for Standard address:

44AFFq5kSiGBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVGQBEP3A

And then the view key when prompted for View key:

f359631075708155cc3d92a32b75a7d02a5dcf27756707b47a2b31b21c389501

After entering and confirming a password for the wallet, you should be asked to provide an optional restore height or date (format: YYYY-MM-DD). Press Enter if you want to get the full history.

You can start exploring after it fully syncs. Read the Cheat Sheet: Monero CLI Wallet⁶ guide to get familiar with the most common commands.

Observations

by sharing a viewkey, you are allowing access to view every incoming transaction for that address
the balance can be inaccurate, as outgoing transactions cannot be reliably viewed as of June 2017 (you need to import the accompanying key images⁷ of each output of the wallet to get the correct balance and view spent transactions⁸; this behavior might change with Seraphis⁹)
note that without the private spend key, view-only wallets cannot spend a balance

That’s it. You can now set up a Monero view-only wallet. Use it to validate incoming transactions to cold/hardware wallets, monitor incoming donations, and validate payments.

Feedback

Let me know if you find this helpful and, depending on interest, I will do my best to post a new Cypherpunk Transmission report every (other?) Monday.

Questions, edits and suggestions are always appreciated @ /about/.

-3RA

Credit goes to gnuteardrops from monero.graphics for the amazing xkcd graphic. Work and xkcd Script font licensed under CC BY-NC 3.0.

/cypherpunk-transmission-002-building-from-source-monero-cli/ ↩
/verify-install-update-monero-cli-wallet-linux-guide/ ↩
(GF base XMR address) 44AFFq5kSiGBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVGQBEP3A ↩
(GF viewkey) f359631075708155cc3d92a32b75a7d02a5dcf27756707b47a2b31b21c389501 ↩
https://github.com/monero-project/monero#supporting-the-project ↩
/monero-cli-wallet-cheat-sheet/ ↩
https://www.getmonero.org/2021/06/24/general-fund-2020-2021-report.html, https://downloads.getmonero.org/GF_wallet_key_images_until_20210616 ↩
https://monero.stackexchange.com/questions/7217 ↩
https://www.getmonero.org/2021/12/22/what-is-seraphis.html, https://github.com/monero-project/research-lab/issues/92 ↩

CT-006: Setting up a public Onion Service

Mon, 21 Nov 2022 UTC

This is the 6th report in the new Cypherpunk Transmission series.

Motivation

Onion Services offer solid privacy and security benefits to Tor users: the traffic is E2E encrypted and TLS is unnecessary, IP addresses are irrelevant, open ports are not required, and impersonation is impossible.

Despite the stigma associated with their previous name, Hidden Services can indeed be used for publically offered services, which are not intended to be hidden.

This guide shows how easy it actually is to, permissionlessly, set up an Onion Service for a website.

Assumptions

you have ssh access to a secured¹ VPS (Debian/-based) from a GNU/Linux machine
basic terminal knowledge
~20 mins free time

1. Install Tor

SSH into your server and updgrade the packages first:

sudo apt update && sudo apt upgrade -y

Verify the CPU architecture with:

sudo dpkg --print-architecture

If the ouptut is amd64, arm64, or i386, proceed. Otherwise, you probably need to build Tor from source².

Install apt-transport-https:

sudo apt install apt-transport-https

Create a new file tor.list in /etc/apt/sources.list.d/ by running:

sudo nano /etc/apt/sources.list.d/tor.list

Check your OS codename:

lsb_release -c

Paste these two lines inside the new file to add the most stable packages:

deb [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg] https://deb.torproject.org/torproject.org <DISTRIBUTION> main
deb-src [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg] https://deb.torproject.org/torproject.org <DISTRIBUTION> main

Replace <DISTRIBUTION> with your OS codename (ie. bullseye).

Add the GPG key that was used to sign the packages:

wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | gpg --dearmor | sudo tee /usr/share/keyrings/tor-archive-keyring.gpg >/dev/null

It is time to install tor and the tor Debian keyring package:

sudo apt update && sudo apt install tor deb.torproject.org-keyring

Note: if you don’t have nano or wget, install them with sudo apt install nano wget.

Finally, make sure tor is up and running correctly:

sudo systemctl status tor

If the tor.service status is active, we are good to go.

2. Install a web server

You can choose any web server, but I will use Nginx:

sudo apt install nginx -y

Check the status with sudo systemctl status nginx and point a browser to your VPS IP address.

If the Welcome to Nginx page doesn’t load, try checking your firewall settings and allow the default 80 port (ie. sudo ufw allow 80).

By default, Nginx should serve the website from /var/www/html. Feel free to edit the index.html or index.nginx-debian.html.

You can restart the web server with:

sudo sytemctl restart nginx

3. Configure the Onion Service

Open the torrc config file:

sudo nano /etc/tor/torrc

Uncomment the following two lines under the This section is just for location-hidden services by removing the # sign:

HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 80 127.0.0.1:80

Replace hidden_service with your hidden service name (ie. my-onion-blog) and restart Tor:

sudo systemctl restart tor.service

4. Access and backup the Onion Service

Display your onion v3 service hostname with:

cat /var/lib/tor/hidden_service/hostname

You should now be able to access the .onion with the Tor browser.

Make a backup of the /var/lib/tor/hidden_service directory containing hostname and private_key. That’s all you need to move the Onion Service to a new server.

Observations

keep your private_key private and set properly restrictive user permissions for that file
keep Tor up-to-date so that critical security flaws are fixed
it is possible to create custom vanity onion addresses³ (ie. mysitenameyx4fi3l6x2gyzmtmgxjyqyorj9qsb5r543izcwymle.onion)
advertise your onion site using the Onion-Location Header⁴
for advanced threat models, look into the Vanguards Add-On⁵
to learn how the hidden service protocol works, read the Tor v3 rendezvous spec⁶

Done. You are now in full control of your own domain, which is invulnerable to malicious takeovers from any authority.

Feedback

Let me know if you find this helpful and, depending on interest, I will do my best to post a new Cypherpunk Transmission report every (other?) Monday.

Questions, edits and suggestions are always appreciated @ /about/.

-3RA

Credit goes to gnuteardrops from monero.graphics for the amazing xkcd graphic. Work and xkcd Script font licensed under CC BY-NC 3.0.

/cypherpunk-transmission-003-basic-server-security/ ↩
https://community.torproject.org/onion-services/setup/install/#installing-tor-from-source/ ↩
https://community.torproject.org/onion-services/advanced/vanity-addresses/ ↩
https://community.torproject.org/onion-services/advanced/onion-location/ ↩
https://github.com/mikeperry-tor/vanguards/ ↩
https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt/ ↩

CT-005: Contributing to Monero anonymously

Mon, 14 Nov 2022 UTC

This is the 5th report in the new Cypherpunk Transmission series.

Motivation

Anyone can anonymously contribute code to the Monero software. Although the project’s centralized Git repository is currently hosted on Github, an account is not required to submit a patch.

Git is a distributed version control system and its design allows development to continue uninterrupted by any Github outages, errors and potential bans.

This is not a version control or C++ programming guide. Instead, it should serve as a reminder that Git is not Github, and anonymous contributions to Monero are indeed possible and welcome.

Assumptions

git¹ is installed on your system
you already have a copy of the latest monero software on your system (CT-002²)
basic terminal, git knowledge

1. Configure Git identity

Let’s first set up your well-known alias (a name and email - doesn’t need to be a real address) that will be baked into your commits.

Open up a terminal in your local monero repository directory and type in:

git config user.name "Anon5589"
git config user.email "anon5589@inter.net"

Note: replace name and email accordingly; optionally use the --global flag if you want to set up a global identity, for all projects.

A quick git config --list should now output:

user.name=Anon5589
user.email=anon5589@inter.net

The settings are saved in .git/config.

2. Make a change

Assuming you have updated the copyright year in README.md, you can add the modified file to the index and create a new commit:

git add README.md
git commit -m "README: update copyright year"

Note: display the commit logs with git log.

3. Prepare the patch

git format-patch HEAD -1 --stdout > new-update.patch

cat new-update.patch to see the formatted patch for the last commit. Output should be similar to this:

From 13f5aff0990a61cba2381e11d6fa7dd351b1290c Mon Sep 17 00:00:00 2001
From: Anon5589 <anon5589@inter.net>
Date: Mon, 14 Nov 2022 14:12:00 -0700
Subject: [PATCH] README: update copyright year

---
 README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README.md b/README.md
index 0ab1a8f31..dd02c2e10 100644
--- a/README.md
+++ b/README.md
@@ -1,6 +1,6 @@
 # Monero

-Copyright (c) 2014-2022 The Monero Project.
+Copyright (c) 2014-2023 The Monero Project.

 ## Table of Contents
-- 
2.38.0

4. Send the patch

Post the patch to any pastebin³ site that is JS-free and select a long timeout/expiration date.

While you could send the patch via email, it is recommended to share the pastebin link in the #monero-dev⁴ chatroom to avoid delays.

All you have to do now is to wait for feedback from the community.

Observations

patches submitted over IRC should ideally be high quality
patches should generally be self contained (one patch per separate issue, feature, or logical change)
use descriptive commit messages
squash (merge) related patches whenever possible
it is recommended to PGP sign commits
read CONTRIBUTING.md⁵ to learn more about the process
adapt this to your own threat model/workflow (ie. use tor to download source, share patch;)

That’s it. You can now start contributing to Monero anonymously, without a Github account.

Feedback

Let me know if you find this helpful and, depending on interest, I will do my best to post a new Cypherpunk Transmission report every (other?) Monday.

Questions, edits and suggestions are always appreciated @ /about/.

-3RA

Credit goes to gnuteardrops from monero.graphics for the amazing xkcd graphic. Work and xkcd Script font licensed under CC BY-NC 3.0.

https://git-scm.com/download/ ↩
/cypherpunk-transmission-002-building-from-source-monero-cli/ ↩
https://paste.debian.net/ ↩
irc://irc.libera.chat/#monero-dev (IRC), https://matrix.to/#/#monero-dev:matrix.org (Matrix) ↩
https://github.com/monero-project/monero/blob/master/docs/CONTRIBUTING.md ↩

CT-004: GPG encrypted communication

Mon, 07 Nov 2022 UTC

This is the 4th report in the new Cypherpunk Transmission series.

Motivation

We cannot expect anyone to grant us privacy out of their beneficence. Distrust the infrastructure and any encryption services provided by 3rd parties, by default. We must encrypt manually, locally.

Mechanisms such as TLS and passwords only partially protect the content of our messages. For a lot of threat models, it is better to use encryption for everything, not just secret data.

Although not perfect, GPG is still pretty good and very relevant even after decades. It is also relatively easy to use. Follow this simple guide to learn the basics.

Assumptions

gnupg¹ is installed on your system
you already own a keypair²
basic terminal knowledge

1. Key exchange

1.1 Export your public key

Open up a terminal and list your secret keys first:

gpg -K

The output should contain at least one block like this:

sec   rsa4096 2022-11-01 [SC]
      BCE15F74D18112824899608AFD103120DC7BCC36
uid           [ultimate] escapethe3ra@disroot.org
ssb   rsa4096 2022-11-01 [E]

The next line below sec should contain your key’s fingerprint.

Now you can export your publick key in .asc (ascii armored) format:

gpg --export -a BCE15F74D18112824899608AFD103120DC7BCC36 > escapethe3ra@disroot.org

Note: replace the key fingerprint and file name accordingly.

The previous command should have created a file that starts with —–BEGIN PGP PUBLIC KEY BLOCK—– and ends with —–END PGP PUBLIC KEY BLOCK—–. This can be shared with the world.

You could make your pubkey publicly available by uploading it to your own website. It is recommended to also include your key’s fingerprint.

1.3 Fetch your partner’s public key

To start communicating, you need to encrypt your messages with your partner’s public key.

If you don’t have one currently, that’s okay. I am happy to play that role.

Download my public key³ file first:

wget https://monero.observer/3RA_pubkey.asc

If the key’s fingerprint matches BCE15F74D18112824899608AFD103120DC7BCC36, import it:

gpg --show-keys 3RA_pubkey.asc

gpg --import 3RA_pubkey.asc

Note: if the fingerprint does not match, do not import it. Delete the file and try downloading it again.

2. Sending encrypted messages

2.1 Write the message

Write a simple message and save it to msg-1.txt:

echo "Hello 3RA! GPG is easy :)" > msg-1.txt

2.2 Encrypt and send the message

Now let’s encrypt and sign the message:

gpg --encrypt --sign --armor --recipient BCE15F74D18112824899608AFD103120DC7BCC36 msg-1.txt

You should now have a msg-1.txt.asc file that looks like this:

-----BEGIN PGP MESSAGE-----
[..]
-----END PGP MESSAGE-----

Send me that message via any communication channel included in my contact-signed.txt⁴ file (preferably email or XMPP).

Note: remember to include your own public key if you want to receive an encrypted reply.

3. Decrypting messages

3.1 Decrypting raw text streams

Run gpg in a terminal and paste the message at the prompt. Then, simply press CTRL+D to signal end of message and trigger decryption. You should see the decrypted message in your terminal.

3.2 Decrypting files

For files, type in:

gpg file_name_encrypted

Type N and enter a new file name if you don’t want to overwrite the original.

Alternatively, you can skip all prompts by using gpg --decrypt file_name_encrypted > file_name_decrypted.

Observations

any file type can be encrypted and decrypted (pdf, images, audio, video, text); watch out for malware and don’t execute stuff you don’t trust
GPG encryption only hides the contents of files (does not hide meta-data: message size, sender and receiver)
protect your secret key with a strong passphrase and never share it with anyone
respect your partner by fully encrypting your replies (ie. do not expose your partner’s messages in cleartext)

That’s it for this basic GPG communication guide. If you need help, you know how and where to contact me.

Onward.

Feedback

Let me know if you find this helpful and, depending on interest, I will do my best to post a new Cypherpunk Transmission report every (other?) Monday.

Questions, edits and suggestions are always appreciated @ /about/.

-3RA

Credit goes to gnuteardrops from monero.graphics for the amazing xkcd graphic. Work and xkcd Script font licensed under CC BY-NC 3.0.

Update: modified email to reflect current address.

CT-003: Basic server security

Mon, 31 Oct 2022 UTC

This is the third report in the new Cypherpunk Transmission series.

Motivation

The first thing admins usually do after logging into an off-the-shelf server is to secure it.

While there are a lot of advanced techniques and methods that can be used to improve the security of a new server and help keep it protected from various threats, this guide will only focus on the essentials.

Assumptions

you have ssh access to a VPS (Debian/-based) from a GNU/Linux machine
basic terminal and nano editor knowledge
~1 hour free time

1. Add new user

Note: run ssh root@server_ip in a terminal if you are not connected. Replace server_ip with your VPS IP address.

To avoid using the root account on a regular basis, we need to first add a new user and grant it administrative privileges:

adduser newuser

Enter a strong password and hit Enter to skip optional fields.

usermod -aG sudo newuser

2. Install firewall

Update and install a basic firewall via apt:

apt update

apt install ufw

Set default policies:

ufw default deny incoming

ufw default allow outgoing

Allow ssh connections and enable the firewall:

ufw allow SSH

Verify the status with:

ufw status verbose

Only proceed if the output includes this line:

To             Action      From
--             ------      ----
22/tcp (SSH)   ALLOW IN    Anywhere

Enable the firewall:

ufw enable

Note: later you will probably need to adjust the firewall settings to allow traffic in from other services that you install; example for Nginx: sudo ufw allow 'Nginx Full'.

You can now close the connection to the server with exit.

3. Harden SSH

3.1 Client config

On your local machine, open the ssh_config file:

sudo nano /etc/ssh/ssh_config

Add or modify these lines to allow public key authentication, disable IPv6 to reduce attack surface, and use the strongest cipher suites, message integrity codes, and key exchange algorithms available:

PubkeyAuthentication yes
AddressFamily inet
StrictHostKeyChecking ask
Ciphers chacha20-poly1305@openssh.com
MACs hmac-sha2-512-etm@openssh.com
KexAlgorithms curve25519-sha256

Save the file with CTRL+X > Y > press Enter.

3.2 Server config

Open two terminal tabs/windows and establish two separate SSH connections to the server, for backup purposes:

ssh root@server_ip

Restart the sshd daemon:

systemctl restart sshd

If both connections are still alive, try opening a third terminal window and test new connections:

ssh root@server_ip

Proceed if everything is working as expected.

In any terminal, make a backup of the original SSH configuration file with:

cp /etc/ssh/sshd_config /etc/ssh/sshd_config_backup

Now open the sshd_config file:

nano /etc/ssh/sshd_config

Add or modify these lines to enable SSH v2 for added protections against known vulnerabilities, disable IPv6, disallow root/pass logins, only allow logins from the user newuser, and use the strongest ciphers and algos available:

Protocol 2
AddressFamily inet
PermitRootLogin prohibit-password
PasswordAuthentication no
AllowUsers newuser
Ciphers chacha20-poly1305@openssh.com
MACs hmac-sha2-512-etm@openssh.com
KexAlgorithms curve25519-sha256

Note: replace newuser with the actual username from step 1.

Note: run ssh -Q cipher, ssh -Q mac, and ssh -Q kex for a list of supported ciphers and algorithms.

You can also change the default ssh daemon listen port from 22 to something else in an attempt to avoid open ports scans:

Port 3489

Note: if you change the default ssh port, you need to update ufw rules; example: ufw allow 3489. Connect with ssh newuser@server_ip -p 3489.

Save the file with CTRL+X > Y > press Enter.

3.2 Test connection

Restart the sshd daemon:

systemctl restart sshd

Open another terminal tab/window and try to SSH to the server:

ssh newuser@server_ip

If it doesn’t work, check for configuration errors using the other terminal and then try again.

If successful, you will be able to ssh with newuser to the server from now on, and install any software you want.

Observations

use strong and random passwords for system logins to protect against brute-force attacks
generate and use strong SSH keys protected by passphrases
update system regularly; you could automate the process with a cron job
optionally install Fail2Ban to monitor system logs and protect against DDoS attacks

That’s it for this basic server security guide. Reach out to me if you run into any trouble. Good luck!

Feedback

Let me know if you find this helpful and, depending on interest, I will do my best to post a new Cypherpunk Transmission report every (other?) Monday.

Questions, edits and suggestions are always appreciated @ /about/.

-3RA

Credit goes to gnuteardrops from monero.graphics for the amazing xkcd graphic. Work and xkcd Script font licensed under CC BY-NC 3.0.

CT-002: Building from source - Monero CLI

Mon, 24 Oct 2022 UTC

This is the second report in the new Cypherpunk Transmission series.

Motivation

Anyone can download, run and install binaries that were built by someone else. Relatively few users ever build their own programs, despite the advantages:

security (no need to trust potentially compromised binaries, rely on source code integrity)
control (build for any distro, hardware, add/remove options)
knowledge (become a contributor to FLOSS)

Building from source usually involves a series of steps, such as compiling, linking, running automated tests and packaging. It can sound nightmarish for new users, but it certainly is not.

By getting familiar with the process, you will also be able to start contributing to your favorite open source projects, like Monero.

Assumptions

you have (sudo) access to a GNU/Linux machine (Debian/-based)
1GB+ free disk space && ~1 hour free time
you are not scared of dragons

Compiling Monero

Let’s practice by compiling the official Monero CLI Wallet from source.

1. Install dependencies

Paste this long command in a terminal to upgrade packages, install git, and all dependencies:

sudo apt update && sudo apt upgrade -y && sudo apt install build-essential cmake pkg-config libssl-dev libzmq3-dev libunbound-dev libsodium-dev libunwind8-dev liblzma-dev libreadline6-dev libexpat1-dev libpgm-dev qttools5-dev-tools libhidapi-dev libusb-1.0-0-dev libprotobuf-dev protobuf-compiler libudev-dev libboost-chrono-dev libboost-date-time-dev libboost-filesystem-dev libboost-locale-dev libboost-program-options-dev libboost-regex-dev libboost-serialization-dev libboost-system-dev libboost-thread-dev python3 ccache doxygen graphviz git

2. Get source code

Recursively clone the repository and change directory to source code root:

git clone --recursive https://github.com/monero-project/monero && cd monero

3. Build

Compile the most stable Monero release:

git checkout release-v0.18 && make

Done! The executable files (including monerod, monero-wallet-cli) can be found in build/Linux/release-v0.18/release/bin.

Note that the process might take a while to complete.

Observations

to compile and test the most recent (unstable) software, use git checkout master && make
to enable parallel build, use make -j<number of threads> instead of make (minimum 1 core, 2GB/thread)
to build and run optional tests to verify binaries, run make release-test (may take hours to complete)
to build for other distros/hardware and learn more about different build options, consult the official docs
you can also experiment by building related software from source (ie. Monero GUI, XMRig, P2Pool)

Reach out to other Monero contributors if you get any errors or if you discover anything interesting during your journey.

Feedback

Let me know if you find this helpful and, depending on interest, I will do my best to post a new Cypherpunk Transmission report every (other?) Monday.

Questions, edits and suggestions are always appreciated @ /about/.

-3RA

Credit goes to gnuteardrops from monero.graphics for the amazing xkcd graphic. Work and xkcd Script font licensed under CC BY-NC 3.0.

CT-001: Threat modeling demystified

Mon, 17 Oct 2022 UTC

This is the first report in the new Cypherpunk Transmission series.

Motivation

There is no such thing as full privacy and security. It’s impossible to protect all your assets from everyone all the time.

Everything is a trade-off, tools and techniques are ephemeral, and that’s why threat modeling is key.

A list of the most probable threats to your security and privacy endeavors shouldn’t be too hard to create.

Assumptions

you care enough about privacy and security

Threat modeling A-T-F-R-M

(A)ssets - (T)hreats - (F)ails - (R)isks - (M)itigations

Let’s take a closer look at each step:

(A) Assets

What assets do you want to protect? Identify assets worth protecting.

(T) Threats

Who do you want to protect the assets from? Which adversaries might be interested in those assets? Speculate.

(F) Fails

How bad are the consequences if you fail to protect the assets from those threats? What capabilities does your adversary have?

(R) Risks

What is the probability that any of those fail scenarios might happen?

(M) Mitigations

How much convenience are you willing to sacrifice in order to prevent the fail scenarios? What are you technical and financial constraints?

Example scenario

Jane (34, married with kids, works at small company)

Jane thinks she might have a rare illness and doesn’t want her family, friends and co-workers to find out about it at this point.

(A)

medical search queries

(T)

interested: family, friends, co-workers
indirectly interested: big tech/search engines
not really interested: ISP, OS, hackers

(F)

family has access to Jane’s devices (laptop, phone)
friends and co-workers can see her public social media stuff
search engines can see the queries and her IP address
the company might be able to get a hold of her search queries via a third party
ISP/OS has the capability to inspect/capture/profile her traffic
someone might be able to place a keylogger on her machine
fail: people might change their behavior towards Jane
fail: she might lose her job
fail: blackmail is a possibility

(R)

very high probability: friends see her social media posts related to the medical searches
very high probability: family member accidentally finds browser with search query open
high probability: family member sees targeted (medical) ads on her social media
high probability: suspicious husband looks at the browser history
high probability: the search engine shares her data with third parties
very low probability: the ISP or OS shares traffic with her company (no real incentive)
very low probability: a hacker could log her keystrokes and blackmail her (poor risk-reward)

(M)

no-go: installing the tor browser/using a Tails usb might be a red flag; family could ask unnecessary questions
no-go: locking (password) phone/laptop could also raise suspicions
no-go: having a separate sim card dedicated to this (with no history/contacts) is risky and might become a burden
plan: avoid posting anything related to (A) on social media
plan: use a SearX/SearXNG search instance; always remember to close browser and clear history
plan: use a separate (dedicated) browser in incognito mode on a home machine; do not use it for any other stuff (this should mitigate most probable scenarios)

Observations

Although imperfect, the random example above should provide a big picture view of the threat modeling process and hopefully help you get started.

Here are a few notes to keep in mind:

review your security plan periodically and revise it accordingly
do not share your own specific threat model scenario with anyone
use pen and paper and protect/destroy the actual list after you’re done
more complex != more secure; keep it simple

Feedback

Let me know if you find this helpful and, depending on interest, I will do my best to post a new Cypherpunk Transmission report every (other?) Monday.

Questions, edits and suggestions are always appreciated @ /about/.

-3RA

Credit goes to gnuteardrops from monero.graphics for the amazing xkcd graphic. Work and xkcd Script font licensed under CC BY-NC 3.0.

Monero Observer

CT-017: Rethinking the Monero CCS: A cypherpunk proposal

Motivation

Assumptions

1. The status quo

2. Possible ways forward

3. A cypherpunk proposal

4. Comparison table

Observations

Feedback

CT-016: Using 1vyrain to 'soft disable' the dreaded Intel ME on xx30 ThinkPads

Motivation

Assumptions

0. WARNINGS!

0.1 The good news

0.2 The bad news

1. Check BIOS compatibility3

2. Downgrade BIOS using IVprep

2.1 Prepare BIOS settings

2.2 Download IVprep

3. Exploit BIOS using 1vyrain

3.1 Download 1vyrain

3.2 Create live USB

3.2.1 On Linux

3.2.2 On Windows

3.3 Prepare BIOS settings

3.4 Exploit BIOS!

4. Disable Intel ME

Observations

Feedback

CT-015: Monero lore compendium

Motivation

Assumptions

1. Questions

2. Answers

Where can I buy and sell XMR without KYC?

What is the best Monero wallet for desktop?

Does Monero have hidden inflation bugs?

What is Monero’s maximum supply?

Where can I find XMR remote nodes to connect to?

How can I build Monero CLI from source?

Can ‘Mordinals’ still affect Monero’s fungibility if the ‘tx_extra’ field is reduced in size?

How does BTC Lightning Network compare with Monero in terms of privacy?

Did Monero have a premine?

When does Monero celebrate its birthday?

What are the best Monero mobile wallets?

What’s the recommended way to mine Monero?

Observations

Feedback

CT-014: Whonix virtual machines on Debian using KVM

Motivation

Assumptions

0. Check virtualization support

1. KVM

1.1 Install

1.2 Configure

2. Whonix

2.1 Download

2.2 Verify

2.3 Decompress

2.4 License Agreement

2.5 Import VM Templates

2.6 Copy Image Files

2.7 (optional) Cleanup

2.8 (optional) Increase memory

2.9 Start Whonix

2.9.1 CLI

2.9.2 GUI

3. Post install

Observations

Feedback

CT-013: Moneranoj: Unite or 'curb your cypherpunk'

Motivation

Assumptions

1. A big picture view

1.1 State of affairs

1.2 The issues

2. Getting involved

Observations

Feedback

1. Check BIOS compatibility³