On Thu, May 05, 2016 at 01:13:53PM +0200, u-myfx_at_aetey.se wrote:
> On Wed, May 04, 2016 at 08:40:32PM -0400, Jan Harkes wrote:
> > On Wed, May 04, 2016 at 11:44:35AM +0200, u-myfx_at_aetey.se wrote:
> > > Probably the most apparent one is the limit on the key length in the
> > > security layer. It is a hard one too, because the limitation is hardwired
> > > in the current protocol.
> 
> > Can you point out where the key length is hardwired to a undesirable
> > length?
> 
> [BTW thanks for the illustrated analysis of the handshake]
> 
> > This is either a username (clog/auth2) and the
> > shared secret is looked up in the password database, you aren't even
> > using this bit because you are using kerberos.
> 
> We are using multiple authentication authorities at the same time,
> including Kerberos realms _and_ the Coda authentication database.
> The security of Coda password authentication is relevant.
...
> matter once upon a time). The key in the database is also short
> and is being used without strengthening, for backward compatibility.

No, it is using the exact same strenghtening as the Coda token because
it happens under the covers during the RPC2 new connection handshake.

https://github.com/cmusatyalab/coda/blob/master/lib-src/rpc2/rpc2-src/rpc2a.c#L233

Jan