[Chugalug] Is time for crypto for non-techies class?
danlyke at flutterby.com
Tue Jun 11 17:20:10 UTC 2013
On Tue, 11 Jun 2013 10:58:22 -0400
Stephen Kraus <ub3ratl4sf00 at gmail.com> wrote:
> I'm sure they have something that can crack most open source
> encryption solutions.
I doubt it, and I certainly wouldn't trust any closed-source encryption
The big issue with crypto isn't the crypto itself, it's the procedures
that flow around it. For instance (and this is a non-academic
discussion), say I want to have secure communications with my family:
* First, I need to generate keys on a machine I believe is relatively
secure, and they need to generate keys on machines they believe are
relatively secure. Given that many banking scams these days are
happening through Man-In-The-Browser attacks, this probably means a
Linux box with trusted provenance.
Especially given that Apple and Google were listed in that Prism
slide, this suggests that we should treat iOS and Android as suspect.
Windows we treat as suspect because even without Microsoft's
involvement it could easily be compromised.
That might even mean Gentoo, so that I have some notion that I'm
using signed source packages, but we'll say that for whatever reason
I trust the various Ubuntu packagers, so everyone's running Ubuntu.
* Second, we need to exchange public keys. This probably isn't too bad,
we can email them, and then verify key fingerprints via a secondary
channel, say, voice over telephone. In the process of doing this, if
one of those channels are compromised, we've then removed plausible
deniability for statements made with a message decrypted by one of
* Now we need to use that encryption, and have a mechanism for
refreshing those keys when they expire. My email client is pretty
good for encrypting point-to-point if it knows the target email is
encrypted, but I'm not sure how it does for CC lists.
* So that leaves two big remaining gaping holes: The first is that I
need to encrypt everything I say to my family, so that encrypted
traffic isn't an obvious red flag. This might even mean intentionally
sending unencrypted messages to some people on CC lists so that
there's a trail of "this message was innocuous but encrypted to these
recipients", but the second is...
... as the Verizon Wireless stuff demonstrates, the fact that the
message was sent at all is evidence. And encrypting the message
doesn't hide the sender and recipient, or the size of the message.
* And if a machine is compromised (sister clicks on a virus, I
compile and run from a source repo that has a diff in it), then we
have a set of issues involving those messages, and what happens with
archived messages, that we should be careful of.
(For instance: At the border, DHS searches my laptop and notices I
save all the cute pictures of my nephew, but delete a few messages in
there at a time that might correlate with something else. That's a
So given all of that, the hard part isn't generating the keys, or even
exchanging the keys, it's thinking about how we use them that's the
And, frankly, this is the part where I'm confident that I haven't worked
out all of the holes.
More information about the Chugalug