PVV Calacualtion

Jul 13, 2011 at 10:28 PM


 I am trying to calculate the PVV for the Card 599999789012341 and PIN 1234 PVKI=1 and PVK pairs are 4CA2161637D0133E and 5E151AEA45DA2A12.

Your software is given 5170, however if you look into the website http://www.m-sinergi.com/hairi/doc.html which post a similar Java based program is gives 0798!!

Are they many algorithms to calculate the PVV? Do I have to enter the PVV encrypted in your software.




Jul 14, 2011 at 8:16 AM

I think that there's a mistake in the implementation of the Java based program. The reason I'm saying that is that if you use a card number of 59999978901234111 with the EFT calculator (the rest of the data remain the same) you get a PVV of 0798.

Here's what happens. When creating the PVV, you create a 16-hex string from the PAN the PVKI and the PIN. In order to do that, you start with the 12 right-most characters of the card excluding the check digit. For your PAN, that is equal to 999978901234. Next you take the leftmost 11 digits of this, append the PVKI and the PIN and you get the 16-hex block. For your data, that is equal to 9999789012311234. You then 3DES encrypt this with the PVKs. The result for your data is 517EF00CDEEDE498, so the PVV is equal to 5170.

What the Java based program did is got the rightmost 11 digits, including the check digit, and proceeded from there thus creating a 16-hex block of 9978901234111234 which, when encrypted, returns 07AFC9BF82CC172E.

I believe that EFT calculator implements the PVV algorithm correctly.

Jul 14, 2011 at 9:56 AM

Thank you very much for clear explination.

Jul 24, 2011 at 4:38 AM
Edited Jul 24, 2011 at 5:19 AM



I specifically stated on my java based program GUI, on PVV creation, that you need to know which part of PAN to use, because I didn't do any PAN parsing/filtering in that section.

So, know there wasn't a misimplementation on my part, just read the menus more carefully.

Other then that, what nickntg said is correct.


Edit, Hey on my example you need to enter 5999997890123412, you missed the two there amr_salah




Jan 7, 2012 at 1:30 PM


just to know, can u explain how calculate cvk pair in cvv sector


Jan 9, 2012 at 9:33 AM

You can check out the GenerateCVV method of the source code.

Mar 13, 2012 at 12:13 PM

Hi guys,

im a little confused with the pvk pair. how do i calculate the pvkpair for the visa pvv section?


Mar 13, 2012 at 2:35 PM

It's the other way around, basically. You need the PVK pair in order to calculate the PVV.

Mar 13, 2012 at 2:37 PM
Edited Mar 13, 2012 at 2:41 PM

so there is no way to find out?

i understand i need the pvk pair. but how do i get the pvk pair.

I am new to this sorry about that.

Mar 13, 2012 at 2:50 PM

It's strange how often I get this question, from different people and for various reasons...

The answer is no, there's no practical way to get the PVK pair out of the PVV. In other words, there's no practical way to guess/brute-force the PVK pair from the contents of a track II (which often includes the PVV). For more details and to understand why not, read this great thread. Although PVK pairs in Thales form a 128-bit key, you also have parity bits that leave you with an effective key length equal to 112 bits. Still, 2^112 is a very big number.

May 3, 2012 at 10:00 AM
Edited May 3, 2012 at 10:01 AM

Hy nickntg

I ve a question regarding the calculation of a pvv and the use of keys

as i read in general  the pvk is used to derive the pvv .. therefor it s encrypted with a lmk .. how das it work ...

i do not understand if the lmk is attached to the pvk .. and then encrypted under another key , 

or if the lmk is attached by the control vector ( pvk) to be encrypted by what? 

So it s written ...

 The VISA PIN Validation Value (PVV) calculation method consists of the following steps:

1.Let X denote the transaction_security_parameter element.This parameter is the result of concatenating the 12-numeric-digit generating data with the 4-numeric-digit customer-entered PIN.

2.Encrypt X with the double-length key that has a control vector that specifies the PINGEN (or PINVER) key type to get 16 hexadecimal digits (64 bits).

3.Perform decimalization on the result of the previous step by scanning the 16 hexadecimal digits from left to right, skipping any digit greater than X9, until 4 decimal digits (for example, digits that have values from X0toX9) are found. If all digits are scanned but 4 decimal digits are not found, repeat the scanning process, skipping all digits that are X9 or less and selecting the digits that are greater than X9.Subtract 10 (XA) from each digit selected in this scan.

4.Concatenate and use the resulting digits for the PVV.The PVV is not encrypted.


How do I have to understand this?

please reply asap.

kind regards


May 3, 2012 at 10:26 AM

The LMK is just a key that is used to encrypt other keys. Specifically for PVKs, the purpose is to allow applications to keep the encrypted PVK and thus use it with a PVV calculation, but since each HSM device has unique LMKs it would be impossible to use the encrypted PVK at another device.

May 3, 2012 at 4:18 PM

so , am I right when thinking that the pvk encrypted with the particular lmk and after encryption used to calculate the pvv?

May 3, 2012 at 5:02 PM

To make things clearer, the LMK does not participate in the PVV calculation algorithm at all. You can calculate a PVV by using the PVK only. You can also browse the source code to see how the PVV is calculated.

Does that help?

May 4, 2012 at 11:58 AM

well , I am confused about .. because written is the following in operations manuals


Generating a VISA Pin Verification Value


Function: To generate a VISA PIN Verification Value (PVV).



Inputs: Encrypted PVK A under LMK pair 14-15: 16 hexadecimal characters.

           Encrypted PVK B under LMK pair 14-15: 16 hexadecimal characters.

           The CVK can be presented as a double length key using the new scheme.

           The PVV data block comprising:

           The 11 right-most digits of the account number (excluding check digital): 11 decimal digits.

           The PIN verification key indicator (PVKI): 1 decimal digit.

           The 4 left-most digits of the clear PIN: 4 decimal digits.

Outputs: The PIN Verification Value (PVV): 4 decimal digits.


In opposite you are saying that I would only need the PVK to calculate the PVV . So I do need the TSP to be encrypted by PVK to get as a result the PVV, am I right ?

( I do not need to encrypt the PVK under an LMK to get the PVV ?!)


May 4, 2012 at 12:57 PM

I'll try to make it more clear if I can.

An EFT calculator, or a human, would only need the PAN, the PIN, the PVK and the PVKI to find the PVV. And if you think about it, that's what the EFT calculator actually asks you for.

The LMK set is a horizontal level of security applied by the HSM to all keys, regardless of their nature. The keys might be PVKs, TMKs, TPKs, BDKs, or whatever; everything is encrypted using the LMK set before it leaves the HSM and is given to an application that accesses it. This is done to protect the encrypted key - in the case of PVV generation/verification, the PVK.

In other words, keys are not encrypted under the LMK set because the algorithm they're used for demands it. They are encrypted to protect the keys themselves from observation.

May 4, 2012 at 2:26 PM

thanks a lot  :-)

now i start to understand .

And the PVK is everywhere ( worldwide)  the same , isn t it ?

otherwise it would nt be possible for a POS terminal or an ATM to recognize and recalculate the PVV to compare , is nt it ?

Or how do issuer calculate a PVK which can be read by POS/EFT hardware ?






May 5, 2012 at 7:06 PM

No, every issuer has its own PVK...obviously! Anyone that has the PVK of a card program can create new cards!

A POS/ATM terminal do not verify the PIN. They encrypt the PIN using their own key and sent it upstream to the acquirer. The acquirer sends the message to the issuer who is the only entity that can verify the PIN...and that should make sense, right? I mean, imagine if anyone else except your bank could determine if your PIN is correct or not.

May 7, 2012 at 11:52 AM

wow, a lot questions rise ...

on one hand you are certainly in regards of an online authorization of values like pin,pvv,cvv .... but on the other hand I was wondering how verification is working in offline transactions , so e.g.  when the pos / atm has little given information ... up to know I thought that an hsm in the atm  is calculating by its own the pvv/cvv to compare it with given information by the user of the pin/account

I certainly know that there exist offline and online verification methods ,as issuers and their providers / acquirer  demand in manuals always the option for offline transactions and authorizations depending on service codes and may be pvv/cvv as discret data .. when e.g. tha pos/atm is not able to read the information given on a chipcard like in europe.

I never thought that the pvk is individual from issuer to issuer ... i know that there have been institutional key and so called pool keys to verify , this system went on up to beginning of the years 2000 .. and when I m reading in manuals of processing noe there s always talked about e.g. account individual keys which are generated in transactions to verify and compare the given values pvv/cvv...

e.g. I wonder how the PINGEN key is used  to derive a pin from the accountnumber to get further on the pvv... is it used in cleartext  ore is it encrypted before use ?

Is the PINGEN Key just a half of a pinderive key?( cause some information is telling about PINGEN Key as control vector which has to be added to a value in relation to the hsm encryption).

I could ask thousand questions more but first I have to admire the work you ve done with the advice and freeware you ve written.



May 7, 2012 at 1:19 PM

Thanks. The important thing to understand regarding the PIN key is that a terminal (ATM or POS) does not need any kind of outside knowledge to create an encrypted PIN block. The PIN pad contains the PIN key and along with the PIN entered and parts of the card it can create an encrypted PIN block. The only reason for the existence of the PIN block is to create the PIN entered by the customer during transit from device, to acquirer, to network, to the issuer.

Having said that, the terminal does not have any other responsibility, and it should not have any other responsibility or cryptographic knowledge of other processes. If you were the issuer, you'd want a secure card setup where only your own system could generate valid new cards. That means that an issuer will want to protect the cryptographic keys used to create new cards: the PIN verification keys, the card verification value keys, etc. Using the currently dominant 3DES technology, that requirement translates directly to the issuer being the only entity that can verify the details of a card, such as PIN entered, CVV, CVV2 or iCVV.

The offline PIN verification is a slightly different situation used with chip cards but still a variation of the same story. The card contains an offline PIN block and compares that to the PIN block created by a device; if they match, the PIN is accepted as valid and a transaction can be sent upstream. Using offline PIN puts a burden to the issuer who has to ensure that a PIN change transaction which changes the customer PIN should also send a script to the card to update the offline PIN.