I’m pretty sure that certain three letter agencies are using this kind of attack.
It wasn’t clear to me that this conclusion is warranted i.e. it depends on whether “our database” includes all public keys on the planet, all public keys in use specifically with ProtonMail, or something in between.
The overall topic is a bit beyond my level of knowledge but I think the conclusions are:
2048 bits is not enough (use minimum 3072)
when generating secret keys (symmetric or asymmetric) do make sure that you have enough entropy - I use external hardware to supplement entropy
specifically for SSH (not directly relevant to that paper, I think) use ECDSA rather than older choices (which by now is the default anyway, I think) - more generally, keep software current and keep abreast of developments in crypto
i believe protonm recommends that rsa 4096 bit keys should be generated on PC-desktop-class compute devices and not mobile phones
one thing with protonm that people aren’t aware of is that the encryption key that the contact list is protected with is SEPARATE from the other keys and i haven’t found a way to change it from 2048 to anything more secure. i’m probably too paranoid in this case but it wouldn’t hurt for them to implement an easy way for people to change it should they wish to do so …
another point. encryption keys have EXPIRATION dates and they should be manually changed together with the password/passphrase at least once/year imo.
i’ve seen that some people working in support at Purism with keys that haven’t been changed since 2016 … perhaps they don’t need to but public keys are … well … PUBLIC, so for customers peace of mind they should not neglect this aspect …
Some good points there. Of course certificates have formal expiration dates but all crypto should be considered to have some expiration date due to ongoing developments and attempts to break. Crypto is never “set and forget”.