Can you please explain Reed Solomon encoding part's Identity matrix? - math

I am working on a object storage project where I need to understand Reed Solomon error correction algorithm,
I have gone through this Doc as a starter and also some thesis paper.
1. content.sakai.rutgers.edu
2. theseus.fi
but I can't seem to understand the lower part of the identity matrix (red box), where it is coming from. How this calculation is done?
Can anyone please explain this.

The encoding matrix is a 6 x 4 Vandermonde matrix using the evaluation points {0 1 2 3 4 5} modified so that the upper 4 x 4 portion of the matrix is the identity matrix. To create the matrix, a 6 x 4 Vandermonde matrix is generated (where matrix[r][c] = pow(r,c) ), then multiplied with the inverse of the upper 4 x 4 portion of the matrix to produce the encoding matrix. This is the equivalent of "systematic encoding" with Reed Solomon's "original view" as mentioned in the Wikipedia article you linked to above, which is different than Reed Solomon's "BCH view", which links 1. and 2. refer to. The Wikipedia's example systematic encoding matrix is a transposed version of the encoding matrix used in the question.
https://en.wikipedia.org/wiki/Vandermonde_matrix
https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction#Systematic_encoding_procedure:_The_message_as_an_initial_sequence_of_values
The code to generate the encoding matrix is near the bottom of this github source file:
https://github.com/Backblaze/JavaReedSolomon/blob/master/src/main/java/com/backblaze/erasure/ReedSolomon.java
Vandermonde inverse upper encoding
matrix part of matrix matrix
01 00 00 00 01 00 00 00
01 01 01 01 01 00 00 00 00 01 00 00
01 02 04 08 x 7b 01 8e f4 = 00 00 01 00
01 03 05 0f 00 7a f4 8e 00 00 00 01
01 04 10 40 7a 7a 7a 7a 1b 1c 12 14
01 05 11 55 1c 1b 14 12
Decoding is performed in two steps. First, any missing rows of data are recovered, then any missing rows of parity are regenerated using the now recovered data.
For 2 missing rows of data, the 2 corresponding rows of the encoding matrix are removed, and the 4 x 4 sub-matrix inverted and used the multiply the 4 non-missing rows of data and parity to recover the 2 missing rows of data. If there is only 1 missing row of data, then a second data row is chosen as if it was missing, in order to generate the inverted matrix. The actual regeneration of data only requires the corresponding rows of the inverted matrix to be used for a matrix multiply.
Once the data is recovered, then any missing parity rows are regenerated from the now recovered data, using the corresponding rows of the encoding matrix.
Based on the data shown, the math is based on finite field GF(2^8) modulo 0x11D. For example, encoding using the last row of the encoding matrix with the last column of the data matrix is (0x1c·0x44)+(0x1b·0x48)+(0x14·0x4c)+(0x12·0x50) = 0x25 (using finite field math).
The question example doesn't make it clear that the 6 x 4 encode matrix can encode a 4 x n matrix, where n is the number of bytes per row. Example where n == 8:
encode data encoded data
01 00 00 00 31 32 33 34 35 36 37 38
00 01 00 00 31 32 33 34 35 36 37 38 41 42 43 44 45 46 47 48
00 00 01 00 x 41 42 43 44 45 46 47 48 = 49 4a 4b 4c 4d 4e 4f 50
00 00 00 01 49 4a 4b 4c 4d 4e 4f 50 51 52 53 54 55 56 57 58
1b 1c 12 14 51 52 53 54 55 56 57 58 e8 eb ea ed ec ef ee dc
1c 1b 14 12 f5 f6 f7 f0 f1 f2 f3 a1
assume rows 0 and 4 are erasures and deleted from the matrices:
00 01 00 00 41 42 43 44 45 46 47 48
00 00 01 00 49 4a 4b 4c 4d 4e 4f 50
00 00 00 01 51 52 53 54 55 56 57 58
1c 1b 14 12 f5 f6 f7 f0 f1 f2 f3 a1
invert encode sub-matrix:
inverse encode identity
46 68 8f a0 00 01 00 00 01 00 00 00
01 00 00 00 x 00 00 01 00 = 00 01 00 00
00 01 00 00 00 00 00 01 00 00 01 00
00 00 01 00 1c 1b 14 12 00 00 00 01
reconstruct data using sub-matrices:
inverse encoded data restored data
46 68 8f a0 41 42 43 44 45 46 47 48 31 32 33 34 35 36 37 38
01 00 00 00 x 49 4a 4b 4c 4d 4e 4f 50 = 41 42 43 44 45 46 47 48
00 01 00 00 51 52 53 54 55 56 57 58 49 4a 4b 4c 4d 4e 4f 50
00 00 01 00 f5 f6 f7 f0 f1 f2 f3 a1 51 52 53 54 55 56 57 58
The actual process only uses the rows of the matrices that correspond
to the erased rows that need to be reconstructed.
First data is reconstructed:
sub-inverse encoded data reconstructed data
41 42 43 44 45 46 47 48
46 68 8f a0 x 49 4a 4b 4c 4d 4e 4f 50 = 31 32 33 34 35 36 37 38
51 52 53 54 55 56 57 58
f5 f6 f7 f0 f1 f2 f3 a1
Once data is reconstructed, reconstruct parity
sub-encode data reconstruted parity
31 32 33 34 35 36 37 38
1b 1c 12 14 x 41 42 43 44 45 46 47 48 = e8 eb ea ed ec ef ee dc
49 4a 4b 4c 4d 4e 4f 50
51 52 53 54 55 56 57 58
One alternate to this approach is to use BCH view Reed Solomon. For an odd number of parities, such as RS(20,17) (3 parities), 2 matrix multiplies and one XOR is needed for encoding, and for a single erasure only XOR is needed. For e>1 erasures, a (e-1) by n matrix multiply is done, followed by an XOR. For an even number of parities, if an XOR is used as part of the encode, then a e by n matrix multiply is needed to correct, or the e x n matrix used for encode, allowing one XOR for the correction.
Another alternative is Raid 6, where "syndromes" are appended to the matrix of data, but do not form a proper code word. One of the syndrome rows, called P, is just XOR, the other row called Q, is successive powers of 2 in GF(2^8). For a 3 parity Raid 6, the third row is called R, is successive powers of 4 in GF(2^8). Unlike standard BCH view, if a Q or R row is lost, it has to be recalculated (as opposed to using XOR to correct it). By using a diagonal pattern, if 1 of n disks fail, then only 1/n of the Q's and R's need to be regenerated when the disk is replaced.
http://alamos.math.arizona.edu/RTG16/ECC/raid6.pdf
Note that this pdf file's alternate method uses the same finite field as the method above, GF(2^8) mod 0x11D, which may make it easier to compare the methods.

Related

Dota2 packet analysis uknown wiretype for proto message

I am trying to gain access to in game chat information from dota2 packets. I knew this used to possible since there were multiple projects that intercepted dota2 network traffic and translated chat text to print out on an overlay over dota2. Right now I am using wireshark with protobuf addon installed. I can see a few packets here and there to valve servers outside the USA and can see the protobuf addon for wireshark working on these packets but I get an unknown wiretype error for 95% of the packets I believe to be related to dota. In almost all of these packets the UDP data payload starts off with 56 53 30 31
here is an example hex dump from wireshark. Are these 4 bytes some sort of header and then the proto messages start?
0000 c8 a7 0a a4 63 ed 6c fd b9 4b 6e 16 08 00 45 00
0010 00 70 58 db 40 00 40 11 85 1a c0 a8 01 f5 d0 40
0020 c9 a9 9e 96 69 89 00 5c 72 7c **56 53 30 31** 30 00
0030 06 00 00 02 00 00 00 1d fe 11 11 10 00 00 d7 0a
0040 00 00 01 00 00 00 11 10 00 00 30 00 00 00 24 fd
0050 37 3c b4 30 a5 48 fa 3d ea 30 1a 1f d8 a9 41 e0
0060 e0 6c 44 ba bb 4e ba fc e7 ac ed f9 40 19 86 20
0070 84 71 52 5d b3 1f da 36 40 d9 b6 2e e1 e5
That is ascii code for "VS01", so yes, it might be some kind of version identifier.

read_table with minus zero (-0) in R

I am reading a .txt file in R with read_table.
This file contains multiple columns, where three of them corresponds to 'hh mm ss'. Since 00 00 00 corresponds to midnight, any value before that is negative, as in, -00 30 00 corresponds to 30 minutes to midnight.
Here is some of the .txt data:
-00 53 30
-00 53 05
-00 52 43
-00 52 20
00 02 25
00 02 37
data <- read.table('data.txt',header = FALSE, stringsAsFactors = FALSE)
Output data:
00 53 30
00 53 05
00 52 43
00 52 20
00 02 25
00 02 37
The problem is I need it to be a "negative zero".
How can I overcome this?

unable to decrypt 3DES with SessionKey

I'm developing a C project to read/write Desfire Contactless Cards.
Right now I achieved to authenticate and I'm able to read data from the card, but it's encrypted with 3DES.
I want to decrypt next message:
EB 54 DF DD 07 6D 7C 0F BD D6 D1 D1 90 C6 C7 80 92 F3 89 4D 6F 16 7C BF AA 3E 7C 48 A8 71 CF A2 BD D0 43 07 1D 65 B8 7F
My SessionKey (generated in Authentication step) is:
44 E6 30 21 4A 89 57 38 61 7A B8 7C A9 91 B2 C0
I know the IV={ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }
With this information, I can go here and choosing 3DES, CBC mode, I can decrypt the message and I have means to know that it's right.
It should be, decrypted:
10 1a 01 31 32 ae 03 de 39 b0 00 97 7f 65 e9 43 93 89 53 5c 9e 04 a9 3f 95 71 24 0f 0a 9b f7 ee d4 5b 1b c6 78 7a f4 36
Anyhow, I tried to implement the C code using OpenSSL des library and I find the next difficulty:
I need 3 Keys of 8 bytes each, but I have 1 SessionKey of 16 bytes
long.
I tried to split SessionKey into Key1/Key2/Key1 without success.
I have read so much about it, the only clue i found is that I have to generate those 3 keys from my 16byte SessionKey (taking it as a password) but I feel it is too advanced for me.
If this is the only way, is there any tutorial about ossl key derivation (evp_bytestokey)? Is there any other way?
Thanks
Edit:
So, right now I'm in a very weird spot. As noted by many of you, I had already taken first 8 bytes from Session Key as Key 3 (that's what I referred to with Key1/Key2/Key1). Anyway it seemed to not work, but slightly it did, which is what puzzles me.
I get:
Decrypted : 11 1B 00 30 33 AF 02 DF DE 01 00 00 00 01 01 00 14 C1 26 8F 03 20 20 41 00 30 39 01 00 00 00 00 00 00 00 00 00 00 75 B1
When
Expected : 10 1a 01 31 32 ae 03 de de 01 00 00 00 01 01 00 14 c1 26 8f 03 20 20 41 00 30 39 01 00 00 00 00 00 00 00 00 00 00 75 b1
So I get the expected result XORing first 8 bytes with 01. Does that make any sense?? As in OSSL docu it says: Note that there is both a DES_cbc_encrypt() and a DES_ncbc_encrypt() in libcrypto. I recommend you only use the ncbc version (n stands for new). See the BUGS section of the OpenSSL DES manpage and the source code for these functions.
But I have access only to older version... Could it be the problem??
Perhaps the encryption is two-key 3DES, in that case repeat the first 8-bytes , bytes 0-7 as bytes 16-23: 44 E6 30 21 4A 89 57 38 61 7A B8 7C A9 91 B2 C0 44 E6 30 21 4A 89 57 38.
Some 3DES implementations will do this automatically, some you must do it yourself.
If this does not work you will need to provide more information in the question.
Size of session key
Since you refer to MIFARE DESFire and you are using a 16 byte session key, you probably use 2-key triple DES. This means that the 16 byte session key is actually two keys (8 bytes, or actually 56 bits, each with 8 unused "parity" bits).
In order to map this to 3DES with 3 keys, you simply need to append the first 8 bytes to the end of your session key, so that you get
+-------------------------+-------------------------+
16 byte session key: | 8 bytes | 8 bytes |
| 44 E6 30 21 4A 89 57 38 | 61 7A B8 7C A9 91 B2 C0 |
+-------------------------+-------------------------+-------------------------+
24 byte 3DES key: | 8 bytes | 8 bytes | 8 bytes |
| 44 E6 30 21 4A 89 57 38 | 61 7A B8 7C A9 91 B2 C0 | 44 E6 30 21 4A 89 57 38 |
+-------------------------+-------------------------+-------------------------+
First block of decrypted plaintext
If the first 8 bytes of the decrypted plaintext differ from the expected value but the remaining bytes match, this is a clear indication that you are using an incorrect initialization vector for CBC mode.
Have a look at how CBC mode works:
So for the first block, the plaintext is calculated as
P0 = DecK(C0) XOR IV
For the remaining blocks, the plaintext is calculated as
Pn = DecK(Cn) XOR Cn-1
This means that only the decryption of the first block depends on the IV. The decryption of the remaining blocks depends on the preceding ciphertext instead.
Since you assumed the IV to be all zeros, the XOR operation does nothing. Hence, in your case, the plaintext of the first block is calculated as
P0 = DecK(C0) XOR {0} = DecK(C0) = '10 1A 01 31 32 AE 03 DE'
As this expected value deviates from the actual value that you get ('11 1B 00 30 33 AF 02 DF'). This most likely means that you used an incorrect IV for decryption:
P0 = DecK(C0) = '10 1A 01 31 32 AE 03 DE'
P'0 = DecK(C0) XOR IV = '11 1B 00 30 33 AF 02 DF'
You can calculate the IV that you used by XORing the two values:
P'0 = P0 XOR IV
P'0 XOR P0 = IV
IV = '11 1B 00 30 33 AF 02 DF' XOR '10 1A 01 31 32 AE 03 DE'
= '01 01 01 01 01 01 01 01'
As this IV differs in exactly the LSB of each byte being set to one, I wonder if you accidentally used the method DES_set_odd_parity() on the IV. This would explain why the LSB (i.e. the parity bit if the value was a DES key) was changed.
It's possible that you don't need 3 keys of 32bits, but only one of 3*32bits, with the bytes in the good order
Best regards

Desfire EV1 communication examples

There are lots of questions about Desfire EV1 cards here on Stackoverflow.
But if you search for some example data the only place where you will find a few bytes is in Ridrix Blog. But this is quite incomplete.
A lot of people wrote their problems there while developing code for Desfire cards. But mostly when they solved their problem they were too lazy to post the solution. So you find many questions but very few answers with data examples.
Even if you have the Desfire EV1 documentation (I dont have it, I studied easypay code), you will need more than that. A documentation is only theory. But what is the reason that your card returns an Authentication Error or an Integrity Error or an unexpected CMAC?
Is the Session key OK ?
Is CBC working in the correct mode ?
Is the CMAC calculated correctly ?
Is the CRC32 correct ?
Is the IV of the session key correct before / after a function call ?
Without examples you are completely lost.
After spending several weeks with Desfire EV1 development I decided to post some examples for all those who need input data to feed their complex cryprographic functions and compare the output with the expected data. I know that this is EXTREMELY helpfull.
Here you find some Debug output from the most important Desfire EV1 operations.
Currently you cannot find this information in internet.
If I would have had these examples I would have saved a LOT of time developing my code.
Pitfalls for ISO and AES authenticated sessions
In ISO and AES mode EVERY encryption/decryption goes through CBC.
The IV of the session key is reset to zero only ONCE when the key is created after authentication.
The IV of the authentication key is reset only ONCE when authentication starts.
During authentication:
Random B is received from the card with RECEIVE + DECIPHER
Random AB is sent to the card with SEND + ENCIPHER
Random A is received with RECEIVE + DECIPHER
The CMAC is a copy of the IV of the session key.
The CMAC must mostly be calculated for data sent to the card and for data returned from the card.
But all commands that do a CBC encryption (e.g. ChangeKeySettings) differ from that scheme.
Commands that send/receive multiple frames (e.g. GetApplicationIDs) must calculate the CMAC over the data of all frames that have been sent/received (not including the 0xAF status byte).
For TX data the CMAC is calculated over the command byte + all parameter bytes.
For RX data the CMAC is calculated over all response bytes + the last status byte (always 00 = Success) that must be appended at the end!
The authentication is invalidated:
when an error occures (status != 00 and != AF),
when SelectApplication is executed,
after the same key has been changed that was used for authentication,
when another card comes into the RF field (don't forget to reset your variables).
In these cases the session key is no longer valid and so a CMAC must not be calculated.
The CRC32 of the new key is calculated only over the key data itself.
The CRC32 of the cryptogram is calculated over command, key number and the not yet encrypted cryptogram.
The following debug output has been generated by my code running in a Teensy 3.2 with a PN532 board from Adafruit.
For further details see my source code.
The C++ source code has been written for Arduino/Teensy, but it has been designed multiplatform so that it can be compiled on Visual Studio, Linux or other platforms. The ZIP file also contains a Visual Studio project.
In the following examples all keys have key version 0x10.
ISO Authentication with 2K3DES default key #0
*** Authenticate(KeyNo= 0, Key= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (DES))
Sending: <1A 00>
Response: <AF B8 90 04 7F 2D C8 D6 8B>
* RndB_enc: B8 90 04 7F 2D C8 D6 8B
* RndB: 74 B8 43 5F CB A0 B6 75
* RndB_rot: B8 43 5F CB A0 B6 75 74
* RndA: 92 31 34 8B 66 35 A8 AF
* RndAB: 92 31 34 8B 66 35 A8 AF B8 43 5F CB A0 B6 75 74
* RndAB_enc: 7C 84 6A 50 7B 9B 6E 68 64 BC 33 72 A3 06 A8 C1
Sending: <AF 7C 84 6A 50 7B 9B 6E 68 64 BC 33 72 A3 06 A8 C1>
Response: <00 B7 96 DD 3F 81 15 45 F3>
* RndA_enc: B7 96 DD 3F 81 15 45 F3
* RndA_dec: 31 34 8B 66 35 A8 AF 92
* RndA_rot: 31 34 8B 66 35 A8 AF 92
* SessKey: 92 30 34 8A 74 B8 42 5E 92 30 34 8A 74 B8 42 5E (DES)
Change 2K3DES default key #0
*** ChangeKey(KeyNo= 0)
* SessKey: B4 28 2E FA 9E B8 2C AE B4 28 2E FA 9E B8 2C AE (DES)
* SessKey IV: 00 00 00 00 00 00 00 00
* New Key: 00 10 20 31 40 50 60 70 80 90 A0 B0 B0 A0 90 80 (2K3DES)
* CRC Crypto: 0x5001FFC5
* Cryptogram: 00 10 20 31 40 50 60 70 80 90 A0 B0 B0 A0 90 80 C5 FF 01 50 00 00 00 00
* CryptogrEnc: 87 99 59 11 8B D7 7C 70 10 7B CD B0 C0 9C C7 DA 82 15 04 AA 1E 36 04 9C
Sending: <C4 00 87 99 59 11 8B D7 7C 70 10 7B CD B0 C0 9C C7 DA 82 15 04 AA 1E 36 04 9C>
Response: <00>
Change 2K3DES default key #1
*** ChangeKey(KeyNo= 1)
* SessKey: 9C 70 56 82 5C 08 9E C8 9C 70 56 82 5C 08 9E C8 (DES)
* SessKey IV: 00 00 00 00 00 00 00 00
* New Key: 00 10 20 31 40 50 60 70 80 90 A0 B0 B0 A0 90 80 (2K3DES)
* Cur Key: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (DES)
* CRC Crypto: 0xD7A73486
* CRC New Key: 0xC4EF3A3A
* Cryptogram: 00 10 20 31 40 50 60 70 80 90 A0 B0 B0 A0 90 80 86 34 A7 D7 3A 3A EF C4
* CryptogrEnc: 7D 83 D3 4E FB 6C 84 98 48 E2 D6 37 AD A2 D0 87 14 36 1A E6 C4 63 14 52
Sending: <C4 01 7D 83 D3 4E FB 6C 84 98 48 E2 D6 37 AD A2 D0 87 14 36 1A E6 C4 63 14 52>
Response: <00 1D 5C 27 97 10 86 30 8D>
CMAC: 1D 5C 27 97 10 86 30 8D
ISO Authentication with 3K3DES default key #0
*** Authenticate(KeyNo= 0, Key= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (3K3DES))
Sending: <1A 00>
Response: <AF 14 65 76 AC 1B 7D B8 CA 24 84 C5 69 7F 80 12 E1>
* RndB_enc: 14 65 76 AC 1B 7D B8 CA 24 84 C5 69 7F 80 12 E1
* RndB: BA 91 37 BB 7A 18 33 E7 39 F0 5E 8F 07 87 D0 C4
* RndB_rot: 91 37 BB 7A 18 33 E7 39 F0 5E 8F 07 87 D0 C4 BA
* RndA: F5 68 6F 3A 39 1C D3 8E BD 10 77 22 81 44 5B F6
* RndAB: F5 68 6F 3A 39 1C D3 8E BD 10 77 22 81 44 5B F6 91 37 BB 7A 18 33 E7 39 F0 5E 8F 07 87 D0 C4 BA
* RndAB_enc: D0 55 BD 5E A0 1E BF C3 02 93 D4 8A 54 A0 51 B4 0A 66 57 7A 38 3C 58 ED 77 5C 51 BC 97 D4 FA BD
Sending: <AF D0 55 BD 5E A0 1E BF C3 02 93 D4 8A 54 A0 51 B4 0A 66 57 7A 38 3C 58 ED 77 5C 51 BC 97 D4 FA BD>
Response: <00 E1 EE 93 F0 12 C8 D6 72 11 D4 33 7C AD 56 6A 40>
* RndA_enc: E1 EE 93 F0 12 C8 D6 72 11 D4 33 7C AD 56 6A 40
* RndA_dec: 68 6F 3A 39 1C D3 8E BD 10 77 22 81 44 5B F6 F5
* RndA_rot: 68 6F 3A 39 1C D3 8E BD 10 77 22 81 44 5B F6 F5
* SessKey: F4 68 6E 3A BA 90 36 BA D2 8E BC 10 32 E6 38 F0 80 44 5A F6 06 86 D0 C4 (3K3DES)
Change 3K3DES default key #0
*** ChangeKey(KeyNo= 0)
* SessKey: F4 68 6E 3A BA 90 36 BA D2 8E BC 10 32 E6 38 F0 80 44 5A F6 06 86 D0 C4 (3K3DES)
* SessKey IV: 00 00 00 00 00 00 00 00
* New Key: 00 10 20 31 40 50 60 70 80 90 A0 B0 B0 A0 90 80 70 60 50 40 30 20 10 00 (3K3DES)
* CRC Crypto: 0xA2003ED6
* Cryptogram: 00 10 20 31 40 50 60 70 80 90 A0 B0 B0 A0 90 80 70 60 50 40 30 20 10 00 D6 3E 00 A2 00 00 00 00
* CryptogrEnc: 7F 88 90 C7 CA B9 A4 22 81 73 A6 41 B6 5F 0F 43 FD 40 4A 01 13 71 A9 90 4A 62 9E 3C 20 B2 FF 63
Sending: <C4 00 7F 88 90 C7 CA B9 A4 22 81 73 A6 41 B6 5F 0F 43 FD 40 4A 01 13 71 A9 90 4A 62 9E 3C 20 B2 FF 63>
Response: <00>
Change 3K3DES default key #1
*** ChangeKey(KeyNo= 1)
* SessKey: 9C 52 0E 3C B4 5A B2 A4 A2 00 C4 DA 72 2C 0E F4 38 FE 8A 48 F8 18 9E 56 (3K3DES)
* SessKey IV: 00 00 00 00 00 00 00 00
* New Key: 00 10 20 31 40 50 60 70 80 90 A0 B0 B0 A0 90 80 70 60 50 40 30 20 10 00 (3K3DES)
* Cur Key: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (3K3DES)
* CRC Crypto: 0x078BAED8
* CRC New Key: 0x12A6733E
* Cryptogram: 00 10 20 31 40 50 60 70 80 90 A0 B0 B0 A0 90 80 70 60 50 40 30 20 10 00 D8 AE 8B 07 3E 73 A6 12
* CryptogrEnc: 72 18 2F 5B 0C F1 7E A0 86 A5 AE A5 64 ED 98 7A F3 90 CD B3 78 36 4E 2B C2 45 8B 3A E3 23 98 4D
Sending: <C4 01 72 18 2F 5B 0C F1 7E A0 86 A5 AE A5 64 ED 98 7A F3 90 CD B3 78 36 4E 2B C2 45 8B 3A E3 23 98 4D>
Response: <00 D2 E3 BD 0D 09 47 72 ED>
CMAC: D2 E3 BD 0D 09 47 72 ED
AES Authentication with AES default key #0
*** Authenticate(KeyNo= 0, Key= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (AES))
Sending: <AA 00>
Response: <AF FF 0A FB 10 B4 3F 3B 34 23 36 57 0F 7A 0E 8B 74>
* RndB_enc: FF 0A FB 10 B4 3F 3B 34 23 36 57 0F 7A 0E 8B 74
* RndB: 1F 45 19 27 E7 C0 FC DE 60 9E E8 02 EF 69 76 04
* RndB_rot: 45 19 27 E7 C0 FC DE 60 9E E8 02 EF 69 76 04 1F
* RndA: 73 AE 5D 30 17 42 21 64 FB 16 25 D8 1F 2A 69 8C
* RndAB: 73 AE 5D 30 17 42 21 64 FB 16 25 D8 1F 2A 69 8C 45 19 27 E7 C0 FC DE 60 9E E8 02 EF 69 76 04 1F
* RndAB_enc: B3 11 34 03 F5 73 95 35 CA 1A 5D 4B D4 38 BE 03 2B 54 28 32 3D 0A 83 4D 11 8F 35 06 C4 2C 5B 01
Sending: <AF B3 11 34 03 F5 73 95 35 CA 1A 5D 4B D4 38 BE 03 2B 54 28 32 3D 0A 83 4D 11 8F 35 06 C4 2C 5B 01>
Response: <00 E2 AE 7D 31 29 48 19 69 E9 A0 C7 CC 89 1E DF 58>
* RndA_enc: E2 AE 7D 31 29 48 19 69 E9 A0 C7 CC 89 1E DF 58
* RndA_dec: AE 5D 30 17 42 21 64 FB 16 25 D8 1F 2A 69 8C 73
* RndA_rot: AE 5D 30 17 42 21 64 FB 16 25 D8 1F 2A 69 8C 73
* SessKey: 73 AE 5D 30 1F 45 19 27 1F 2A 69 8C EF 69 76 04 (AES)
Change AES default key #0
*** ChangeKey(KeyNo= 0)
* SessKey: 73 AE 5D 30 1F 45 19 27 1F 2A 69 8C EF 69 76 04 (AES)
* SessKey IV: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
* New Key: 00 10 20 30 40 50 60 70 80 90 A0 B0 B0 A0 90 80 (AES)
* CRC Crypto: 0x6BE6C6D2
* Cryptogram: 00 10 20 30 40 50 60 70 80 90 A0 B0 B0 A0 90 80 10 D2 C6 E6 6B 00 00 00 00 00 00 00 00 00 00 00
* CryptogrEnc: 97 41 8E 6C C0 1C 4E 6F AD 4D 87 4D 8D 42 5C EA 32 51 36 11 47 2C DA 04 E3 5E FB 77 9A 7D A0 E4
Sending: <C4 00 97 41 8E 6C C0 1C 4E 6F AD 4D 87 4D 8D 42 5C EA 32 51 36 11 47 2C DA 04 E3 5E FB 77 9A 7D A0 E4>
Response: <00>
Change AES default key #1
*** ChangeKey(KeyNo= 1)
* SessKey: 1C D3 8E BD 95 F3 1C 8A B8 7F 0A C9 C4 EB 64 C6 (AES)
* SessKey IV: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
* New Key: 00 10 20 30 40 50 60 70 80 90 A0 B0 B0 A0 90 80 (AES)
* Cur Key: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (AES)
* CRC Crypto: 0x84B47033
* CRC New Key: 0x1979E3BF
* Cryptogram: 00 10 20 30 40 50 60 70 80 90 A0 B0 B0 A0 90 80 10 33 70 B4 84 BF E3 79 19 00 00 00 00 00 00 00
* CryptogrEnc: 30 23 FA 06 2D 25 0A 04 35 BA E9 45 CA BE 96 5D 62 2A 47 1D 32 5D 1D 42 EA 81 44 41 CB 1A 20 C3
Sending: <C4 01 30 23 FA 06 2D 25 0A 04 35 BA E9 45 CA BE 96 5D 62 2A 47 1D 32 5D 1D 42 EA 81 44 41 CB 1A 20 C3>
Response: <00 9B 68 30 91 50 E0 72 5E>
CMAC: 9B 68 30 91 50 E0 72 5E
CMAC Calculation for AES 128
From: NIST
AES Key: 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
SubKey1: fb ee d6 18 35 71 33 66 7c 85 e0 8f 72 36 a8 de
SubKey2: f7 dd ac 30 6a e2 66 cc f9 0b c1 1e e4 6d 51 3b
Message: <empty>
CMAC: bb 1d 69 29 e9 59 37 28 7f a3 7d 12 9b 75 67 46
Message: 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
CMAC: 07 0a 16 b4 6b 4d 41 44 f7 9b dd 9d d0 4a 28 7c
Message: 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51 30 c8 1c 46 a3 5c e4 11
CMAC: df a6 67 47 de 9a e6 30 30 ca 32 61 14 97 c8 27
If you need more examples (also for CreateApplication, SelectApplication, DeleteApplication, GetApplicationIDs, GetKeyVersion, GetKeySettings, ChangeKeySettings, GetCardVersion, FormatCard, CreateStdDataFile, GetFileIDs, GetFileSettings, WriteFileData, ReadFileData, DeleteFile) download the ZIP file on Codeproject where you find a HTML file with the entire selftest that tests all these commands.

Float to hex conversion - reverse engineering

I'm trying to do some reverse engineering on my heating system. Monitoring the CAN BUS results in receiving hexademical strings, for example:
00 D0 68 D6 86 83 61 8F
61 C0 02 5C 12 B5 02 5C
12 78 04 39 04 03 05 02
05 C4 04 5C 12 5C 12 5C
12 5C 12 D0 68 00 00 00
00 18 08 37 D2 00 00 00
00 00 00 00 00 15 75 F2
F0 01 00 01 00 00 00 1F
I know that for example the temperature value of 22.5°C should be somewhere in there.
So far I have tried to look for the following conversions:
Possibility 1: ascii to hex
22.5 = 32 32 2E 35
Possibility 2: float to hex conversion
22.5 = 0x 41 b4 00 00
However none of these resulted in a match.
What would be other possibilities to converted a float to a hex string?
Thx
note: the given string is just a small part of my can sniffer so don't look for 22.5 in my given string here. I'm just looking for other possible conversions.

Resources