Subject: RE: AES and SHA-1 timing

From: "Paul Leach" <[email-masked]>
Date: Tue, 15 Apr 2003 15:16:35 -0700

>
> -----Original Message-----
> From: Ken Raeburn [mailto:[email-masked]]
> Sent: Saturday, April 12, 2003 4:35 PM
> To: [email-masked]
>
> "Paul Leach" <[email-masked]> writes:
> > Even though 256 bits is mandatory to implement, 128 bits is quite
> > adequate to deploy in practice. Doesn't that mean that all these
> > numbers should be halved?
>
> We could have different defaults for the two versions.
>
> > If so, and if I read the rest of these numbers correctly,
> then worst
> > case a person, running on a MIPS R5000 200mhz, would add
> 4.3 seconds
> > to their logon time.
> >
> > Given all the other stuff that probably happens at logon
> time, I don't
> > see that as terrible.
>
> Actually, I think "all the other stuff that probably happens
> at logon time" is getting to be pretty terrible already, on
> some systems.  I typed my correct password; I want to start
> working *now*.  (Or, for those more resigned to slow logins,
> I want to get some confirmation so I can go make my coffee now.)
>
> At least in most of the UNIX login GUIs I've seen, this would
> be 4.3s (or 8.6s, whatever) where the window appears frozen,
> because the single-threaded process is entirely devoted to
> SHA-1 calculations.

Could I ask, purely as a point of information, what vintage are the MIPS
R500 200mhz and Sun Ultra 10 Model 300, UltraSPARC-IIi 300MHz? How big a
percentage of the installed base are they at MIT (and elsewhere)? How big
will they be in a year or so when people actually get around to installing
new versions of Kerberos that include the AES cipher suite?

Paul

---

From: Ken Raeburn <[email-masked]>
Date: Tue, 15 Apr 2003 22:04:18 -0400

> new versions of Kerberos that include the AES cipher suite?

Both at least four years old, I think.  Around the MIT Athena
environment, the breakdown (according to a survey done with some of
our local UNIX tools) is something like:

    SPARC Solaris systems (over 700 cpus, including multiple cpus from
    a few higher-end systems, so adjust downwards a little for
    per-system stats):
        8%            < 300MHz
       26%  >=300MHz, < 400MHz
       21%  >=400MHz, < 500MHz
       43%  500MHz
        2%  >=650MHz

    Linux PCs (over 200):
        5%  450-666 MHz
       28%  800 MHz
       41%  1-1.2 GHz
       26%  2 GHz

    IRIX systems: Under 100 in all, about half are 300MHz, the rest
    are 200MHz or slower.  They'll all be decommissioned this summer.

    Windows PCs: no data

I believe this survey excludes most student-bought machines, laptops,
probably some department- and faculty-owned machines, etc., and all
Windows systems.  It certainly doesn't include PDAs and cell
phones. :-)

After some hardware upgrades this summer, I think the oldest, slowest
desktop UNIX systems we'd expect to have in significant use are
roughly 400MHz Suns and 500MHz or 600MHz PCs, which I believe is about
what we were buying three years ago.  (I could well be wrong,
especially on the PCs.)  With a little luck, we might actually get the
AES code deployed this summer.

Ken

---

From: Marcus Watts <[email-masked]>
Date: Wed, 16 Apr 2003 03:28:14 -0400

> new versions of Kerberos that include the AES cipher suite?

The machine I'm typing this on is a 1st generation Ultra-5 (Ultra-IIi @
270 Mhz), about 5 years old.  Most of my workgroup still has one
sitting on their desk.  Most of the oldest machines we have "in production"
are 170 Mhz Ultra-1s, which we're retiring, but the process will
undoubtedly be slowed down by the 10% budget reduction the state of
Michigan has imposed on us this year.  We also have various newer
machines of course.  "We" here is only a tiny corner of the university,
and I don't have good stats right off for the population of computers
at the University as a whole.

Different parts of the university have different budgets and
priorities; a decade back some parts of the U were bemoaning the
disappearance of MTS (timesharing on IBM 370 isa hardware) while other
parts has long since jumped ship and brought up their own Unix based
infrastructure.  Today that might translate into some parts having labs
full of recent fast machines, while other parts might be well be
dealing with 5 (or 10!) year old hardware and postponing the inevitable
hardware upgrade.  Because of this uneven distribution of hardware, I'm
not sure that overall stats would actually be very meaningful.

One of the constraints we will certainly have for the near future is
production services that make non-optimal use of kerberos.  This
includes the dial-up service, which uses radius, the imap servers,
which as deployed accept cleartext passwords and impose no limit on
frequency of sessions - we have users who authenticate and check mail
once a second; and cosign, a web authentication service I think
vaguelly similar to some parts of .net.  The common thing to all 3 is
that they have one or a small number of shared servers which
authenticate many many users.  This is certainly not a good use of
kerberos -- but it's the reality we face here.

I just had a look at our kerberos log and machine room, and I have some
possibly useful statistics.  The 10 top machines requesting AS_REQ are
all imap machines (the "bad" cleartext password thing).  They
*averaged* about 1 request a second for the 2 hours the log file I
looked at happened to cover.  Midnight - 2am is probably not the peak
usage time.  The machines themselves are 10 CWI machines, probably
mostly Blade 1000 boards, dual UltraSparc III @ 1 Ghz.  Some other top
offenders include the dial-up service (radius), which all goes through
a single ultra-5 (270 or 300 Mhz), about 1 request every 5 seconds, and
what I think is the cosign login server, 1 request every 6 seconds (a
CWI machine, possibly single or dual ultra-IIi @ 500 Mhz, which
would also be doing ssl.)

The campus computing sites offer temporary use of machines to students
on a walk-in basis.  They make an effort to have fairly current
technology.  The high end machines include:
	Dell Optiplex GX260 P4/2.6
	Macintosh G4/1 Ghz with 1.6Gb RAM
I don't have a full breakdown of these and various lesser models, but
there are many hundred of these machines out at the various sites.  An
ambitious group of students could easily get a considerable amount of
computing power - whether they could keep it for 90 days or whatever
without being noticed is of course another question.

Institutional politics, user inertia, and protocol and software
limitations are all very hard to fix right.  We have certainly got
things deployed which are much worse than the use of even DES.  I think
we (umich) would like to offer AES as an option whenever MIT has it in
their released code, and would like to work to retire K4 and DES in
favour of it when this happens (K4 is declining now, but DES remains
king), but this is going to be a slow process at best.  A very slow
string to key function is very much going to impede our efforts here.
Probably by the time we are actually able to turn DES off (at best >4
years?), the timing model that Paul Leach used to justify his 1 second
delay will be completely obselete, if it isn't already out of date.
We see some form of preauthentication logic as being a much
more promising way to protect weak keys.

				-Marcus Watts

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 16 Apr 2003 07:39:52 -0700

> more promising way to protect weak keys.

This summarizes it nicely.

Cheers,

Nico
--