Now that file data should be store in a database via <dp:url-open ...>, but not in UTF-8 but its original encoding.
While there is a solution for this kind of problem (slides 6-8 in this WSTE webcast)the conversion to and from UTF-8 are overhead at least.

In addition the filename of the file uploaded is not available by DataPower convert-http action.

One solution is making use of swaform tool which even is able to deal with binary file data in file upload fields (see slide 16 of this WSTE webcast).

Another solution is making use of stylesheet fileupload.xsl attached in this posting:

A 64bit des:encrypt-blk() call takes roughly 3ms, which means that you do not want to apply that on big data.

The implementation works of 01-strings, hexTObin and other conversion functions included.

This reminds me 5.5 years back when I worked in Smartcard development department in Boeblingen Lab.

The person responsible for side channel attacks left IBM and I was the first who raised the hand for the equipment:

two oscilloscope cards for the server (100MHz, 2GHz)

a special card reader with high precision probe

many smartcards, some secure, others less secure, for adjustment

software for doing side channel attacks.

What was easy to do was to break triple DES on cards without randomization counter-measure based on statistical analysis of several thousand measurements.

What I heard about is the single request break of RSA private keys in early smardcards.The code for doing exponentiation in that cards was "efficient", it did compute

x^(2*n) by (x^n)^2 and

x^(2*n+1) by ((x^n)^2)*x

So the single bits of the private key could be directly seen on the oscilloscope by long (odd exponent) or short (even exponent) areas of high power consumtion.

We did not have the equipment to cut reader power based on some runtime condition or at a specific clock cycle of computation.

But the certification agencies (and real attackers) had.

Once we got a complaint from a cert agency that a specific pattern on the oscilloscope would leak information.

They claimed that the pattern corresponds to a specific part of the OS code.

Using the oscilloscope I was able to disprove that statement.

I just added code that created spikes at specific locations in the OS code.

Then running the request the oscilloscope proved that the pattern of the complaint belonged to a totally different part of the OS code.Now how to generate a "spike"?That was easy -- just power on the (hardware) random generator and immediately power it off with the next command.

But that was long ago, before IBM sold its smartcard business and I joined DataPower development 4.5 years ago.