(Illustration by Gaich Muramatsu)
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>Received on 2007-03-21 08:47:42