BP-Tools: Cryptographic Calculator - Generic menu

 

BP-Tools icon

Introduction

The BP-Tools set consist of applications supporting payment transaction service development, testing and benchmarking. It currently consists of following components: Cryptographic Calculator, EMV Tool, HSM Commander and P3 Card Edit Tool.

EFTlab distributes BP-Tools under Creative Commons Legal Code Attribution-NoDerivs 3.0 Unported and completely free. This packag comest with a full support and monthly releases instantly bringing new features.

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

Generic Cryptography

This set of tools focuses on working with common cryptography algorithms used across payments, extended with further features as character encoding, keys generation and validation related to their practical usage.

 

BP-Tools icon

Introduction

The BP-Tools set consist of applications supporting payment transaction service development, testing and benchmarking. It currently consists of following components: Cryptographic Calculator, EMV Tool, HSM Commander and P3 Card Edit Tool.

EFTlab distributes BP-Tools under Creative Commons Legal Code Attribution-NoDerivs 3.0 Unported and completely free. This packag comest with a full support and monthly releases instantly bringing new features.

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

Generic Cryptography

This set of tools focuses on working with common cryptography algorithms used across payments, extended with further features as character encoding, keys generation and validation related to their practical usage.

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

Base64

Base64 is a group of similar binary-to-text encoding schemes that represent binary data in an ASCII string format by translating it into a radix-64 representation. The term Base64 originates from a specific MIME content transfer encoding.

Base64 encoding schemes are commonly used when there is a need to encode binary data that needs to be stored and transferred over media that are designed to deal with textual data. This is to ensure that the data remains intact without modification during transport. Base64 is commonly used in a number of applications including email via MIME, URL address encoding and storing complex data in XML or databases.

Base64: Encoding finished
****************************************
Data:                    Hello World!
----------------------------------------
Encoded Data:            SGVsbG8gV29ybGQh

ISO8583 Bitmap

Support for ISO8583 Bitmap preparation. Parses bitmap (hexadecimal data) into bits and construct a bitmap back from binary data provided. Screen reacts on Enter in Bitmap input and also on each bit-checkbox tick. NOTE: Algorithm detects 1st bit to be set to indicate secondary bitmap presence as per ISO8583 standard.

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

Hashes

Hashes are one-way destructible cryptography algorithms being frequently used for unique data identification and also for validation. You can meet them at all places across payments starting with payment message validation, EMV SDA and DDA procedures, networking protocols and ending perhaps with transaction database indexing. Our Hash Calculator provides you with following hashing options: MD4, MD5, SHA-1, SHA-224, SHA-256, SHA-348, SHA-512, RIPEMD-160, TIGER-192, CRC32, CRC32_RFC1510, CRC32_2440 and WHIRLPOOL.

Output from this function should read like this:

Hashes: Hashing operation finished
****************************************
Data:                    C1D0F8FB4958670DBA40AB1F3752EF0D
Hash type:               MD5
----------------------------------------
Hash:                    4C618FD14C14881EFB13352E400473B1

Character Encoding

In payments we do rely on understanding of different types of character encoding. Knowing how to translate Hexadecimal values to their binary representation and vice versa is vital. Similar applies for EBCDIC <->ASCII and ASCII -> Hexadecimal.

Typical use case can be like this:

Character Encoding: Encoding done
****************************************
Data In:                 57652C206174204546544C61622C2062656C6965766520746861742074657374696E67206D75737420656D706F77657220627573696E65737320616E64206E6F7420736C6F7720697420646F776E2E
----------------------------------------
Data Out:                We, at EFTLab, believe that testing must empower business and not slow it down.

Keys DEA

Have you ever been looking for DEA key generator? A way how to combine a key from multiple components? Or found yourself in a need of checking key's parity & generating key check value (KCV)? Then this tool does all of this for you: Generates cryptographic keys, allows users to XOR key combination and do a key validation. Key generator uses libGcrypt library and it's powerful random number generator set to level GCRY_STRONG_RANDOM. This setting is strong enough for all random number requirements.

Key Generator

The Key generator make use of so-called entropy gathering modules built-in your operation system and all operations are being carried in a secured memory allocated specially for this feature with SECMEM settings. This generator is suitable for any test to production system key generation as being reliable and well secured. All keys are generated with a Checksum value so their lodgement in a payment system can be immediately validated.

Options available are a number of keys to generate, final key length and key parity forcing option. Keys to generate option allows generating up to 1000 random keys, which might be handy for generating large batches of terminal keys etc. Key length option provides generation algorithm with key's output length. Values 64-bit (16H), 128-bit (32-H), 192-bit (48H) and 256-bit (64H) correspond key standard having key lengths defined as Single, Dual, Triple and 256-bit. The last option - Key parity tells application whether some parity should be forced on a key generated. Dual key length and Odd parity are default settings.

Output from this screen should read like this:

DEA Keys: Key generation finished
****************************************
Key length:              Dual
Key parity:              Right odd
Keys generated:          3
----------------------------------------
Key #1:                  C8491F643B9E6D01401C9143D0F275C4
KCV:                     77D872
Key #2:                  EAB93D3D4F5123FE792FF4B9E07CF84A
KCV:                     9D7D46
Key #3:                  AD401F4FDA894A324C68267357FE9215
KCV:                     4A5000

Key Combination

The second tab "Key combination" enables users to combine (XOR) up to 9 keys. This feature is handy for forming a key from several components. Even this screen allows up to 9 components to be used only first two are compulsory for key operation. Application for will also guard that the keys have all input digits as hexadecimals (0-9 | A-F) and that key lengths are 16, 32, 48 or 64 characters.

Output from this screen should read like this:

DEA Keys: Key combination operation finished
****************************************
Key #1:                  B02310D37A8A9D7952C1C1D5F8F73D61
Key #2:                  9D4FEF8C75DAE3FDBCD3BF899E196E20
----------------------------------------
Combined key:            2D6CFF5F0F507E84EE127E5C66EE5341
KCV:                     E1EDFE

Parity enforcement

Sometimes you might find your keys need to be of some parity to continue with another calculation. So we prepared an easy screen that modifies your key to meet the requested parity check.

Output from this screen should read like this:

DEA Keys: Key validation finished
****************************************
Key:                     B02310D37A8A9D7952C1C1D5F8F73D61
Key length:              32
Parity enforced:         Even
New key:                 B12211D27B8B9C7853C0C0D4F9F63C60
KCV:                     FAE09C

Validation

The last tab "Validation" provides a basic check to be carried on a key provided. Application will check whether it can detect any parity and will also generate appropriate key Checksum. Application input is again limited to hexadecimal digits (0-9 | A-F) and that key lengths allowed are 16, 32, 48 or 64 characters.

Output from this screen should read like this:

DEA Keys: Key validation finished
****************************************
Key:                     B02310D37A8A9D7952C1C1D5F8F73D61
Key length:              32
Parity detected:         Odd
KCV:                     FAE09C

****************************************
Key:                     B02310D37A8A9D7952C1C1D5F8F73D65
Key length:              32
Parity detected:         No parity
KCV:                     2D8C08

****************************************
Key:                     6C4DF909186C9CEE39AFD466A6A62D72
Key length:              32
Parity detected:         Even
KCV:                     3A4220

Keys HSM

Developing a payment system employing the Hardware Security Modules (HSMs) can sometimes prove challenging. Whilst in production HSMs provide a priceless service, in testing and development environments having a black box where cryptography is silently performed can make it hard to diagnose issues since ensuring the correct keys are loaded is an issue. Now with BP-Cryptographic Calculator you can easily check the loaded keys.

Keys Futurex

Key Encryption/Decryption

Encrypts/ Decrypts provided key under a Futurex test MFK and its modifier.

 Futurex Keys: Key encryption finished
 ****************************************
 Plain Key:          4090670C3EE229C3E9BAA71EC0BCB974
 Parity detected:    No parity
 MFK:                D2DE5CD9110F4CAB11111111111111110123456789ABCDEF
 Key modifier:       4
 Encrypted Key:      BFB1FB2768ED622EC7E923992C6F4A44
 KCV:                DED19A

The following figure shows this in action:

Key Lookup

Tries to decrypt provided key under all Test MFKs and find a match with KCV value or parity.

 Futurex Keys: Lookup finished - 217 records found matching filter criteria
 ****************************************
 Input Key:        4090670C3EE229C3E9BAA71EC0BCB974
 Input KCV:        Not checked
 Input Parity:     Any
 ----------------------------------------
 MFK [Modifier]: Plain key            KCV    Parity
 MFK single [00]: FB44403370B3E3822C79AEBEB9436E40    4C0CD2    No parity
 KEK single [00]: 47A647689869C42969E37519AD5D5756    87B95D    No parity
 MFK double [00]: 70CF6478F6F55F6E98A7365262F933CE    C5D708    No parity
 KEK double [00]: 6DDA764A3F26B5AC8E4DD813A06362BD    A66979    No parity
 MFK triple [00]: E2F60DBA0B85234BB8294778A9270623    7E9311    No parity
 KEK triple [00]: 9EF86E6CDE9AB64FE7BCF4075FF4F43D    7A83FA    No parity
 MFK single [00]: BAF3360C5ED84B1F420AF5B6652B7A07    12ADD9    No parity
 MFK single [01]: 4FC633DD0783F8C16D874C02E691B0E7    9E793B    No parity
 KEK single [01]: 8C871084DB62A79DA6B5D18331741227    BED558    No parity
 MFK double [01]: 4E0D9628642BB073A949F1E1B17B29B6    7CE8EE    No parity
 KEK double [01]: 0A28F9F148CCDE7CA93C50FD7F6A996C    B7B140    No parity
 MFK triple [01]: D6E65EC0E3F72F19D7DA668A0F87BFA7    BA0C6D    No parity
 KEK triple [01]: ACE46163908ED8D620E4B4A788B2D51B    5C3230    No parity
 MFK single [01]: 3B040B6FCCB2B9B64FD5DE748E6EEE5F    0E7C89    No parity
 MFK single [02]: F082B204850536F3D49095892AC4CEB3    CD3188    No parity
 KEK single [02]: 941F5BFB13ABA84C1E5CCBB225F8ADE5    3F09DA    No parity
 MFK double [02]: 8BD7DCD035E989D1866218FD98707964    60062E    No parity
...

BP-Cryptographic Calculator also includes an option to log all operations performed that can be useful when looking for a key and not knowing the KCV, just knowing the parity or even better not knowing anything. From the experience of the EFTlab team in testing, it's frequently found that test keys are not randomly generated, but are more likely a sequence of hexadecimal digits, making them easy to spot. This functionality is demonstrated in the figure below:

Keys HP Atalla

Key Encryption

Encrypts provided working key under a HP Atalla test MFK.

 HP Keys: Key encryption finished
 ****************************************
 Plain Key:        4090670C3EE229C3E9BAA71EC0BCB974
 KCV (S):          6C3C
 Parity detected:  No parity
 AKB header:       1PUNE000 [Valid]
 Plain MFK Key:    2ABC3DEF4567018998107645FED3CBA20123456789ABCDEF
 ----------------------------------------
 AKB header:       1PUNE000
 Key under MFK:    26AFF233B421666DF88562CC5DF38E6B798CB61F0F7D37EC
 MAC:              AB7926DB83DAE2D2
 AKB:              1PUNE000,26AFF233B421666DF88562CC5DF38E6B798CB61F0F7D37EC,AB7926DB83DAE2D2

The following figure shows this in action:

AKB Decode

Tries to decrypt provided Atalla Key Buffer (AKB) from under test MFK and find a match with KCV value or parity.

 HP Keys: Lookup finished
 ****************************************
 AKB:              1PUNE000,D3266EC69C61820019F4A9640A8F603DA14F78E154C7522D,55720A06F8964B8F
   Header:         1PUNE000 [Valid]
   Key:            D3266EC69C61820019F4A9640A8F603DA14F78E154C7522D
   MAC:            55720A06F8964B8F [Valid]
 Input KCV:        3BAF
 Input Parity:     Any
 ----------------------------------------
 Plain key:        0000000055556666
 KCV (S):          3BAF
 Parity:           Even

Keys SafeNet

Key Encryption/Decryption

Encrypts / Decrypts provided SafeNet Host-stored key under a SafeNet test KM and its modifier.

 SafeNet Keys: Key encryption finished
 ****************************************
 Plain Key:           4090670C3EE229C3E9BAA71EC0BCB974
 KCV:                 6C3CD4
 Key format:          11 - Double-length DES3 (ECB Encrypted)
 Plain KM Key:        AAAAAAAAAAAAAAAA1111111111111111
 KM variant:          00 - DPK
 KM (variant applied):AAAAAAAAAAAAAAAA1111111111111111
 ----------------------------------------
 Encrypted Key:       49B53658EF017B9FDA79CA447EB27A0D
 KCV:                 587655
 Parity detected:     No parity
 Host-stored Key:     111149B53658EF017B9FDA79CA447EB27A0D

The following figure shows this in action:

Key Lookup

Tries to decrypt provided SafeNet Host-stored key under test KM and find a match with KCV value or parity.

 SafeNet Keys: Lookup finished - 34 records found matching filter criteria
 ****************************************
 Input Key:        1113AFD9FD6D4C1B83B98FAE02D1900E2955
 Input KCV:        Not checked
 Input Parity:        Any
 ----------------------------------------
 Variant [Type]: Plain key                       KCV    Parity        Desc.
 00 [1113]: 722737E2FCC3238690143EA428B370DF    0B91E9    No parity    DPK
 01 [1113]: B153759D6D0DF4D824E0C06A798E74EB    23D7BB    No parity    PPK
 02 [1113]: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF    CAAAAF    Even         MPK
 03 [1113]: 738B993D7164F52EF244EDF3BC0F9350    1A599F    No parity    KIS
 04 [1113]: 9EB697AF5B918318336C6E6E093DECB8    D4843C    No parity    KIR
 05 [1113]: 70875FA3D55B4CA2FECC591E9CBBFE38    155C1C    No parity    KTM
 06 [1113]: F7C78CC32756A6FF796F59AEA2B13AEA    AFC2DA    No parity    CSCK
 07 [1113]: 56F3CA5819B6DF9BF5E9FEC42CA9B0C5    F7284F    No parity    KPV, DT
 08 [1113]: B7760EC907C975F293C143B82FBFD506    729607    No parity    KPVV
 09 [1113]: F14D8AFA5F879FF5FC4B0EC87A60565C    E4069C    No parity    KCVV
 10 [1113]: 893F353058C1C5B1B2B535F3452FBD27    3C5A62    No parity    KI
 12 [1113]: B7667AEC047C14AB35BFDAD99CFC6F01    85A395    No parity    MAC Residue
...

BP-Cryptographic Calculator also includes an option to log all operations performed that can be useful when looking for a key and not knowing the KCV, just knowing the parity or even better not knowing anything. From the experience of the EFTlab team in testing, it's frequently found that test keys are not randomly generated, but are more likely a sequence of hexadecimal digits, making them easy to spot. This functionality is demonstrated in the figure below:

Keys Thales

Key Encryption/Decryption

Developing a payment system employing the Thales Hardware Security Modules (HSMs) can sometimes prove challenging. Whilst in production HSMs provide a priceless service, in testing and development environments having a black box where cryptography is silently performed can make it hard to diagnose issues since ensuring the correct keys are loaded is an issue. Now with BP- Cryptographic Calculator you can easily check the loaded keys.

Firstly the Thales HSM allows configuration of up to 20 Local Master Keys (LMKs). To reduce the risk of a key becoming compromised Thales employs five schemes and seven variants. These are represented by a binary mask used atop the key prior to use in cryptographic operations. Using the appropriate key results in key pair selection, a XOR operation with the scheme and finally another XOR with a key variant. Simply said out of the original 20 keys there can be 700 completely different keys for any cryptographic purpose.

However setting a key under the LMK, scheme, variant or retrieving a key is intentionally complex. This is why EFTlab have developed the Thales key encoding and decoding functionality for the default Thales key set.

Thales Keys: Key encryption finished
****************************************
Plain Key:               B02310D37A8A9D7952C1C1D5F8F73D61
Key scheme:              U
Key length:              32
Parity detected:         Odd
LMK Pair:                00-01: 01010101010101017902CD1FD36EF8BA
LMK Variant:             1
Encrypted Key:           85A498E630E7B900C508589CE2B0C992
KCV:                     85B866

The following figure shows this in action:

Key Lookup

When working with Thales HSMs in development developers and testers often need to verify keys to ensure a system is processing correctly. Payment systems are often full of keys making it difficult to find what parameters are being used for their decryption to reveal their clear value. Usually what's left is just a key preceded with a scheme letter and checksum (KCV) of hidden key; how can developers and testers reveal the original key?

In short there are two ways; the first (and quickest) is to search through documentation hoping for a lucky draw. The second is to brute force using all available HSM keys, their schemes and variants to attempt to reveal key candidates and follow with KCV operation on top of those. Whilst hypothetically brute-force operations should just take too long, we have prepared a tool making this possible on an environment where the default Thales key sets are loaded. As demonstrated on the figure below, with BP-Cryptographic Calculator it takes only a few milliseconds to reveal the clear key.

Thales Keys: Lookup finished - Match found
****************************************
Input Key:               U227AA70949A9D254638E79950C3AF770
Input KCV:               BA9B76
Input Parity:            Odd
----------------------------------------
LMK pair [Variant]:      Plain key                            KCV     Parity
14-15 [5]:               7538A1F161E00B26AE2C80E0C4B99DA4    BA9B76    Odd

BP-Cryptographic Calculator also includes an option to log all operations performed that can be useful when looking for a key and not knowing the KCV, just knowing the parity or even better not knowing anything. From the experience of the EFTlab team in testing, it's frequently found that test keys are not randomly generated, but are more likely a sequence of hexadecimal digits, making them easy to spot. This functionality is demonstrated in the figure below:

Luhn Check

The Luhn algorithm or Luhn formula, also known as the "modulus 10" or "mod 10" algorithm, is a simple checksum formula used to validate a variety of identification numbers, such as credit card numbers, IMEI numbers, National Provider Identifier numbers in US and Canadian Social Insurance Numbers. It was created by IBM scientist Hans Peter Luhn and described in U.S. Patent No. 2,950,048, filed on January 6, 1954, and granted on August 23, 1960.

The algorithm is in the public domain and is in wide use today. It is specified in ISO/IEC 7812-1. It is not intended to be a cryptographically secure hash function; it was designed to protect against accidental errors, not malicious attacks. Most credit cards and many government identification numbers use the algorithm as a simple method of distinguishing valid numbers from mistyped or otherwise incorrect numbers.

The formula verifies a number against its included check digit, which is usually appended to a partial account number to generate the full account number. This account number must pass the following test:

  • From the rightmost digit, which is the check digit, moving left, double the value of every second digit; if the product of this doubling operation is greater than 9 (e.g., 7 × 2 = 14), then sum the digits of the products (e.g., 10: 1 + 0 = 1, 14: 1 + 4 = 5).
  • Take the sum of all the digits.
  • If the total modulo 10 is equal to 0 (if the total ends in zero) then the number is valid according to the Luhn formula; else it is not valid.

Luhn algorithm: Luhn Digit check finished
****************************************
Input:                    79927398713
Luhn Digit:               3
----------------------------------------
Result:                   Check Passed

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

UUID

A universally unique identifier (UUID) is an identifier standard used in software construction. A UUID is simply a 128-bit value. The meaning of each bit is defined by any of several variants.

For human-readable display, many systems use a canonical format using hexadecimal text with inserted hyphen characters.

The intent of UUIDs is to enable distributed systems to uniquely identify information without significant central coordination. In this context the word unique should be taken to mean 'practically unique' rather than 'guaranteed unique'. Since the identifiers have a finite size, it is possible for two differing items to share the same identifier.

UUID: Generate UUID Variant 4 (random) finished
****************************************
UUID:        5e0835cc-1975-425f-b937-19c0cdb89103

Summary

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

Cryptographic Calculator and other tools covered in BP-Tools 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.

BP-Tools

BP-Tools is a set of freeware applications for EFT testing, benchmarking and transaction service development.

See more...

Download...

Download Flyer...

BP-Sim

The Babylon Payments Simulator (BP-Sim) is a family of highly efficient regression and stress testing tools, designed for deployment in development and pre-production environments. BP-Sim allows users to perform an extensive range of tests across the chain of payment services.

See more...

Download Flyer...

BP-Processing

The Babylon Payments Processing Suite(BP-Processing) is a suite of EFTlab's products for realtime payment transaction processing and authorisation.

See more...