Tenho experimentado (a partir do CLI) os exemplos de criptografia em https://www.php.net/manual/en/function.openssl-encrypt.php e gostaria de saber como lidar com um arquivo maior, como um arquivo de banco de dados SQLite de alguns GB. Eu estava recebendo um erro de alocação de memória antes de seguir este exemplo na mesma página PHP.
Demorei para entender; mas finalmente consegui fazer funcionar em um banco de dados SQLite de 3 GB. Acho que base64 é o padrão se definir options=0 e eu estava tentando usar o exemplo mais novo fornecido para o caso simples junto com o exemplo antigo para um arquivo grande que usa opções de OPENSSL_RAW_DATA.
Minha pergunta é: essa abordagem dada naquele post de oito anos ainda é a abordagem adequada? Alguns dos exemplos dão um antes e depois da versão 7.1.
É correto usar os primeiros 16 bytes de um bloco criptografado como o próximo vetor de inicialização?
O número de blocos por criptografia/descriptografia é importante? Deve-se usar o maior tamanho que caiba na alocação máxima de memória ou algo mais?
<?php
//$key should have been previously generated in a cryptographically safe way, like openssl_random_pseudo_bytes
$key = "abcd1234dcba4321";
$cipher = "aes-256-cbc";
$feBlocks = 10000;
$fpPlain = fopen("../Database/filename.db",'rb');
$fpEncrypt = fopen("encrypted.enc", 'wb');
if (in_array($cipher, openssl_get_cipher_methods()))
{
$ivlen = openssl_cipher_iv_length($cipher);
$iv = openssl_random_pseudo_bytes($ivlen);
// Put the initialzation vector to the beginning of the file
fwrite($fpEncrypt, $iv);
while (!feof($fpPlain)) {
$plaintext = fread($fpPlain, $ivlen * $feBlocks);
$ciphertext = openssl_encrypt($plaintext, $cipher, $key, $options=OPENSSL_RAW_DATA, $iv);
// Use the first 16 bytes of the ciphertext as the next initialization vector
$iv = substr($ciphertext, 0, $ivlen);
fwrite($fpEncrypt, $ciphertext);
}
fclose($fpPlain);
fclose($fpEncrypt);
}
$fpEncrypt = fopen("encrypted.enc", 'rb');
$fpPlain = fopen("decrypted.db",'wb');
$ivlen = openssl_cipher_iv_length($cipher);
// Get the initialzation vector from the beginning of the file
$iv = fread($fpEncrypt, $ivlen);
while (!feof($fpEncrypt)) {
// we have to read one block more for decrypting than for encrypting
$ciphertext = fread($fpEncrypt, $ivlen * ($feBlocks+1));
$plaintext = openssl_decrypt($ciphertext, $cipher, $key, $options=OPENSSL_RAW_DATA, $iv);
// Use the first 16 bytes of the ciphertext as the next initialization vector
$iv = substr($ciphertext, 0, $ivlen);
fwrite($fpPlain, $plaintext);
}
fclose($fpEncrypt);
fclose($fpPlain);
Os exemplos da
openssl_encrypt()documentação implementam criptografia autenticada (AEAD), uma vez como AES/CBC com um HMAC (antes da v7.1, Exemplo #2) e uma vez com GCM (depois da v7.1, Exemplo #1), mas como criptografia de uma etapa. Além da confidencialidade, o AEAD também garante autenticidade.No entanto, uma implementação personalizada verdadeiramente robusta do AEAD em blocos não é trivial (para os requisitos, veja, por exemplo, a listagem na primeira seção de Encrypted streams and file encryption ) da documentação do Libsodium ), então é melhor usar uma biblioteca confiável. Uma opção para PHP é o Sodium , um wrapper do Libsodium . O Libsodium / Sodium tem uma API de streaming, veja Encrypted streams and file encryption e as
sodium_crypto_secretstream_...funções.Seu código (ou o código subjacente do exemplo ) implementa criptografia chunk-wise com AES/CBC. O código pode ser otimizado, mas em princípio está OK (desde que AEAD não seja necessário para seus requisitos).
Em relação às otimizações: A criptografia no código atual preenche todos os pedaços de texto simples e usa o primeiro bloco de um pedaço de texto cifrado como o IV para o próximo pedaço de texto simples. Isso significa que o tamanho do pedaço da criptografia deve ser conhecido durante a descriptografia para que os mesmos pedaços de texto cifrado possam ser reconstruídos. Além disso, o preenchimento dos pedaços intermediários é ineficiente.
Faria mais sentido desacoplar os tamanhos dos pedaços para criptografia e descriptografia. Isso pode ser alcançado se:
Com esses requisitos, a criptografia fornece o mesmo texto cifrado que uma criptografia de uma etapa forneceria, como pode ser melhor visto no diagrama CBC . As alterações de código necessárias são pequenas.
Alguém poderia ter a ideia de estender o código com um MAC para um AEAD. Isso é possível, mas como já mencionado acima, é melhor considerar uma biblioteca estabelecida por razões de segurança.
Em princípio, sim, mas com relação à otimização mencionada acima, faria mais sentido usar o último bloco de um pedaço de texto cifrado como o IV para o próximo pedaço de texto simples.
Com sua implementação, há a restrição de que o tamanho do bloco para descriptografia depende do tamanho da criptografia, o que é eliminado com a otimização.
Além disso, o tamanho do pedaço selecionado terá impacto no desempenho. Eu usaria um tamanho de pedaço preferencialmente grande (mas teste isso).