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.
To clarify, the files are encrypted with a symmetric key, which even though is "private", is not part of a public-private key pair in asymmetric crypto.
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.
Right, I see that now. Adding an additional layer of RSA and per-file keys is an interesting twist. Generating a public/private key pair instead of a symmetric key seems to let them encrypt as many files as they want without keeping the private key in memory (which they relied on Windows to erase).
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.
locality is looking suspect for other reasons too, as it's one of the only ways to avoid 'black hole firewalls' [1] (the other way to avoid firewalls involves giving up conservation of information which would be bad for QM theory).
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.
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).
It was a larger number at first, but try remembering say 10 words in a row over a long period of time; most people find that difficult.
If hashing is implemented properly (i.e. is slow with a large number of iterations) then passphrases shouldn't have to be that long. And if it isn't, then pretty much anything you use will be as bad as each other (Some people are still using MD5 for example!!) :)
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.
