Err. here's a trimmed version for those of you who don't feel like reading the entire log <g/>
----- Original Message ----- From: "David McNab" <[email protected]> > <scipient> insanity: i am going to do my best to explain > why it would actually be a disservice to you to make > the FCP extension you are asking for > <insanity> ok - i'm listening > <scipient> oh, if i say it here will you post it to the > list? > <scipient> good, i hate writing email > <scipient> here's the problem > <scipient> well, first, you know that SVK, SSK, and KSK > are basically all the same thing right? > <scipient> and in 0.4 we have made that stronger > <scipient> there are really only 2 keytypes, CHK and SVK > <scipient> so a freenet key, in its serialized binary > form, has 2 parts > <scipient> the first 20 bytes are the public key > fingerprint > <scipient> for SVK-type keys > <scipient> and if there is a docname, like SSK, it is > mixed into the public key fingerprint part using some > hashing functions > <scipient> the next 3 bytes are a size indicator and > keytype indicator > <scipient> the problem is that when you generate a > cryptographic public/private keypair > <scipient> you have no way of determining those last 3 > bytes of the freenet key at that time > <scipient> without additional knowledge > <scipient> for example > <scipient> you could take that same first 20 bytes > <scipient> and add different 3 byte endings > <scipient> to create different, legitimatae freenet keys > <insanity> ok > <scipient> so how can we decide which one you want when > you ask for a cryptographic keypair? > <insanity> just a sec.. > <scipient> also, it might not always be 3 bytes > <insanity> will this new scheme break DBRs? > <scipient> well - that's irrelevant to the present discussion > <scipient> but we can talk about that - that is a good point > <scipient> actually, the old scheme breaks DBRs too > <scipient> but a curious set of coincidences prevents it > from being noticed > <insanity> so how can a dbr work when the public key can > vary? > <scipient> insanity: please understand that the public > key does NOT vary (this was found to be untrue for the public freenet uri. that public uri is encoded into the new metadata-format dbrs. bad. so we fixed it) > <oierw`> quick question: why do we still have the > endbytes when we have the TLA? > <oierw`> (except byte 21) > <scipient> steven and oskar argued about that > <scipient> the idea is that you can support more than > one verification method > <scipient> i.e. the tla only fixes the major byte of the > keytype > <scipient> not necessarily the minor byte > <oierw`> scipient: ah. > <scipient> actually, i propose we retain byte 21 but > relax the verification on non CHKs to file size <= > rather than == > <oierw> scipient: sounds good > <scipient> it should be GenerateDSAPair instead of > GenerateSVKPair > <scipient> you have some valid points > <scipient> if you want to propose a GenerateURI command > go ahead > <oierw`> mainly, the idea that setting SVKs to byte21 = > <= 2 ** size > <scipient> size <= 2 ** byte21 ? > <scipient> ;-) okay. I'm really horrible at this sort of stuff, but that should do it. :) -Mathew _______________________________________________ Devl mailing list Devl at freenetproject.org http://lists.freenetproject.org/mailman/listinfo/devl
