[ULS-SIG] Encryption and identity

[Duncan McGreggor]

On Sat, Jul 9, 2011 at 10:07 PM, Duncan McGreggor
<duncan.mcgreggor at gmail.com> wrote:
> On Sat, Jul 9, 2011 at 6:51 PM, Duncan McGreggor
> <duncan.mcgreggor at gmail.com> wrote:
>> Zooko and Brian,
>>
>> You guys are the first two people I think of when I start thinking
>> about good security in Python code :-)
>>
>> I'm doing some experimentation with some of the concepts that underly
>> ultra large-scale systems... in particular, I'm exploring "governance"
>> of nodes in an abstract network/mesh. I'm preparing to implement some
>> voting procedures whereby nodes in a network can elect a leader node
>> to act as a proxy between the other nodes and a larger network
>> (limiting flooding, providing dynamic routing, etc.).
>>
>> This quickly led to concerns of rogue nodes, "stuffed ballot boxes",
>> etc. The first experiments are toy: taking place in a single Python
>> process. What mechanisms would you suggest I use to ensure that only
>> known nodes are allowed to vote? My first thought was public/private
>> keys generated by the nodes. Similarly, for encrypting data between
>> nodes.
>>
>> I'd like to have the implementation be as light-weight as possible...
>> eventually, this is the sort of thing that could go into masses of
>> tiny devices, e.g., health and environment monitoring nodes in a
>> hospital, carried on internal ventilation currents, attached to
>> walls/clothing/etc, adhered to patients, etc.
>>
>> Are there good papers you would recommend reading? Blog posts? Source code?
>>
>> Thanks!
>>
>> d
>
> A couple years ago, Alex Martelli recommended using pycrypto:
>  http://stackoverflow.com/questions/1137874/recommended-python-cryptographic-module/1138183#1138183
>
> I'm checking out the latest here:
>  https://github.com/dlitz/pycrypto
>
> From the README:
>
> """
> Another application is in writing daemons and
> servers.  Clients and servers can encrypt the data being exchanged and
> mutually authenticate themselves; daemons can encrypt private data for
> added security.  Python also provides a pleasant framework for
> prototyping and experimentation with cryptographic algorithms; thanks
> to its arbitrary-length integers, public key algorithms are easily
> implemented.
> """
>
> Thoughts anyone?
>
> d

As for the identity bit, it seems that some sort of PKI is going to be
necessary. This is not to say the current, global PKI (see this
presentation: https://docs.google.com/present/view?id=df9sn445_206ff3kn9gs&pli=1),
but rather *a* PKI.

I don't know enough about it to sufficiently outline or describe a
scenario where we can be guaranteed that each of the trillion or so
sensors in our imaginary hospital has the identity that we know and
expect. But it would likely have to entail the life cycle of the
sensors and utilize hospital technical staff. A trusted, distributed
storage mechanism would also be necessary (Tahoe-LAFS anyone?), since
sooner or later, the sensors will run out of space and not be able to
each hold copies of all the public keys.

Initialization of the first units would require a trusted environment
and a trusted individual. With all keys generated and shared, the
units would then seed the trusted web. Additional groups could be
introduced in a similar manner. I'm guessing, anyway. I just don't
have enough black hat in me to be able to anticipate the ways in which
sensing devices could be compromised and security measures
circumvented... or enough white hat to work around these.

d