Brandon writes:
Here is my version of
the proposal, mixing the truly agreed upon things with my ideas on the
subject.
There is a field containing public, plaintext metadata, in the dotted
field format.
PublicMetadata.Expires=10/26/2002
PublicMetadata.HeaderLength=1002
PublicMetadata.Encryption=RC4
OK, but...why bother with "PublcMetadata" (or "Metadata.Public" if you
want to be truly anal)? It's not clear that it adds anything. I can
tell it's public -- it's not encrypted. Likewise, private metadata is
encrypted and therefore, well, private. (I assume the word "Metadata"
tells the node something it needs to know).
Each multipart item should probably contain a list of keys for
other parts.
OK, I have a slightly different notion of "multipart" -- but yours has
some advantages, so let me integrate the two and propose:
1. The first part of a multipart message is inserted under the
key(s) intended by the user. Its headers contain:
MIMEType=multipart/linear
Multipart.PartNumber=1
Multipart.PartCount=3
Mulitpart.Part2.Key=D013F88300744B8926D89661DDFD2E93
Mulitpart.Part3.Key=9C858CDC8C3129073785AEB5682079BE
Multipart.TotalLength=38362
The TotalLength field lets the implementation whack off any
padding in the last part (padding adds to the mixmasterliness,
especially if all clients agree on the same part size -- I like
16K).
2. The additional parts are inserted solely under their CHK's.
Their headers contain the following:
MIMEType=multipart
Multipart.PartNumber=2
Mulitpart.Part1.Key=E1B8115F246A85D93AE2731F0C51691D
None of these headers are truly necessary, but can help the
receiver determine make sure the data is intact.
Open questions:
1. Where does the "real" MIMEType of the message go? Does the
entire message itself constitute a message with its own headers,
or can all the headers of the multipart message be included as
part of part 1's headers?
2. Are the parts encrypted individually, or is the whole message
encrypted and then split up? Does it matter?
One idea is to have a multipart/raid5 type. The encoding for that
should be pretty straightforward.
In a whackier vein, there could be a multipart/otp type, with an extra
"part" that is the one-time-pad. Each of the data parts is XOR'd
against the many-time-pad. This isn't truly secure (we can call it
"craptography"), but it will prevent most nodes from reading the
contents of the message. The originating node will have an easier time
reading it, and any node with part 1 can acquire and read the data, too.
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
