On Sun, May 12, 2024 at 12:44 PM Richard Miller <9f...@hamnavoe.com> wrote:
> 23h...@gmail.com:
> > sorry for ignoring your ideas about a p9sk3, but is your mentioning of
> > ocam's razor implying that dp9ik is too complicated?
> > is there any other reason to stick with DES instead of AES in
> > particular? i'm not a cryptographer by any means, but just curious.
>
> My comments are about p9sk1; I'm not implying anything about other
> algorithms. When working with other people's software, whether
> professionally or for my own purposes, I try to take a
> minimum-intervention approach: because it's respectful, because of
> Occam's Razor, because of Tony Hoare's observation that software can
> be either so simple that it obviously has no bugs, or so complicated
> that it has no obvious bugs.
Forgive my saying it, Richard, but I think this is a somewhat overly
staid view of things.
Software, as a constructed object, is maybe unique in that it is
almost infinitely malleable, and the "minimum intervention" approach
is often not terribly useful. As for being respectful of other
people's software, who are these other people? The original authors of
plan 9 are no longer involved, and indeed, the intellectual property
has been transferred to the foundation, and by any reasonable standard
the "community" has been given responsibility for the evolution of the
code.
As for the proposed strawman `p9sk3`, I fail to see what advantage
that would have over dp9ik, except perhaps a less silly name. The
person who wrote the paper on plan 9 security sees it being superior
to what's there now, after all, and frankly he'd know better than
either Occam or Tony Hoare.
- Dan C.
> 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.
>
> This is only the first scratching of an idea, not implemented yet.
>
> I've got nothing against AES. I'm not a cryptographer either, but I did once
> have to build a javacard implementation for a proprietary smartcard which
> involved a lot of crypto infrastructure, and had to pass EMV certification.
> Naturally that needed AES, elliptic curves, and plenty of other esoterica
> to fit in with the existing environment and specifications.
>
------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T56397eff6269af27-M76fe847d3ed83b053ad32e0f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
