Segredo de chave vs sigilo de algoritmo


8

é uma afirmação bem conhecida de que

"A segurança criptográfica deve confiar em uma chave secreta em vez de em um algoritmo secreto ."

Eu gostaria de perguntar sobre alguns detalhes sobre isso. E quais são as diferenças?

Vejo o óbvio que, para um sistema multiusuário, gerar uma chave é extremamente mais fácil do que gerar um algoritmo distinto para cada par de usuários (e mesmo para um único par de usuários, alguém poderia argumentar que atualizar a chave é mais fácil)

Mas, é o único argumento?

Quero dizer, se definirmos

AlgorithmA = AlgorithmX + key A
AlgorithmB = AlgorithmX + key B

Então, uma alteração na chave não é diferente de uma alteração no algoritmo.

A única diferença que vejo é que, para um novo par de usuários / chaves

  • A maior parte da estrutura do algoritmo permanece constante no caso de chave secreta,

  • A maior parte da estrutura do algoritmo precisa mudar no caso do algoritmo secreto

Mas onde está o limite? "maior parte" do significado?

Eu gostaria de ter mais opiniões e pistas para entender por que essa distinção geralmente é mencionada.


Respostas:


4

Definição de problema

O objetivo da criptografia é aproximar um processo pelo qual

crypt(x)

não transmite informações sobre x, mas existe uma função decryptque

decrypt(crypt(x)) == x

Se a descriptografia e criptografia foram feitas apenas na mesma execução do mesmo programa, você pode implementar isso perfeitamente usando o estado oculto:

var map = {};  // A hidden hashmap.

function crypt(x) {
  var k = unique_unforgeable_value();
  map[k] = x;
  return k;
}

function decrypt(k) { return map[k]; }

Na prática, porém, crypte decryptsão chamados por programas diferentes ou execuções diferentes do mesmo programa, precisamos aproximar cryptusando uma função determinística cuja saída é indistinguível de bits aleatórios - ela deve ser incompressível (no sentido de codificação de Shannon) não há bits de estrutura extras que possam ser usados ​​para coletar informações sobre x.

Os algoritmos são altamente estruturados, portanto, compressíveis. Portanto, o que precisamos é de uma maneira de obter aparente aleatoriedade, mantendo o determinismo necessário paradecryptcrypt=EudentEuty.

Responda

Currying um algoritmo compressível simples com um segredo incompressível

crypt = crypt_algo(secret)
decrypt = decrypt_algo(secret)

podemos aproximar o objetivo acima. crypte decryptter alto conteúdo de informações devido ao alto conteúdo de informações secretas crypt_algoe ainda decrypt_algoter baixo conteúdo de informações.

secretprecisa ser mantido longe dos atacantes para que isso funcione, pois caso contrário, um invasor pode simplesmente fazer o curry acima. O algoritmo não precisa ser mantido em segredo, pois fornece apenas uma pequena parte do conteúdo informativo da função em curry.

Embargo

"A segurança criptográfica deve confiar em uma chave secreta em vez de em um algoritmo secreto."

Eu discordo do em vez da parte.

Você pode obter alguma medida de defesa em profundidade mantendo os dois em segredo, mas o teste crypt_algoé difícil; portanto, historicamente, os algoritmos secretos desenvolvidos internamente por amadores tiveram um desempenho pior quando submetidos a ataques do que aqueles que foram cuidadosamente revisados ​​por um grande número de pessoas. criptografadores profissionais. É por isso que a segurança pela obscuridade ganhou um nome merecidamente ruim. A "obscuridade" refere-se a tentativas de manter o algoritmo em segredo como um substituto para proteger adequadamente as chaves.


Eu acho que esta é a resposta correta, o algoritmo tem estrutura e chave não faz, e essa é a chave =)
Hernan_eche

5

A distinção que você deseja fazer entre a chave e o algoritmo propriamente dito não se baseia se a maior parte da operação está contida em uma ou outra, mas em onde está a complexidade. Não estou falando aqui de complexidade algorítmica, mas de complexidade no seu significado cotidiano: dificuldade de entender e raciocinar.

O algoritmo propriamente dito é complexo e difícil de raciocinar. Geralmente, ele faz várias manipulações de bits aparentemente arbitrárias, operações lógicas e aritméticas e embaralhamento geral dos dados. É muito difícil para um leigo ou mesmo para um criptógrafo saber quanta privacidade todas essas manipulações realmente compram para você e que tipo de análise criptográfica ela pode estar vulnerável. Portanto, a melhor maneira de ter certeza da segurança do algoritmo é divulgá-lo e analisá-lo por especialistas o mais amplamente possível. FAÇA-O PÚBLICO.

A chave, por outro lado, é um conceito simples: é um monte de bits que precisam ser aleatórios. Não há necessidade de revisar a chave para garantir a correção da criptografia. Qualquer chave deve ser tão forte quanto qualquer outra chave (e, se isso não for verdade, pode, em princípio, ser descoberto pela revisão do algoritmo, não pela chave). Sabemos que a qualidade da aleatoriedade disponível para gerar chaves é menos do que perfeita. Portanto, na prática, algumas chaves podem ser fracas devido à falta de aleatoriedade, mas pelo menos todos podem saber sem precisar ser um criptógrafo especialista e sem precisar criar uma análise difícil da chave que uma boa aleatoriedade levará a uma boa chave. Portanto, use a melhor aleatoriedade disponível, para que você não precise (NÃO DEVE!) Compartilhar a chave com todos para ter confiança em sua criptografia.


Eu acho que isso merece um comentário. Eu li sua resposta e entendi seu ponto de vista, está certo em algum momento, mas selecionei a resposta de @Mike Samuel que surpreendentemente diz exatamente o contrário !. É que o algoritmo é menos complexo que a chave, porque o algoritmo possui (e precisa) uma estrutura, mas a chave (não precisa ter uma estrutura). Concordo. Em vez disso, você disse: "A chave, por outro lado, é um conceito simples: é um monte de bits que precisam ser aleatórios"; na verdade, um simples "conceito" não é um simples "dado". A complexidade de um dado 'aleatório' é a complexidade máxima possível!
21712 Hernan_eche

@Hernan_eche A chave tem alta complexidade de Kolmogorov em relação a outras cadeias de bits do mesmo comprimento. Mas, conceitualmente, é apenas uma sequência aleatória de bits e, como conceito, é muito mais fácil de entender do que qualquer bom algoritmo de criptografia.
David Richerby

2

Fiz a mesma pergunta há alguns anos de um dos conhecidos especialistas em criptografia.

O ponto mais interessante aqui é que você pode pensar na chave para conter o código do algoritmo e o algoritmo ser uma simples Universal Turing Machine (UTM). Lembre-se de que queremos fazer é ter um algoritmo fixo para a tarefa criptográfica que não muda de uma execução para outra, se você considerar que a chave faz parte do algoritmo, o algoritmo precisa mudar a cada vez para verifique se está seguro. Com um algoritmo fixo e uma chave escolhida aleatoriamente, não temos esse problema.

A diferença original é mais clara se você pensar na criptografia pré-moderna. Se o adversário soubesse que o algoritmo estava perdido, tudo seria inútil, manter o algoritmo era essencial. Se em um caso em particular o algoritmo fosse conhecido, tudo seria perdido para todos os usos futuros. Na criptografia moderna, a chave é não parte do algoritmo , que é escolhido aleatoriamente , revelando o algoritmo criptográfico (e até mesmo as chaves usadas anteriormente) não comprometer a segurança de seus futuros usos já que no futuro corre a chave será apenas mais um Se você escolher uma string escolhida aleatoriamente e que daria segurança, as chaves usadas anteriormente não ajudam em nada na nova execução.

Então, o que acontece se considerarmos o UTM mais uma chave aleatória? A menos que a chave tenha uma estrutura legal , você não pode provar que o algoritmo será seguro; por exemplo, uma chave escolhida aleatoriamente na distribuição uniforme não funcionará. A chave precisaria ser "essencialmente" um algoritmo fixo mais uma sequência aleatória, caso em que não é realmente diferente de mover a parte do algoritmo fixo da chave para o UTM, não está mudando de uma execução para outra.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.