OSXFuse and Encryption

[Fred T]

Hi,

I created a OSX application that mounts a virtual file system using OSXFuse.  I would like to integrate AES-256 bit encryption services with my application.  The encryption library I am using encrypts the data in 1082 byte blocks.  

The issue I am having is on the decryption side of things.  I have an encrypted file residing in a folder which is processed via the openFileAtPath and readFileAtPath methods.  I perform my decryption logic within readFileAtPath.  

Issue  - readFileAtPath provides the data to me in blocks of a certain size. For example.. OSXFuse will call readFileAtPath on an encrypted file with size at 4096 bytes.  I decrypt the data in 1082 byte blocks.  I can decrypt three of these blocks or 3246 bytes of data and save the rest to be processed on the next read.  However when control exits readFileAtPath, buffer is holding 3246 bytes of decrypted data.. not 4096 bytes that OSXFuse expects.  This causes it to resend the last 850 bytes in the next read which throws everything off.  

I have tried specifying the return value of readFileAtPath to match that of what we receive when we read the file (i.e, 4096 bytes) but this causes corruption in the returned data..  I have tried specifying the return value of readFileAtPath to what we actually process (three blocks of encrypted data or 3,246 bytes), but this causes OSXFuse to make subsequent readFileAtPath calls with previously sent data as noted earlier..

So my question is..  is there a way to get OsxFuse to properly compensate for the encrypted data?  Is there a way for me to control the size parameter that is supplied in readFileAtPath?

Any ideas or thought would be very helpful.

Thanks,

--Fred

[Sam Moffatt]

Why don't you decrypt the next block and return the requested bytes and then leave the remainder of the next block in memory until a subsequent read occurs. You have to solve the alignment problem on your side if he fence (it's an implementation detail of your code not the VFS layer).

Cheers,

Sam

--

Sam Moffatt

http://pasamio.id.au

Note: I'm not at my desk, responses may be delayed

--
You received this message because you are subscribed to the Google Groups "OSXFUSE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osxfuse-grou...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Fred T]

Hi Sam,

Thanks for responding..  The decryption library that we are using does not support decryption of partial blocks.  It is designed to decrypt the encrypted data in 1082-byte blocks.  On the front of each block is header info which includes the encrypted block size..   Also.. the encryption library is used across multiple platforms.  I'd like to keep this code the same for all platforms we support..

--Fred

[Sam Moffatt]

What I'm suggesting is that you decrypt the entire next block and return the amount of data that is expected to be returned in the request and store what isn't there in memory until the next read. This is no different to a read ahead buffer that many systems implement to ensure that high latency bound requests are smoother.

Do you have a filesystem implementation on another platform that behaves differently?

Cheers,

Sam

Sam Moffatt
http://pasamio.id.au

--

[Fred T]

Hi Sam,

Thanks for taking the time to respond to my question.  

I believe I am doing what you suggest...

- (int)readFileAtPath:(NSString *)path

             userData:(id)userData

               buffer:(char *)buffer 

                 size:(size_t)size 

               offset:(off_t)offset

                error:(NSError **)error

When this api is called, size is assigned a value of 4096.  As mentioned, my encryption library decrypts the data in 1082 byte blocks.  I decrypt three blocks of data and have 850 bytes left over.  I save this data off in a separate buffer to be utilized in the next read.

Also..  the decrypted data are being copied back to buffer.

I'm not sure, but I think this is what you are suggesting when you mention to read-ahead..  ?

--Fred

[Sam Moffatt]

Hi Fred,

If you're handling a request for 4096 bytes and you have 1082 byte blocks, then shouldn't you need to read four blocks (3 x 1082 = 3246; 4 x 1082 = 4328) to get 4096 bytes of data and you should then store the remainder of the bytes (4 x 1082 - 4096 = 232) in memory. You still need to provide the 850 bytes in the request (4096 - 3246), so I'm a little confused on the maths here as you should have 232 left.

I had a few read throughs of this email, but a testing strategy I'd implement is a simple text file with 0 to 9 per line and then progressively read that file to see what you get back. That should help you see what sort of data corruption you're seeing.

Cheers,

Sam

Sam Moffatt
http://pasamio.id.au

[iradi...@gmail.com]

Hi Fred, I'm just dealing with similar issue right now. I'd like to build AES256 secured filesystem above osxfuse. perhaps you can share me your insights about this task ? 

thanks a lot 

Irad