On Thu, Sep 5, 2013 at 4:14 PM, grarpamp <grarpamp@gmail.com> wrote:
... Perhaps my issue is just with the words. I read Bamford as indicating attacks against the crypto itself, not tricks applied downstream or around it (regardless of how wholesale, specific, successful or profitable a given applied approach might be in the eyes of the doers or the done).
when i read what he wrote, in the context of how i expect this system is built, it is to me a violation of the implied assumptions in crypto that he is discussing. assumptions like "SSL private keys are kept on the servers, not provided to third parties" ... for national security reasons. assumptions like "i'm using ZRTP, my call is end-to-end secure!" (why the !^@# is ZRTP termination the usual mode in VoIP server implementations? E.g. wiretap mode. Oh, nevermind...) the list goes on.
While recently novel and profitable with centralized services, borrowing traditional certs [1] or logging the PFS session keys [2] is vastly different from having a working "cryptanalysis" against the long term thought to be dependable underlings such as RSA, AES, ECC, etc.
you'll notice that all of the targets mentioned above have a public key exchange mechanism where by session secrets can be exchanged in presumed privacy - unless forward secrecy is used. we've seen how the "latency" added for forward secrecy provides fig leaf coverage for real reason. keep-alive don't care about your start-up latency! in short: #1 with the private keys handed over or pilfered, to support DPI-SSL, is reasonable, effective, and fits within the parameters of what we've discovered. it could be part of the certificate renewal process, an infrequent one-off. #2 is not done, since this would be logistically ugly - every web server somehow feeding back ephemeral keys or session secrets to the spooks. not going to happen. #2 does raise an interesting proposition - if forward secrecy becomes common this collection mechanism is crippled. watch for push back against wide deployment of PFS suites on large web properties. (spoiler alert: i'll bet you money this won't happen, for all sorts of stated reasons except the real one.)
Then again, might as well ship the plaintext straight off the servers.
the live dip is PRISM, the passive snarf is UPSTREAM, of which BULLRUN is a part? remember, "You should use both." best regards,