Hrm, this didn't appear to get sent the first time. Resending, sorry to
anyone who gets duplicates.
-----Original Message-----
From: Timm Murray <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Monday, June 11, 2001 12:46 PM
Subject: PalmOS client and ENCP
>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
