> From: [email protected] [mailto:discuss-
> [email protected]] 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.   ;-)
_______________________________________________
Discuss mailing list
[email protected]
http://lists.blu.org/mailman/listinfo/discuss

Reply via email to