I've been thinking recently about writing a Freenet client for PalmOS. On
the philosophy that it's simply impractical to run a node on a device with
little muti-tasking and small ammounts of memory, I've written up a proposal
for "Encrypted Node Connection Protocol" (ENCP), which will allow embedded
devices to connect securely to a mother Freenet node. I imagine this being
used by everyone from a user with a single PalmPilot connecting to their
node at home over a secure connection, all the way up to a huge office
complex with hundreds of embedded networked machines running off a
centralized server (a naughty word, I know, but I don't see how it can be
avoided).
(I am purpasely not naming this "Encrypted Freenet Client Protocol", because
it really has very little to do with FCP. The syntax of the commands are
designed to be much simpler, though related to FCP.)
Yes, I am in the middle of coding this, though the commands themselves are
not yet coded in; if there's any glareing errors in the way I've done the
command syntax, it's OK because that part hasn't even been coded yet.
Here is the draft of the proposal:
Encrypted Node Connection Protocol
This protocol takes a philosophy similar to FCP, but greatly simplified.
Some of this
was inspired by the FCP protocol with some SMTP mixed in. It is ment for
securely
connecting to a Freenet node remotely using embedded devices where
it is impractical to run a real node on the device itself, but you can
conntact a larger
computer that is running its own node.
NOTES
All communication is encrypted using AES with a shared secret as the key.
The shared
secret used should be 64 or 128 bits in length. All commands used in this
document are in
their unencrypted form; you must encrypt anything outgoing (unless stated
otherwise) and
decrypt anything incoming.
Commands are case-insensitive ('HELO' is the same as 'helo' is the same as
'hElO'). For return values, anything inbetween pointy braces <like this>
is variable data. There may also be comments on various values which will
come after a pound (#) symbol.
Options for a given command are to be given
on the same line as the command itself; for instance, an "INSERT" command
would be given as "INSERT 5 1024 KSK@someksk" (followed by the data to
insert). Options for
a given command inbetween pointy braces <like this> is required;
options inbetween square brackets [like this] are optional.
Unlike FCP, there is no filtering of IP/host names that are allowed to
connect. The only
requirement is that you have the shared secret in order to properly
encrypt/decrypt
communication.
COMMANDS
Name: HELO
Options: None
Description: Initial greeting used right after connecting.
Returns: Hello <ip/domain name> <protocol version> [whatever you want]
Errors: BadHello, # Sent unencrypted, then the server cuts the connection
TooManyConnections # Then the server cuts the connection
Name: INSERT
Options: <HTL> <size> <Freenet URI> # "size" is in bytes
Description: Inserts data into Freenet. The given data will follow on the
next line for "size" number of bytes. No information will
be returned by the server until that number of bytes is
reached
Returns: DataInserted
Errors: RouteNotFound, URIError, FormatError, KeyCollision
Name: REQUEST
Options: <HTL> <Freenet URI>
Description: Requests data (duh).
Returns: DataFound <size> # "size" is in bytes. Starting on the next
# line, "size" number of bytes (the data) will
# be returned.
Errors: RouteNotFound, URIError, DataNotFound, FormatError
Name: MAKESVK
Options: None
Description: Generates a new SVK public/private key pair
Returns: SVK <public key> <private key>
Errors: None
Name: MAKECHK
Options: <size> # "size" is in bytes.
Description: Generates a CHK for the given data. The next line will be
"size"
number of bytes of data to generate the CHK from. Nothing
will be sent from the server until "size" number of bytes is
reached.
Returns: CHK <value>
Errors: None
Name: QUIT
Options: None
Description: Signals that the connection is complete
Returns: Goodbye <ip/domain name> # and then the server cuts the
connection
Errors: None
DEPLOYMENT
A normal user with a single device connected to their home node doesn't need
much in the
way of scaleability. Therefore, most users can safely run an ENCPHandler on
their home
node and connect directly to it.
However, as the number of connections increase, so does the number of active
threads, both
in the connection handler itself and the Freenet node. As such, the number
of Java
threads can mount up much faster then Fred alone (which is already known to
be
thread-hungry).
A possible solution is to either use a non-Java node implementation (at this
time, no
such stable implementation exists) or to run the Freenet node and
ENCPHandler on
seperate machines, connected directly together over the network. Care
should be taken to
ensure that someone cannot evesdrop on an unencrypted Freenet connection.
It may be
desireable to modify the standard ENCPHandler to be used as a relay which
then connects
to a diffrent machine running the regular ENCPHandler over an ENCP
connection. There
would mean there is only two extra Java processes on the machine containing
the real
node (one for the main thread, one for the connection handleing itself).
_______________________________________________
freenet-tech mailing list
[EMAIL PROTECTED]
http://lists.freenetproject.org/mailman/listinfo/tech
