Saving encrypted customProperties outside the app?

[Mark Brownell]

On Tuesday, September 30, 2003, at 11:29  AM, Rob Cozens wrote:

> Mark has contributed Rev_Blowfish to the revolution_ipc group's stack 
> library as a starting point for incorporating support for Blowfish 
> encryption/decryption into the collection of IPC commands that will be 
> released (most likely) in one library stack, Jan's libIPC.

Rob, et al:

This is how I envision using blowfish with Jan's libIPC. The Blowfish 
algorithm would be separated from all key authentication and encryption 
level handlers and would run from two parts. Part one would be the 
creation of the P and S boxes based on an encryption key passed to it. 
Part two would be encryption or decryption of data using these P and S 
boxes. This process would leave the algorithm's bit level wide open to 
developers, and in my opinion it should. In other words the developer 
would use 64 bit in a parameter and that would automatically limit the 
bit level to 64 bit encryption.

function createBoxes, encryptionKey, bitLevel
   return P1Array
   return S1Array
   return S2Array
   return S3Array
   return S4Array
end createBoxes

So: createBoxes("abcdefgh", 64) gives you a set of boxes for this key
these boxes could be stored as a fixed set of boxes that
encrypt/decrypt can use later if you wish this capability.

-----------------------

function encryptData dataToEncrypt
   -- uses the P1, S1, S2, S3, S4 arrays somehow.
   -- This is done so that preset boxes can be used that
   -- matches a certain encryption key.
   return encryptedDataChunk
end encryptData

function decryptData dataToDecrypt
   -- uses the P1, S1, S2, S3, S4 arrays somehow.
   -- This is done so that preset boxes can be used that
   -- matches a certain encryption key.
   return decryptedDataChunk
end decryptData

So: put encryptData("your data here") into blabWhat

So: put decryptData("~1*^ /hd io&%") into sayWhat

------------------------

for a higher level of libIPC security there should be this even though 
it will slow things down during the first half second of process.

function encryptDataBest dataToEncrypt, encryptionKey, bitLevel
   -- P1, S1, S2, S3, S4 arrays are created here first
   return encryptedDataChunk
end encryptDataBest

function decryptDataBest dataToDecrypt, encryptionKey, bitLevel
   -- P1, S1, S2, S3, S4 arrays are created here first
   return decryptedDataChunk
end decryptDataBest

So: put encryptData("your data here", "abcdefgh", 64) into blabWhat

So: put decryptData("~1*^ /hd io&%", "abcdefgh", 64) into sayWhat

-----------------------

So the thing here is you would have unrestricted blowfish that requires 
the developer to set the bit level available from the libIPC. It should 
be written so that if the parameter for bit level is missing that the 
function should exit without working. This puts the responsibility on 
the shoulders of the developer using the libIPC.

Now what is not worked out here is a function for setting a proper 
access key. revBlowfish uses 56 chars everytime for the key.

32 bit encryption = 4 chars repeated 14 times = 56

64 bit encryption = 8 chars repeated 7 times = 56

96 bit encryption = 12 chars repeated 4.66 times = 56

128 bit encryption = 16 chars repeated 3.5 times = 56

So the createBoxes("abcdefgh", 64) would take the first 8 chars of the 
passed key and repeat them 7 times to create the key that blowfish uses 
to create the boxes.

Proper key creation or use should be handled by the developer I think. 
If a generic key manipulation feature were desired then a separate 
function could be created for the libIPC. This would be used for 
situations where twelve keys where needed and only ten where provided

Mark