Recently I got a stylesheet with really HUGE number of arguments in a concat() function.

My first approach of determining the arity was not nice and needed handwork, but did give the result I needed.

Later I learned from our XQuery team that XPath 2 has a much simpler solution for that:

Just replace concat(...) by count( (...) ) making the argument list an XPath 2 sequence and applying the count() function.

This approach is really easy, and can be evaluated by any XQuery processor.

With v6.0 firmware DataPower has an XQuery 1.0 compiler, so you can evaluate with DataPower.
You can also evaluate on any other XQuery 1.0 processor like saxon.
Or you can do it online at http://try.zorba.io.

This is just the table showing the measured times (on a 9004 XI50, reported in milli seconds , but with sub nano second precision):

00

99

AA

FF

FF

#runs

10000

10000

10000

10000

20000

hex2num1

23

35

36

35

72

hexdig2num2

27

30

30

32

64

hex2num2

7

8

8

8

16

hexdig2num3

19

19

22

24

47

hex2num3

4

4

4

4

8

The increased values for *func:hexdig2num* are due to the fact that digit comparisons are done sequentially.The last column gives just the values for doubled number of calls.The worst case wrt time is input 'FF' which enforces quite some <xsl:when>s tests.

And the winner is "hex2num3 with hexdig2num3":(4+24)/10000 = 2.8 [microsecond/call]

Since DataPower XSLT processor does not provide tail-recursion optimization use of divide-and-conquer technique is required.This recursive function runs out of stack space because a 4MB string results in more than 50.000 lines -- too much for recursion call-depth.

This is the devide-and-conquer technique which solves the problem easily -- determine $mid as offset where to split, "near" the middle (multiple of 76):

What can be learned from this?Always implement "little helper functions" as efficient as possible -- you never know how others make use of them ... :-)

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.

Attached to that posting is a correctly formatted multipart/signed sample message (with CRLFs) and the stylesheet.

This sytelsheet is a nice demonstration of these features:* accessing Non-XML input

* UTF-8 validate input (needed for safety, OK for scenario since ASCII is a subset of UTF-8)* having a func:function doing some preparation work (eliminate soft line breaks, split at '=3D')* having a recursive func:function doing the rest.

Important for the recursive function is doing only what needs to be done in the stylesheet and rely on efficient extension functions (regexp:replace) where possible.

Last, but not least, it demonstartes how you can map a unicode code point to a parsed charecter entity inside a stylesheet by mapping (for ISO-8859-1 sample).