So at the lowest level we should be using the best possible keys. The
  64-bit key that Rune mentioned are the ones that are passed in Coda
  tokens. The RPC2-API defined an encryption key as a fixed 8-byte
  character array (RPC2_EncryptionKey), and when strong encryption was
  added we kept this around to avoid breaking the API.

64-bit keys are simply too short, and I think it's worth breaking the
API.  Having to rebuild rpc2 and coda at the same time is really not a
big deal.  Or, one could add new functions that take larger keys, and
have the current ones just make a larger key with the 64 bits given
and zero and call the new one.

But do you mean wire format for coda as well?

  So to derive a usable key from the secret information we get from both
  Coda tokens and user passwords we passed this through a 'PBKDF'

But isn't the user's password used only to get a token, and then
there are simply bits in the session key in a token?

Are you saying that coda does the repeated hashes of the 64 bit value
to derive 128 bit keys, to increase the work factor of brute forcing
the token key?

(I agree that lower case passwords don't have enough entropy.)

  I don't use kerberos myself, and the pre-built debian packages don't
  have it enabled.

This is really too bad - coda having it's own authentication database
is suboptimal from a systems viewpoint.  One benefit is that we'd
be able to get stronger authentication for kerberos realms that use
hardware tokens etc. as part of ticket issuance.

-- 
    Greg Troxel <gdt_at_ir.bbn.com>