應使用加密式虛擬亂數產生器建立初始化向量 (IV)。不使用隨機 IV 會使得到的加密文字更易於預測，且更易受到 Dictionary 攻擊。

範例 1：以下程式碼會使用非隨機 IV 執行 AES 加密：

...
Blob iv = Blob.valueOf('1234567890123456');
Blob encrypted = Crypto.encrypt('AES128', encKey, iv, input);
...

應使用加密式虛擬亂數產生器建立初始化向量 (IV)。不使用隨機 IV 會使得到的加密文字更易於預測，且更易受到字典攻擊。

範例 1：以下程式碼使用硬式編碼位元組來建立非隨機 IV。

byte[] iv = { 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 };
using (SymmetricAlgorithm aesAlgo = SymmetricAlgorithm.Create("AES"))
{
    ...
    aesAlgo.IV = iv;
    ...
}

應使用加密式虛擬亂數產生器建立初始化向量 (IV)。不使用隨機 IV 會使得到的加密文字更易於預測，且更易受到字典攻擊。

範例 1：以下程式碼使用硬式編碼字串來建立非隨機 IV。

unsigned char * iv = "12345678";
EVP_EncryptInit_ex(&ctx, EVP_idea_gcm(), NULL, key, iv);

使用加密式虛擬亂數產生器建立初始化向量 (IV)。否則，得到的加密文字更易於預測，且更易受到 dictionary 攻擊。

範例 1：以下程式碼重複使用金鑰做為 IV：

import (
    "crypto/aes"
    "crypto/cipher"
    "crypto/rand"
)
...
block, err := aes.NewCipher(key)
...
mode := cipher.NewCBCEncrypter(block, key)
mode.CryptBlocks(ciphertext[aes.BlockSize:], plaintext)

如果您使用金鑰做為 IV，攻擊者可能會復原金鑰，從而允許對資料解密。

請使用加密式虛擬亂數產生器建立初始化向量 (IV)。未能使用隨機 IV，將會使得到的加密文字更易於預測，且更易受到字典攻擊。

範例 1：以下程式碼使用硬式編碼字串來建立非隨機 IV。

...
const iv = "hardcoded"
const cipher = crypto.createCipheriv("aes-192-ccm", key, iv)

應使用加密式虛擬亂數產生器建立初始化向量 (IV)。不使用隨機 IV 會使得到的加密文字更易於預測，且更易受到字典攻擊。

範例 1：以下程式碼使用硬式編碼位元組來建立非隨機 IV。

...
NSString *iv = @"1234567812345678";  //Bad idea to hard code IV
char ivPtr[kCCBlockSizeAES128];

[iv getCString:ivPtr maxLength:sizeof(ivPtr) encoding:NSASCIIStringEncoding];
...
ccStatus = CCCrypt(   kCCEncrypt,
                      kCCAlgorithmAES128,
                      kCCOptionPKCS7Padding,
                      [key cStringUsingEncoding:NSASCIIStringEncoding],
                      kCCKeySizeAES128,
                      [ivPtr], /*IV should be something random (not null and not constant)*/
                      [self bytes], dataLength, /* input */
                      buffer, bufferSize, /* output */
                      &numBytesEncrypted
                  );

此外，如果呼叫 CCCrypt 時已選取 CBC 模式並且未提供 IV (nil)，則會使用所有零的 IV。

應使用加密式虛擬亂數產生器建立初始化向量 (IV)。不使用隨機 IV 會使得到的加密文字更易於預測，且更易受到字典攻擊。

範例 1：以下程式碼重複使用金鑰做為 IV：

from Crypto.Cipher import AES
from Crypto import Random
...
key = Random.new().read(AES.block_size)
cipher = AES.new(key, AES.MODE_CTR, IV=key)

當您使用金鑰做為 IV 時，攻擊者可能會復原金鑰，從而允許解密資料。

應使用加密式虛擬亂數產生器建立初始化向量 (IV)。不使用隨機 IV 會使得到的加密文字更易於預測，且更易受到字典攻擊。

範例 1：以下程式碼重複使用金鑰做為 IV：

require 'openssl'
...
cipher = OpenSSL::Cipher::AES.new('256-GCM')
cipher.encrypt
@key = cipher.random_key
cipher.iv=@key

encrypted = cipher.update(data) + cipher.final # encrypts data without hardcoded IV
...

當您使用金鑰做為 IV 時，攻擊者可能會復原金鑰，從而允許解密資料。

應使用加密式虛擬亂數產生器建立初始化向量 (IV)。不使用隨機 IV 會使得到的加密文字更易於預測，且更易受到字典攻擊。

範例 1：以下程式碼使用硬式編碼位元組來建立非隨機 IV。

...
let cStatus = CCCrypt(UInt32(kCCEncrypt),
UInt32(kCCAlgorithmAES128),
UInt32(kCCOptionPKCS7Padding),
key,
keyLength,
"0123456789012345", 
plaintext, 
plaintextLength,
ciphertext, 
ciphertextLength,
&numBytesEncrypted)

此外，如果呼叫 CCCrypt 時已選取 CBC 模式並且未提供 IV (nil)，則會使用所有零的 IV。

區塊編碼器的作業模式是一種演算法，它描述如何一再套用密碼的單一區塊作業來安全地轉換超過一個區塊的資料量。有些作業模式包含了電子程式碼籍 (ECB)、加密區塊鏈結 (CBC)、加密回饋 (CFB) 和計數器 (CTR)。

在本質上，ECB 模式的安全性較低，因為它會為完全相同的純文字區塊產生一樣的加密文字。CBC 模式容易遭受 Padding oracle 攻擊。CTR 模式則無這些弱點，因此為優先選用的模式。

範例 1：以下程式碼使用 AES 加密搭配 ECB 模式：

  ...
  var objAesCryptoService = new AesCryptoServiceProvider();
  objAesCryptoService.Mode = CipherMode.ECB;
  objAesCryptoService.Padding = PaddingMode.PKCS7;
  objAesCryptoService.Key = securityKeyArray;
  var objCrytpoTransform = objAesCryptoService.CreateEncryptor();
  ...
  

區塊編碼器的作業模式是一種演算法，它描述如何一再套用密碼的單一區塊作業來安全地轉換超過一個區塊的資料量。有些作業模式包含了電子程式碼籍 (ECB)、加密區塊鏈結 (CBC)、加密回饋 (CFB) 和計數器 (CTR)。

在本質上，ECB 模式的安全性較低，因為它會為完全相同的純文字區塊產生一樣的加密文字。CBC 模式容易遭受 Padding oracle 攻擊。CTR 模式則無這些弱點，因此為優先選用的模式。

範例 1：以下程式碼使用 AES 加密搭配 ECB 模式：

EVP_EncryptInit_ex(&ctx, EVP_aes_256_ecb(), NULL, key, iv);

區塊編碼器的作業模式是一種演算法，它描述如何一再套用密碼的單一區塊作業來安全地轉換超過一個區塊的資料量。有些作業模式包含了電子程式碼籍 (ECB)、加密區塊鏈結 (CBC)、加密回饋 (CFB) 和計數器 (CTR)。

在本質上，ECB 模式的安全性較低，因為它會為完全相同的純文字區塊產生一樣的加密文字。CBC 模式容易遭受 Padding oracle 攻擊。CTR 模式則無這些弱點，因此為優先選用的模式。

範例 1：以下程式碼使用 AES 加密搭配 CBC 模式：

...
    block, err := aes.NewCipher(key)
	if err != nil {
		panic(err)
	}

	ciphertext := make([]byte, aes.BlockSize+len(plaintext))
	iv := ciphertext[:aes.BlockSize]
	if _, err := io.ReadFull(rand.Reader, iv); err != nil {
		panic(err)
	}

	mode := cipher.NewCBCEncrypter(block, iv)
	mode.CryptBlocks(ciphertext[aes.BlockSize:], plaintext)
...

過時的加密演算法 (如 DES) 無法再提供可供敏感資料使用的足夠保護。加密演算法依賴金鑰長度做為其中一個能夠確保加密強度的主要機制。加密強度通常是依產生有效金鑰時所需的時間及運算能力來衡量。運算能力的進步，使現在能夠在合理的時間範圍內取得短型密鑰。例如，在 1970 年代初次開發出 DES 演算法時，要破解此演算法中使用的 56 位元金鑰面臨極大的運算困難，但今天可使用平常便可取得的設備，在不到一天內破解 DES。

區塊編碼器的作業模式是一種演算法，它描述如何一再套用密碼的單一區塊作業來安全地轉換超過一個區塊的資料量。有些作業模式包含了電子程式碼籍 (ECB)、加密區塊鏈結 (CBC)、加密回饋 (CFB) 和計數器 (CTR)。

在本質上，ECB 模式的安全性較低，因為它會為完全相同的純文字區塊產生一樣的加密文字。CBC 模式容易遭受 Padding oracle 攻擊。CTR 模式則無這些弱點，因此為優先選用的模式。

範例 1：以下程式碼使用 AES 加密搭配 ECB 模式：

...
ccStatus = CCCrypt( kCCEncrypt,
                    kCCAlgorithmAES,
                    kCCOptionECBMode, // Uses ECB mode
                    key,
                    kCCKeySizeAES128,
                    iv,
                    plaintext,
                    sizeof(plaintext),
                    ciphertext,
                    sizeof(ciphertext),
                    &numBytesEncrypted);
...

區塊編碼器的作業模式是一種演算法，它描述如何一再套用密碼的單一區塊作業來安全地轉換超過一個區塊的資料量。有些作業模式包含了電子程式碼籍 (ECB)、加密區塊鏈結 (CBC)、加密回饋 (CFB) 和計數器 (CTR)。

在本質上，ECB 模式的安全性較低，因為它會為完全相同的純文字區塊產生一樣的加密文字。CBC 模式容易遭受 Padding oracle 攻擊。CTR 模式則無這些弱點，因此為優先選用的模式。

範例 1：以下程式碼使用 AES 加密搭配 ECB 模式：

from Crypto.Cipher import AES
from Crypto import Random
...
key = Random.new().read(AES.block_size)
random_iv = Random.new().read(AES.block_size)
cipher = AES.new(key, AES.MODE_ECB, random_iv)

區塊編碼器的作業模式是一種演算法，它描述如何一再套用密碼的單一區塊作業來安全地轉換超過一個區塊的資料量。有些作業模式包含了電子程式碼籍 (ECB)、加密區塊鏈結 (CBC)、加密回饋 (CFB) 和計數器 (CTR)。

在本質上，ECB 模式的安全性較低，因為它會為完全相同的純文字區塊產生一樣的加密文字。CBC 模式容易遭受 Padding oracle 攻擊。CTR 模式則無這些弱點，因此為優先選用的模式。

範例 1：以下程式碼使用 AES 加密搭配 ECB 模式：

require 'openssl'
...
cipher = OpenSSL::Cipher::AES.new('256-ECB')

區塊編碼器的作業模式是一種演算法，它描述如何一再套用密碼的單一區塊作業來安全地轉換超過一個區塊的資料量。有些作業模式包含了電子程式碼籍 (ECB)、加密區塊鏈結 (CBC)、加密回饋 (CFB) 和計數器 (CTR)。

在本質上，ECB 模式的安全性較低，因為它會為完全相同的純文字區塊產生一樣的加密文字。CBC 模式容易遭受 Padding oracle 攻擊。CTR 模式則無這些弱點，因此為優先選用的模式。

範例 1：以下程式碼使用 AES 加密搭配 ECB 模式：

...
ccStatus = CCCrypt(UInt32(kCCEncrypt),
                UInt32(kCCAlgorithmAES128),
                UInt32(kCCOptionECBMode),
                keyData.bytes,
                keyLength,
                keyData.bytes,
                data.bytes,
                data.length,
                cryptData.mutableBytes,
                cryptData.length,
                &numBytesEncrypted)
...

目前密碼編譯的規範，建議應該使用長度至少為 2048 個位元的金鑰，並搭配使用 RSA 演算法。但是，電腦運算能力以及因子分析技術 [1] 不斷進步，未來不可避免地會增加建議的金鑰長度。

範例 1：以下程式碼使用 RSA 演算法搭配 512 位元加密金鑰。

  static public byte[] EncryptWithRSA(byte[] plaintext, RSAParameters key) {
    try {
      RSACryptoServiceProvider rsa = new RSACryptoServiceProvider(512);
      rsa.ImportParameters(key);
      return rsa.Encrypt(plaintext, true);
    }
    catch(CryptographicException e) {
      Console.WriteLine(e.Message);
      return null;
    }
  }

如果使用對稱式加密法，則金鑰長度必須超過 128 個位元。

目前密碼編譯的規範，建議應該使用長度至少為 2048 個位元的金鑰，並搭配使用 RSA 演算法。但是，電腦運算能力以及因子分析技術 [1] 不斷進步，未來不可避免地會增加建議的金鑰長度。

範例 1：以下程式碼會產生 512 位元的 RSA 加密金鑰。

  EVP_PKEY * get_RSA_key() {
    unsigned long err;
    EVP_PKEY * pkey;
    RSA * rsa;
    rsa = RSA_generate_key(512, 35, NULL, NULL);
    if (rsa == NULL) {
      err = ERR_get_error();
      printf("Error = %s\n",ERR_reason_error_string(err));
      return NULL;
    }
    pkey = EVP_PKEY_new();
    EVP_PKEY_assign_RSA(pkey, rsa);
    return pkey;
  }

如果使用對稱式加密法，則金鑰長度必須超過 128 個位元。

目前密碼編譯的規範建議應該使用長度至少為 2048 個位元的金鑰，並搭配 RSA 演算法使用。若是對稱式加密法，則金鑰長度必須至少為 128 個位元。但是，電腦運算能力以及因子分析技術 [1] 不斷進步，未來不可避免地會增加建議的金鑰長度。

範例 1：以下程式碼會產生 1024 個位元的 RSA 金鑰：

  ...
  myPrivateKey := rsa.GenerateKey(rand.Reader, 1024);
  ...

目前密碼編譯的規範，建議應該使用長度至少為 2048 個位元的金鑰，並搭配使用 RSA 演算法。但是，電腦運算能力以及因子分析技術 [1] 不斷進步，未來不可避免地會增加建議的金鑰長度。

範例 1：以下程式碼會產生 512 位元的 RSA 金鑰。

  ...
  crmfObject = crypto.generateCRMFRequest(
                "CN=" + name.value,
                password.value,
                authenticator,
        	keyTransportCert,
                "setCRMFRequest();",
                512, null, "rsa-dual-use");
  ...

如果使用對稱式加密法，則金鑰長度必須超過 128 個位元。

目前密碼編譯的規範，建議應該使用長度至少為 2048 個位元的金鑰，並搭配使用 RSA 演算法。但是，電腦運算能力以及因子分析技術 [1] 不斷進步，未來不可避免地會增加建議的金鑰長度。如果使用對稱式加密法，則金鑰長度必須超過 128 個位元。

範例 1：以下程式碼使用較弱的加密演算法與長度不足的金鑰。

...
CCCrypt(kCCEncrypt,
        kCCAlgorithmDES,
        kCCOptionPKCS7Padding,
        key,
        kCCKeySizeDES, // 64-bit key size
        iv,
        plaintext,
        sizeof(plaintext),
        ciphertext,
        sizeof(ciphertext),
        &numBytesEncrypted);
...

目前密碼編譯的規範，建議應該使用長度至少為 2048 位元的金鑰，並搭配使用 RSA 演算法。但是，電腦運算能力以及因子分析技術 [1] 不斷進步，未來不可避免地會增加建議的金鑰長度。

範例 1：以下程式碼會產生 1024 位元的 RSA 加密金鑰。

...
$keysize = 1024;
$options = array('private_key_bits' => $keysize, 'private_key_type' => OPENSSL_KEYTYPE_RSA);
$res = openssl_pkey_new($options);
...

如果使用對稱式加密法，則 Triple DES 的金鑰長度應至少為 168 位元，AES 至少為 128 位元。

目前密碼編譯的規範，建議應該使用長度至少為 2048 個位元的金鑰，並搭配使用 RSA 演算法。但是，電腦運算能力以及因子分析技術 [1] 不斷進步，未來不可避免地會增加建議的金鑰長度。

範例 1：以下程式碼會產生 1024 位元的 RSA 加密金鑰。

...
from Crypto.PublicKey import RSA
key = RSA.generate(1024)
...

如果使用對稱式加密法，則 Triple DES 的金鑰長度應至少為 168 位元，AES 至少為 128 位元。

目前密碼編譯的規範，建議應該使用長度至少為 2048 個位元的金鑰，並搭配使用 RSA 演算法。但是，電腦運算能力以及因子分析技術 [1] 不斷進步，未來不可避免地會增加建議的金鑰長度。

範例 1：以下程式碼會產生 1024 位元的 RSA 加密金鑰。

  require 'openssl'
  ...
  pkey = OpenSSL::PKey::RSA.new 1024
  ...
  

如果使用對稱式加密法，則金鑰長度必須至少為 128 個位元才能使用 AES。

目前密碼編譯的規範，建議應該使用長度至少為 2048 個位元的金鑰，並搭配使用 RSA 演算法。但是，電腦運算能力以及因子分析技術 [1] 不斷進步，未來不可避免地會增加建議的金鑰長度。如果使用對稱式加密法，則金鑰長度必須超過 128 個位元。

範例 1：以下程式碼使用較弱的加密演算法與長度不足的金鑰。

...
let iv = getTrueRandomIV()
...
let cStatus = CCCrypt(UInt32(kCCEncrypt),
UInt32(kCCAlgorithmDES),
UInt32(kCCOptionPKCS7Padding),
key,
UInt32(kCCKeySizeDES), // 64-bit key size
iv, 
plaintext, 
plaintextLength,
ciphertext, 
ciphertextLength,
&numBytesEncrypted)
...

目前密碼編譯的規範，建議應該使用長度至少為 2048 個位元的金鑰，並搭配使用 RSA 演算法。但是，電腦運算能力以及因子分析技術 [1] 不斷進步，未來不可避免地會增加建議的金鑰長度。

如果使用對稱式加密法，則金鑰長度必須超過 128 個位元。

產生對稱式金鑰，以及加密或解密機密資訊都需要數個步驟，忽略任何一個必要步驟都會減弱所產生之對稱式金鑰或加密文字的強度，或是不正確地解密現有的加密文字。

範例 1：以下程式碼跳過呼叫 EVP_DecryptUpdate，這會導致解密加密文字失敗。

...
EVP_DecryptInit_ex(&ctx, EVP_aes_256_gcm(), NULL, key, iv);
...
if(!EVP_DecryptFinal_ex(&ctx, outBuf+outBytes, &tmpOutBytes))
  prtErrAndExit(1, "ERROR: EVP_DecryptFinal_ex did not work...\n");
...

產生對稱式金鑰，以及加密或解密機密資訊都需要數個步驟，忽略任何一個必要步驟都會減弱所產生之對稱式金鑰或加密文字的強度，或是不正確地解密現有的加密文字。

範例 1：以下程式碼跳過呼叫 OpenSSL::Cipher#update，這會導致解密加密文字失敗：

require 'openssl'
...
decipher = OpenSSL::Cipher::AES.new(128, :GCM)
decipher.decrypt
decipher.key = key
decipher.iv = iv

plain = decipher.final #missed update method
...

允許使用者控制的值決定金鑰大小，可能會允許攻擊者指定空白金鑰，從而讓解密已使用空白金鑰加密的任何資料變得相對容易。即使需要使用非零值，攻擊者仍可以指定可能的最低值，這會降低加密的安全性。

安全性較低的加密：使用者控制的金鑰大小問題會在以下情況中發生：

1. 資料透過一個不可信賴的來源進入程式

2. 使用者控制的資料包含在金鑰大小參數內，或全部用作加密函數內的金鑰大小參數。

如同許多軟體的安全性弱點一樣，安全性較低的加密：使用者控制的金鑰大小是達到目的的一種手段，而不是一個目的。此弱點的基礎很簡單：攻擊者將惡意資料傳遞到應用程式，然後在執行加密的同時，資料用作金鑰大小值的全部或一部分。

具有使用者控制的金鑰大小的問題便是它會導致各種攻擊：

1. 攻擊者可能使用此弱點為加密作業 (包含攻擊者可存取的任何資料) 指定一個零金鑰大小。通過該方式，嘗試將許多不同的演算法與空白金鑰搭配使用來解密自己的資料，以洩漏應用程式內使用的加密實作相關的資訊將非常容易。這可能會透過允許攻擊者僅關注破解工作期間的特定演算法，讓解密其他使用者的加密資料變得更容易。
2. 攻擊者可能操縱其他使用者的加密金鑰大小，或誘騙其他使用者使用零大小的加密金鑰 (或盡可能小)，這可能會導致攻擊者讀取其他使用者的加密資料 (一旦攻擊者瞭解到所使用的加密演算法)。

範例 1：以下程式碼會使用使用者控制的金鑰大小參數執行 RSA 加密：

    ...
    RSACryptoServiceProvider rsa1 = new RSACryptoServiceProvider(Convert.ToInt32(tx.Text));
    ...
    

Example 1 中的程式碼將成功執行，但可取得此功能的任何人均能夠透過修改文字方塊值 tx.Text 操縱用於加密演算法的金鑰大小參數。程式發佈後，想要復原與使用者控制的金鑰大小相關的問題便會相當棘手，因為很難知道惡意使用者是否已判斷出指定加密作業的金鑰大小。

藉由允許使用者控制的值決定金鑰大小，攻擊者可能會指定空白金鑰，從而讓解密已使用空白金鑰加密的任何資料變得相對容易。即使需要使用非零值，攻擊者仍可以指定可能的最低值，這會降低加密的安全性。

安全性較低的加密：使用者控制的金鑰大小問題會在以下情況中發生：

1.資料透過一個不可信賴的來源進入程式

2.使用者控制的資料包含在金鑰大小參數內，或全部用作加密函數內的金鑰大小參數。

如同許多軟體的安全性弱點一樣，安全性較低的加密：使用者控制的金鑰大小是達到目的的一種手段，而不是一個目的。此弱點的基礎很簡單：攻擊者將惡意資料傳遞到應用程式，然後將該資料用作金鑰大小值的全部或一部分來執行加密。

具有使用者控制的金鑰大小的問題便是它會導致各種攻擊：

1.攻擊者可以使用該弱點為加密作業 (包含攻擊者可存取的任何資料) 指定一個零金鑰大小。然後嘗試將許多不同的演算法與空白金鑰搭配使用來解密自己的資料，以洩漏應用程式內使用的加密實作相關的資訊將非常容易。這可能會透過允許攻擊者僅關注破解工作期間的特定演算法，讓解密其他使用者的加密資料變得更容易。
2.攻擊者可操縱其他使用者的加密金鑰大小，或誘騙其他使用者使用零加密金鑰大小 (或另一個極低的數字)，可能會讓攻擊者讀取其他使用者的加密資料 (在攻擊者已瞭解使用的加密演算法後)。

範例 1：以下程式碼使用使用者控制的衍生金鑰長度產生 RSA 金鑰：

...
rsa.GenerateKey(random, user_input)
...

Example 1 中的程式碼將成功執行，但可取得此功能的任何人均能夠操縱加密演算法的金鑰長度參數，因為變數 user_input 可由使用者控制。發佈軟體後，想要復原與使用者控制的金鑰大小相關的問題便會相當棘手。想知道惡意使用者是否已控制指定加密作業的金鑰大小，難如登天。

允許使用者控制的值決定金鑰大小，可能會允許攻擊者指定空白金鑰，從而讓解密已使用空白金鑰加密的任何資料變得相對容易。即使需要使用非零值，攻擊者仍可以指定可能的最低值，這會降低加密的安全性。

安全性較低的加密：使用者控制的金鑰大小問題會在以下情況中發生：

1. 資料透過一個不可信賴的來源進入程式

2. 使用者控制的資料包含在金鑰大小參數內，或全部用作加密函數內的金鑰大小參數。

如同許多軟體的安全性弱點一樣，安全性較低的加密：使用者控制的金鑰大小是達到目的的一種手段，而不是一個目的。此弱點的基礎很簡單：攻擊者將惡意資料傳遞到應用程式，然後在執行加密的同時，將該資料用作金鑰大小值的全部或一部分。

具有使用者控制的金鑰大小的問題便是它會導致各種攻擊：

1.攻擊者可能使用此弱點為加密作業 (包含攻擊者可存取的任何資料) 指定一個零金鑰大小。通過該方式，嘗試將許多不同的演算法與空白金鑰搭配使用來解密自己的資料，以洩漏應用程式內使用的加密實作相關的資訊將非常容易。這可能會透過允許攻擊者僅關注破解工作期間的特定演算法，讓解密其他使用者的加密資料變得更容易。
2.攻擊者可能操縱其他使用者的加密金鑰大小，或誘騙其他使用者使用零大小的加密金鑰 (或盡可能小)，這可能會導致攻擊者讀取其他使用者的加密資料 (一旦攻擊者瞭解到所使用的加密演算法)。

範例 1：以下程式碼會使用使用者控制的金鑰大小參數執行 AES 加密：

...
@property (strong, nonatomic) IBOutlet UITextField *inputTextField;
...
CCCrypt(kCCEncrypt,
        kCCAlgorithmAES,
        kCCOptionPKCS7Padding,
        key,
        sizeof(_inputTextField.text),
        iv,
        plaintext,
        sizeof(plaintext),
        ciphertext,
        sizeof(ciphertext),
        &numBytesEncrypted);
...

Example 1 中的程式碼將成功執行，但可取得此功能的任何人均將能夠透過修改 UITextField inputTextField 中的文字操縱用於加密演算法的金鑰大小參數。程式發佈後，想要復原與使用者控制的金鑰大小相關的問題便會相當棘手，因為很難知道惡意使用者是否已判斷出指定加密作業的金鑰大小。

允許使用者控制的值決定金鑰大小，可能會允許攻擊者指定空白金鑰，從而讓解密已使用空白金鑰加密的任何資料變得相對容易。即使需要使用非零值，攻擊者仍可以指定可能的最低值，這會降低加密的安全性。

安全性較低的加密：使用者控制的金鑰大小問題會在以下情況中發生：

1.資料透過一個不可信賴的來源進入程式

2.使用者控制的資料包含在金鑰大小參數內，或全部用作加密函數內的金鑰大小參數。

如同許多軟體的安全性弱點一樣，安全性較低的加密：使用者控制的金鑰大小是達到目的的一種手段，而不是一個目的。此弱點的基礎很簡單：攻擊者將惡意資料傳遞到應用程式，然後在執行加密的同時，資料用作金鑰大小值的全部或一部分。

具有使用者控制的金鑰大小的問題便是它會導致各種攻擊：

1.攻擊者可能使用此弱點為加密作業 (包含攻擊者可存取的任何資料) 指定一個零金鑰大小。透過該方式，嘗試將許多不同的演算法與空白金鑰搭配使用來解密自己的資料，以洩漏應用程式內使用的加密實作相關的資訊將非常容易。這可能會透過允許攻擊者僅關注破解工作期間的特定演算法，讓解密其他使用者的加密資料變得更容易。
2.攻擊者可能操縱其他使用者的加密金鑰大小，或誘騙其他使用者使用零大小的加密金鑰 (或盡可能小)，這可能會導致攻擊者讀取其他使用者的加密資料 (一旦攻擊者瞭解到所使用的加密演算法)。

範例 1：以下程式碼從密碼衍生金鑰，但使用由使用者控制的衍生金鑰長度：

...
$hash = hash_pbkdf2('sha256', $password, $random_salt, 100000, strlen($password));
...

Example 1 中的程式碼將成功執行，但可取得此功能的任何人均能夠操縱加密演算法的金鑰長度參數，因為變數 user_input 可由使用者控制。程式發佈後，想要復原與使用者控制的金鑰大小相關的問題便會相當棘手，因為很難知道惡意使用者是否已判斷出指定加密作業的金鑰大小。

允許使用者控制的值決定金鑰大小，可能會允許攻擊者指定空白金鑰，從而讓解密已使用空白金鑰加密的任何資料變得相對容易。即使需要使用非零值，攻擊者仍可以指定可能的最低值，這會降低加密的安全性。

安全性較低的加密：使用者控制的金鑰大小問題會在以下情況中發生：

1. 資料透過一個不可信賴的來源進入程式

2. 使用者控制的資料包含在金鑰大小參數內，或全部用作加密函數內的金鑰大小參數。

如同許多軟體的安全性弱點一樣，安全性較低的加密：使用者控制的金鑰大小是達到目的的一種手段，而不是一個目的。此弱點的基礎很簡單：攻擊者將惡意資料傳遞到應用程式，然後在執行加密的同時，將該資料用作金鑰大小值的全部或一部分。

具有使用者控制的金鑰大小的問題便是它會導致各種攻擊：

1.攻擊者可能使用此弱點為加密作業 (包含攻擊者可存取的任何資料) 指定一個零金鑰大小。通過該方式，嘗試將許多不同的演算法與空白金鑰搭配使用來解密自己的資料，以洩漏應用程式內使用的加密實作相關的資訊將非常容易。這可能會透過允許攻擊者僅關注破解工作期間的特定演算法，讓解密其他使用者的加密資料變得更容易。
2.攻擊者可能操縱其他使用者的加密金鑰大小，或誘騙其他使用者使用零大小的加密金鑰 (或盡可能小)，這可能會導致攻擊者讀取其他使用者的加密資料 (一旦攻擊者瞭解到所使用的加密演算法)。

範例 1：以下程式碼從密碼衍生金鑰，但使用由使用者控制的衍生金鑰長度：

...
dk = hashlib.pbkdf2_hmac('sha256', password, random_salt, 100000, dklen=user_input)
...

Example 1 中的程式碼將成功執行，但可取得此功能的任何人均能夠操縱加密演算法的金鑰長度參數，因為變數 user_input 可由使用者控制。程式發佈後，想要復原與使用者控制的金鑰大小相關的問題便會相當棘手，因為很難知道惡意使用者是否已判斷出指定加密作業的金鑰大小。

允許使用者控制的值決定金鑰大小，可能會允許攻擊者指定空白金鑰，從而讓解密已使用空白金鑰加密的任何資料變得相對容易。即使需要使用非零值，攻擊者仍可以指定可能的最低值，這會降低加密的安全性。

安全性較低的加密：使用者控制的金鑰大小問題會在以下情況中發生：

1. 資料透過一個不可信賴的來源進入程式

2. 使用者控制的資料包含在金鑰大小參數內，或全部用作加密函數內的金鑰大小參數。

如同許多軟體的安全性弱點一樣，安全性較低的加密：使用者控制的金鑰大小是達到目的的一種手段，而不是一個目的。此弱點的基礎很簡單：攻擊者將惡意資料傳遞到應用程式，然後在執行加密的同時，將該資料用作金鑰大小值的全部或一部分。

具有使用者控制的金鑰大小的問題便是它會導致各種攻擊：

1. 攻擊者可能使用此弱點為加密作業 (包含攻擊者可存取的任何資料) 指定一個零金鑰大小。通過該方式，嘗試將許多不同的演算法與空白金鑰搭配使用來解密自己的資料，以洩漏應用程式內使用的加密實作相關的資訊將非常容易。這可能會透過允許攻擊者僅關注破解工作期間的特定演算法，讓解密其他使用者的加密資料變得更容易。
2. 攻擊者可能操縱其他使用者的加密金鑰大小，或誘騙其他使用者使用零大小的加密金鑰 (或盡可能小)，這可能會導致攻擊者讀取其他使用者的加密資料 (一旦攻擊者瞭解到所使用的加密演算法)。

範例 1：以下程式碼從密碼衍生金鑰，但使用由使用者控制的衍生金鑰長度：

...
dk = OpenSSL::PKCS5.pbkdf2_hmac(password, random_salt, 100000, user_input, digest)
...

Example 1 中的程式碼將成功執行，但可取得此功能的任何人均能夠操縱加密演算法的金鑰長度參數，因為變數 user_input 可由使用者控制。程式發佈後，想要復原與使用者控制的金鑰大小相關的問題便會相當棘手，因為很難知道惡意使用者是否已判斷出指定加密作業的金鑰大小。

允許使用者控制的值決定金鑰大小，可能會允許攻擊者指定空白金鑰，從而讓解密已使用空白金鑰加密的任何資料變得相對容易。即使需要使用非零值，攻擊者仍可以指定可能的最低值，這會降低加密的安全性。

安全性較低的加密：使用者控制的金鑰大小問題會在以下情況中發生：

1. 資料透過一個不可信賴的來源進入程式

2. 使用者控制的資料包含在金鑰大小參數內，或全部用作加密函數內的金鑰大小參數。

如同許多軟體的安全性弱點一樣，安全性較低的加密：使用者控制的金鑰大小是達到目的的一種手段，而不是一個目的。此弱點的基礎很簡單：攻擊者將惡意資料傳遞到應用程式，然後在執行加密的同時，資料用作金鑰大小值的全部或一部分。

具有使用者控制的金鑰大小的問題便是它會導致各種攻擊：

1. 攻擊者可能使用此弱點為加密作業 (包含攻擊者可存取的任何資料) 指定一個零金鑰大小。通過該方式，嘗試將許多不同的演算法與空白金鑰搭配使用來解密自己的資料，以洩漏應用程式內使用的加密實作相關的資訊將非常容易。這可能會透過允許攻擊者僅關注破解工作期間的特定演算法，讓解密其他使用者的加密資料變得更容易。
2. 攻擊者可能操縱其他使用者的加密金鑰大小，或誘騙其他使用者使用零大小的加密金鑰 (或盡可能小)，這可能會導致攻擊者讀取其他使用者的加密資料 (一旦攻擊者瞭解到所使用的加密演算法)。

範例 1：以下程式碼會使用使用者控制的金鑰大小參數執行 AES 加密：

...
@IBOutlet weak var inputTextField : UITextField!
...
let key = (inputTextField.text as NSString).dataUsingEncoding(NSUTF8StringEncoding)
let keyPointer = UnsafePointer<UInt8>(key.bytes)
let keyLength = size_t(key.length)
...
let operation : CCOperation = UInt32(kCCEncrypt)
let algoritm : CCAlgorithm = UInt32(kCCAlgorithmAES128)
let options : CCOptions = UInt32(kCCOptionPKCS7Padding)
var numBytesEncrypted :size_t = 0
CCCrypt(operation,
        algorithm,
        options,
        keyPointer,
        keyLength,
        iv,
        plaintextPointer,
        plaintextLength,
        ciphertextPointer,
        ciphertextLength,
        &numBytesEncrypted)
...

Example 1 中的程式碼將成功執行，但可取得此功能的任何人均將能夠透過修改 UITextField inputTextField 中的文字操縱用於加密演算法的金鑰大小參數。程式發佈後，想要復原與使用者控制的金鑰大小相關的問題便會相當棘手，因為很難知道惡意使用者是否已判斷出指定加密作業的金鑰大小。