This discussion is archived
3 Replies Latest reply: Oct 30, 2012 12:42 AM by EJP RSS

Java Checksum CRC32

966781 Newbie
Currently Being Moderated
Hi there,

i have a Java Project which communicates with a JavaCard. All messages are secured with a CRC32.
My problem is, about 10 from 100 CRC32 calculations on the Java side goes wrong. The same message on both sides but different CRCs. The most time it works fine but sometimes it does not match. There can be no real CRC errors because i dont use a real card ... only an simulator.

I searched a free CRC32 calculator with google and tried it there, the CRC32 from the card is right, the CRC from the Java Host is wrong. Theres an example:

49byte input message:
byte[] input = new byte[]{(byte)32, (byte)66, (byte)40, (byte)-60, (byte)11, (byte)-65, (byte)-2, (byte)-47,
(byte)-7, (byte)-32, (byte)-110, (byte)-33, (byte)76, (byte)-16, (byte)26, (byte)-98,
(byte)77, (byte)-122, (byte)-86, (byte)125, (byte)0, (byte)76, (byte)99, (byte)72,
(byte)109, (byte)50, (byte)-43, (byte)56, (byte)-64, (byte)47, (byte)96, (byte)-2,
(byte)104, (byte)-128, (byte)-13, (byte)-127, (byte)-36, (byte)16, (byte)2, (byte)2,
(byte)114, (byte)-6, (byte)-21, (byte)-25, (byte)-99, (byte)-11, (byte)-120, (byte)-6, (byte)-105};
CRC32 in Java over these 49byte:

-5, -61, -70, 3

CRC32 in Java Card over these 49byte:

15, -68, -59, -93

When i wirte it down as a hex string you can see its nearly the same.

Java host: 0xFBC3BA03
Card: 0x0FBC3BA3

It seems there is a kind of rotation in the calculation.

Free CRC32 calculators says the Card is right. But both CRC32 implemantaions (Java API and JavaCard API) using the exactly same polynom.

Anyone knows this issue ? I haven't got the slightest idea why this happens.
  • 1. Re: Java Checksum CRC32
    rp0428 Guru
    Currently Being Moderated
    >
    My problem is, about 10 from 100 CRC32 calculations on the Java side goes wrong.
    >
    Then you are doing it wrong on the Java side because Java 1.6 gives the same answer you say is right
    byte[] input = new byte[]{(byte)32, (byte)66, (byte)40, (byte)-60, (byte)11, (byte)-65, (byte)-2, (byte)-47,
    (byte)-7, (byte)-32, (byte)-110, (byte)-33, (byte)76, (byte)-16, (byte)26, (byte)-98,
    (byte)77, (byte)-122, (byte)-86, (byte)125, (byte)0, (byte)76, (byte)99, (byte)72,
    (byte)109, (byte)50, (byte)-43, (byte)56, (byte)-64, (byte)47, (byte)96, (byte)-2,
    (byte)104, (byte)-128, (byte)-13, (byte)-127, (byte)-36, (byte)16, (byte)2, (byte)2,
    (byte)114, (byte)-6, (byte)-21, (byte)-25, (byte)-99, (byte)-11, (byte)-120, (byte)-6, (byte)-105};
    
      java.util.zip.CRC32 myCRC = new java.util.zip.CRC32();
    
      myCRC.update(input);
      System.out.println(myCRC.getValue());
    
    263994275 = 0xFBC3BA3      
  • 2. Re: Java Checksum CRC32
    966781 Newbie
    Currently Being Moderated
    Hi,

    thanks for the reply.
    Finally i found the misstake i made...

    On Java side i converted the long into an hex-string and then splitted the hex-string into a 4byte array.
    But the long.tohexstring method removes the leading zeros.

    So if i split the hexstring it results in "FB", "C3", "BA" and "03" instead of "0F", "BC", "3B", "A3".
    Thats the reason it works the most time fine and only if the first byte of the hexstring is smaller then "10" it failed.
  • 3. Re: Java Checksum CRC32
    EJP Guru
    Currently Being Moderated
    There are easier and more direct and correct ways to convert longs to byte arrays. No need to invent one, especially a wrong one.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points