<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 <scipient> the freenet key is public key FINGERPRINT _PLUS_ other stuff at the end <insanity> sorry - i meant freenet key <scipient> ok <scipient> anyway, since SSK mixes the document name into the pk fingerprint part <scipient> and DBR is just a recipe for determing the document name <scipient> well.. you see? <insanity> dbr needs a way of determining the 3-byte ending <insanity> without knowing the file size <scipient> not necessarily <scipient> we will probably have to remove byte 21 altogether <scipient> no big deal <insanity> so, let me paraphrase some of this... <insanity> i've got a private key, say, 'pppppp'... <insanity> and i insert 2 different files <insanity> file1 is accessed by SSK at publickeyEND1/path1 <insanity> and file2 is accessed by SSK at publickeyEND2/path2 <insanity> where END1 and END2 are the end bytes resulting from insertion of file 1 and file 2 respectively - i guess what matters most to me in this is... <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 <insanity> so how can i set up a dbr that'll actually work? <scipient> i.e. the tla only fixes the major byte of the keytype <scipient> not necessarily the minor byte <oierw`> scipient: ah. <scipient> insanity: we will have to kill byte21 and byte22-23 will always be the same for SSK DBRs <scipient> for the foreseeable future <insanity> but didn't you say that bytes22-23 vary? <scipient> although... <scipient> we could just sort of insist that freesite mapfiles always be 32k or something <scipient> i dunno <scipient> that DBRs always be the same size in general <scipient> not great <scipient> but not too bad given the limited set of powers of 2 from 1024 to 32768 <scipient> insanity: the SSKs we are using now will fix bytes22-23 <insanity> by 'now' do you mean 0.3 or 0.4? <scipient> they are fixed in 0.3 and they are fixed in 0.4 <scipient> though not to the same values <insanity> tell me if this is insane... <scipient> it is <oierw`> yes, it is <oierw`> it can't be done <oierw`> you need the 21st byte set to a number and it needs to be correct <scipient> unless we kill it <oierw`> yes :) <oierw`> actaully, killing it would be the best solution <insanity> with my fcpCreateSvkKeypair() function, i send an FCP GenerateSVKKeypair, grab the private key, then insert a tiny file @ htl=1, and grab the returned URI, and extract the full freenet public key from that <scipient> GenerateSSK wouldn't be too terribly annoying i guess <scipient> insanity: why do you do all that crap when you can just add the correct suffix yourself? <oierw`> how many files do you insert which require the full SSK path? <insanity> you mean 'QAgE'? <oierw`> I can see 1. <scipient> in base 64 yes <insanity> one mapfile per day per freesite <insanity> at the moment, each freesite file requires 3 key requests <insanity> it would be good to not require another request <insanity> but at worst case, a mapfile could be put into a chk <oierw`> way of inserting freesite <oierw`> this is the official way as of now <oierw`> find out all the chks of the files <oierw`> generate mapfile <oierw`> find out chk of mapfile <oierw`> start inserting mapfile and all those other things <oierw`> insert main DBR <oierw`> that means: generate a keypair *** epsas has joined #freenet <oierw`> insert the main DBR using that keypair <oierw`> insert todays DBR <oierw`> take already known private key <oierw`> insert file as: freenet:SSK@[private]/[dbr]-[nam e] <oierw`> do not add a QAgE to [private] <oierw`> that's it <oierw`> I don't see what the problem is? <oierw`> todays DBR is the mapfile <oierw`> or whatever <oierw`> the only key you need to know is the main DBR <oierw`> which is encoded properly on insert <oierw`> so what's the big deal!??? <insanity> but in the dbr, <insanity> the suffix bytes need to be known <oierw`> no, they don't <oierw`> why should they? <oierw`> a mapfile is based entirely on chks anyways <insanity> i'm not talking about mapfile <oierw`> unless you are doing multiple-level mapfiles <insanity> when you get the mapfile, you're home and hosed <oierw`> tell me when you need it <insanity> i'm talking about the dbr <insanity> step 1 - i get a keypair <insanity> call the keys <pub> and <priv> <insanity> i insert dbr with 'SSK@<pub>/sitename' <insanity> someone else wants to view the site <insanity> and their client gets dbr'ed to 'SSK@<pub>/yyy ymmddhhmmss-sitename' <insanity> which 404's <oierw`> okay. I just looked over the current dbr spec <oierw`> (it's changed since they were first made) <oierw`> hmm. <insanity> but 'SSK@<pub>QAgE/yyyymmddhhmmss-sitename' succeeds <scipient> well heavens <scipient> just do that then <insanity> the issue is not with insert, but with retrieval. <insanity> like, <oierw`> scipient: look at the DateRedirect spec <scipient> yeah i know <oierw`> DateRedirect <oierw`> [Increment=<number: time-grain size in seconds, default=86400>] <oierw`> BaseLine=<date:> <oierw`> Predate=<string: the portion of the key URI that comes before the date> <oierw`> Postdate=<string: the portion of the key URI that comes after the date> <scipient> silly huh <oierw`> yes :) <oierw`> they were made more general thus they mess everything up <scipient> but we can put it in the uri now <scipient> well if someone were to code it <scipient> my FreenetURI class will parse it into a FieldSet for you! <oierw> heh <insanity> what's a requester supposed to do when he's given a public key, and doesn't know the size of the file he's seeking? The client can add 'QAgE' which is a hack, but works (for now) <scipient> dude <scipient> you always distribute a URI with the full freenet key <insanity> via DBR only? <oierw> scipient: he's right <scipient> oh come on <oierw> no no no <scipient> i've already stated the solutions to that <oierw> you have Predate= <oierw> it'll mess everything up <oierw> I think <scipient> we either kill byte 21 or mandate every dbr be the same size <oierw> you are still hardcoding constants into clients ;p <insanity> but then won't mapfiles also need to be the same size? <scipient> insanity: yes.. <oierw> which is why you make the mapfiles 32k <insanity> better set it to ezcetly 32k then, to allow for large freesites <insanity> oops - crossed lines ;] * oierw sets it to 32k - 1 bytes <oierw> (yes, I know it's pointless, but it's still fun : <oierw> ) <scipient> killing byte 21 would be ok <oierw> where is byte 21 used? <scipient> oierw: simple pleasures ;) <scipient> that's the funny thing <oierw> it's in the storables. <scipient> it's only real use is to know the file size before you decide to download it! <oierw> heh <scipient> which is useful <oierw> not much in a ssk <mjr> not much <scipient> CHKs are the real lifeblood <oierw> agreed <scipient> but <scipient> freesites are pretty important too <insanity> so, Section 243A/4(3) of the Freenet Protocol Amendment Bill legislates that all SSKs, SVKs (and maybe KSKs as well) be 32k <oierw> no. <scipient> he he <oierw> section 243A/4(3) of the Freenet Protocl Amendment Bill legislates that all SVK derived keytypes will have a known size of 0 <oierw> ooh. that'd be fun <oierw> :) <scipient> that's probably the right thing to do <insanity> we need a new keytype - TVK - 'Telepathically Hashed Key' <oierw> we already have those *** epsas has quit IRC (outtie) <scipient> since you know it's <=32k anyway <scipient> keep byte 21 but just set it to zero for non CHKs <oierw> taking out byte 21 does evil things :) <scipient> actually we can just drop it <scipient> why? <scipient> different keytypes can have different byte lengths <scipient> fred is designed that way <oierw> yes <oierw> but on the human side <oierw> a chk is a touch longer than a svk :) <insanity> what's a human? <oierw> by one base-64 number :) <mjr> subsection 456C of the Freenet Protocol Amendment Bill imposes the death penalty on those heretics who insist that SSKs are derived from SVKs, whereas every decent person agrees that SVKs are a special case of SSKs <oierw> where do KSKs fit in? :) <oierw> they are a special case of SVKs <mjr> KSKs are a special case of stupidity! <oierw> and thus a super-special case :) <insanity> human-readable == stupidity ?? <scipient> stupid-human-readable! <oierw> no. publically spammable = stupidity <oierw> it's the only insecure keytype <insanity> but also the only convenient keytype <scipient> actually, i propose we retain byte 21 but relax the verification on non CHKs to file size <= rather than == <oierw> scipient: sounds good <oierw> insanity: not so <insanity> so byte 21 is fixed for non-chk's? <scipient> convenience breeds large families! <oierw> insanity: the only convenient keytypes for word-of-mouth transmission <oierw> insanity: byte 21 is the log2(length) of the file <oierw> where length is a multiple of 2 <scipient> i like the word-hash keys <scipient> s/multiple/power/ ;p <oierw> scipient: I know. I just couldn't remember the word for it :) <insanity> so, if byte 21 is the same for all non-chk's <= 32k, then it won't change for these keys? <scipient> it's all about the twooossss, mmaaaaannnnn <oierw> correct <oierw> alice, 2 ** 17 <alice> 131072 <oierw> alice, 2 ** 7 <alice> 128 <oierw> wrong idea. :p <insanity> why use base 2 logs? why not more 'mathematically correct' base-e logs? <oierw> alice, 2 ** 13 <alice> 8192 <oierw> alice, 2 ** 15 <alice> 32768 <insanity> only kidding :) <oierw> so byte 21 is F <scipient> what's 0f0203 in base64 <scipient> insanity: do you want to ask the audience??? <scipient> or phone a friend? <insanity> ? <scipient> is ? your final answer? <insanity> i don't even know the char mappings for base 64 sorry <scipient> oh, i'm so sorry <scipient> but you could to return home with this nice pile of rotting muck <scipient> could to! whoa, that's a good one <scipient> what the fuck did i mean? <insanity> i'm still unconvinced about the alleged folly of adding an FCP command or option to take care of the base 64 stuff <insanity> or at least allow the use of fixed constants for the trailing key bytes <scipient> i think it's kind of ironic though <scipient> i mean, FCP completely relieves you of the burden of writing code to generate DSA keypairs and make DSA signatures <scipient> and you are complaining about having to encode your own base64 <scipient> ;p <scipient> anyway, it will be a fixed constant for your purposes <scipient> so there! <oierw> unless you want to insert a KSK <oierw> :) <insanity> well, with unix, i can call open() without knowing the structure of inodex, or the ext2 filesystem <insanity> all that is hidden from me, which i appreciate <oierw> except you are calling open <oierw> then saving the inodes to the file <scipient> my god you are comparing base 64 to open() !? <scipient> are you irritated by having to learn decimal also? * oierw just yanks agl's code :) <mjr> this discussion is getting out of control, man <insanity> i'm not the only client writer <insanity> why require the same code to be written n times? <oierw> scipient: yes. it should be in hex <scipient> then warren mjr had to regulate... <oierw> insanity: you need a base-64 reader/writer anwyays <mjr> beable beable beable <oierw> 1: dbr's require it <scipient> yea if you ever want to insert a CHK! <scipient> er <oierw> yes. dbr's are going to be *gasp* base64 encoded <scipient> n/m <scipient> calculate your own CHK <oierw> scipient: GenerateCHK. :) <scipient> yea that thing <scipient> an abomination!!!! <oierw> it's already spec'd <oierw> plus it might have it's uses <oierw> not many, mind you <oierw> but it does allow for more parallelism <insanity> parallel inserting is crucial given freenet's performance <oierw> one shouldn't insert at htl 100 <oierw> never ever insert at htl 100 in the current network <insanity> unless one wants others to be able to find one's files <oierw> every htl100 insert messes up the network more <oierw> it's better to have hardsuck than hardpush <scipient> mjr, do you have the jellybeans of funk ready? <mjr> my jellybeans of funk are standing by <scipient> someone should post some porn pictures on freenet illustrating the principle of suck hard versus thrust hard <insanity> i've tested hardsuck vs hardpush - @ htl<100, the hardest suck fails <oierw> the hardest push fucks up the network for everyone <oierw> take your pick <insanity> even inserting @ htl=100, many hard sucks fail <oierw> it's better for some files to be irretreivable than for some idiot to come along and screw it up for everyone else. <scipient> mjr: initiate jellybeans of funk launch sequence! <insanity> depends on your definition of 'some'. * mjr flips a few toggle switches <scipient> oierw: by that logic, we should reduce the maximum htl <oierw> some is less than all and more than some <insanity> in my experience, 'some' < 20% <oierw> scipient: nah. hardsuck is safe. it just doesn't do anything :) <oierw> scipient: plus it doesn't mess up every nodes routing table with short refs <oierw> good <insanity> what about dropping max htl for inserts, and upping it for requests? <scipient> oierw: it could have a separate max for insert vs. request <oierw> that could work <scipient> mjr: flip more toggle switches! <oierw> I love 12.5 minute requests anwyays <insanity> that way, you can be polite and insert @ htl 20, and your clients can suck like an electrolux and (eventually) score <scipient> what is it? <oierw> you know a kickass fs on the paper is worth one in the code <scipient> i dunno, maybe a GenerateURI command would be allright <scipient> it should be GenerateDSAPair instead of GenerateSVKPair <insanity> FreeWeb sucks... <insanity> according to the fproxy htl setting <insanity> but the next version won't use fproxy - only fcp <insanity> any more to be said on the subject of key generation before i lift the transcript and post it to dev? <scipient> don't do that <scipient> our conversations are too bizarre for dev <mjr> this conversation is too bizarre to ever have happened in the first place <mjr> it must be a dream <scipient> it is, actually <scipient> freenet is actually produced by a species of mold that grows on oranges <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> ;-)
_______________________________________________ Devl mailing list Devl at freenetproject.org http://lists.freenetproject.org/mailman/listinfo/devl
