However, that implies that the adversary sticks to the network's difficulty setting. If it didn't, it could create longer chains using much less computing power.
The Bitcoin network's backbone is spanned by fully validating nodes ("full nodes"). This type of Bitcoin client participates in the peer-to-peer network by unilaterally validating and enforcing all rules of the Bitcoin protocol. They rely on their peers to provide information, but can individually assess the validity thereof. Each and every full node has parsed the complete blockchain from scratch to converge to the network's current state.
The difficulty target of Bitcoin blocks is updated every 2016 blocks. Hereby the new difficulty is a function of the time the previous difficulty period took and the previous difficulty. If the previous 2015 blocks were found in less time than a fortnight, the difficulty increases and if the blocks took longer the difficulty decreases (see How is difficulty calculated?). Since each full node processed the complete blockchain from the genesis block, they are aware of and have validated the difficulty and timestamps of the previous blocks. Hence, each node knows exactly which difficulty to expect for the next block. Therefore, an attacker's "forged" blockchain tip with a long-chain of low-difficulty blocks would not match the expected difficulty statement and thus be found invalid by every full node in the network. Since full nodes don't relay invalid information, the attacker's chain would also not be broadcast beyond his peers.
Further, "longest chain" is a bit of a misnomer, actually the best chain tip is determined by the highest accumulated difficulty. If e.g. an attacker would fork off from the Genesis Block and mine 1,000,000 blocks with the minimum difficulty, their chain would be "longer", but have less total difficulty and would not be consider. Besides, the attacker would also need to fake the timestamps or any nodes that tried to follow the chain would expect a different difficulty after the first retarget, and this causes problems further down the road when full nodes don't accept blocks with timestamps that are more than two hours in the future.
I wonder: Why is this setting (an adversary ignoring the difficulty and mining a long chain) not considered? Nodes that freshly join the network don't know about the difficulty and, according to the longest-chain-rule, must choose the adversary's chain.
The scenario has been covered extensively in best-chain.
- Full nodes that freshly join the network validate the complete blockchain unilaterally (only depending on finding a single source of correct data)
- Full nodes sync only the block headers first, which already must fulfill the required difficulty and must adhere to the difficulty retargeting rules
- The "longest-chain" rule is an imprecise moniker for what is happening, it's actually "most total work"¹
- Light clients can check block headers for self-consistency, could do just a block header sync (each block header is 80 B, so altogether about ~50 MiB today), will ask multiple peers for their best chaintip.
- Invalid blocks are not propagated on the network, so light clients benefit from the "herd immunity" of full nodes and are unlikely to be fooled except in conjuction with a highly targeted eclipse attack.
¹ Actually, this was a bug in the original implementation that really only checked the height which was fixed by replacing it with total work.