É a primeira vez que estou usando criptografia no MariaDB, então preciso garantir que estou acertando. Eu preciso simplesmente armazenar alguns identificadores de forma criptografada e estou me perguntando se estou fazendo isso corretamente. Como estou recebendo alguns comportamentos inesperados na recuperação de dados (às vezes apenas), estou suspeitando que há algo errado (e estive verificando com os documentos etc., tudo parece certo ..?).
- Estou armazenando os dados em
BLOB
eNOT NULL
colunas, nada mais especificado. - Estou inserindo os dados usando isso, enquanto
key
é gerado viaopenssl rand -base64 32
INSERT INTO data_table ( encr_data ) VALUES( AES_ENCRYPT( "secret_string", "key" ) );
- Estou recuperando os dados usando isso:
SELECT CAST( AES_DECRYPT( encr_data, "key" ) AS CHAR ) as encr_data FROM data_table;
Essa é a maneira correta de fazer isso no MariaDB? A sequência secreta consiste em cerca de 35 a 40 caracteres.
É realmente fundamental para mim, pois o aplicativo que estou codificando está armazenando alguns dados secretos para serem usados com outra API. Em outras palavras, a criptografia não deve trazer nenhum risco quanto à integridade dos dados em si. Apenas o pensamento de precisar regenerar todos os dados criptografados devido a qualquer erro de criptografia (tornando os dados criptografados + armazenados inutilizáveis) ...
Portanto, preciso garantir que nenhum dado seja cortado da string criptografada e que a criptografia seja feita corretamente, daí o motivo dessa pergunta.
AES_ENCRYPT
retorna dados binários (BLOB
ouBINARY(...)
)CASTing
um BLOB para um CHAR faz uma bagunça. Não faça isso.Você pode convertê-lo para hexadecimal via
HEX(AES_ENCRYPT(...))
. Isso pode ser colocado em umVARCHAR
ouTEXT
.Se forem 40 emojis, serão necessários muitos bytes. Sugiro declarar a coluna de uma destas maneiras:
Se o uso for para validação de senha, o AES é a abordagem errada. Em vez disso, use um hash unidirecional (MD5, SHA%, etc).
NULL vs NOT NULL -- Isso depende da lógica de negócios. Se você precisa "ainda não definido" (etc), então
NULL
é razoável.