Classic ASP
Tips on Matching Encryption with another System

This example provides tips on matching encryption results produced by another system.
Chilkat Classic ASP Downloads

Classic ASP
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<%
' This example assumes the Chilkat API to have been previously unlocked.
' See Global Unlock Sample for sample code.

set crypt = Server.CreateObject("Chilkat.Crypt2")

' Let's examine 256-bit AES encryption in CBC mode.
' CBC mode is Cipher Block Chaining, and it uses an IV (initialization vector)
crypt.CryptAlgorithm = "aes"
crypt.CipherMode = "cbc"
crypt.KeyLength = 256
crypt.PaddingScheme = 0
ivHex1 = "000102030405060708090A0B0C0D0E0F"
ivHex2 = "FF0102030405060708090A0B0C0D0E0F"
crypt.SetEncodedIV ivHex1,"hex"
keyHex = "000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F"
crypt.SetEncodedKey keyHex,"hex"

' Matching encryption requires all of the above settings to be matched exactly.
' Let's get our output in hex format so we can easily see the values of the encrypted bytes.
crypt.EncodingMode = "hex"

' Encrypt something small:
Response.Write "<pre>" & Server.HTMLEncode( crypt.EncryptStringENC("Hello")) & "</pre>"
' The result is 5B827AB3B4F9F2292C2B74C8A6C99A3D
' This 16 bytes -- exactly one AES encryption block.

' Let's change only the padding scheme.
crypt.PaddingScheme = 3

' Encrypt again:
Response.Write "<pre>" & Server.HTMLEncode( crypt.EncryptStringENC("Hello")) & "</pre>"
' The result is entirely different: 469C28CC576069F807891FEE2DE76D68

' The padding scheme only affects the very last block of output.  Therefore,
' if all settings match except for the padding scheme, we're unable to
' know if we encrypt a very small amount of data. However, if we encrypt
' a larger amount of data, the single difference becomes apparent:
Response.Write "<pre>" & Server.HTMLEncode( "-- Only the padding scheme differs --") & "</pre>"
crypt.PaddingScheme = 0
Response.Write "<pre>" & Server.HTMLEncode( crypt.EncryptStringENC("HelloHelloHelloHelloHelloHelloHello")) & "</pre>"
crypt.PaddingScheme = 3
Response.Write "<pre>" & Server.HTMLEncode( crypt.EncryptStringENC("HelloHelloHelloHelloHelloHelloHello")) & "</pre>"

' Now examine the outputs:
' F6A201F8E0B6595FA20E4A212A2AD9A5046DAF29E8B35AD15CEE56A1A69F2A3A7B347A7C15E26E7A6760533C7A8E0D44
' F6A201F8E0B6595FA20E4A212A2AD9A5046DAF29E8B35AD15CEE56A1A69F2A3A292CA61D03A85E1AC39B50D4DA71691E
' We can see the output matches except for the last block, which is affected by the padding scheme.

' If we are able to easily use ECB mode w/ the other system
' we are trying to match, then eliminate the IV from the picture.
' If the encryption matches in ECB mode, but not in CBC mode,
' then we know all correct except for the IV.
' For example, you can see how the IV changes everything with CBC mode,
' but it's not used in ECB mode:
crypt.PaddingScheme = 0
crypt.CipherMode = "cbc"
Response.Write "<pre>" & Server.HTMLEncode( "-- Only the IV differs, CBC mode produces different output. --") & "</pre>"
crypt.SetEncodedIV ivHex1,"hex"
Response.Write "<pre>" & Server.HTMLEncode( crypt.EncryptStringENC("HelloHelloHelloHelloHelloHelloHello")) & "</pre>"
crypt.SetEncodedIV ivHex2,"hex"
Response.Write "<pre>" & Server.HTMLEncode( crypt.EncryptStringENC("HelloHelloHelloHelloHelloHelloHello")) & "</pre>"

crypt.CipherMode = "ecb"
Response.Write "<pre>" & Server.HTMLEncode( "-- Only the IV differs, ECB does not use the IV.  The outputs are the same. --") & "</pre>"
crypt.SetEncodedIV ivHex1,"hex"
Response.Write "<pre>" & Server.HTMLEncode( crypt.EncryptStringENC("HelloHelloHelloHelloHelloHelloHello")) & "</pre>"
crypt.SetEncodedIV ivHex2,"hex"
Response.Write "<pre>" & Server.HTMLEncode( crypt.EncryptStringENC("HelloHelloHelloHelloHelloHelloHello")) & "</pre>"

' If we can eliminate the padding scheme and IV from the degrees of freedom,
' then the only remaining likely differences are (1) the secret key,
' and (2) the input data itself.

' The secret key is composed of binary bytes of exactly KeyLength bits.
' For 256-bit AES encrytion, the key length is 256, and therefore the 
' secret key is exactly 32 bytes.  (32 * 8 bits/byte = 256 bits)
' If the secret key is derived from an arbitrary password string, then one must
' exactly duplicate the derivation scheme (such as PBKDF2, for example)
' The input bytes to the derivation scheme must also match.  For example,
' is it the utf-8 byte representation of the password string that is used
' as the starting point for the derivation, or perhaps utf-16, or ANSI (1 byte per char)?

' Likewise, if the data being encrypted is a string, what byte representation of
' the string is being encrypted?  If the bytes presented to the encryptor are different,
' then the output is different.

%>
</body>
</html>