I have 2 different 3DES (ede) keys (meaning double length). I encrypted an 8-byte block using the keys and got the same output. Is this okay? Or is it rare? Is this even possible?
One thing I observed was key1 xor 0101....01 = key2. Can this be the reason. Is it like, for all such pairs of keys, 3DES works same? Also, are there any other such blocks (like 0101...01) which have the same effect?
example:
data: a21156bcdd00018a
key1: ff41777b3372b7817872b4b212f0c942
cipher text: 76 4f ab e0 2a e0 9b 11
key2: FE40767A3273B6807973B5B313F1C843
cipher text: 76 4f ab e0 2a e0 9b 11
and when data: 0000000000000000
ciphertext 1 = ciphertext 1 = 7adfa8ccbb7b3d29
basically, giving all same output.
Does this have to do something with 3DES algo?
Take a look at your keys in binary:
FF/FE 41/40 77/76 7B/7A 33/32 72/73 B7/B6 81/80
Key1 bit 0-63: 11111111 01000001 01110111 01111011 00110011 01110010 10110111 10000001
Key2 bit 0-63: 11111110 01000000 01110110 01111010 00110010 01110011 10110110 10000000
78/79 72/73 B4/B5 B2/B3 12/13 F0/F1 C9/C8 42/43
Key1 bit 64-127: 01111000 01110010 10110100 10110010 00010010 11110000 11001001 01000010
Key2 bit 64-127: 01111001 01110011 10110101 10110011 00010011 11110001 11001000 01000011
You might notice that they only differ on the last bit of each byte. This is a parity bit that ain't used by DES during encryption. From DES's point of view they are the same key.
Related
Let's assume that I have 512-byte packets plus a 16-bit CRC at the end. I would like to determine what the CRC parameters are.
It's a Fujitsu chip, where I'm writing the the flash with a programmer, the programmer calculates the CRC for me, and I read out the CRC with an oscilloscope. I have the ability to check every possible combination.
My test messages are 512 zeros except for one byte that I set to the values 0 to 17 in decimal. The one byte is one of the first four or last two in the packet. Here are the resulting CRCs in hexadecimal, where the rows are the value of the byte, and the columns are which byte is set:
00 01 02 03 510 511
00 00 00 00 00 00 00
01 0x8108 0x0100 0x3020 0xC6B0 0xF1F0 0x8108
02 0x8318 0x0200 0x6040 0x0C68 0x62E8 0x8318
03 0x0210 0x0300 0x5060 0xCAD8 0x9318 0x0210
04 0x8738 0x0400 0xC080 0x18D0 0xC5D0 0x8738
05 0x0630 0x0500 0xF0A0 0xDE60 0x3420 0x0630
06 0x0420 0x0600 0xA0C0 0x14B8 0xA738 0x0420
07 0x8528 0x0700 0x90E0 0xD208 0x56C8 0x8528
08 0x8F78 0x0800 0x0008 0x31A0 0x0AA8 0x8F78
09 0x0E70 0x0900 0x3028 0xF710 0xFB58 0x0E70
10 0x0C60 0x0A00 0x6048 0x3DC8 0x6840 0x0C60
11 0x8D68 0x0B00 0x5068 0xFB78 0x99B0 0x8D68
12 0x0840 0x0C00 0xC088 0x2970 0xCF78 0x0840
13 0x8948 0x0D00 0xF0A8 0xEFC0 0x3E88 0x8948
14 0x8B58 0x0E00 0xA0C8 0x2518 0xAD90 0x8B58
15 0x0A50 0x0F00 0x90E8 0xE3A8 0x5C60 0x0A50
16 0x9FF8 0x1000 0x0010 0x6340 0x1550 0x9FF8
17 0x1EF0 0x1100 0x3030 0xA5F0 0xE4A0 0x1EF0
As you can see the first and last bytes give the same value. I tried several variations of CRC-16, but without much luck. The closet one was CRC-16 with polynomial 0x1021 and initial value 0.
The fact that every single CRC ends in 0 or 8 strongly suggests that it is not a 16-bit CRC, but rather a 13-bit CRC. Indeed, all of the sequences check against a 13-bit CRC with polynomial 0x1021 not reflected, initial value zero, and final exclusive-or zero.
We can't be sure about the initial value and final exclusive-or unless you can provide at least one packet with a length other than 512. With only examples of a single length, there are 8,191 other combinations of initial values and final exclusive-ors that would produce the exact same CRCs.
I'm trying to understand the algorithm used for compression value = 1 with the Epson ESCP2 print command, "ESC-i". I have a hex dump of a raw print file which looks, in part, like the hexdump below (note little-endian format issues).
000006a 1b ( U 05 00 08 08 08 40 0b
units; (page1=08), (vt1=08), (hz1=08), (base2=40 0b=0xb40=2880)
...
00000c0 691b 0112 6802 0101 de00
esc i 12 01 02 68 01 01 00
print color1, compress1, bits1, bytes2, lines2, data...
color1 = 0x12 = 18 = light cyan
compress1 = 1
bits1 (bits/pixel) = 0x2 = 2
bytes2 is ??? = 0x0168 = 360
lines2 is # lines to print = 0x0001 = 1
00000c9 de 1200 9a05 6959
00000d0 5999 a565 5999 6566 5996 9695 655a fd56
00000e0 1f66 9a59 6656 6566 5996 9665 9659 6666
00000f0 6559 9999 9565 6695 9965 a665 6666 6969
0000100 5566 95fe 9919 6596 5996 5696 9666 665a
0000110 5956 6669 0456 1044 0041 4110 0040 8140
0000120 9000 0d00
1b0c 1b40 5228 0008 5200 4d45
FF esc # esc ( R 00 REMOTE1
The difficulty I'm having is how to decode the data, starting at 00000c9, given 2 bits/pixel and the count of 360. It's my understanding this is some form of tiff or rle encoding, but I can't decode it in a way that makes sense. The output was produced by gutenprint plugin for GIMP.
Any help would be much appreciated.
The byte count is not a count of the bytes in the input stream; it is a count of the bytes in the input stream as expanded to an uncompressed form. So when expanded, there should be a total of 360 bytes. The input bytes are interpreted as either a count of bytes to follow, if positive, in which case the count is the byte value +1; and if negative the count is a count of the number of times the immediately following byte should be expanded, again, +1. The 0D at the end is a terminating carriage return for the line as a whole.
The input stream is only considered as a string of whole bytes, despite the fact that the individual pixel/nozzle controls are only 2 bits each. So it is not really possible to use a repeat count for something like a 3-nozzle sequence; a repeat count must always specify a full byte 4-nozzle combination.
The above example then specifies:
0xde00 => repeat 0x00 35 times
0x12 => use the next 19 bytes as is
0xfd66 => repeat 0x66 4 times
0x1f => use the next 32 bytes as is
etc.
I read that AES 128 CTR mode should work on blocks of 16 bytes (128bit), like CBC mode.
indeed, if I try with openssl to encode 18 bytes plaintext with :
max#jarvis:~$ printf 0123456789abcdefgh | openssl enc -e -nopad -nosalt -aes-128-cbc -K 00000000000000000000000000000000 -iv 00000000000000000000000000000000 | hd
bad decrypt
140670739715200:error:0607F08A:digital envelope routines:EVP_EncryptFinal_ex:data not multiple of block length:../crypto/evp/evp_enc.c:425:
00000000 14 f5 fe 74 69 66 f2 92 65 1c 22 88 bb ff 46 09 |...tif..e."...F.|
00000010
max#jarvis:~$ printf 0123456789abcdefgh | openssl enc -e -nosalt -aes-128-cbc -K 00000000000000000000000000000000 -iv 00000000000000000000000000000000 | hd
00000000 14 f5 fe 74 69 66 f2 92 65 1c 22 88 bb ff 46 09 |...tif..e."...F.|
00000010 c2 ae b2 99 18 cd 6e ee 55 92 77 d9 e8 f3 1f bf |......n.U.w.....|
00000020
the ciphertext is 16 or 32 bytes, depending on the presence of -nopad parameter.
but if I try CTR:
max#jarvis:~$ printf 0123456789abcdefgh | openssl enc -e -nopad -nosalt -aes-128-ctr -K 00000000000000000000000000000000 -iv 00000000000000000000000000000000 | hd
00000000 56 d8 79 e7 db bf 1a 0c b0 75 9b 3b a9 50 4e 48 |V.y......u.;.PNH|
00000010 3f 8a |?.|
00000012
max#jarvis:~$ printf 0123456789abcdefgh | openssl enc -e -nosalt -aes-128-ctr -K 00000000000000000000000000000000 -iv 00000000000000000000000000000000 | hd
00000000 56 d8 79 e7 db bf 1a 0c b0 75 9b 3b a9 50 4e 48 |V.y......u.;.PNH|
00000010 3f 8a |?.|
00000012
the ciphertext is 18 bytes, like plaintext, in each case.
I cannot figure out why
CTR mode makes a block cipher (like AES) behave as a stream cipher. The results you are getting are expected - the size of the input data will equal the size of the output data.
CBC operates block by block, which is what mandates a padding scheme. CTR passes blocks of a counter value to AES, still honoring the block size, but then takes the output block and XORs it with the plaintext.
In your case above, two full 128-bit blocks will have been passed through AES to produce the key stream, but only 128 + 16 bits (18 bytes) of that key stream are used and XORed with your plaintext, producing a ciphertext of equal length.
AES 128 CTR is very much NOT like AES 128 CBC, and the wikipedia page you linked to makes it very clear. Note how the cleartext is injected into the encryption block in the CBC mode, but never passes through the encryption block in the CTR mode.
CTR encryption is done by taking a nonce, a block counter (CTR!), and the key, and encrypting them to make a very-hard-to-guess block of pseudorandom data, called the keystream. The keystream is XOR-ed with the cleartext, to obtain ciphertext. The XOR is done byte-wise, so you can truncate the keystream to match the length of the cleartext. Notice that the cleartext is never subject itself to AES block cipher encryption. The block cipher is used as a one-way function to generate pseudorandom keystream. CTR can be used with a variety of keystream sources, not only with the AES encryption block.
CBC is started, for the first block, by taking the cleartext xor-ed with a random initialization vector (IV), and then actually passing it through the AES block cipher encryption. The ciphertext from the preceding block is used as the new IV for the successor block, i.e. IV is never reused.
I'm trying to discover devices, from a coordinator, in my network.
So I sent an ND command to the coordinator and I'm correctly receiving response from other Xbee.
The next step will be to store the information I've received in a web application, in oder to send commands and data.
However, what I'm still missing is some parts in the frame respose. So far I've mapped the frame like this:
1 7E start frame
===== =================== MESSAGE LENGHT
2-3 0x00 0x19 -> 25
===== =================== PACKET TYPE
4 88 -> response to a remote AT command
5 02 frame ID
===== =================== AT COMMAND
6-7 0x4E 0x44 "ND"
8 00 status byte (00 -> OK)
===== =================== MY - Remote Address
9-10 0x17 0x85
===== =================== SH - SERIAL NUMBER HIGH
11-14 0x00 0x13 0xA2 0x00
===== =================== SL - SERIAL NUMBER LOW
15-18 0x40 0xB4 0x50 0x23
===== =================== SIGNAL
19 20
= ======== NI - Node Identifier
20 00
21 FF
22 FE
23 01
24 00
25 C1
26 05
27 10
28 1E
===== ===== CHECKSUM (25th bytes from MESSAGE LENGHT)
29 19
So, where I can find in this response the address of the device ?
My guess is in the NI part of the message but, I haven't find any example/information of how the data are organised.
Could someone point me in the right direction?
As someone told me in the dig.com forum
NI<CR> (Variable length)
PARENT_NETWORK ADDRESS (2 Bytes)<CR>
DEVICE_TYPE (1 Byte: 0=Coord, 1=Router, 2=End Device)
STATUS (1 Byte: Reserved)
PROFILE_ID (2 Bytes)
MANUFACTURER_ID (2 Bytes
So, loking to my frame response:
00 --- Node Identifier variable, (here 1 byte = 00 because no value is set up).
FFFE --- parent network address (2 bytes)
01 --- device type
00 --- status
C105 --- profile id
101E --- manufacturing id
This, afaik, means that in this last part of the frame, no information about address of the device are given. Only information are the SL and SH.
The 16-bit network address is what you've labeled "MY" (0x1785), and the 64-bit MAC address is the combination of SH/SL (00 13 A2 00 40 B4 50 23).
I am just beginner to ISO 8583 messaging format.
So, i already search information about that at WIKI and Code Project
So as i understand about that is..
this message we can divide 3 parts ...
1.MTI (Message Type Indicator)
1.1.Version
1.2.Message Class
1.3.Message Function
1.4.Message Origin
2.Bitmap
Indicate which data elements are present.
3.DataElement
The essence of the whole ISO message, contain information about the transaction such as ...
transaction type,
amount,
customerid
and so on.
So, After i reading these two web references, I want to make divide my ISO messaging log as MTI, bitmap, and Data Element.
For example.
(0800 2020000000800000 000000 000001 3239313130303031)
MTI: 0800 (1987 version, Network Management Message, Request, Acquirer)
Bitmap: 20 20 00 00 00 80 00 00 (eg. 20 = 0010 0000 ,so position 3 is on)
DataElement:(by seeing Bitmap , we can defined data element as follow)
field 03:000000 (Processing Code)
field 11:000001 (Systems trace audit number)
field 41:3239313130303031 (Card acceptor terminal idenfication)
But my problem is, I already have ISO 8583 messaging log from my ATM Machine.
This actual output messaging log is not very clear like this upper example.
So I cannot divide this message to MTI, Bitmap and Data element like upper example.
Here are my Example of data
00 14 5e 47 2e d8 00 1a d4 0c 32 0f 08 00 45 00
00 7b b2 ec 40 00 80 06 e5 29 ac 11 05 37 ac 11
05 0d 1a 78 1a 78 bf 1c 66 c8 8f 11 b5 a9 50 18
3f b6 c8 f6 00 00 00 51 31 31 1c 30 30 32 1c 1c
1c 31 3b 1c 3b 35 32 36 34 30 32 31 37 30 33 32
36 34 30 32 34 3d 31 34 30 35 32 32 31 31 30 30
What you have there as a sample is just the representation of the transaction info as it's transmitted over the wire. This is effectively the way all data transmission looks like at the transport layer, regardless of application.
Depending on the terminal management application/switch you're using (Postilion and Base24 are good examples), there should be a translation of that hex payload into ASCII text somewhere in your logs.
For the sample you have, you should first convert it to binary and then convert the binary result to ASCII. Using those steps, I can tell you the Institution Identifier Number (or Bank Identifier Number) in that sample is 526402. The snippet you've posted contains the Track 2 data, which also has the PAN in it. I'm not posting that here for obvious reasons (I'm not even going to apply the masking to it)
The hexadecimal dump for sure is not ISO 8583 dialect message. There are lot Field Separators with Hex code 0x1C.
The bytes at the beginning of your example looks like several layers of different packets. I do not pretend to correct decryption, but it might be Mobile IP packet inside IP packet inside TCP packet.
The last, most important part for your investigations - is the part of NDC Message - the Network message protocol from NCR for ATMs.
TCP - RFC 793
00 14 5e 47 2e d8 00 1a d4 0c 32 0f 08 00 45 00
00 7b b2 ec __ __ __ __ __ __ __ __ __ __ __ __
source_port: "0014" # // 20
destination_port: "5E47" # // 24135
sequence: "2ED8001A" # // 785907738
acknowledgment: "D40C320F" # // 3557569039
offset: "00" # [xxxx____]
bits: "00" # Control Bits
window: "4500" # // 17664
crc: "007B"
urgency: "B2EC" # // 45804
IP - RFC 791
__ __ __ __ __ __ 40 00 80 06 e5 29 ac 11 05 37 ac 11
05 0d 1a 78 1a 78 bf 1c __ __ __ __ __ __ __ __ __ __
b1:
version: "4"
IHL: "0" # Internet Header Length (in DWORDs)
type: # Type of Service
precedence: "00"
# 000_____ - Routine
delay: "00"
# ___0____ - Normal Delay
throughput: "00"
# ____0___ - Normal Throughput
relibility: "00"
# _____0__ - Normal Relibility
size: "8006" # // 32774
identifier: "E529"
fragment:
flags: "AC11"
# _0______________ - May Fragment
# __1_____________ - More Fragments
offset: "0C11" # [___xxxxxxxxxxxxx] // 3089
ttl: "05" # // 5
protocol: "37" # // 55 - MOBILE
crc: "AC11"
source_ip: "050D1A78" # // 5.13.26.120
destination_ip: "1A78BF1C" # // 26.120.191.28
Mobile IP (?) - RFC 3344
__ __ __ __ __ __ __ __ 66 c8 8f 11 b5 a9 50 18
3f b6 c8 f6 __ __ __ __ __ __ __ __ __ __ __ __
protocol: "66" # // 102 - PNNI
code: "C8" # // 200
crc: "8F11"
destination_ip: "B5A95018" # Home address // 181.169.80.24
source_ip: "3FB6C8F6" # Original sender // 63.182.200.246
Plus not identified part or already header from NDC message:
__ __ __ __ 00 00 00 51 __ __ __ __ __ __ __ __
NDC Transaction Request Message (beginning)
__ __ __ __ __ __ __ __ 31 31 1c 30 30 32 1c 1c
1c 31 3b 1c 3b 35 32 36 34 30 32 31 37 30 33 32
36 34 30 32 34 3d 31 34 30 35 32 32 31 31 30 30
a: "" # Protocol Header // skipped
b: "1" # Message Class
c: "1" # Message Sub-Class
FS: 0x1c
d: "002" # Logical Unit Number (LUNO)
FS: 0x1c
FS: 0x1c
e: // empty ?
FS: 0x1c
f: "1" # Top of Receipt Transaction Flag
g: ";" # Message Co-Ordination Number // 0x3b
FS: 0x1c
h: ";526402******4024=1405221100" # Track 2 Data // masked and expired
The rest part of NDC message in the next network packet / fragment.
#user3223324 I agree with #kolossus on many of his points including someones personal info appears in your trace. I can only hope it is a true test card.
This looks like a packet sniffer trace such as from Wireshark and not trace off of the terminal. Most ATM manufacturers have a trace mechanism right on the terminal itself that can be activated to capture Terminal to Host message and vice-versa but on newer machines requires escalated privilege or something in the possession of the field technician to activate with masking disabled. The host systems all also have a trace functionality that will at least turn it to text usually also accompanied by the hex for comparison. I believe Wireshark also has some basic HEX to Text conversion tools built into it.
The other problem I see you possibly encountering is that you are trying to decode something that you think is ISO-8583 but it is not. I know there are ISO-8583 ATMs out there, but they are few and far between as I believe most still run IFX, NDC, 911/912 or one of the other vendor specific formats or an emulation of them. Those are much shorter payload messages and there is little to no commonality between them and / or ISO-8583.
On variants of ISO-8583, there are many many variants that share the same primary, secondary, and some tertiary bitmaps. The specification itself allows for a lot of flexibility and customization and definition within certain criteria for many of the bitmaps, and then even the standard ones can have unique differences in the values they contain.
Most I see today are still a variant of ISO-8583-87 (Deluxe's is baseline of many) or a hybrid primarily supporting 01xx, 02xx, 04xx, and 08xx messages. I wouldn't get hung up on the first position too much as other than internally within applications (i.e. Postilion & Base24) it is almost always 0. Some are all text, some BCD with packed bitmaps, some text bitmaps with packed numerics.
The other thing you are going to have to account for is data element ByteMaps and now TLV as well.
So long answer, but we would need to know the format you are trying to parse or at least the make of the ATM.
To reverse a hex dump to a message can be very error prone.
ISO8583 protocol implementation varies based on the data it carries and the format of the individual fields. The field data can be BCD, ASCII etc and it may be fixed data or variable data that has a length indicator preceding the data to enable parsing.
If I look at your message closely, I see a lot of 0x1C's in it. These are generally field separators and it leads me to believe the message is a raw atm message in the atms specification and is not a traditional ISO8583 message.