# Calculating 3DES Key Check Value (KCV)

I am trying to verify a Triple DES Key Component generated by PC Crypto. The key portion is:

E6F1081FEA4C402CC192B65DE367EC3E


and the KCV value that should be returned is:

212CF915


In theory, it should be calculated as: encryption of binary 0's with the key portion with 3DES.

I have been trying the following link, but the calculation doesn't work. http://tripledes.online-domain-tools.com/

I used the following parametrization on the online tool.

Could anyone confirm that the calculation is performed as I mentioned?

• Could you provide more details on what options did you select on that online tool? Did you use Hex, rather than Plaintext? – tum_ Jun 29 '16 at 17:29
• hello, I used the following: (updated in the post) – neif Jun 29 '16 at 18:10
• I don't know what's wrong but a few comments: 1/ your KVC is 4 bytes hex, while the result of 3des encryption is 8 bytes, so your theory of how KVC is calculated is at least not complete (maybe it's simply wrong?); 2/ You key is 16 bytes, which represents a specific usage of 3des where 1st key (first 8 bytes) is used on 1st stage, 2nd 8 bytes on 2nd stage, then 1st key used again on the 3rd stage (you can read in detail on wiki). I'm not sure how this tool behaves if you select 3des and supply a 16 byte key rather than a "full" 24 byte one. – tum_ Jun 29 '16 at 18:41
• 3/ and the input to 3des is 8 bytes (16 hex digits), looks like you provided 32 hex zeroes? However, in ECB mode this makes no difference - the result should be in the 1st 8 bytes of the 'encrypted text'. Well, both halves would be the same, which is exactly the case on your screenshot... – tum_ Jun 29 '16 at 18:47
• See, the link is to KCV and you were asking about KVC :) Just kidding. In wiki you can find all sorts of false info; it says "normally consists of" implying that there might be other methods, I'd rather search for precise info on KCV in PC Crypto (no idea what this is, never used). Why KCV is 4 bytes if 3des encryption of a "zero block" yields 8? In other words - there is a mistake somewhere, you need to nail it down. Try a different online tool, check if the result is the same.. Try performing 3des as 3 single des operations one by one - wiki should give you the exact algorithm - it's easy. – tum_ Jun 29 '16 at 19:22

Three problems here:

1. The online tool used expects a 24-byte (48 hex-character) key; thus you should enter E6F1081FEA4C402CC192B65DE367EC3EE6F1081FEA4C402C as the key, duplicating the first 8 bytes; this is the customary way to extend a two-block triple DES key of 16 bytes to a three-block triple DES key of 24 bytes.

2. You gave 16 bytes (32 hex chars) as input, which is twice as many bytes as required; this doesn't affect the computation of the KCV though.

3. The KCV value is supposed to be the first 3 bytes (6 hex chars) of the result, not 4 bytes (8 hex chars).

When this is fixed, the KCV 212cf9 is correctly obtained using the tool.

Note: it is a bad idea to use an online tool in order to check a real key, just like it is a bad idea to use an online RNG to generate a real key.

• the idea was not to use the online service "in production", it was just to validate that script was valid :) – neif Nov 28 '16 at 12:19

I just put together a tiny python (python 3) example that calculates the KCV that PC Crypto is issuing (first 4 bytes of the encryption of binary 0's with the key portion). I can confirm that the execution worked. The script is based on the official IBM documentation (I had access to the official repository although I wasn't able to find the docs online to reference them).

import binascii
import hashlib
import base64
from pyDes import *

data = '000000000000000000000000000000'
key = 'E6F1081FEA4C402CC192B65DE367EC3E'

key = binascii.unhexlify(key)
data= binascii.unhexlify(data)

print('key: ' + str(key))

d = k.encrypt(data)

print('KCV: ' + str(binascii.hexlify(d)[0:8]))

• I'm assuming that the fact that you wrote an answer means the problem is solved, although to be honest I don't understand both the answer and what the root of the problem was in the first place :) "Not 8, but 4 bytes ... The KCV is the first six digits..." - is beyond me and it's my time to sleep, anyway... – tum_ Jun 29 '16 at 21:07
• Hello, it is solved. I am actually investigating how and why the process is built like this, but that is a decision of the vendor... – neif Jun 30 '16 at 16:31

Key: E6F1081FEA4C402CC192B65DE367EC3E Algorithm: 3DES ECB Crypto operation: Decoding Data: 212CF915 Padding Method: None

Decoded data: EBB7EC7B4CC5C804 DES operations count: 3

[2016-10-12 12:58:39] DEA Keys: Key parity enforcement finished

Key: E6F1081FEA4C402CC192B65DE367EC3E Key length: 32 Parity enforced: Even New key: E7F0091EEB4D412DC093B75CE266ED3F KCV: 212CF9

Key: E6F1081FEA4C402CC192B65DE367EC3E Algorithm: 3DES ECB Crypto operation: Encryption Data: 212CF9 Padding Method: Zeros

Encrypted data: 13894FA653595256 DES operations count: 3

[2016-10-12 13:02:09] DES/3DES operation finished

Key: E6F1081FEA4C402CC192B65DE367EC3E Algorithm: 3DES ECB Crypto operation: Encryption Data: 212CF9 Padding Method: None

Encrypted data: 4242424242420000 DES operations count: 0