[Cryptography] crypto software design advice; separate admin interface, or not?

Bear bear at sonic.net
Tue May 6 00:46:56 EDT 2014


I'm coding a peer which does roughly the job of an encrypted inetd +
onion routing through a fully decentralized p2p network. 

The basic security design is that I'm avoiding it having the ability to
decrypt anything at all that it doesn't absolutely need to do its job.  

It has a 'listener', which listens on a known port and, when it gets 
an incoming connection, accepts a new peer (with an ephemeral port), 
negotiating a link key, updates its peer list, and then handles 
messages normally.

>From any peer, it gets a packet, decrypts using the link key that goes
with that peer, and then it has a decrypted header that gives minimal
information - at least a protocol number - and a payload which, despite
being decrypted with the link key, is still encrypted with its end2end
key.  The end2end key depends on the protocol and for protocols not
handled by the peer isn't available to the peer.

If the protocol number indicates that the payload should be handed off
to a program on the local machine, that's all the information that the
peer ever gets.  In the more usual case that the received packet isn't
for the local machine, the protocol will be 'route' or 'broadcast' or
'ping' or something, and there will be minimal additional information
such as a key/address, an expiry time, a list of IP+port addresses for
other peers, and/or a ZKP puzzle or solution (to prevent someone
announcing the receipt of a message and thereby cancelling its further
propagation, without actually having the key/address to which the
message is addressed).  Anyway, if another message (or more than one)
needs to issue as a result of processing the incoming packet, the peer
changes the header information as needed, then uses one (or more) of its
other link keys to encrypt the new header and reencrypt the payload, and
sends to whichever other peers are appropriate.  Rinse, repeat, until it
gets shut down.

Now, my basic question here is, is there a good reason for this to have
a separate  administrative interface? 

Someone could use the administrative interface to do things we don't 
want strangers across the net to do, such as accessing link keys by
port, dumping our (limited) routing information, shutting down the peer
or something. The usual method of securing this would guard against that
by having the admin interface on a separate port.  

But the fact of the matter is that nobody who isn't the real admin ought
to be able to get an admin command accepted, because absolutely every
packet is encrypted and nobody else ought to have the admin's key. So
the admin can (and maybe should?) just connect using the listener, like
any peer. 

I like this because it would make the program simpler; no separate admin
interface means not as many special cases and not as much complexity to
set it up or administrate it.  But is it reasonable to accept
(encrypted) admin commands on a regular port accessible to random remote
peers? 

Opinions?

				Bear




More information about the cryptography mailing list