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
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
