rafael, sei que a ideia não faz mais sentido devido aos diversos vazamentos de d · gpoleszuk

rafael, sei que a ideia não faz mais sentido devido aos diversos vazamentos de dados que ocorreram recentemente, enriquecendo bancos de dados clandestinos por aí. Pensando numa maneira de dificultar, imaginei o seguinte conjunto de dados pessoais de um cliente (fictício) de uma empresa (fictícia).

NOME COMPLETO     : JOAO DA SILVA SÓ
DATA DE NASCIMENTO: 29/02/2000
CPF               : 987.654.321-00
RG                : 12.234.567-X SSP/RR
ENDEREÇO          : AVENIDA ESPERANÇA SEM FIM, 789, BAIRRO LOGO ALI
CEP               : 97531-024 - 5105507 - VILA BELA DA SANTÍSSIMA TRINDADE - MT
CELULAR           : +5565987654321
EMAIL             : [email protected]
PASSPHRASE CLIENTE: QUALQUER COISA VALE DESDE QUE SO O CLIENTE SE LEMBRE
SALT              : 5d60adc890a3dc0bd7b9b621edac9272
ÚLTIMA ATUALIZAÇÃO: 01/02/2024 14:15:16

Hoje, corre o risco de cadastros assim estarem sendo subidos para sistemas na nuvem. Porém, em vez subir esses ~600 bytes, poderiam ser apenas 32 bytes gerados pelo SHA256: be6034da95b490d59eb881c06b18e2092913985155bfb56d3c1e0b06eab99b2b

As colisões de hash são evitadas devido a existência da passphrase e do salt mesmo que o cliente forneça poucos dados pessoais. A desanonimização, quando necessária, ocorre em sistema offline fora das vistas de qualquer ataque online. Se ocorrer a atualização dos dados, um novo hash é gerado. E ainda, se esses hashes fizerem parte de uma blockchain, o campo ÚLTIMA ATUALIZAÇÃO torna-se redundante.

De uma maneira geral, os únicos campos que realmente são livres para alteração a qualquer tempo e quantas vezes precisar são PASSPHRASE CLIENTE, SALT e, consequentemente, o campo ÚLTIMA ATUALIZAÇÃO. Destes, o primeiro é guardado com o cliente, os demais com a empresa junto com o hash. Perdendo-se a passphrase, um novo cadastro pode ser gerado. Conforme prevê a LGPD em seu artigo 18, "o titular poderá a qualquer momento e mediante requisição, a eliminação dos dados pessoais tratados com o consentimento do titular, exceto nas hipóteses previstas no art. 16 desta lei". Com tal método, a simples omissão ou perda da passphrase dá ao titular dos dados o poder de praticamente anonimizá-los para sempre.

Talvez tenha ficado a dúvida, como o cliente ficará com esse cadastro? Assinando digitalmente o hash.

Cara, excelente sua ideia. Se tivesse ainda um sistema que atualiza o SALT de forma recorrente e faz uma nova criptografia dos dados, fica bem difícil descobrir os dados iniciais. Eu tava pensando em fazer um SGBD pra fazer isso, mas dai me esbarrei em todo resto que um SGDB precisa implementar pra funcionar bem (indexação, busca e tals). Mas muito boa sua ideia, parabéns.

Ela só tem um problema, ela comprime os dados em uma única string, impossibilitando estudos sobre informações do cliente. Mas acho que isso poderia ser resolvido gerando de alguma forma alguma outra sequência de hash de cada um dos campos (sem colisão), dai vai ser possível fazer estudos (analise de dados e ciência de dados) mesmo em informações sensíveis, ao mesmo tempo que garante a segurança das informações (com chaves que são informadas pelo próprio cliente), e se ainda incorporar por exemplo algum tipo de 2FA que também gera uma segunda chave pra incorporar na ananomização dos dados, fica ainda mais difícil.

Fiquei empolgado com essa ideia agora. kkkkk

Quer levar isso adiante? Você pensou em incorporar blockchain também, eu pensei em algo semelhante, mas esqueci da possibilidade de usar informações vindas do próprio cliente pra anonimizar os dados.