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

1. Download the addin file – Clarion3rdParty.sdaddin
2. Start the Clarion 7 IDE:
   
3. Go to the Tools menu and select the Addin Manager:
   
4. Click the Install Addin button:
   
5. Find the Addin file you downloaded in Step 1
   
6. You should now see the new addin listed in the Addin Manager, restart the IDE to see what it does!
   
7. And there you have it, a new menu item under Help–>Web !
   

Simply adding a menu item is very easy with the new Clarion 7 IDE. I suppose the hardest part is finding the correct names for everything and getting them in the right place. The Clarion3rdParty.sdaddin file you downloaded at the beginning is just a zip file containing one XML formatted “addin” file. This XML simply tells the IDE what you want to do and where to do it.

This is the XML used in the Clarion3rdParty addin:

<AddIn name    = "Clarion3rdPartyAddin"
   author      = "Brahn Partridge"
   url         = ""
   copyright   = ""
   description = "TODO: Put description here">
 
	<Manifest>
		<Identity name="ClarionEdge.Clarion3rdPartyAddin" version="0.1"/>
		<Dependency addin = "SharpDevelop" version = "2.1"/>
	</Manifest>
 
	<Path name = "/SharpDevelop/Workbench/MainMenu/Help/Web">
		<MenuItem id = "Clarion3rdParty" label = "Clarion 3rd Party" type="Menu">
			<MenuItem id = "ClarionEdge"
					  label = "www.clarionedge.com"
					  icon = "Icons.16x16.WebSearchIcon"
					  link = "http://www.clarionedge.com/"/>
		</MenuItem>
 
	</Path>
</AddIn>

And the download again in case you missed it:

Download:	Clarion3rdParty.sdaddin
Version:	0.1
Updated:	May 20, 2009
Size:	471 bytes
Downloads:	197