Encryption, paranoia and virtual machines

[R. Russell Reiter]

I think this conversation must be similar to one held by ARPA just before they pulled the plug on MULTICS funding. I'm a little weak on the details, but wasn't this the formative basis of the BSD code.

I think it boils down to the fact that you cannot legislate or otherwise compel someone to moral behaviour, you can only punish immoral behaviour.

Thats the "rub." There is no data security without trust. But who to trust and when to trust them is a question of the ages.

Roman emperors wrapped strips of paper around cylinders of a certain diameter. They then wrote the message along the length of it and then unwrapped the paper. Only if the paper was wrapped around a same sized stick, could the message be deciphered. You can bet the messages and the sticks traveled by different routes and that no messenger had access to both.




Jamon Camisso <jamon.camisso-H217xnMUJC0sA/PxXw9srA at public.gmane.org> wrote:

>-----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

R. Russell Reiter's Left Brain Messaging Matrix
[Currently Under Development] Your mileage may vary.
--
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