That's exactly the trick: the attacker doesn't send you their private key, they decrypt (using their private key) the other private key that the ransomware generated on your machine, which is what was used to encrypt the per-file AES keys.
This doesn't appear to be how WannaCry works: as ridiculous as it sounds, it looks like WannaCry actually generates a private key on the infected machine. If you look in search_primes.cpp (from line 251) in the linked repo, you'll see that the tool is literally searching the memory for prime numbers that divide the public modulus.
EDIT: CiPHPerCoder appears to have figured how the key management works.
The objects in boxes scenario you have described is useful to think about when coming to grips with QM and entanglement. However, one needs to be careful, because there is an additional subtlety: QM can have measurement scenarios that are not only entangled, but also non-local [1]. This means that it is provably impossible to endow the variables that you are measuring with prior, local assignments, e.g. like in the boxes scenario. So there is actually another phenomenon present in QM that makes it weird, and is strictly speaking distinct from entanglement.
Have a look at pass [1], it's a minimalist tool in bash that is so simple you can easily make adjustments to it yourself. The codebase is very small so it is easy to audit. The principle is that your password are encrypted with your public key. You can then use git to keep running copies of your encrypted passwords on many devices.
I don't see the harm in leaving the option in, given that for some applications a longer passphrase is critical (not everything can use iterated hash schemes: for instance if you want to deniably encrypt a hard drive partition to look like random data).
EDIT: also, 'explicit' is a nice touch, makes some pretty memorable passphrases, but I hope you're not taking from a small list of profanities, since that would seriously diminish the entropy. Be sure to factor in the (probably) much smaller number of possible 'explicit' passphrases when doing entropy calculations.
Online bruteforcing is not feasible except for extremely weak passwords or sites with security vulnerabilities. What is feasible is bruteforcing stolen password hashes (think Adobe leak) or say a hard drive encrypted with a memorable password, and this is where secure passphrases come into play.
Don't forget that passphrases are also have security uses other than authentication: symmetric encryption of private keys, disk/file encryption, etc. where their use is pretty much unavoidable. Obviously a very long randomly-generated encryption key saved to a usb stick is more resistant to brute force than a memorable passphrase, but you still want to symmetrically encrypt it with a good passphrase to keep it (relatively) secure in case it gets into the wrong hands.
I would suggest increasing the maximum length from 5. Many applications that don't use iterated hashing schemes like PBKDF2 recommend much longer passphrases for security against brute-force [1].
[1] Off the top of my head: cryptsetup with plain dm-crypt recommends a random English sentence of > 135 characters length (i.e. a passphrase of 27 words at 5 characters per word).