Encryption, paranoia and virtual machines

Jamon Camisso jamon.camisso-H217xnMUJC0sA/PxXw9srA at public.gmane.org
Fri Nov 25 19:57:49 UTC 2011


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/25/2011 02:19 PM, Christopher Browne wrote:
> Characteristic case:  the rape crisis centre, where the admins in the
> back room have NO business having access to the data, prurient or
> otherwise.  Victims won't talk freely if their skin crawls at the
> thought of unknown people reading their accounts - data simply won't
> get recorded unless it is secured against the admins, and that's not
> "one layer of admins, but not the others that we do trust", that's
> secured against access by ALL the admins.  Your premise of an extra
> layer of administrators doesn't work.

That's a great example of how trust can be shifted from one party to
another. But my point is that ultimately, there's still a leap of faith
on everyone's part to trust in other parties. Otherwise a) no one would
call, b) no one would be hired in the first place. The admins may not be
trusted, but the staff or volunteers are. Presumably the training or
vetting undergone by the staff could just as easily be administered to
the admins.

> A less sensitive, but still interesting example is that of library
> data collection:  <http://www.wayner.org/node/31>
<snip>
> The surprising result is that the library doesn't need to keep a list
> of what people are reading to stop theft. A few simple one way
> functions can lock out even the most adept snoops. (A good one-way
> function is the Secure Hash Algorithm or SHA and many toolkits now
> come with implementations that implement it and a more general,
> metaprotocol, the HMAC.)"
> 
> You don't store the list of individuals and the books they have
> borrowed, you store SHA1 digests of those.

Sure you don't, but what stops the librarian from storing said list when
you checkout a book?

This is the whole point. Technical systems be damned, no matter how far
you take it, you have to trust someone or something. That's all that I'm
saying.

The broader theme here is understanding where to place one's trust
depending on the configuration of one's systems or staff, and evaluating
those against the risk factors involved in a possible compromise.

Jamon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJOz/M5AAoJEDJp9n+rTckFHVQQAMBV5ViglXQUpz541SaPVsNl
fcY7IIuiCLfUqgZE7u4xmDlk9izOM/5+mQpp3C+TbH8FoWzdUUHxSh0hyoDs/INw
FyR07VUOuJq+DRYZdx3PUDTbeALyy7NqU4bIeaDUe8K30PLbce/OR3rjkiljsHRg
TmklRzivk4oGtBPUS4rlNYlqXz3aQYD4pnnCRAoExqWfD8nWMBofrd5hEnbwXvtg
KqBhmh/Jo4E8S+IZ+EcLr443eAIdZAO8FSex/BGFPKlj8uqclMEPgYqBNSwtTZ9P
c+qMyKYr1HryQMwoUkj/jOyQ7AkTN772sYpVAgCZgMDZQt4bmoSJC8CELybb5fzX
PgwDZqPPRwwfz3VfeJ7Wdg17X3rCwAxiQ/oft1Hc/jECxDDtJFzDD8DrekB9qNMT
lw8fIPz6sJneREgQB8l1DrT7WdioF0aw0uswlYTbFJXj3906nUngeZfsLpNygd3y
GGJo0PUTqCy14mnikZRFd77MkQjR8C1zvD8HvORwOM3UjqZAHTD+FGy3zevWbdWp
JKeBDea4/zJ2sCoI8Pvzmb9/zosvWw+Z/v07Srwf1QIzNiunbfNQgmsG+lP4Avp6
YIghiCcQI6CQSSXDM3vg8tpubWwXbzMXveQy+dj/YcPsAt4DTG+rFzeOLF9xmQvu
UQj8JEAU3gNsMvjfATe4
=A2C3
-----END PGP SIGNATURE-----
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists





More information about the Legacy mailing list