Os vetores de inicialização (IVs) devem ser criados usando um gerador criptográfico de números pseudoaleatórios. Sem usar um IV aleatório, o texto criptografado resultante se torna muito mais previsível e suscetível a um ataque de dicionário (Dictionary Attack).

Exemplo 1: O seguinte código realiza a criptografia AES usando um IV não aleatório:

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

Vetores de inicialização (VIs) devem ser criados com o uso de um gerador de números pseudoaleatórios criptográfico. A não utilização de um VI aleatório torna o texto cifrado resultante muito mais previsível e suscetível a um ataque de dicionário.

Exemplo 1: O código a seguir cria um IV não aleatório usando bytes codificados.

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

Vetores de inicialização (VIs) devem ser criados com o uso de um gerador de números pseudoaleatórios criptográfico. A não utilização de um VI aleatório torna o texto cifrado resultante muito mais previsível e suscetível a um ataque de dicionário.

Exemplo 1: O código a seguir cria um VI não aleatório usando uma string inserida em código fixo.

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

Use um gerador de números pseudoaleatórios criptográficos para criar vetores de inicialização (IVs). Caso contrário, o texto cifrado resultante será mais previsível e suscetível a um ataque de dicionário.

Exemplo 1: Este código reutiliza a chave como o IV:

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

Se você usa a chave como o IV, os invasores podem recuperar a chave, o que lhes permite decifrar os dados.

Crie os vetores de inicialização (IVs) usando um gerador criptográfico de números pseudoaleatórios. A falha em usar um IV aleatório torna o texto criptografado resultante muito mais previsível e suscetível a um ataque de dicionário.

Exemplo 1: O código a seguir cria um IV não aleatório usando uma string embutida em código.

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

Vetores de inicialização (VIs) devem ser criados com o uso de um gerador de números pseudoaleatórios criptográfico. A não utilização de um VI aleatório torna o texto cifrado resultante muito mais previsível e suscetível a um ataque de dicionário.

Exemplo 1: O código a seguir cria um IV não aleatório usando bytes codificados.

...
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
                  );

Além disso, se o modo CBC for selecionado ao chamar o CCCrypt e nenhum IV for fornecido (nil), então um IV de todos os zeros será utilizado.

Vetores de inicialização (VIs) devem ser criados com o uso de um gerador de números pseudoaleatórios criptográfico. A não utilização de um VI aleatório torna o texto cifrado resultante muito mais previsível e suscetível a um ataque de dicionário.

Exemplo 1: Este código reutiliza a chave como o 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)

Quando você usa a chave como o IV, um invasor pode recuperar a chave, permitindo que os dados sejam decifrados.

Vetores de inicialização (VIs) devem ser criados com o uso de um gerador de números pseudoaleatórios criptográfico. A não utilização de um VI aleatório torna o texto cifrado resultante muito mais previsível e suscetível a um ataque de dicionário.

Exemplo 1: Este código reutiliza a chave como o 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
...

Quando você usa a chave como o IV, um invasor pode recuperar a chave, permitindo que os dados sejam decifrados.

Vetores de inicialização (VIs) devem ser criados com o uso de um gerador de números pseudoaleatórios criptográfico. A não utilização de um VI aleatório torna o texto cifrado resultante muito mais previsível e suscetível a um ataque de dicionário.

Exemplo 1: O código a seguir cria um IV não aleatório usando bytes codificados.

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

Além disso, se o modo CBC for selecionado ao chamar o CCCrypt e nenhum IV for fornecido (nil), então um IV de todos os zeros será utilizado.

O modo de operação de um código cifrado em bloco é um algoritmo que descreve como aplicar repetidamente a operação de bloco único de um código cifrado para transformar com segurança quantidades de dados maiores do que um bloco. Alguns modos de operação incluem Electronic Codebook (ECB), Cipher Block Chaining (CBC), Cipher Feedback (CFB) e Counter (CTR).

O modo ECB é inerentemente fraco, pois produz o mesmo texto cifrado para blocos idênticos de texto sem formatação. O modo CBC é vulnerável aos ataques de padding oracle. O modo CTR é a melhor opção porque não apresenta essas vulnerabilidades.

Exemplo 1: O seguinte código usa o código cifrado AES com o modo ECB:

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

O modo de operação de um código cifrado em bloco é um algoritmo que descreve como aplicar repetidamente a operação de bloco único de um código cifrado para transformar com segurança quantidades de dados maiores do que um bloco. Alguns modos de operação incluem Electronic Codebook (ECB), Cipher Block Chaining (CBC), Cipher Feedback (CFB) e Counter (CTR).

O modo ECB é inerentemente fraco, pois produz o mesmo texto cifrado para blocos idênticos de texto sem formatação. O modo CBC é vulnerável aos ataques de padding oracle. O modo CTR é a melhor opção porque não apresenta essas vulnerabilidades.

Exemplo 1: O seguinte código usa o código cifrado AES com o modo ECB:

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

O modo de operação de um código cifrado em bloco é um algoritmo que descreve como aplicar repetidamente a operação de bloco único de um código cifrado para transformar com segurança quantidades de dados maiores do que um bloco. Alguns modos de operação incluem Electronic Codebook (ECB), Cipher Block Chaining (CBC), Cipher Feedback (CFB) e Counter (CTR).

O modo ECB é inerentemente fraco, pois produz o mesmo texto cifrado para blocos idênticos de texto sem formatação. O modo CBC é vulnerável aos ataques de padding oracle. O modo CTR é a melhor opção porque não apresenta essas vulnerabilidades.

Exemplo 1: O seguinte código usa o código cifrado AES com o modo 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)
...

Algoritmos de criptografia antiquados, como o DES, não oferecem proteção suficiente para uso com dados confidenciais. Algoritmos de criptografia dependem do tamanho da chave como um dos principais mecanismos para garantir a segurança criptográfica. A força criptográfica é medida frequentemente pelo tempo e pela capacidade computacional necessários para a geração de uma chave válida. Avanços na capacidade computacional possibilitaram a obtenção de chaves de criptografia pequenas em um tempo razoável. Por exemplo, a chave de 56 bits usada no DES representava um obstáculo computacional significativo na década de 1970, quando o algoritmo foi desenvolvido, mas hoje o DES pode ser quebrado em menos de um dia usando equipamentos disponíveis normalmente.

O modo de operação de um código cifrado em bloco é um algoritmo que descreve como aplicar repetidamente a operação de bloco único de um código cifrado para transformar com segurança quantidades de dados maiores do que um bloco. Alguns modos de operação incluem Electronic Codebook (ECB), Cipher Block Chaining (CBC), Cipher Feedback (CFB) e Counter (CTR).

O modo ECB é inerentemente fraco, pois produz o mesmo texto cifrado para blocos idênticos de texto sem formatação. O modo CBC é vulnerável aos ataques de padding oracle. O modo CTR é a melhor opção porque não apresenta essas vulnerabilidades.

Exemplo 1: O seguinte código usa o código cifrado AES com o modo ECB:

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

O modo de operação de um código cifrado em bloco é um algoritmo que descreve como aplicar repetidamente a operação de bloco único de um código cifrado para transformar com segurança quantidades de dados maiores do que um bloco. Alguns modos de operação incluem Electronic Codebook (ECB), Cipher Block Chaining (CBC), Cipher Feedback (CFB) e Counter (CTR).

O modo ECB é inerentemente fraco, pois produz o mesmo texto cifrado para blocos idênticos de texto sem formatação. O modo CBC é vulnerável aos ataques de padding oracle. O modo CTR é a melhor opção porque não apresenta essas vulnerabilidades.

Exemplo 1: O seguinte código usa o código cifrado AES com o modo 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)

O modo de operação de um código cifrado em bloco é um algoritmo que descreve como aplicar repetidamente a operação de bloco único de um código cifrado para transformar com segurança quantidades de dados maiores do que um bloco. Alguns modos de operação incluem Electronic Codebook (ECB), Cipher Block Chaining (CBC), Cipher Feedback (CFB) e Counter (CTR).

O modo ECB é inerentemente fraco, pois produz o mesmo texto cifrado para blocos idênticos de texto sem formatação. O modo CBC é vulnerável aos ataques de padding oracle. O modo CTR é a melhor opção porque não apresenta essas vulnerabilidades.

Exemplo 1: O seguinte código usa o código cifrado AES com o modo ECB:

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

O modo de operação de um código cifrado em bloco é um algoritmo que descreve como aplicar repetidamente a operação de bloco único de um código cifrado para transformar com segurança quantidades de dados maiores do que um bloco. Alguns modos de operação incluem Electronic Codebook (ECB), Cipher Block Chaining (CBC), Cipher Feedback (CFB) e Counter (CTR).

O modo ECB é inerentemente fraco, pois produz o mesmo texto cifrado para blocos idênticos de texto sem formatação. O modo CBC é vulnerável aos ataques de padding oracle. O modo CTR é a melhor opção porque não apresenta essas vulnerabilidades.

Exemplo 1: O seguinte código usa o código cifrado AES com o modo ECB:

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

As diretrizes de criptografia atuais sugerem que um comprimento de chave de pelo menos 2048 bits deve ser usado com o algoritmo RSA. No entanto, os avanços contínuos na capacidade computacional e em técnicas de fatoração [1] significam que aumentos futuros no tamanho de chave recomendado são inevitáveis.

Exemplo 1: O código a seguir usa o algoritmo RSA com uma chave de criptografia de 512 bits.

  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;
    }
  }

Quando se trata de criptografia simétrica, os comprimentos de chaves devem ser de pelo menos 128 bits.

As diretrizes de criptografia atuais sugerem que um comprimento de chave de pelo menos 2048 bits deve ser usado com o algoritmo RSA. No entanto, os avanços contínuos na capacidade computacional e em técnicas de fatoração [1] significam que aumentos futuros no tamanho de chave recomendado são inevitáveis.

Exemplo 1: O código a seguir gera uma chave de criptografia RSA de 512 bits.

  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;
  }

Quando se trata de criptografia simétrica, os comprimentos de chaves devem ser de pelo menos 128 bits.

As diretrizes de criptografia atuais sugerem que um comprimento de chave de pelo menos 2048 bits deve ser usado com o algoritmo RSA. Para criptografia simétrica, os comprimentos de chaves devem ser de pelo menos 128 bits. No entanto, os avanços contínuos na capacidade computacional e em técnicas de fatoração [1] significam que aumentos futuros no tamanho de chave recomendado são inevitáveis.

Exemplo 1: O seguinte código gera uma chave RSA de 1024 bits:

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

As diretrizes de criptografia atuais sugerem que um comprimento de chave de pelo menos 2048 bits deve ser usado com o algoritmo RSA. No entanto, os avanços contínuos na capacidade computacional e em técnicas de fatoração [1] significam que aumentos futuros no tamanho de chave recomendado são inevitáveis.

Exemplo 1: O código a seguir gera uma chave RSA de 512 bits.

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

Quando se trata de criptografia simétrica, os comprimentos de chaves devem ser de pelo menos 128 bits.

As diretrizes de criptografia atuais sugerem que um comprimento de chave de pelo menos 2048 bits deve ser usado com o algoritmo RSA. No entanto, os avanços contínuos na capacidade computacional e em técnicas de fatoração [1] significam que aumentos futuros no tamanho de chave recomendado são inevitáveis. Quando se trata de criptografia simétrica, os comprimentos de chaves devem ser de pelo menos 128 bits.

Exemplo 1: O código a seguir usa um algoritmo de criptografia fraco e um tamanho de chave insuficiente.

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

As diretrizes de criptografia atuais sugerem que um comprimento de chave de pelo menos 2048 bits deve ser usado com o algoritmo RSA. No entanto, os avanços contínuos na capacidade computacional e em técnicas de fatoração [1] significam que aumentos futuros no tamanho de chave recomendado são inevitáveis.

Exemplo 1: O código a seguir gera uma chave de criptografia RSA de 1024 bits.

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

Quando se trata de criptografia simétrica, os comprimentos de chave devem ser de pelo menos 168 bits para Triple DES e 128 bits para AES.

As diretrizes de criptografia atuais sugerem que um comprimento de chave de pelo menos 2048 bits deve ser usado com o algoritmo RSA. No entanto, os avanços contínuos na capacidade computacional e em técnicas de fatoração [1] significam que aumentos futuros no tamanho de chave recomendado são inevitáveis.

Exemplo 1: O código a seguir gera uma chave de criptografia RSA de 1024 bits.

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

Quando se trata de criptografia simétrica, os comprimentos de chave devem ser de pelo menos 168 bits para Triple DES e 128 bits para AES.

As diretrizes de criptografia atuais sugerem que um comprimento de chave de pelo menos 2048 bits deve ser usado com o algoritmo RSA. No entanto, os avanços contínuos na capacidade computacional e em técnicas de fatoração [1] significam que aumentos futuros no tamanho de chave recomendado são inevitáveis.

Exemplo 1: O código a seguir gera uma chave de criptografia RSA de 1024 bits.

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

Quando se trata de criptografia simétrica, os comprimentos de chave devem ser de pelo menos 128 bits para AES.

As diretrizes de criptografia atuais sugerem que um comprimento de chave de pelo menos 2048 bits deve ser usado com o algoritmo RSA. No entanto, os avanços contínuos na capacidade computacional e em técnicas de fatoração [1] significam que aumentos futuros no tamanho de chave recomendado são inevitáveis. Quando se trata de criptografia simétrica, os comprimentos de chaves devem ser de pelo menos 128 bits.

Exemplo 1: O código a seguir usa um algoritmo de criptografia fraco e um tamanho de chave insuficiente.

...
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)
...

As diretrizes de criptografia atuais sugerem que um comprimento de chave de pelo menos 2048 bits deve ser usado com o algoritmo RSA. No entanto, os avanços contínuos na capacidade computacional e em técnicas de fatoração [1] significam que aumentos futuros no tamanho de chave recomendado são inevitáveis.

Quando se trata de criptografia simétrica, os comprimentos de chaves devem ser de pelo menos 128 bits.

A geração de chaves simétricas e a criptografia ou descriptografia de segredos são procedimentos que envolvem várias etapas, e a não realização de qualquer uma dessas etapas necessárias pode comprometer a força das chaves simétricas ou do texto cifrado gerados, ou ainda resultar na descriptografia incorreta de um texto cifrado existente.

Exemplo 1: O código a seguir ignora a chamada para EVP_DecryptUpdate, o que resultará na incapacidade de descriptografar o texto cifrado.

...
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");
...

A geração de chaves simétricas e a criptografia ou descriptografia de segredos são procedimentos que envolvem várias etapas, e a não realização de qualquer uma dessas etapas necessárias pode comprometer a força das chaves simétricas ou do texto cifrado gerados, ou ainda resultar na descriptografia incorreta de um texto cifrado existente.

Exemplo 1: Este código ignora a chamada de OpenSSL::Cipher#update, o que resultará em uma falha ao decifrar o texto criptografado:

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

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

Permitir que um valor controlado pelo usuário determine o tamanho da chave pode fazer com que o invasor seja capaz de especificar uma chave vazia, facilitando assim a descriptografia de quaisquer dados que tenham sido criptografados com essa chave vazia. Mesmo que um valor diferente de zero seja necessário, um invasor ainda pode especificar o menor valor possível, diminuindo a segurança da criptografia.

Problemas de Criptografia Fraca: Tamanho de Chave Controlado pelo Usuário ocorrem quando:

1. Dados entram em um programa através de uma fonte não confiável

2. Dados controlados pelo usuário são incluídos no parâmetro de tamanho de chave, ou usados inteiramente como o parâmetro de tamanho de chave dentro de uma função de criptografia.

Tal como acontece com muitas vulnerabilidades de segurança de software, a vulnerabilidades de Criptografia fraca: Um tamanho de chave controlado pelo usuário é um meio para um fim, e não um fim em si mesmo. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados para um aplicativo, e esses dados são então usados como todo ou parte do valor de tamanho da chave durante a realização da criptografia.

O problema em se ter um tamanho de chave controlado pelo usuário é que ele pode permitir vários ataques:

1. O invasor pode usar essa vulnerabilidade para especificar um tamanho de chave igual a zero para as operações de criptografia que envolvem dados que ele pode acessar. Desse ponto em diante, seria simples para ele tentar descriptografar seus próprios dados usando vários algoritmos diferentes junto com chaves vazias a fim de deixar vazar informações sobre a implementação da criptografia utilizada no aplicativo. Isto pode facilitar a descriptografia dos dados criptografados de outros usuários, permitindo que o invasor se concentre apenas em algoritmos específicos durante seus esforços de cracking.
2. O invasor pode manipular tamanhos de chaves de criptografia de outros usuários ou enganar esses usuários a ponto de levá-los a usar um tamanho de chave de criptografia igual a zero (ou o mais baixo possível), potencialmente permitindo que o invasor leia os dados criptografados de outros usuários (já que ele tem conhecimento do algoritmo de criptografia utilizado).

Exemplo 1: O código a seguir realiza uma criptografia RSA com um parâmetro de tamanho de chave controlado pelo usuário:

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

O código no Example 1 será executado com êxito, mas qualquer pessoa que possa chegar a essa funcionalidade conseguirá manipular o parâmetro de tamanho de chave do algoritmo de criptografia modificando a o valor da caixa de texto tx.Text. Após a distribuição do programa, pode ser difícil desfazer um problema com tamanhos de chave controlados pelo usuário, pois seria extremamente difícil saber se um usuário mal-intencionado determinou o tamanho da chave de uma determinada operação de criptografia.

Ao permitir que um valor controlado pelo usuário determine o tamanho da chave, um invasor pode especificar uma chave vazia, o que permite com relativa facilidade a descriptografia de quaisquer dados que tenham sido criptografados com essa chave vazia. Mesmo que um valor diferente de zero seja necessário, um invasor ainda pode especificar o menor valor possível, diminuindo a segurança da criptografia.

Problemas de Criptografia Fraca: Tamanho de Chave Controlado pelo Usuário ocorrem quando:

1. Dados entram em um programa através de uma fonte não confiável

2. Dados controlados pelo usuário são incluídos no parâmetro de tamanho de chave, ou usados inteiramente como o parâmetro de tamanho de chave dentro de uma função de criptografia.

Tal como acontece com muitas vulnerabilidades de segurança de software, a vulnerabilidades de Criptografia fraca: Um tamanho de chave controlado pelo usuário é um meio para um fim, e não um fim em si mesmo. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados para um aplicativo, e esses dados são então usados como todo ou parte do valor de tamanho da chave para realizar a criptografia.

O problema em se ter um tamanho de chave controlado pelo usuário é que ele pode permitir vários ataques:

1. O invasor pode usar essa vulnerabilidade para especificar um tamanho de chave igual a zero para as operações de criptografia que envolvem dados que ele pode acessar. Seria simples tentar descriptografar seus próprios dados usando vários algoritmos diferentes junto com chaves vazias para vazar informações da implementação da criptografia utilizada no aplicativo. Isto pode facilitar a descriptografia dos dados criptografados de outros usuários, permitindo que o invasor se concentre apenas em algoritmos específicos durante seus esforços de cracking.
2. O invasor pode manipular tamanhos de chaves de criptografia de outros usuários ou enganar esses usuários a ponto de levá-los a usar um tamanho de chave de criptografia igual a zero (ou outro número menor), potencialmente permitindo que o invasor leia os dados criptografados de outros usuários (depois que ele tiver conhecimento do algoritmo de criptografia utilizado).

Exemplo 1: O código a seguir gera uma chave RSA com um tamanho de chave controlado pelo usuário:

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

O código no Example 1 será executado com êxito, mas qualquer um que possa chegar a essa funcionalidade será capaz de manipular o parâmetro chave de tamanho para o algoritmo de criptografia, uma vez que a variável user_input pode ser controlada pelo usuário. Após a liberação do software, pode ser difícil desfazer um problema com tamanhos de chave controlados pelo usuário. É extremamente difícil saber se um usuário mal-intencionado controlava o tamanho da chave de uma determinada operação de criptografia.

Permitir que um valor controlado pelo usuário determine o tamanho da chave pode fazer com que o invasor seja capaz de especificar uma chave vazia, facilitando assim a descriptografia de quaisquer dados que tenham sido criptografados com essa chave vazia. Mesmo que um valor diferente de zero seja necessário, um invasor ainda pode especificar o menor valor possível, diminuindo a segurança da criptografia.

Problemas de Criptografia Fraca: Tamanho de Chave Controlado pelo Usuário ocorrem quando:

1. Dados entram em um programa através de uma fonte não confiável

2. Dados controlados pelo usuário são incluídos no parâmetro de tamanho de chave, ou usados inteiramente como o parâmetro de tamanho de chave dentro de uma função de criptografia.

Tal como acontece com muitas vulnerabilidades de segurança de software, a vulnerabilidades de Criptografia fraca: Um tamanho de chave controlado pelo usuário é um meio para um fim, e não um fim em si mesmo. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados para um aplicativo, e esses dados são então usados como todo ou parte do valor de tamanho da chave durante a realização da criptografia.

O problema em se ter um tamanho de chave controlado pelo usuário é que ele pode permitir vários ataques:

1. O invasor pode usar essa vulnerabilidade para especificar um tamanho de chave igual a zero para as operações de criptografia que envolvem dados que ele pode acessar. Desse ponto em diante, seria simples para ele tentar descriptografar seus próprios dados usando vários algoritmos diferentes junto com chaves vazias a fim de deixar vazar informações sobre a implementação da criptografia utilizada no aplicativo. Isto pode facilitar a descriptografia dos dados criptografados de outros usuários, permitindo que o invasor se concentre apenas em algoritmos específicos durante seus esforços de cracking.
2. O invasor pode manipular tamanhos de chaves de criptografia de outros usuários ou enganar esses usuários a ponto de levá-los a usar um tamanho de chave de criptografia igual a zero (ou o mais baixo possível), potencialmente permitindo que o invasor leia os dados criptografados de outros usuários (já que ele tem conhecimento do algoritmo de criptografia utilizado).

Exemplo 1: O código a seguir realiza uma criptografia AES com um parâmetro de tamanho de chave controlado pelo usuário:

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

O código no Example 1 será executado com êxito, qualquer pessoa que puder acessar essa funcionalidade conseguirá manipular o parâmetro de tamanho de chave para o algoritmo de criptografia modificando o texto no UITextField inputTextField. Após a distribuição do programa, pode ser difícil desfazer um problema com tamanhos de chave controlados pelo usuário, pois seria extremamente difícil saber se um usuário mal-intencionado determinou o tamanho da chave de uma determinada operação de criptografia.

Permitir que um valor controlado pelo usuário determine o tamanho da chave pode fazer com que o invasor seja capaz de especificar uma chave vazia, facilitando assim a descriptografia de quaisquer dados que tenham sido criptografados com essa chave vazia. Mesmo que um valor diferente de zero seja necessário, um invasor ainda pode especificar o menor valor possível, diminuindo a segurança da criptografia.

Problemas de Criptografia Fraca: Tamanho de Chave Controlado pelo Usuário ocorrem quando:

1. Dados entram em um programa através de uma fonte não confiável

2. Dados controlados pelo usuário são incluídos no parâmetro de tamanho de chave, ou usados inteiramente como o parâmetro de tamanho de chave dentro de uma função de criptografia.

Tal como acontece com muitas vulnerabilidades de segurança de software, a vulnerabilidades de Criptografia fraca: Um tamanho de chave controlado pelo usuário é um meio para um fim, e não um fim em si mesmo. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados para um aplicativo, e esses dados são então usados como todo ou parte do valor de tamanho da chave durante a realização da criptografia.

O problema em se ter um tamanho de chave controlado pelo usuário é que ele pode permitir vários ataques:

1. O invasor pode usar essa vulnerabilidade para especificar um tamanho de chave igual a zero para as operações de criptografia que envolvem dados que ele pode acessar. Desse ponto em diante, seria simples para ele tentar descriptografar seus próprios dados usando vários algoritmos diferentes junto com chaves vazias a fim de deixar vazar informações sobre a implementação da criptografia utilizada no aplicativo. Isto pode facilitar a descriptografia dos dados criptografados de outros usuários, permitindo que o invasor se concentre apenas em algoritmos específicos durante seus esforços de cracking.
2. O invasor pode manipular tamanhos de chaves de criptografia de outros usuários ou enganar esses usuários a ponto de levá-los a usar um tamanho de chave de criptografia igual a zero (ou o mais baixo possível), potencialmente permitindo que o invasor leia os dados criptografados de outros usuários (já que ele tem conhecimento do algoritmo de criptografia utilizado).

Exemplo 1:Este código deriva uma chave de uma senha, mas usa um tamanho de chave derivada controlado pelo usuário:

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

O código no Example 1 será executado com êxito, mas qualquer um que possa chegar a essa funcionalidade será capaz de manipular o parâmetro chave de tamanho para o algoritmo de criptografia, uma vez que a variável user_input pode ser controlada pelo usuário. Após a distribuição do programa, pode ser difícil desfazer um problema com tamanhos de chave controlados pelo usuário, pois seria extremamente difícil saber se um usuário mal-intencionado determinou o tamanho da chave de uma determinada operação de criptografia.

Permitir que um valor controlado pelo usuário determine o tamanho da chave pode fazer com que o invasor seja capaz de especificar uma chave vazia, facilitando assim a descriptografia de quaisquer dados que tenham sido criptografados com essa chave vazia. Mesmo que um valor diferente de zero seja necessário, um invasor ainda pode especificar o menor valor possível, diminuindo a segurança da criptografia.

Problemas de Criptografia Fraca: Tamanho de Chave Controlado pelo Usuário ocorrem quando:

1. Dados entram em um programa através de uma fonte não confiável

2. Dados controlados pelo usuário são incluídos no parâmetro de tamanho de chave, ou usados inteiramente como o parâmetro de tamanho de chave dentro de uma função de criptografia.

Tal como acontece com muitas vulnerabilidades de segurança de software, a vulnerabilidades de Criptografia fraca: Um tamanho de chave controlado pelo usuário é um meio para um fim, e não um fim em si mesmo. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados para um aplicativo, e esses dados são então usados como todo ou parte do valor de tamanho da chave durante a realização da criptografia.

O problema em se ter um tamanho de chave controlado pelo usuário é que ele pode permitir vários ataques:

1. O invasor pode usar essa vulnerabilidade para especificar um tamanho de chave igual a zero para as operações de criptografia que envolvem dados que ele pode acessar. Desse ponto em diante, seria simples para ele tentar descriptografar seus próprios dados usando vários algoritmos diferentes junto com chaves vazias a fim de deixar vazar informações sobre a implementação da criptografia utilizada no aplicativo. Isto pode facilitar a descriptografia dos dados criptografados de outros usuários, permitindo que o invasor se concentre apenas em algoritmos específicos durante seus esforços de cracking.
2. O invasor pode manipular tamanhos de chaves de criptografia de outros usuários ou enganar esses usuários a ponto de levá-los a usar um tamanho de chave de criptografia igual a zero (ou o mais baixo possível), potencialmente permitindo que o invasor leia os dados criptografados de outros usuários (já que ele tem conhecimento do algoritmo de criptografia utilizado).

Exemplo 1: Este código deriva uma chave de uma senha, mas usa um tamanho de chave derivada controlado pelo usuário:

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

O código no Example 1 será executado com êxito, mas qualquer um que possa chegar a essa funcionalidade será capaz de manipular o parâmetro chave de tamanho para o algoritmo de criptografia, uma vez que a variável user_input pode ser controlada pelo usuário. Após a distribuição do programa, pode ser difícil desfazer um problema com tamanhos de chave controlados pelo usuário, pois seria extremamente difícil saber se um usuário mal-intencionado determinou o tamanho da chave de uma determinada operação de criptografia.

Permitir que um valor controlado pelo usuário determine o tamanho da chave pode fazer com que o invasor seja capaz de especificar uma chave vazia, facilitando assim a descriptografia de quaisquer dados que tenham sido criptografados com essa chave vazia. Mesmo que um valor diferente de zero seja necessário, um invasor ainda pode especificar o menor valor possível, diminuindo a segurança da criptografia.

Problemas de Criptografia Fraca: Tamanho de Chave Controlado pelo Usuário ocorrem quando:

1. Dados entram em um programa através de uma fonte não confiável

2. Dados controlados pelo usuário são incluídos no parâmetro de tamanho de chave, ou usados inteiramente como o parâmetro de tamanho de chave dentro de uma função de criptografia.

Tal como acontece com muitas vulnerabilidades de segurança de software, a vulnerabilidades de Criptografia fraca: Um tamanho de chave controlado pelo usuário é um meio para um fim, e não um fim em si mesmo. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados para um aplicativo, e esses dados são então usados como todo ou parte do valor de tamanho da chave durante a realização da criptografia.

O problema em se ter um tamanho de chave controlado pelo usuário é que ele pode permitir vários ataques:

1. O invasor pode usar essa vulnerabilidade para especificar um tamanho de chave igual a zero para as operações de criptografia que envolvem dados que ele pode acessar. Desse ponto em diante, seria simples para ele tentar descriptografar seus próprios dados usando vários algoritmos diferentes junto com chaves vazias a fim de deixar vazar informações sobre a implementação da criptografia utilizada no aplicativo. Isto pode facilitar a descriptografia dos dados criptografados de outros usuários, permitindo que o invasor se concentre apenas em algoritmos específicos durante seus esforços de cracking.
2. O invasor pode manipular tamanhos de chaves de criptografia de outros usuários ou enganar esses usuários a ponto de levá-los a usar um tamanho de chave de criptografia igual a zero (ou o mais baixo possível), potencialmente permitindo que o invasor leia os dados criptografados de outros usuários (já que ele tem conhecimento do algoritmo de criptografia utilizado).

Exemplo 1: Este código deriva uma chave de uma senha, mas usa um tamanho de chave derivada controlado pelo usuário:

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

O código no Example 1 será executado com êxito, mas qualquer um que possa chegar a essa funcionalidade será capaz de manipular o parâmetro chave de tamanho para o algoritmo de criptografia, uma vez que a variável user_input pode ser controlada pelo usuário. Após a distribuição do programa, pode ser difícil desfazer um problema com tamanhos de chave controlados pelo usuário, pois seria extremamente difícil saber se um usuário mal-intencionado determinou o tamanho da chave de uma determinada operação de criptografia.

Permitir que um valor controlado pelo usuário determine o tamanho da chave pode fazer com que o invasor seja capaz de especificar uma chave vazia, facilitando assim a descriptografia de quaisquer dados que tenham sido criptografados com essa chave vazia. Mesmo que um valor diferente de zero seja necessário, um invasor ainda pode especificar o menor valor possível, diminuindo a segurança da criptografia.

Problemas de Criptografia Fraca: Tamanho de Chave Controlado pelo Usuário ocorrem quando:

1. Dados entram em um programa através de uma fonte não confiável

2. Dados controlados pelo usuário são incluídos no parâmetro de tamanho de chave, ou usados inteiramente como o parâmetro de tamanho de chave dentro de uma função de criptografia.

Tal como acontece com muitas vulnerabilidades de segurança de software, a vulnerabilidades de Criptografia fraca: Um tamanho de chave controlado pelo usuário é um meio para um fim, e não um fim em si mesmo. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados para um aplicativo, e esses dados são então usados como todo ou parte do valor de tamanho da chave durante a realização da criptografia.

O problema em se ter um tamanho de chave controlado pelo usuário é que ele pode permitir vários ataques:

1. O invasor pode usar essa vulnerabilidade para especificar um tamanho de chave igual a zero para as operações de criptografia que envolvem dados que ele pode acessar. Desse ponto em diante, seria simples para ele tentar descriptografar seus próprios dados usando vários algoritmos diferentes junto com chaves vazias a fim de deixar vazar informações sobre a implementação da criptografia utilizada no aplicativo. Isto pode facilitar a descriptografia dos dados criptografados de outros usuários, permitindo que o invasor se concentre apenas em algoritmos específicos durante seus esforços de cracking.
2. O invasor pode manipular tamanhos de chaves de criptografia de outros usuários ou enganar esses usuários a ponto de levá-los a usar um tamanho de chave de criptografia igual a zero (ou o mais baixo possível), potencialmente permitindo que o invasor leia os dados criptografados de outros usuários (já que ele tem conhecimento do algoritmo de criptografia utilizado).

Exemplo 1: O código a seguir realiza uma criptografia AES com um parâmetro de tamanho de chave controlado pelo usuário:

...
@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)
...

O código no Example 1 será executado com êxito, qualquer pessoa que puder acessar essa funcionalidade conseguirá manipular o parâmetro de tamanho de chave para o algoritmo de criptografia modificando o texto no UITextField inputTextField. Após a distribuição do programa, pode ser difícil desfazer um problema com tamanhos de chave controlados pelo usuário, pois seria extremamente difícil saber se um usuário mal-intencionado determinou o tamanho da chave de uma determinada operação de criptografia.