On Fri, Dec 09, 2005 at 08:47:49PM +0000, Matthew Toseland wrote: > SSKs > ---- > > URI > --- > > URI: SSK@<pubkey hash>,<decryption key>/<document name> > > Data is 1kB. > > Routing key = H(E(H(docname)) XOR H(pubkey))
No, H(E(H(docname)) + H(pubkey)) where + means append. > (The reason for the outer hash is so that an attacker cannot forge a > response when he only knows the routing key, the privkey and the pubkey. > This is the case if the attacker knows that the key is a KSK). > > STRUCTURE > --------- > > Headers: > 2 Symmetric cipher type > 415 Public key (with implied hash) > [0 Implicit H(data)] > 32 E(H(docname)) > ? Encrypted headers > 32 Hash of all fields apart from self and signature > 42 Signature on hash > > Encrypted headers: > [0 IV = E(H(docname))] > 32 H(decrypted data) = data decryption key > 2 Data length + metadata flag > 2 Data compression algorithm > > So: > 415 Pubkey > 2 Symmetric cipher type > 32 Hash of all other fields except signature (pubkey is hashed) > 42 Signature on hash > > Encrypted: > 32 H(H(docname) + H(pk)) - serves as IV; the purpose of an IV is to prevent > building up dictionaries, H(H(docname)+H(pk)) is unique. > 32 H(decrypted data) = data decryption key (as on a CHK) > 2 Data length + metadata flag > 2 Data compression algorithm > > TOTAL LENGTH: > - 144 bytes excluding pubkey > - 559 bytes including pubkey > > Either way we can include the headers on the DataReply, then send the > data after it. However, if it is the former, we can include the *data* > on the DataReply. > > SSK REQUESTS: GENERAL > --------------------- > > Inserts and requests of SSKs have different requirements to inserts and > requests of CHKs: > - We can optimize the common case of the receiver already has the > pubkey. > - Block size is very small; so small that we can fit the data and the > headers into a single packet if we leave out the pubkey. > - SSKs (especially KSKs!) can collide. If they do, we want to propagate > the old data rather than the new data, but we still want to propagate > it. > > So: > > SSK INSERTS > ----------- > > SSK inserts will be handled separately from CHK inserts. > > SSKInsertRequest: > - ID (64 bit ID) - 8 > - HTL (maximum initially) - 1 > - Closest so far (double precision location, initially self.loc) - 8 > - Key - 32 > - Pubkey hash - 32 > - Headers - 144 > - Data - 1024 > > Total size: 1237 bytes - comfortably fits inside a ~ 1400 byte UDP > packet. > > Note that this is significantly different to a CHK insert request! > > SSKAccepted: > - ID (see above) - 8 > - NeedPubKey (boolean, if true, we need to send the pubkey) - 1 > > (Standard errors e.g. RejectedLoop also apply) > > If we need to send the pubkey: > SSKPubkey > - ID (see above) - 8 > - Pubkey - 415 > > Completion is also standard: InsertReply etc. > > Collisions can occur on an SSK insert. If node A sends an insert to node > B, and node B already has different data for the given key, it will: > - Send a DataReply back to A with its original data > - Insert its data at the HTL given by the insert > > SSK REQUESTS > ------------ > > SSK requests are almost identical to CHK requests... > > SSKDataRequest: (or probably just DataRequest) > - ID (64 bit ID) - 8 > - HTL (initially maximum) - 1 > - Closest so far - 8 > - Key - 32 > - HasKey - boolean - 1 > (exactly the same as a CHK request, except for HasKey) > > The request proceeds exactly as a CHK request would, except for near the > end. We send a normal DataReply, with the headers. But we also send an > SSKPubkey, as above, if HasKey was false. > > Prerequisites > ------------- > - Include keytype suffixes on keys > - Upgrade keylength to 32 bytes > -- > Matthew J Toseland - toad at amphibian.dyndns.org > Freenet Project Official Codemonkey - http://freenetproject.org/ > ICTHUS - Nothing is impossible. Our Boss says so. > _______________________________________________ > Tech mailing list > Tech at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20051213/902389e9/attachment.pgp>
