It takes about 512 logins, because after you've leaked a certain number of RSA key bits, you can set up a lattice search for the remaining bits. Because of the way the authentication and key escrow system worked, Mega could have run this attack over long periods of time, in parallel for all its users; the attack doesn't have to occur within a bounded period of time the way, say, an ephemeral-static ECDH TLS attack would work.
Maybe I misunderstand, but wouldn't the attack be visible to the user when the encryption glitches out and they have to reattempt the login or something?
No! That's another amazing detail here. The attacker is the server, and so it can just pretend you logged in successfully. You won't have fetched your key properly, but the Mega client automatically re-fetches the key when that happens.
> You won't have fetched your key properly, but the Mega client automatically re-fetches the key when that happens.
Is that something it could hypothetically do, or something that the current code does? In the latter case, is there any legitimate reason for doing that? And this would be detectable right, maybe not by a casual observer, but by a security researcher?
Sure; you could also look for all-zero SIDs. That relies on you knowing about this attack a priori, and if you know about it you can just not have the vulnerability.
No, I don't agree at all. There is literally new science in this paper; the idea that random "security researchers" looking at benign-looking crypto code and monitoring all the connections their clients made (a thing nobody does) would ever have caught this is not plausible.
