equivrel

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.

Thanks!

I'd love one! I've been really excited about this project for over a year but still in the invite queue :(.

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).