Mac algorithm DESEDE ANSI X9.19

[mehrdad2000]

Hi
need to use mac algorithm DESEDE ANSI X9.19 in jmeter-iso8583

Any idea?
Thanks

[tilln]

@mehrdad2000
Are you sure you have the correct acronym? Google finds nothing for DESEDG. Do you mean DESEDE?

[mehrdad2000]

@tilln Yes, Sorry it’s typo, I mean DESEDE.

[tilln]

@mehrdad2000
Well, in that case you may want to have a look at the Crypto PreProcessor's MAC generation feature which supports DESEDE.

[mehrdad2000]

@tilln Thanks, try these but neither generate hash that match with ANSI X9.19:

• DES9797Alg3
• DESISO9797MAC
• ISO 9797-1 Algorithm 3
• ISO9797ALG3MACWITHISO7816-4PADDING
• DESWITHISO9797
• ISO9797ALG3
• ISO7816d4Padding
• ISO7816-4/ISO9797-1
• X9.19

https://stackoverflow.com/questions/39187598/java-c-implementation-of-ansi-x9-19-retail-mac

[tilln]

@mehrdad2000
Are you getting a MAC value generated at all but an incorrect one or are you getting errors/exceptions in the log?
Is it possible that you are using the wrong key or the right key with an incorrect length?
Is the MAC key static/fixed or dynamic i.e. a session-based key that changes, and if so how are you getting it?

[mehrdad2000]

@tilln
1-mac generated with ISO9797Alg3Mac and not match with mac that generated with ANSI X9.19.
2-mac key is correct.
3-length of mac key is 16.
4-mac generate in each message and jmeter put in bit 128.
5-i have mac calculator that write in java and exactly use this algorithm ISO9797Alg3Mac to generate mac, and value that generated by jmeter is different with mac that generate by this Mac calculator.

[tilln]

3-length of mac key is 16.

16 bytes or 16 hex digits?

5-i have mac calculator that write in java and exactly use this algorithm ISO9797Alg3Mac to generate mac

If you could share your Java code and your JMeter script then I may be able to debug why they produce different results?

[tilln]

Please also confirm what JMeter and plugin versions you are using.

[mehrdad2000]

@tilln mac key length are 32 hex, jmeter-5.6.2, jmeter-iso8583-1.3

[mehrdad2000]

@tilln here is the java calculator that i use:

//Calculation MAC
    private void jButton34ActionPerformed(java.awt.event.ActionEvent evt) {                                          
        // TODO add your handling code here:
        if(!"".equals(jTextField36.getText()))
        {
            if(!"".equals(jTextArea11.getText()))
            {
                //Get KEY
                //try{
                String TextKey = jTextField36.getText().replace("-","").replace(" ","");
                byte[] key = new byte[TextKey.length()/2];
                for(int i =0 ; i< TextKey.length(); i +=2)
                {
                    key[i/2] = (byte)((Character.digit(TextKey.charAt(i), 16) << 4)+ Character.digit(TextKey.charAt(i+1), 16));
                }
                
                   
                byte[] data=jTextArea11.getText().getBytes(StandardCharsets.UTF_8); 
                
                
                
                int i =0 ;
                
               ISO9797Alg3Mac myMac = new ISO9797Alg3Mac(new DESEngine());
               KeyParameter keyP = new KeyParameter(key);
               myMac.init(keyP);
               myMac.update(data, 0, data.length);

               byte[] out = new byte[8];

               myMac.doFinal(out, 0);
               
               jTextField37.setText(Byte2String(out));     
            }
            else 
            {
                JOptionPane.showMessageDialog(new JFrame(), "Data is empty!", "Error",JOptionPane.ERROR_MESSAGE);
            }
        }
        else 
        {
            JOptionPane.showMessageDialog(new JFrame(), "MAC KEY is empty!", "Error",JOptionPane.ERROR_MESSAGE);
        }
        
    }

[tilln]

Thanks, @mehrdad2000.

Can you just confirm one thing quickly for me, then perhaps I won't need to see your script:
Is the MAC calculation correct with a JMeter version before 5.6?

If so, I suspect you may be using random or dynamically changing values in some message field e.g. via the __Random function or similar?

[mehrdad2000]

@tilln Try 5.5 and not generate correct mac.

[tilln]

@mehrdad2000
I'm sure you'll understand I need to reproduce your issue or I won't be able to help much, so I'm going to need your script.

I have tried running code similar to your snippet above but I get the same value as with this plugin.

I have attached a sample script: issue77.jmx
When running this with debug output you'll see the value added by the Crypto PreProcessor, e.g.

2024-03-01 13:44:43,647 INFO o.a.j.m.J.JSR223 PreProcessor: MAC value=d095516b4ea52065
2024-03-01 13:44:43,652 DEBUG n.c.b.j.i.ISO8583Crypto: Processing sampler 'ISO8583 Sampler'
2024-03-01 13:44:43,652 DEBUG n.c.b.j.i.ISO8583Crypto: No PIN field defined, skipping PIN Block encryption
2024-03-01 13:44:43,652 DEBUG n.c.b.j.i.ISO8583Crypto: No ARQC field defined, skipping ARQC calculation
2024-03-01 13:44:43,653 DEBUG n.c.b.j.i.ISO8583Crypto: New MAC key instance assigned
2024-03-01 13:44:43,666 DEBUG n.c.b.j.i.ISO8583Component: Add field DE64=d095516b4ea52065

The sample script also demonstrates how you can use your calculation result instead of the Crypto PreProcessor's result.

[mehrdad2000]

@tilln Thanks but still not match:

expected result that calculated by calculator: 6d3b4c1ef5af47b0,

current result of jmeter with jrs223 that you mentioned: 02237F5FAF64E63E

calculator + jmx file with sample message here: mysample.zip

[tilln]

@mehrdad2000

The packed message bytes in your JMeter script and Python script don't match if I use the jPOS packager iso93ascii.xml: DE12 is 12 vs 6 digits.

Also, between your Java and Python code, which one is the reference implementation with the correct results?

Is the server you are testing accepting the manually calculated MAC value if you add that to the message?

Have you ruled out a packager related error, where the fields are packed in a different way by the script than they are unpacked by the server and therefore they result in different MAC values?

[mehrdad2000]

@tilln
1-change DE12 from 12 to 6 on iso93ascii.xml generated mac is ECCBDA6C65B7CFC8, restore it and also add 6 numbers to bit 12 for test it generates another mac 1027C570F7C2EDD6 and still not match with 6d3b4c1ef5af47b0! also try to use iso87ascii.xml and DE12 is 6 but produce different mac!

2-both do the same thing, and generate same result, I just rewrite it in python so you can run it in bash without any dependency. java code is a part of larger code that has UI. so, python code is reference code.

3-yes but code of this server that calculate mac has legacy code. but it except same mac as python calculator created for message sample i put in python code.

Any idea?
Thanks,

[tilln]

@mehrdad2000
I have created a snapshot release for you to test a fix.
Please report back whether this fixes your issue.

[mehrdad2000]

@tilln Thanks, do i still need to use JRS223 script that exist in issue77.jmx or it should work with "ISO8583 Crypto PreProcessor"?

[tilln]

@mehrdad2000 It should now work with the "ISO8583 Crypto PreProcessor" and your ISO9797Alg3Mac algorithm.

[mehrdad2000]

@tilln Thank you so much, work like charm! :)

[tilln]

Thanks for reporting this.
The fix will be included in the next release.