It would appear that this attack is only relevant to “dumb” systems that use RSA for bulk encryption/decryption. Properly designed systems (e.g. S/MIME) would always use a much more efficient symmetric (wrapping) key for “user-data” crypto and then RSA just to protect that tiny wrapping key. Similarly, RSA only needs to protect the small hash of a digital signature. In these systems, there is *no* bulk RSA decryption to listen in on!

The Lockbox technology comes out of Melbourne, Australia. So (with completely client-side key/storage management) it looks pretty bad for the NSA or FBI: (1) No keys - all keys are client-side (there are no server-side keys) so they'd have to go after each end user individually (2) No ciphertext - users can store their encrypted data directly onto any overseas S3 server (e.g. Europe, Asia, South America) (3) No application influence - Lockbox is based in Australia and there is no Australian law nor treaty that could force an Australian company to compromise their commercial offering, nor any way to prosecute if the poisoned code didn't work. (Even if they could force poisoned code, they could never keep it secret as anyone could dissemble Lockbox's client-side code to reveal the poisoned code.)

Currently, SpiderOak isn't very private when sharing (hence the "expectation" sentance above). The core reason is that their sharing keys are server-side (see - https://spideroak.com/blog/20120507010958-increasing-transparency-alongside-privacy). Conversly, all Lockbox keys (and certificates) are purely client-side (there are no server-side keys) so that the "cloud" only ever stores encrypted blobs and is totally "blind" to all information being exchanged. If Lockbox got a legal (or NSA) demand they couldn't hand over anything except encrypted blobs of data (as they just don't have the keys). If SpiderOak got a legal demand, they'd have to hand over their shared data (as they do have access to the sharing keys).