At 9:18 AM +1000 6/2/99, Greg Rose wrote:
>At 16:38 1/06/99 -0400, it was written: [by Arnold Reinhold]
...
>>
>>I would argue that UNIX is an excellent object lesson for John's point. 12
>>bits was a bad design decision, even in the 70's.
>
>I take exception to this last statement. The design (of the salted
>passwords) was done in the late 70s, and given the constraints of the time
>was quite a reasonable decision. Remember that memory and long term storage
>on PDP-11s was tight. The machines couldn't possibly support user
>populations greater than hundreds (in particular, UIDs were only 8 bits!);
>10-12 was typical, and 40 was a hugely overloaded university.
Implementing a longer salt would have required one or two bytes per user in
the passwd file. By your own numbers that would totaled less than 100 bytes
of disk space, hardly a constraint even way back in '79.
...
>
>In fact, I think that (intentionally or not) this choice makes a great
>example of the right kind of engineering tradeoffs. As Bruce Schneier
>recently said more eloquently than I, anyone can overengineer it...
>designing to constraints is much harder and more interesting. People who
>believe in day-to-day use of One Time Pads (I'm not accusing anyone here of
>this :-) ) are merely the furthest away from practicality.
>
>Overengineering leads to things like SET, multimegabyte key schedules (I
>hope David Scott isn't listening), and software bloat in general. I *like*
>the elegance of the UNIX salt scheme, and we all learned from it. Sure,
>we'd do it differently today. That's partly because of what it taught us.
>But, knowing what we know now, would we have done it differently *then*,
>with that set of constraints? The answer to that is not at all obvious.
>
I am not knocking the designers of UNIX, who got a awful lot right the
first time, and, after all, were doing a research project. Even
crypt()itself was novel and a big step foward. But I strongly disagree
that leaving room for growth beyond immediately forseeable requirements is
over-engineering. On the contrary, it is usually the committee that has to
fix an under-designed system that ends up producing the bloatware, since at
that point it is hard to say "no" to anyone.
The exponential relationship between field size and name space means that
the difference between a design that will last for a few years and a design
that will last forever is usually quite small. Compare the 32-bit IP
address space with the 48-bit scheme that the designers of Ethernet chose
in the same era. The former is now a pain in the butt and its replacement,
IPv6, is a candidate for the bloatware moniker. Nobody worries about
running out of Ethernet addresses and no one ever will.
>(IMHO the design decision that would most profitably have changed was the
>limitation to 8 character passwords, not the salt.
I agree with you here, though as Steve Bellovin pointed out, hashing hadn't
been invented yet. Sigmund Porter first came up with the passphrase idea in
1981 [1]. The hubris-laden decision to make the passwd file world-readable
is another candidate for when we get that time machine working.
...
>If I design something like this that is still in very
>widespread use in 2020, I'll consider myself to have done very well, or
>society will be to blame, one or the other. ...
Unfortunately we never know which of our designs will end up in the bit
bucket and which will be cast in stone. And, when we are talking crypto, we
never know just how important the secrets will be that our designs end up
protecting. I'd rather nail each problem the first time.
Arnold Reinhold
[1] S. N. Porter, A Password Extension for Improved Human Factors,
Advances in Cryptology: A Report on CRYPTO 81, Allen Gersho, editor, volume
0, U.C. Santa Barbara Dept. of Elec. and Computer Eng., Santa Barbara,
1982. Pages 81--81. Also in Computers & Security, Vol. 1. No. 1, 1982,
North Holland Press.
