I have uploaded the VS source code as well as the compiled binaries to Google Project Hosting in case anyone wants to play – https://code.google.com/p/clarion-accessory-addin/

Note: This has not been approved by the Clarion 3rd Party Association as an official update to the Clarion7 install standard so please use your common sense when considering this addin! I wanted to make the source available so that if there is interested perhaps others would like to contribute.

Other Note: I am also evaluating Google Project Hosting as a possible destination for the source of all the other addins. They are currently being hosted on http://www.assembla.com/ but the google option looks like it has pretty sweet support for open source projects which I think is what I want to do with the current addins. I would love to hear your thoughts, leave a comment or send me an email.

J-Blowfish is a Clarion wrapper (pure Clarion source, no black boxes) for the Blowfish  encryption algorithm. Most of this code was written by Andy Ireland  – we have added a helper class, examples, templates, etc.

I learnt a lot looking into this code a few years ago (wow, it was 2006 looking at my notes!). At the time we needed an implementation of the Blowfish Encryption Algorithm to share encrypted data between a Clarion and Java application. J-Blowfish seemed like a great fit but unfortunately we found that it was not producing standard encrypted data and was also unable to decrypt anything produced by another implementation.

The solution at the time was to use a C DLL instead. This worked fine but seemed a bit ugly, I would have much preferred a pure clarion solution. Also, the code in  jblowfish.clw intrigued me.

NOTE: This is just me poking around in things to learn something new. Don’t blame me if following anything in this blog sinks your submarine or whatever

Here is what I found…

(It is simpler to deal with hex output so that is the only section I have looked at but the results impact all encrypt/decrypt functions.)

1st, Implementation problem:

(In the “Main” procedure of BlowDemo.app)

In the demo supplied with J-Blowfish the local variable holding the key is not clipped. This means the actual key used for the Encryption is inclusive of the trailing spaces in the STRING.

Additionally, the blowfish encryption mode implemented in J-Blowfish (which I believe is ECB) requires your data to be a multiple of 8 bytes. The original implementation will pad an extra 8 bytes if the data is already a multiple of 8.

Original:

RtnEncryptHex  routine
 
  ! Set some properties
  MyBlowfish.Key32 = loc:Key
  MyBlowfish.Size = Len(Clip(loc:Text)) + (8-(Len(Clip(loc:Text))%8))

Suggested improvements:

RtnEncryptHex  routine
 
  ! Set some properties
  MyBlowfish.Key32 = Clip(loc:Key) ! Because loc:Key is a string not cstring without the Clip() your key is including spaces
 
  IF Len(Clip(loc:Text))%8 > 0
    ! Pad the data to the nearest 8 character block
    MyBlowfish.Size = len(clip(loc:Text)) + (8-(len(clip(loc:Text))%8))
  ELSE
    ! If the data length is exactly a multiple of 8 then there is no need to pad another 8.
    MyBlowfish.Size = len(clip(loc:Text))
  END

2nd, Encryption problem (jblowfish.clw)

The “BlowFish._Encrypt” method seems to be the culprit in the encryption errors I experienced.

In my testing I was using this data:

key: “abc”

plain text: “abcdefgh”

encrypted result (other tools): “94c559d64e1251fb”

I discovered that if in the BlowDemo.exe I used this data, “dcbahgfe” I would get the correct result (almost… the result was also backwards “d659c594 fb51124e”)

So it came down to a problem with the way the data was being passed to the “self.BF_Encrypt(pWork, pWork2)” part of this method.

(note: the BF_Encrypt method is used successfully in the BlowFish.Initialise method, I checked the values being generated and they are all correct)

Basically I believe this is because the Endianness of clarion longs is different to whatever assumption is made in the algorithm J-.Blowfish is based upon.

This is what I came up with:

BlowFish._Encrypt procedure(long pData, long dwBytes)
 
nBlocks                 long,auto
i                       long,auto
pWork                   long,auto
pWork2                  long,auto
bchar                   &byte
block                   string(8)
block2                  string(8)
 
  code
    if dwBytes % 8
      return false.
 
    nBlocks = bshift(dwBytes, -3)
    pWork = pData
 
    loop i = 1 to nBlocks
      pWork2 = pWork + 4
 
      ! Reverse the order of the first 4 bytes 
      bchar &= (pWork + 3)
      block[1] = Chr(bchar)
      bchar &= (pWork + 2)
      block[2] = Chr(bchar)
      bchar &= (pWork + 1)
      block[3] = Chr(bchar)
      bchar &= (pWork + 0)
      block[4] = Chr(bchar)
      ! Reverse the order of the next 4 bytes 
      bchar &= (pWork + 7)
      block[5] = Chr(bchar)
      bchar &= (pWork + 6)
      block[6] = Chr(bchar)
      bchar &= (pWork + 5)
      block[7] = Chr(bchar)
      bchar &= (pWork + 4)
      block[8] = Chr(bchar)
 
      !self.BF_Encrypt(pWork, pWork2) ! <-- doesnt work
      self.BF_Encrypt(Address(block), Address(block)+4)
 
      ! Now swap them back again
      block2[1] = block[4]
      block2[2] = block[3]
      block2[3] = block[2]
      block2[4] = block[1]
      block2[5] = block[8]
      block2[6] = block[7]
      block2[7] = block[6]
      block2[8] = block[5]
      ! And replace the data in "BinData" with the encrypted values
      Poke(pWork, block2)
 
      pWork += 8
    end
    return true

Other considerations:

• This only takes care of the Encryption phase something similar will need to happen in the Decrypt method.
• There may be better ways (band, bshift, bxor, whatever) to do this but it was late and this way is at least descriptive
• I passed a few of the standard test vectors through the changed version and it seems to work correctly now. Most implementations have in them somewhere a self test method that uses these test vectors to prove they are running correctly:

  http://www.schneier.com/blowfish.html

  http://www.schneier.com/code/vectors.txt

• One thing I learned (amongst many!) whilst doing all this. It seems you can safely do a search replace in jpwbfish.inc and jpwbfish.clw to replace all ULONG’s with LONG’s. This may even result in some speed improvements as supposedly longs are faster then ulongs. Reason for this is that longs are 32 bit and that is sufficient for blowfish as it works in 32 bit words. It seemed weired to me at first, its like when you do this:

SomeProcedure PROCEDURE()
x LONG
  CODE
 
  x = 2147483647 ! The highest value a long can take
  Message(x) ! It will show "2147483647"
  x += 1
  Message(x) ! It will show "-2,147,483,648"

But blowfish doesn’t care about the +/- part as it is working directly on the bytes in the long, thus a LONG is sufficient.

(This explanation may be off on a few technical points but you get the drift?)

I hope all the above makes (some) sense!

-brahn