[cryptography] regarding the NSA crypto "breakthrough"

[coderman]

On Thu, Sep 5, 2013 at 4:14 PM, grarpamp <grarpamp at 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,