Comment 34 for bug 344878

Dustin - I was just looking into this last week. I was hoping to come up with
a way to salvage the current design of storing all metadata and ciphertext
in the lower file name for ease of implementation and performance
reasons. My intention was to improve the format. I am pretty confident
that I can squeeze an extra 20 characters out, but I don't think that
will solve the problem for those affected by this bug.

Several folks have requested that we do compression on the filename. I
don't believe that will get us anywhere. There are only a few
non-random bytes after encryption and before encoding.

The biggest issues are from block alignment and random data to generate
unique ciphertext (between 17 and 32 bytes) and the expansion from
encoding to POSIX compliant characters (between 17 and 57 bytes or about
a 33% increase in length), not to mention the static 24 character prefix.

I see a couple options going forward:
1. Provide an easier way for users to disable file name encryption on
   newly created files, but still be able to decrypt existing file
   names.
   + Easy to implement
   + Easy to turn on, as it would simply be an extra mount option
   - Doesn't solve the problem of encrypting long file names

2. Fail over to storing the ciphertext in the file metadata (header or
   xattr) when filenames are too long for the lower file system. The
   lower file name will contain some packet information (similar the
   tag 70 packet in the current design) that indicates the ciphertext
   is actually stored in the file metadata.
   - Considerably more difficult to implement - I haven't yet worked
     out how lookup() will happen
   + Allows for 255 char file names and solves all problems related to
     this bug
   - Performance of lookup() will be affected when long file names are
     in use

Maybe it would be best to implement #1 soon and then begin to
approach #2 afterwards.