> 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).
The way I think message processing should occur with encrypted trailing fields is that the client reads the message into the internal message format, sees that the tailing field is encrypted, decrypts it, and then reads it in to the internal message format. So the stream is turned into a message class and each field becomes an entry and it shouldn't matter in the message class if the fields were originally encrypted or plain. So for the unencrypted metadata we could use one field name and the encrypted metadata another field name. Or, if we're using the dotted field notation (which I like, but hasn't really be approved so much as mostly ignored) then there isn't a need for two separate fields since the subfields are individual fields anyway. So I guess I verbosely agree with you. :-) > padding in the last part (padding adds to the mixmasterliness, > especially if all clients agree on the same part size -- I like > 16K). The mixmasterness should probably be implemented in a separate layer so that it's node to node, not client to node. We should make a traffic analysis defeating encrypted node to node transport layer which pads the messages themselves. > 2. The additional parts are inserted solely under their CHK's. If the parts are redundant (and they don't have to be) then the headers should be redundant and they should be inserted under a guessable key so that any part found will be sufficient, in case other parts disappear. If all parts are needed to decrypt the document (then you won't have the whole file if you're routing it, so won't be responsible for it) then we only need to insert under CHK. > 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? I like it best this way, a message which wraps around a message. Making the client unwrap and integrate messages into an integrated representation in a message class is flexible and useful for different purposes. > 2. Are the parts encrypted individually, or is the whole message > encrypted and then split up? Does it matter? It is must better to encrypt them all together. Encrypting multiply items with the same key lessens security. _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
