[mike@halcrow.us: gnupgfs]

[Michael Halcrow]

On Sat, Aug 28, 2004 at 04:46:54PM +0200, Florian Weimer wrote:
> * Michael Halcrow:
> 
> > So I need to put a subset of GnuPG into my filesystem to support this.
> > I have made a first pass over RFC 2440, but it would be helpful if I
> > could work with one or more GnuPG developers in doing the job right
> > (assuming it can be done at all; I basically need to be able to jump
> > to an offset in the file and start block encryption/decryption via
> > kernel crypto API scatterlists).
> 
> The OpenPGP data format doesn't really support this.  You'd have to
> split your files into blocks of reasonable size.  Each block has to
> be encrypted independently, with a randomly chosen IV (if you use
> CBC mode). 

Section 5.7 of RFC 2440 specifies ``PGP's variant of CFB''.  This
involves prefixing the plaintext with random data and keeping an IV of
all 0's, among other things.  If I use plain vanilla CBC, will GnuPG
be able to decrypt the file?  The reason I am asking is because the
current kernel crypto API supports only ECB and CBC modes.  If GnuPG
can understand CBC, where is the IV stored (RFC 2440 dictates an IV of
all 0's, with random text prepended to substitute)?  How does it
handle the very last block of plaintext, if the size of that block is
less than the cipher block size?

> You should change the IV and rencrypt the complete block each time
> it is updated.  I don't know of any encrypted file system
> implementation which gets this right.

``Getting it right'' is my primary goal with cryptfs.  Both in terms
of security and in terms of usability.  Exactly why is changing the IV
on every update necessary?  I would imagine that, at least with
certain ciphers, having a static IV and key while changing the data
can lend to linear cryptanalysis...

I've begun work on implementing this PGP file format.  For now, I am
not so much interested in my filesystem layer being able to read files
written by GnuPG, but rather for GnuPG to be able to process files
written by cryptfs.

When a new file is created that has a certain crypto policy, I am
immediately writing (for now) an ESK packet (tag 3), followed by a set
of fixed-length (4096 bytes for now) Symmetrically Encrypted Data
packets (SEDP) (tag 9).  Reads and writes are offset by the header
plus the VFS offset into the file divided by the amount of actual data
(which is fixed) in each packet multiplied by the full size of each
packet.  Whatever packet we land on, we read the entire page into
memory, while decrypting it.  If I need to generate a new random
plaintext block to prepend in each packet, then that gets factored
into the offset calculation.

For fun, let's assume each letter equals one byte:

K H P D D D D H P D D D D H P D D D D H P D D D D...
0 1 2 3 4 5 6 7 8 9 101112131415161718192021222324...

K = ESK packet
H = SEDP packet header
P = Plaintext block
D = Encrypted data

Reading at location L would map something like this:

( L / DDDD ) * ( HPDDDD ) + KHP + ( L mod DDDD )

or (L/4)*6+3+(L%4).

If I want extra crypto info for the filesystem, such as HMAC's over
extents, that can be kept in ``comment packets'' (please tell me that
GnuPG is okay with comment packets).  That way, the file's integrity
can be checked dynamically durring the read, so the user won't have to
verify an entire 2-gig file before beginning to work with it (a bad
hash will result in a read error from the filesystem).

Please excuse my thinking out loud, but I am going to writing this up
when I get into the office on Monday, so I just wanted to mull over
some of the details before I jump into it.

And things will go a lot faster if I can just use CBC for now, so
please tell me GnuPG can handle that.  :-)

Mike
.___________________________________________________________________.
                         Michael A. Halcrow                          
       Security Software Engineer, IBM Linux Technology Center       
GnuPG Fingerprint: 05B5 08A8 713A 64C1 D35D  2371 2D3C FDDA 3EB6 601D

Never send a man to do a machine's job. 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20040828/9bf62fd8/attachment.bin