[Discuss] NSA capabilities

Edward Ned Harvey (blu) blu at nedharvey.com
Thu Aug 15 19:18:16 EDT 2013


> From: discuss-bounces+blu=nedharvey.com at blu.org [mailto:discuss-
> bounces+blu=nedharvey.com at blu.org] On Behalf Of Tom Metro
>
> But these impersonation certs don't help them recover the session key
> for a captured SSL session. 

That's correct.  The "trusted" (and hypothetically compromised) CA does not know the private key of any entity.  So as you said, a compromised CA facilitates MITM attack, but does not imply ability to decrypt intercepted communications.


> (Undoubtedly there are CAs who, as a matter of convenience, generate the
> key pair, and could be compelled by the NSA to retain the private key. 

I confirm this.  I certainly know at least one CA (startssl) which offers to generate your key for you.  I never accept this - I generate my own key and CSR, and then upload the CSR.

But startssl, being located in Israel, is perhaps able to escape such influences from the NSA, and perhaps more subject to some other authority.  Who knows, maybe the world's most popular CA's are actually just a front that the NSA puts up, in order to get more information.


> > The more that is encrypted, the more known text the NSA has available
> > for side-channel attacks. The more that is encrypted, the more
> > chances of a hash collision occurring or a pseudo-random key being
> > reused. Scaling up works in the NSA's favor...
> 
> This strikes me as a wild assertion and I don't follow the logic.
> References?

There is a grain of truth, but a silo of untruth.

The grain of truth is:  We all know that stream ciphers and sequential block ciphers produce ciphertext that should be indistinguishable from random, without knowledge of the key.  But in fact, they are not random.  The more repetition, the more it becomes distinguishable from random.  For example, if you use CBC, and you happen to produce a ciphertext block which is in some way related to the next plaintext block ... or if you should happen to produce the same ciphertext block on two separate occasions, then an observer could draw a relationship between the two plaintext blocks.  They may be an XOR of each other, or something like that.  In reality, this is very unlikely, and very difficult to observe, but it's still good practice to re-key your transmission once in a while ... after a certain number of bytes or seconds.

The silo of untruth is:  While it's true that using more widespread encryption enables a widespread attacker (not saying NSA) to observe more of these types of weaknesses, these weaknesses do remain very rare, very difficult to observe, and each incident of such a weakness yields only a little bit of information about the encrypted message.  Using more encryption definitely works *against* the widespread attacker.  Because the alternative is what, using no encryption?  Guess what's easier to crack.  In the message above, Rich smoked a grain of truth and jumped off a cliff into an abyss of crazy hallucination.  "Using more widespread encryption works in their favor to decipher messages."   Red X, points deducted for that response.


> I think Kent Borg is following solid reasoning when he says that
> encrypting everything will increase costs for the NSA to the point that
> the chance that your data gets looked at by some automated process will
> be reduced by several orders of magnitude, unless metadata leads them to
> focus on you. 

+1

But talking about encryption, and specifically referring to the NSA, and referring to the NSA as "attacker" is probably more likely to get them looking at you than any other metadata we've discussed.  Obviously, nobody here is thinking very much about avoiding THAT.

PS.  Never say bomb in a sentence with Bush or Obama.    ;-)


> On the upside, it is said that the NSA will be more inclined to retain
> data that is encrypted, as it raises suspicion, so you've got a free
> backup service. :-)

Nobody cares about backups.  They only care about restores.    ;-)   Good luck with your restore operation.   ;-)



More information about the Discuss mailing list