Introduction

The EFTtools set consist of applications supporting payment transaction service development, testing and benchmarking. It currently consists of following components: Cryptographic Calculator and HSM Commander.

This tutorial focuses on Cryptographic Calculator functionality and is provided in six separated parts as per functionality topics covered by its main menu – Generic, Cipher, Keys, Payments, EMV and Development tools. This tutorial also aspires to provide bits of basic history on algorithms in use.

Cipher Cryptography

This set of tools focuses on working with common cryptography algorithms used across payments.

AES

The Advanced Encryption Standard (AES), the symmetric block cipher ratified as a standard by National Institute of Standards and Technology of the United States (NIST), was chosen using a process lasting from 1997 to 2000 that was markedly more open and transparent than its predecessor, the aging Data Encryption Standard (DES). This process won praise from the open cryptographic community, and helped to increase confidence in the security of the winning algorithm from those who were suspicious of backdoors in the predecessor, DES.

AES is based on the Rijndael cipher developed by two Belgian cryptographers, Joan Daemen and Vincent Rijmen, who submitted a proposal to NIST during the AES selection process. Rijndael is a family of ciphers with different key and block sizes.

AES is a variant of Rijndael which has a fixed block size of 128 bits, and a key size of 128, 192, or 256 bits.

Ccalc’s screen for AES encoding and decoding allows input based on input data type – ASCII or Binary (HexDec). Encryption/Decoding key have to be always provided in hexadecimal digits (0-9 | A-F) and key lengths allowed are 32 (AES-128), 48 (AES-192) or 64 (AES-256) characters.

Cipher modes available are:

• ECB – Electronic Code Book – the simplest of the encryption modes. The message is divided into blocks, and each block is encrypted separately.
• CBC – Cipher-block chaining – each block of plaintext is XORed with the previous ciphertext block before being encrypted. This way, each ciphertext block depends on all plaintext blocks processed up to that point. To make each message unique, an initialization vector must be used in the first block.
• CFB – Cipher feedback – is a close relative of CBC, makes a block cipher into a self-synchronizing stream cipher. Operation is very similar; in particular, CFB decryption is almost identical to CBC encryption performed in reverse.
• OFB – Output feedback – makes a block cipher into a synchronous stream cipher. It generates keystream blocks, which are then XORed with the plaintext blocks to get the ciphertext. Just as with other stream ciphers, flipping a bit in the ciphertext produces a flipped bit in the plaintext at the same location. This property allows many error correcting codes to function normally even when applied before encryption.

AES operation finished
****************************************
Key:                     C1D0F8FB4958670DBA40AB1F3752EF0D
Algorithm:               AES-128
Mode:                    CBC
IV:                      00000000000000000000000000000000
Crypto operation:        Encryption
Data:                    00000000000000000000000000000000
—————————————-
Encrypted data:          BFABFA12C63525EE76FE211684B5731E

DES

Data Security Standard (DES) and its triple key length variant is even after decades today’s foundation for all the financial security. Ccalc’s screen for AES encoding and decoding allows input based on input data type – ASCII or Binary (HexDec). Encryption/Decoding key have to be always provided in hexadecimal digits (0-9 | A-F) and that key lengths allowed are 16, 32 or 48 characters, while Single DES operation requires a Single length key and Triple DES operation requires a Dual or Triple length key.

Single DES

Note that the dual key will be internally extended to triple length by its first half as default. Also data provided will be right padded to a multiple of 8 so the cryptographic operation can be applied. Cryptographic operation itself is triggered by hitting buttons with “Lock” and “Unlock” bitmap, meaning encrypt and decode. Operation result also contain a comment on number of DES operations applied, what might be a very handy information in some cases.

DES/3DES operation finished
****************************************
Key:                     C1D0F8FB4958670DBA40AB1F3752EF0D
Algorithm:               Single DES
Crypto operation:        Encryption
Data:                    00000000000000000000000000000000
—————————————-
Encrypted data:          8CC76BBD107660BE8CC76BBD107660BE
DES operations count:    2

Triple DES CBC

Let’s see how to work with the Cypher Block Chaining (CBC) mode for Triple DES (3DES) operations. CBC uses the 3DES operation preceded with a XOR between the data and previous result applied in 64bit blocks. This encryption mechanism is widely used in the payments industry, often to enhance key exchange process security between a payment device and an acquirer; for example the AS2805 message format’s highly respected security.

The following diagram demonstrates encoding and decoding 2 blocks of data (totaling 128 bits). The first iteration is shown without CBC, the second having CBC mode enabled. The details show that first block was encrypted in a same way for both modes, while the second differs as cypher chaining was in use.

Output from this screen should read like this:

DES/3DES operation finished
****************************************
Key:                     C1D0F8FB4958670DBA40AB1F3752EF0D
Algorithm:               3DES CBC
IV:                      0000000000000000
Crypto operation:        Encryption
Data:                    00000000000000000000000000000000
—————————————-
Encrypted data:          2DAF031DA77D92AC2ECBB931E77E8457

RSA

Ron Rivest, Adi Shamir and Leonard Adleman – MIT guys who formed an encryption algorithm known today better as RSA. While DEA is a well known representative of symmetric cryptography, RSA is today’s king of its asymmetric branch. It clearly rules in all web-based security, but it has an important role in SDA, DDA and CDA operations – vital for EMV functionality.

Covering the RSA functionality would be too much this tutorial. So just few notes briefly. Our RSA implementation does: Key pair generation, Encryption, Decryption, Data Signature and Verification. One for all, note the “Decoding function to be used” option for decrypting operation. This option is vital for Certificate recovery procedure for above mentioned SDA, DDA and CDA operations.

Output from this function should read like this:

RSA: Data decrypt operation finished
****************************************
Key length:              1024
Data to decrypt:         BC9E572CF3408D679C79D32CEAECD681990AFA05DDDDC5E385CDC111A6D289A9B4D32BB19ECDF103952F9FC6F7E45B15885B77CE59CB04944B9EE437E2D0711A457313147209CF405A19322653EF51718ABEC221AE425FCB3B75C76B9DEE1346C1EADE8F92127252CB3D3E0A642C818EDC6DB1716E228CB5B34646DB8D0C13BF
Public modulus [n]:      BEDB6B21E12D2B6EB590EC129FCC847EA4C00BE41CA530A5FA2CCDDE3B7DB3A0F50E6D3E348CD9258D7076973DD01FDC5B7E00F1F714F4E55C650DF88AAA293ED9376D2B0905F589108FB5C2835EA025D036F369891E5F5F3BA4F5E96CF25D164C1B26215B8D9627CDB95C22F00EBF50DF821A984E01309C1677B5D013E2BEEF
Public exponent [e]:     010001
Private exponent [d]:    A6898BC7FA5691C97EC1405D57F6FBBE0E404D9FF4A6E7F64C807FFAE4EA60AD9867C847394F95C340D1DB894934AC3879D54F39D3A203B78791DE48FBA65369B077BD6541AA8200392CA0BF56EEE2AA8478598852BFB537498095C087910176E1E90F92F8564F3012D7DC52B8D7145C40143F51229FE4416CEF50657511E2F1
—————————————-
Decrypted Message:       4C4F50415441
Decrypted Msg. length:   6

ECC

Elliptic-curve cryptography (ECC) is an approach to public-key cryptography based on the algebraic structure of elliptic curves over finite fields. ECC allows smaller keys compared to non-EC cryptography (based on plain Galois fields) to provide equivalent security.

Elliptic curves are applicable for key agreement, digital signatures, pseudo-random generators and other tasks. Indirectly, they can be used for encryption by combining the key agreement with a symmetric encryption scheme. They are also used in several integer factorization algorithms based on elliptic curves that have applications in cryptography, such as Lenstra elliptic-curve factorization. (source: Wikipedia)

ECDSA

In cryptography, the Elliptic Curve Digital Signature Algorithm (ECDSA) offers a variant of the Digital Signature Algorithm (DSA) which uses elliptic curve cryptography. (source: Wikipedia)

ECDSA: Generate key operation finished
****************************************
EC Name: NIST P-256, P-256 (prime256v1)
Key conversion form: 0x04 – Uncompressed
—————————————-
Private key (d): 502E2BF28990C482498A458193BA940B1509266339FBD402F4468D4CF89F57B7
Public key (Q): 046FF4D63954F687D88724BAE9EEBA5A52A4F3C4625E20BE4BF4E0976880234F3923A6AE70D02F2829A699180B30F32794C2D6C46622C26CA6476E50A1332BF87A
Key conversion form: 04
Qx: 6FF4D63954F687D88724BAE9EEBA5A52A4F3C4625E20BE4BF4E0976880234F39
Qy: 23A6AE70D02F2829A699180B30F32794C2D6C46622C26CA6476E50A1332BF87A

FPE

Format-Preserving Encryption (FPE). In cryptography, format-preserving encryption (FPE), refers to encrypting in such a way that the output (the ciphertext) is in the same format as the input (the plaintext). The meaning of “format” varies. Typically only finite domains are discussed, for example:

• To encrypt a 16-digit credit card number so that the ciphertext is another 16-digit number.
• To encrypt an English word so that the ciphertext is another English word.
• To encrypt an n-bit number so that the ciphertext is another n-bit number (this is the definition of an n-bit block cipher).

NIST Special Publication 800-38G, “Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption” specifies two methods: FF1 and FF3. Details on the proposals submitted for each can be found at the NIST Block Cipher Modes Development site, including patent and test vector information. (source: Wikipedia)

FPE – FF1

FF1 is FFX[Radix] “Format-preserving Feistel-based Encryption Mode” which is also in standards processes under ANSI X9 as X9.119 and X9.124. It was submitted to NIST by Mihir Bellare of University of California, San Diego, Phillip Rogaway of University of California, Davis, and Terence Spies of Voltage Security Inc. Test vectors are supplied and parts of it are patented. (DRAFT SP 800-38G Rev 1) requires the minimum domain size of the data being encrypted to be 1 million (previously 100).

FPE FF1 Encode (AES-128): operation finished
****************************************
Radix: 10
Key: 2B7E151628AED2A6ABF7158809CF4F3C
Data: 0123456789
—————————————-
CT: 2433477484

FPE – FF3

FF3 is BPS named after the authors. It was submitted to NIST by Eric Brier, Thomas Peyrin and Jacques Stern of Ingenico, France. Authors declared to NIST that their algorithm is not patented. The HPE Voltage company although claims to own patents also for BPS mode. On 12 April 2017, NIST concluded that FF3 is “no longer suitable as a general-purpose FPE method” because researchers found a vulnerability.

FPE FF3 Encode (AES-128): operation finished
****************************************
Radix: 10
Key: EF4359D8D580AA4F7F036D6F04FC6A94
Tweak: D8E7920AFA330A73
Data: 890121234567890000
—————————————-
CT: 750918814058654607

FPE – FF3-1

FF3-1 (DRAFT SP 800-38G Rev 1) replaces FF3 and requires the minimum domain size of the data being encrypted to be 1 million (previously 100).

FPE FF3-1 Encode (AES-128): operation finished
****************************************
Radix: 10
Key: EF4359D8D580AA4F7F036D6F04FC6A94
Tweak: D8E7920AFA330A
Data: 890121234567890000
—————————————-
CT: 477064185124354662

FPE – FF2 (VAES3)

FF2 is VAES3 scheme for FFX: An addendum to “The FFX Mode of Operation for Preserving Encryption”: A parameter collection for encipher strings of arbitrary radix with subkey operation to lengthen life of the enciphering key. It was submitted to NIST by Joachim Vance of VeriFone Systems Inc. Test vectors are not supplied separately from FF1 and parts of it are patented.

FPE FF2 (VAES3) Encode (AES-128): operation finished
****************************************
Radix: 10
Tweak Radix: 10
Key: 2B7E151628AED2A6ABF7158809CF4F3C
Tweak: 39383736353433323130
Data: 0123456789
—————————————-
CT: 3736124908

FPE – DFF (OFF2)

Authors have submitted a modified algorithm as DFF which is under active consideration by NIST.

FPE DFF[OFF2] Encode (AES-128): operation finished
****************************************
Radix: 10
Tweak Radix: 10
Key: 2B7E151628AED2A6ABF7158809CF4F3C
Tweak: 39383736353433323130
Data: 0123456789
—————————————-
CT: 3234077476

FPE DFF[OFF2] Decode (AES-128): operation finished
****************************************
Radix: 10
Tweak Radix: 10
Key: 2B7E151628AED2A6ABF7158809CF4F3C
Tweak: 39383736353433323130
Data: 3234077476
—————————————-
PT: 0123456789

Summary

In this article, we went through the functionality of Cryptographic Calculator covered by the Cipher Menu.

Cryptographic Calculator and other tools covered in EFTtools suite were designed to help and assist payment industry people in their day to day tasks and make their work the most effective. Our team would be grateful if you would suggest any improvements to our applications or report completely new functionality needed. Feedback from our users like this is exactly what drives the development of its and helps us to share our experience to wide public.