Hi,

I've looked to key length encoding in Harbour level functions. Is it
some standard way to encode length of 8byte unaligned data?

I guess you are talking about .prg functions.
No, it's not a standard. I implemented it only for these functions.

I guess your padding IS standard ANSI X.923 :) If not, we can choose one suitable padding from http://en.wikipedia.org/wiki/Padding_(cryptography)


   function hb_blowfishEncryptRaw( bfKey, cData )
   return left( hb_blowfishEncrypt( bfKey, cData ), len( cData ) )

   function hb_blowfishDecryptRaw( bfKey, cData )
   return hb_blowfishDecrypt( bfKey, cData + ;
            hb_blowfishEncryptRaw( bfKey, repl( chr( 0 ), 7 ) + chr( 8 ) ) )

I had exactly the same idea of hb_blowfishEncryptRaw(), but I was unable to make hb_blowfishDecryptRaw(). My idea was:

function hb_blowfishDecryptRaw( bfKey, cData )
return LEFT(hb_blowfishDecrypt( bfKey, cData + REPL(CHR(0), 8)), cData)

but the problem is that hb_blowfishDecrypt() will return a valid result only if the last byte of decrypted string is <= 8. The probability of this is 1/8, so, additional loop required to feed a function with random stuff instead of REPL(CHR(0), 8) until function return a valid result. Not a nice solution. :)


There is only one question: what to do if passed string length is not
multiple of 8. We have few choices:
1. generate RTE
2. return NIL or "" to indicate error
3. pad string with spaces or chr( 0 ) before encoding
4. pad only strings shorter then 8 bytes. For longer strings encode
   encode all full 64bit blocks then encode last 64bits (decode in
   reveresed order)

The version 4 allow to encode any data longer then 7 bytes without any
problems keeping original size.

What do you prefer?

Since lRaw is .T., perhaps the simple method should be used (1 or 2). Perhaps return NIL is better than RTE since current functions return NIL (or we should add RTE in all functions). 3 choice makes function a little "not raw", but it is also a good choice. But the 4th is the most interesting :) I've not understood your idea, can you describe it it more detail?

The similar to 4 ways of "storing length" is described in http://en.wikipedia.org/wiki/Ciphertext_stealing and http://en.wikipedia.org/wiki/Residual_block_termination , but I'm not sure if we need these. It is not "raw". It could be implemented if lRaw=.F., but the drawback is that it does not work if data size is less than 1 block. So, it is also not suitable.

So, my preference order is:
 3 with CHR(0)
 2 with NIL
 1 (and generate RTE in other cases)
 4


Regards,
Mindaugas
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour

Reply via email to