[146391] in cryptography@c2.net mail archive
[Cryptography] Using Raspberry Pis
daemon@ATHENA.MIT.EDU (Phillip Hallam-Baker)
Mon Aug 26 17:00:13 2013
X-Original-To: cryptography@metzdowd.com
Date: Mon, 26 Aug 2013 16:12:22 -0400
From: Phillip Hallam-Baker <hallam@gmail.com>
To: "cryptography@metzdowd.com" <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============7107684117662357571==
Content-Type: multipart/alternative; boundary=001a11c34438c2a02f04e4df5ff5
--001a11c34438c2a02f04e4df5ff5
Content-Type: text/plain; charset=ISO-8859-1
I really like RPis as a cryptographic tool. The only thing that would make
them better is a second Ethernet interface so they could be used as a
firewall type device.
However that said, the pros are:
* Small, cheap, reasonably fast, has ethernet and even a monitor output
* Boot from an SD card which can be preloaded with the OS and application
build. So it is really easy to use RPi as an embedded device controller.
The main con is that they are not so fast that you want to be routing
packets through them unnecessarily. So they are a great device to make use
of for connection brokering, not such a great idea to tunnel video packets
through them.
It is entirely reasonable to tell someone to get an RPi, download a config
onto an SD card, plug it into their network and apply power and ethernet.
And they take so little power that we could even tell them to install a
pair so that they had a fault tolerant setup (although they are low enough
power, low enough complexity that this may not be necessary or helpful).
In the home of the future there will be hundreds of devices on the network
rather than just the dozens I have today. So trying to configure security
at every point is a non starter. Peer to peer network configurations tend
to end up being unnecessarily chatty and are hard to debug because you
can't tell who is meant to be in command.
The approach that makes most sense to me is to have one or two network
controller devices built on something like RPis and vest all the trust
decisions in those. So rather than trying to configure PKI at hundreds of
devices, concentrate those decisions in just one logical point.
So I would like at minimum such a device to be my DNS + DHCP + PKI + NTP
configuration service and talk a consistent API to the rest of the network.
Which is the work I am doing on Omnibroker.
Putting a mail server on the system as well would be logical, though it
would increase complexity and more moving parts on a trusted system makes
me a little nervous.
--
Website: http://hallambaker.com/
--001a11c34438c2a02f04e4df5ff5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I really like RPis as a cryptographic tool. The only thing=
that would make them better is a second Ethernet interface so they could b=
e used as a firewall type device.<div><br></div><div>However that said, the=
pros are:</div>
<div><br></div><div>* Small, cheap, reasonably fast, has ethernet and even =
a monitor output</div><div><br></div><div>* Boot from an SD card which can =
be preloaded with the OS and application build. So it is really easy to use=
RPi as an embedded device controller.</div>
<div><br></div><div>The main con is that they are not so fast that you want=
to be routing packets through them unnecessarily. So they are a great devi=
ce to make use of for connection brokering, not such a great idea to tunnel=
video packets through them.<br>
</div><div><br></div><div><br></div><div>It is entirely reasonable to tell =
someone to get an RPi, download a config onto an SD card, plug it into thei=
r network and apply power and ethernet. And they take so little power that =
we could even tell them to install a pair so that they had a fault tolerant=
setup (although they are low enough power, low enough complexity that this=
may not be necessary or helpful).</div>
<div><br></div><div><br></div><div>In the home of the future there will be =
hundreds of devices on the network rather than just the dozens I have today=
. So trying to configure security at every point is a non starter. Peer to =
peer network configurations tend to end up being unnecessarily chatty and a=
re hard to debug because you can't tell who is meant to be in command.<=
/div>
<div><br></div><div>The approach that makes most sense to me is to have one=
or two network controller devices built on something like RPis and vest al=
l the trust decisions in those. So rather than trying to configure PKI at h=
undreds of devices, concentrate those decisions in just one logical point.=
=A0</div>
<div><br></div><div><br></div><div>So I would like at minimum such a device=
to be my DNS + DHCP + PKI + NTP configuration service and talk a consisten=
t API to the rest of the network. Which is the work I am doing on Omnibroke=
r.</div>
<div><br></div><div>Putting a mail server on the system as well would be lo=
gical, though it would increase complexity and more moving parts on a trust=
ed system makes me a little nervous.</div><div><br></div><div><br></div>
<div><br></div><div><div><br></div>-- <br>Website: <a href=3D"http://hallam=
baker.com/">http://hallambaker.com/</a><br>
</div></div>
--001a11c34438c2a02f04e4df5ff5--
--===============7107684117662357571==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============7107684117662357571==--
