On Monday 19 Nov 2012 23:05:44 postwall-free...@yahoo.de wrote: > What will actually change for SSKs apart from the way they work internally? > Will the SSK-Generator just spit out new keys with another new ending like > the last time SSKs were changed internally, but everything will keep working > the same as usual, so same FCP-commands for retrieval and inserts and so on, > just with a few added optional parameters here and there?
Yes, that is the plan. Even if we actually implement SSKs as a special case of PSKs, we will continue to support using SSKs in the client layer (FCP etc), with the same API. > > Since I don't assume that backward compatibility will be kept forever, this > would be kinda important. If it amounts to a new key "version" and a few new > optional features, things won't be too bad and most old tools will support > new SSKs immediately. But if everything using SSKs has to be changed at some > point to use the new SSK version, a lot of stuff will break without return, > and thats never pretty. GenerateSSK will generate the "current" kind of SSKs. I.e. the new ones. We may give it some parameters in future though. The lengths of the SSKs may change. > > Even if only the internal workings (and a few new features like different > sizes) change for external applications, this will mean another whole content > migration in the long run: All freesites will have to be migrated, chat users > will once again be torn into another different group (the ones using tools > based on PSKs, vs the ones using one of the old WoTs and the ones using > old-style stuff like Frost) and so on. > > What exactly is the reason that SSKs are changed at all compared to the new > SSKs just being named differently and old SSKs being kept as they are? What > is the advantage here? The old SSKs work just fine for a lot of stuff and I > personally like old working stuff a lot more then new maybe "not so working > until all bugs are finally worked out" stuff which requires a complete > content migration in the long run. Just my opinion of course. The proposed changes do improve security (especially if we allow optionally using secp384r1), but the old stuff is still adequate, so there is no reason to get rid of it, certainly not for a long time. The build 1010 migration we had to get rid of the old content because it was grossly insecure. For secp256r1 it might be faster than the current code, I'm not sure. The main advantages are 1) we can have different block sizes for different applications and 2) we can have PSKs, with SSKs being a specialised form of PSK. > > --- Arne Babenhauserheide <arne_...@web.de> schrieb am Mo, 19.11.2012: > > Von: Arne Babenhauserheide <arne_...@web.de> > Betreff: Re: [freenet-dev] SSK compatibility for infocalypse - was: What is > the ideal size for SSKs? > An: "Matthew Toseland" <t...@amphibian.dyndns.org> > CC: devl@freenetproject.org > Datum: Montag, 19. November, 2012 09:11 Uhr > > Am Sonntag, 18. November 2012, 21:01:02 schrieb Matthew Toseland: > > On Sunday 18 Nov 2012 02:58:55 you wrote: > > > Wait, we're not going to maintain backward compatibility with SSKs? That > > > doesn't seem wise... > > > > Current proposal in a nutshell: > > - Support existing SSKs for back compatibility. > > - New ECC-based PSKs, programmable, allowing all sorts of things including > > multi-writer SSKs for semi-moderated forums. - New SSKs a special case of > > PSKs. > > - Several block sizes: ~ 800B (fit an insert in one packet; ideal for e.g. > > FLIP real-time chat; store in SSK datastores); ~ 2KB (fill one old > > SSK-datastore slot; ideal for forums etc), ~ 32KB (fit in one CHK store > > slot; useful for forum maintenance etc, and more efficient than a separate > > CHK). No other block sizes as they'd be problematic storage-wise. > > Nice! > > Thanks for your summary! > > Best wishes, > Arne > -- > Konstruktive Kritik: > > - http://draketo.de/licht/krude-ideen/konstruktive-kritik > > > -----Integrierter Anhang folgt----- > > _______________________________________________ > Devl mailing list > Devl@freenetproject.org > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
