[OpenAFS-devel] Re: [OpenAFS] Encrypted connections by default in OpenAFS 1.8?

Benjamin Kaduk kaduk@MIT.EDU
Tue, 3 Mar 2015 17:13:23 -0500 (EST)

On Tue, 3 Mar 2015, chas williams - CONTRACTOR wrote:

> On Fri, 27 Feb 2015 22:09:12 -0500
> Jeffrey Altman <jaltman@your-file-system.com> wrote:
> > On 2/27/2015 9:51 PM, Jason Edgecombe wrote:
> > > ** file server option to force authenticated access to use encryption
> >
> > The client needs to be told the connection policy prior to connection
> > establishment (that is what "fs setcrypt" does).  A file server can
> > choose to ignore a connection but by that time the data you wish to be
> > secure has already been transmitted in the clear.  If the connection is
> > rejected by the file server and the clear retransmits the same request
> > using a new encryption connection, the client has now given known
> > plaintext to an attacker to use to determine the encryption key.
> While not a security expert, I think the only problem with the scheme
> would be that the current encryption provided by OpenAFS is not
> semantically secure (anymore).  When rxkg is available one should be
> able to choose an encryption (AES for example) that would defeat a chosen
> plaintext attack as well as a known plaintext attack which would protect
> any keys in use.

A packet encrypted with rxgk is going to have 24 octets of known plaintext
at the start anyway for the rxgk header, and the body payload is
sometimes going to start with the RPC serialization, which is frequently
predictable.  I don't think that it's possible to keep known plaintext out
of the hands of the attacker without dramatically reworking the protocol.
As you point out, there is no need to avoid known plaintext samples with
modern cipher usage.