SSKs ---- URI ---
URI: SSK@<pubkey hash>,<decryption key>/<document name> Data is 1kB. Routing key = H(E(H(docname)) XOR H(pubkey)) (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. -------------- 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/20051209/2eb8d1bc/attachment.pgp>
