On Wed, Mar 21, 2007 at 08:45:38AM -0400, Greg Troxel wrote:
>   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?

Pretty much everything would need to be upgraded simultaneously. I have
a plan how to slowly migrate though. The first (couple) of steps have
already been taken, I've already replaced the old fixed length Coda
token with a new format that allows for variable length keys. However we
only generate tokens that are the same size as the older fixed length
tokens, there was enough redundancy that I even managed to include a
cryptographic hash. This was a change that required both auth2 and
codasrv to be updated at the same time, but we needed no changes to
venus.

The next step will be to let venus not care about the length of the
token. So it can be given a variable length blob that it will pass on to
the server. At this point we'd also want to extend the RPC2-api to
support variable length keys. Once that is deployed we can add a new RPC
to auth2 so that clog can request a variable length (large) Coda token.

If the auth2 daemon supports the new RPC, a client can assume that the
server can handle the larger tokens. At some point the old GetTokens rpc
can be deprecated/removed and we've transitioned.

>   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?

The user's password is never sent across the wire and nothing in the
token contains any bits of the user password.

What happens is that clog sends the username, the server generates a
128-bit random value and sends it back to the client. Now both the
client and the server decrypt this random data with a key that is
derived by hashing the user's password/passphrase.

If both sides used the same password and key-derivation, then both
decryptions will result in the same 128-bit session key. The client then
generates a second 128-bit key and encrypts it with the server's session
key. If the server succesfully decrypts it (proving it knew the user's
password) and sends a reply encrypted with the clients' key both the
client and server know they can trust each other.

(replace 128-bit in this discussion with 256 if the RPC2SEC_KEYSIZE
environment variable was set to 256)

So the weakness in this handshake would be if someone can intercept the
initial 128-bit random number and can try all possible key values and
decrypt to obtain the session key for client->server traffic. So if the
entropy of the input (user password or Coda token or anything else) is
less than size of the session keys, we perform several thousands of hash
operations on the lower entropy secret to derive the encryption key. If
at some point the size of the Coda token key is the same or longer as
the encryption key it will be used as is, we don't take such a shortcut
for passwords since those are not assumed to contain as much entropy
(passwords are not random).

> 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?

Correct, it should make it too expensive to try all possible input values.

Jan