> I thought of 3DES in the first instance because of this desire to be > minimally disruptive. Support for DES is already there and tested. > 3DES only needs extra keys in /mnt/keys, and because 3DES encryption > with all three keys the same becomes single DES, there's a graceful > fallback when users have access only via an older client with > unmodified p9sk1. Obviously the server ticket would always be protected > by 3DES.
it is not obvious to me. but then, you know more about 3des than me. ;) there are some fundamental features in dp9ik that are still missing even when you increase the "quality" of the DES key by giving it arbitrarily longer lengths. also, the server and client keys are the same in p9sk1 as far as i understood. i would welcome public/private key system though (is that what you were thinking of when separating "server key" and "client key". that would add yet another set of features that are currently missing. > This is only the first scratching of an idea, not implemented yet. i can offer strictly less than that even. but it seems to me that concentrating on 3DES just for the sake of similarity to DES is taking ocam's razor slightly too far. though i do find it generally happens that security mechanisms are claimed to be "outdated", resulting in less scientific processes and more popularity contests than anything else, so putting extra scrutiny is highly welcome. on my part i'm simply trusting cinap on his intent and research as i have no hope to ever understand any details. but the dp9ik approach has some novelties which should make it worthwhile for security researchers to study. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T56397eff6269af27-M3d84204e405a926acc80c609 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
