Comet Cryptographic Support

From CometWiki

Latest revision as of 01:46, 10 June 2010

Supported Encryption Algorithms

• RC4 - Rivest Cipher 4: Wiki
• 3DES - Triple Data Encryption Standard: Wiki
• AES - Advanced Encryption Standard: Wiki

Supported Hashing Algorithms

• SHA1 - Secure Hash Algorithm 1: Wiki
• MD5 - Message Digest 5: Wiki

Algorithm Implementation

The following text describes the specifications/requirements for each of the supported algorithms.

RC4 - Rivest Cipher 4: Wiki

• Key Length: Typically 40-256 bits (5-32 bytes)
• Block Size: NA
• Mode: NA
• IV Required: No
• This is the simplest and fastest of the supported algorithms and is the algorithm currently used by Comet-16 and is the default algorithm used by Comet-32. See Encrypt/Decrypt

3DES - Triple Data Encryption Standard: Wiki

• Key Length: 168 bits although 192 bits (24 bytes) must be supplied (parity bits are discarded).
• Block Size: 8 Bytes
• Mode: CBC - Introduces feedback by combining ciphertext and plaintext
• IV Required: Yes

AES - Advanced Encryption Standard: Wiki

• Key Length: 128, 192, 256 bits
• Block Size: 16 Bytes
• Mode: CBC - Introduces feedback by combining ciphertext and plaintext
• IV Required: Yes

SHA1 - Secure Hash Algorithm 1: Wiki

• Output: 160 bits (20 bytes)

MD5 - Message Digest 5: Wiki

• Output: 128 bits (16 bytes)

IV - Initialization Vector Wiki

In Comet the AES and 3DES algorithms are implemented using CBC (Cypher Block Chaining) mode which incorporates feedback from previous cypher operations while encrypting the plaintext. Because at the onset of the encryption there is no feedback information available, it becomes necessary to supply some initial data that can be used to ensure adequate concealment of the initial block of data. To ensure proper concealment of your data an IV or "Initialization Vector" must be supplied to the encryption code. The size of an IV should be the same size as the chosen algorithm's Block Size (8-3DES, 16-AES). This IV value should be unique and must be used for both encrypt and decrypt operations. There is no need to conceal the IV as it cannot be used to learn anything about the key or plaintext and as such it may be stored with the encrypted data. You can use the IB statement CryptoGenerateRandom to create an IV of any desired length.

Cryptographic Keys

An encryption key (called a "seed" in previous documentation), is a series of (random) bytes used to encrypt the data. 3DES requires 3 keys of 56 bits each. The Crypto API expects all 3 keys to be grouped together in the form of 3 consecutive 8-byte blocks. The parity bit (2**7) of each byte is ignored so the total number of bits used will be 168. For AES, the key length depends on the encryption strength desired.

Keys may be generated in many ways. Comet32 Supplies the CryptoGenerateRandom() function to facilitate key/IV generation. The Key and the IV must be "remembered" somewhere, preferably not with the encrypted data. Credit card processing standards require that a different key be used for each credit card instance.

Internet Basic Support

Cryptography in Comet is accomplished through the use of the below listed IB (Internet Basic) functions.

• Encrypt
  • This function is used to encrypt a block of data.
• Decrypt
  • This function is used to decrypt a block of data.
• New - CryptoSetKeyInfo
  • This function is used to specify the desired algorithm and to supply all of the parameters required for encryption/decryption. Because a Key and IV must be specified at this time, the SEED value normally supplied to the encrypt/decrypt functions is not used and will be ignored.
• New - CryptoGenerateRandom
  • This function will generate a binary string of random characters of any length. It can be used for Key and IV generation.
• New - CryptoCreateHash
  • This function will generate a hash of the supplied string as defined by the specified hashing algorithm.

Storing Credit card information

The Following code encrypts the info for a credit card.

! Lets do 256 bit AES
  KeySize = 256
  BlockSize = 16
  Key$ = CryptoGenerateRandom(KeySize/8) ! Generate a key
  IV$ = CryptoGenerateRandom(BlockSize)  ! Generate an IV
! Store the IV and Key somewhere separate from the encrypted data
...
! Pass info to Encryption sub-system
  ErrResult$ = CryptoSetKeyInfo('AES', KeySize, Key$, IV$)
  If (ErrResult$ NE "+OK")Print "bad call to CryptoSetKeyInfo -- result is:'; ErrResult$
! Get Credit card info into CC$ (the Card Security Code (CSC or CVV), must NOT be stored anywhere on the disk, even encrypted)
  CC$ = CCNO$ + CCDate$
  E$ = Encrypt(CC$, "")
! Now E$ contains the encrypted credit card info -- Store it somewhere
...
! Reset the algorithm back to old default (RC4)
  ErrResult$ = CryptoSetKeyInfo("", 0, "", "")

Encrypting Multiple Strings

These Algorithms support encrypting multiple strings with the same IV and Key. By generating the IV and Key and calling CryptoSetKeyInfo() once, successive calls to encrypt/decrypt encrypt or decrypt successive strings. Make sure the same order is used for encrypt and decrypt. Note that for Credit card processing, each credit card must have its own IV and Key.

Test vectors

Test vectors are a set of known ciphers for a given input and key. NIST distributes the reference AES test vectors as AES Known Answer Test (KAT) Vectors (in ZIP format).

Would anyone care to download these and write a test program?

Links to other pages

Encrypting credit card numbers in a database