Conteúdo criptografado em jogos

Eu tenho essa ideia de usar criptografia para impedir que os usuários descubram o conteúdo do meu programa fora do próprio programa. Como os usuários podem encontrar texturas nunca usadas no jogo para fazer parte de algum tipo de ovo de Páscoa enquanto analisam os dados do jogo. Isso pode, por exemplo, arruiná-lo para todos, se publicado online.

Imagine uma sala secreta onde o jogador deve pressionar os números corretos em uma porta de segurança do jogo, que, se correta, deve gerar a chave de descriptografia correta e, em seguida, descriptografar a parte do nível e abrir a porta. Assim, tornando o ovo de Páscoa inacessível, mesmo quando se olha através dos dados do jogo, uma vez que a chave não está realmente armazenada, é gerada com base na entrada do usuário.

Aqui está outro exemplo do que eu estava imaginando. Eu tenho um jogo de quebra-cabeça com, digamos, 20 níveis, cada um criptografado usando uma chave diferente. Em vez de armazenar a chave de descriptografia com o programa, permitindo que alguém descompile o programa e encontre-o, em vez disso, giro a chave de criptografia / descriptografia com base na solução do quebra-cabeça anterior. Dessa forma, o jogador teria que realmente descobrir o quebra-cabeça antes de obter qualquer informação sobre o próximo nível, mesmo ao examinar os dados do jogo.

O jogador, se tiver conhecimento, pode forçá-lo com força bruta "facilmente", uma vez que o número de soluções de quebra-cabeças é provavelmente menor que o número de chaves de descriptografia. É realmente uma questão de complexidade do quebra-cabeça e não é muito importante aqui. Embora eu tenha postado uma resposta sobre isso aqui

Hoje existem programas / jogos que fizeram algo assim? Armazenando conteúdo criptografado em seus jogos? E se não, por que? Existem muitas regras e regulamentos sobre isso, tanto na loja quanto no país? Alguém vê alguma armadilha óbvia que estou perdendo? Ignorando coisas como a experiência do usuário, a ideia parece sólida para mim e me deixa curioso por que não tinha visto isso antes.

Edit : Pode não estar claro exatamente o que estou dizendo, então aqui está um exemplo mais concreto.

Digamos que eu tenho uma função que recebe uma seqüência de 20 caracteres e gera uma chave simétrica que eu posso usar para criptografar / descriptografar algum conteúdo do jogo. A única maneira de o usuário acessar esse conteúdo é conhecer esses 20 caracteres e gerar a mesma chave. Essa chave nunca é armazenada diretamente e é gerada instantaneamente com base na entrada do usuário. Esses personagens estariam escondidos no jogo no que poderia ser livros, diálogo com os NPCs, talvez até mesmo fora do jogo na parte de trás da caixa.

Portanto, com 2 * 10 ^ 28 combinações possíveis para tentar, provavelmente seria mais provável que as pessoas encontrassem o conteúdo da maneira pretendida, em vez de olhar os dados do jogo.

Edição 2 : o conteúdo em questão seria criptografado com uma chave arbitrária e secreta antes de ser enviado ao consumidor. Obviamente, essa chave não será enviada com o jogo. Ele ou ela teria que, de alguma forma, reconfigurar a chave novamente, dada uma série de pistas feitas com base na chave e que estão ocultas ao longo do jogo ou em qualquer outro lugar. No entanto, esse sistema seria transparente para o usuário, pois você não saberia que o conteúdo foi criptografado, a menos que você realmente analisasse os dados do jogo.

Como muitos mencionaram, isso tem uma desvantagem óbvia, pois seu caso de uso é limitado. Uma vez que uma única pessoa tenha descoberto, ele / ela pode compartilhá-lo com todo mundo, se não a chave / solução, então o próprio conteúdo. No entanto, se sua intenção é manter algo tão secreto que uma única pessoa não consiga resolvê-lo e as pessoas tenham que trabalhar juntas para resolvê-lo, ou você tem medo de que seu ovo de páscoa esteja tão bem escondido (por design) que é mais provável que alguém o encontre no código durante o jogo. Então eu acho que isso poderia funcionar muito bem.

Pessoalmente, eu recomendaria usá-lo apenas uma vez por jogo e apenas para coisas que não afetam o jogo principal, como ovos de páscoa, um final secreto. Qualquer quebra-cabeça teria que ser tão complicado ou bem escondido para atrasar as pessoas o suficiente para fazer a criptografia valer a pena e se esse quebra-cabeça atrapalhasse o progresso das pessoas, provavelmente ninguém estaria se divertindo.

Esta pergunta está perguntando se é possível (não apenas comercialmente viável ou alguma outra interpretação) forçar pelo menos 1 usuário a resolver um quebra-cabeça em vez de hackear para desbloquear determinado conteúdo do jogo.

Que eu saiba, isso é definitivamente possível. De fato, é bizarro para mim que outras respostas estejam dizendo que não é possível, mesmo quando foi explicitamente declarado que a chave não é gerada nem armazenada, apenas lida a partir do estado do jogo (que poderia ter googleplexes de possíveis valores). O argumento de que "o jogo sabe como descriptografá-lo" para que não funcione implica que qualquer software de criptografia / descriptografia de código aberto (por exemplo, TrueCrypt) é inerentemente inseguro porque você sabe "como" descriptografar contêineres (basta digitar uma string baseada na entrada do teclado, é simples, certo?).

No caso mais simples, imagine que o jogo em si seja um simulador de teclado e faça a pergunta "qual é a senha dos meus arquivos criptografados?", Claramente todos concordamos que ter o código fonte do jogo não ajudaria. Agora imagine que o jogo faça as perguntas "qual é o nome do maior animal da Terra concatenado com o nome do menor animal?". Não está claro que ter o código fonte do jogo não ajudaria e você ainda precisa resolver o quebra-cabeça?

Com relação a se isso é possível, a resposta é absolutamente SIM, isso é possível.

Já foi tentado. Muitas, muitas vezes. Existe todo um setor secundário dedicado a tentar usar a criptografia para impedir que os usuários acessem um programa como entenderem. E isso nunca funciona. Os melhores esquemas de proteção tendem a durar cerca de um mês antes de serem quebrados, e a coisa sobre a Internet é que, uma vez quebrada uma vez, está quebrada em todos os lugares para sempre assim que alguém a publica. A armadilha óbvia que você está perdendo é que, para que seu programa use os dados, ele deve conter todas as informações necessárias para descriptografá-lo e, se o computador puder fazer isso, uma pessoa com acesso ao computador poderá fazer isso. este.

Isso já foi chamado de "o problema fundamental da criptografia": Alice deseja enviar uma mensagem para Bob, sem que Charlie seja capaz de lê-la, mesmo que ele a compreenda. O problema com a abordagem que você está propondo é que Bob e Charlie são a mesma pessoa neste caso.

Entendo o desejo de não prejudicar seus usuários, mas se as pessoas quiserem spoilers, elas os encontrarão e, se não o fizerem, tenderão a evitar ativamente os spoilers. Mas se você realmente quer fazer um ótimo jogo, siga o caminho oposto: abertura radical. Veja coisas como Neverwinter Nights , Starcraft ou a série Elder Scrolls , jogos que permanecem populares por anos e anos após o lançamento. Eles o fazem porque entregam poderosas ferramentas de design com o jogo que permitem aos usuários explorar tudo, descobrir como funciona e criar e compartilhar seu próprio conteúdo. Um jogo é apenas um jogo, até se tornar uma comunidade , e as comunidades perduram.

Já estou aqui há tempo suficiente para saber que, se o conteúdo estiver lá, alguém o encontrará. Tornar mais difícil apenas atrairá pessoas mais determinadas. Quanto mais popular o seu produto, mais interessante ele se torna. Parcialmente porque é um desafio, em parte porque existem muitos lugares onde você pode obter "cred" publicando esse tipo de informação.

Se a chave é gerada localmente pelo jogo, você pode encontrar uma maneira de trapacear no jogo até o ponto em que a chave é gerada ou simplesmente digitar o trecho de código correto. Se a chave lhe for enviada a partir de um servidor para concluir determinadas etapas do jogo, alguém o enganará, fazendo-o acreditar que chegou longe o suficiente.

No final, seu jogo se beneficiará muito mais com o tempo que você gasta, tornando-o divertido e envolvente, além de tornar difícil descobrir qual é a cor do próximo nível.

A principal razão pela qual isso deve estar no gamedev.SE é que fazer essa criptografia tem consequências na jogabilidade.

Você deseja que a solução para um quebra-cabeça seja a chave de criptografia para o próximo. Ou seja, os dados reais dessa solução devem descriptografar o próximo quebra-cabeça. Isso significa que a chave de descriptografia não faz parte dos dados do seu jogo; é gerado pelo jogador.

E aqui está a consequência. A descriptografia é geralmente binária. Você tem a chave de descriptografia exata necessária para descriptografar os dados ou não.

A conseqüência aqui é que, qualquer que seja o jogo que você crie, deve ser tão estreitamente focado que existe apenas uma solução possível para todos os níveis. Portanto, sua mecânica de quebra-cabeça deve ser projetada com muito cuidado, de modo que o jogador não consiga resolver o quebra-cabeça de maneira diferente da sua intenção.

Veja o Portal, Câmara de Teste 10, por exemplo. Você deveria ir para a esquerda, fazer algumas coisas, depois ir para a direita e fazer algumas coisas, tudo para abaixar uma plataforma.

Ou você pode apenas se dar um pouco de velocidade e se atirar na plataforma quando entrar.

GLaDOS: Então você fez um jogo de quebra-cabeça. Um jogo de quebra-cabeça que pune as pessoas que mais gostam de jogos de quebra-cabeça. Bom trabalho. Mas pelo menos esses hackers não terão seus preciosos dados. Porque as pessoas que gostam de resolver jogos de quebra-cabeça são os tipos exatos de pessoas que procuram soluções para jogos de quebra-cabeça online.

Então isso vale totalmente a pena.

Portanto, jogos de quebra-cabeça como Adventures of Lolo, SpaceCHEM e Portal (entre milhões de outros) estão prontos . Em vez disso, você deve criar seu jogo de forma que seja impossível criar um quebra-cabeça com mais de uma solução. Isso requer muito cuidado e geralmente requer jogabilidade bastante restritiva.

GLaDOS: Então você fez um jogo de quebra-cabeça. Um jogo que deve ser jogado por pessoas que gostam de encontrar soluções criativas para quebra-cabeças. E você criou um jogo que não tem soluções criativas para quebra-cabeças. *aplauso lento*

Não estou dizendo que você não pode criar um jogo assim. Ou que esse jogo não pode ser bom. Só que esse jogo teria que ser projetado de uma certa maneira.

Ah, e você precisa projetar essa jogabilidade de modo que seja impossível (ou altamente difícil) encontrar mecanicamente uma solução.

GLaDOS: Então você fez um jogo de quebra-cabeça. Um jogo de quebra-cabeça que é mais interessante para hackear do que para jogar. Bom trabalho.

Obviamente, há uma ressalva: o significado de "solução". Ou mais, que elementos de uma solução você leva em consideração?

Para qualquer jogo que envolva um personagem em movimento, você provavelmente não usará os movimentos exatos do personagem para construir a chave de descriptografia. Por exemplo, se você tem um jogo de quebra-cabeça em que o jogador precisa pegar determinados itens para "resolver" o quebra-cabeça, você pode fazer com que a chave dependa da ordem em que esses itens são tocados.

Obviamente, isso se depara com o problema acima, onde um jogador encontra uma maneira de fazer coisas fora de ordem. O que novamente significa que você precisa projetar o quebra-cabeça de tal maneira que exista apenas um pedido em que você possa escolher as coisas.

Além disso, quaisquer elementos que você use para construir a chave de descriptografia precisam fornecer entropia suficiente para dificultar a descriptografia de força bruta. Usando a mecânica da ordem de coleta acima, cada novo item é efetivamente um bit extra. Se um nível tiver apenas 8 itens, você estará fazendo criptografia de 8 bits. Qual é porcaria; a maioria dos smartphones consegue lidar com isso em segundos.

Atualmente, você precisa de pelo menos 128 para torná-lo um pouco desafiador. O que agora significa que cada nível precisa ter muitas coisas, impactando novamente o design do jogo.

As respostas aqui são boas; Eu consideraria isso de outra perspectiva. O que você está descrevendo é um recurso . Os recursos têm custos e benefícios. Os custos incluem os custos em dólares da criação do recurso e os "custos de oportunidade". São elas: em um mundo em que você tem dólares finitos, horas e programadores finitos, cada recurso que você faz significa um número infinito de recursos possíveis que não foram feitos em seu lugar.

Portanto, a pergunta é: você pode indicar os custos desse recurso em termos reais? Não há recursos gratuitos, portanto, seja realista sobre os custos. Você está disposto a pagar mil dólares por esse recurso? Cem mil? Um milhão? Quais recursos você deseja cortar para ter esse recurso?

Acho que quando você começar a priorizar as coisas em termos de custos, benefícios e oportunidades perdidas, perceberá que já passou muito tempo pensando sobre esse recurso quando pensava em maneiras de tornar o jogo mais divertido.

O problema de Alice Bob e Eve ilustra isso bem. Como Mason apontou em sua resposta, você não pode esconder um segredo de Eva se Eva também é Bob.

Portanto, qualquer solução consistiria em Bob não ter todas as informações necessárias. Você precisaria tratar cada nível como uma mensagem individual, criptografada separadamente e ter uma fonte externa das mensagens para o próximo nível que fosse capaz de manter as mensagens corretamente.

Mas, eventualmente, isso se torna discutível. Se alguém puder jogar o jogo, também poderá escrever um programa para ingerir o jogo. Então, tudo o que você está fazendo é forçá-los a ir e voltar da sua fonte externa (provavelmente um servidor de algum tipo). Depois que eles descobrem como criar as mensagens para o servidor, é a mesma velha história.

Mas você está esquecendo um elemento-chave aqui. É um jogo. Se alguém trapaceia em um jogo, grande grito. Você não escreveu o jogo para trapaceiros. É o mesmo com orientações passo a passo ou guias de nivelamento: as pessoas que querem o desafio de descobrir por conta própria ignoram as soluções postadas. Mesmo se você fosse capaz de tornar o jogo impossível, sem jogá-lo (sabemos que é logicamente impossível, mas mesmo que você pudesse), apenas um cara passaria antes que ele postasse tudo o que fosse necessário para vencê-lo. Então você está apenas atrasando o inevitável.

Gaste seu tempo fazendo um jogo incrível. Há dez coisas que todo jogo precisa e, pela última vez que olhei, a criptografia não era uma delas.

Acredito que sua ideia não faz sentido.

Quando alguém joga o seu jogo, ele escolhe, não o faz para ganhar um prêmio, o faz por diversão.

Os usuários sabem que o mais divertido é jogar da maneira que você quis dizer e não trapacear , já que seus clientes já confiam em você como contador de histórias.

Assim que alguém encontrar a solução para um quebra-cabeça, ou seja, sua chave, ele poderá simplesmente publicá-la em algum lugar da Internet.
Jogadores que querem trapacear ainda poderão fazê-lo.

No entanto, se o seu jogo apresentar várias soluções, como níveis secretos de Super Mario Land, criptografar seus ativos impedirá um acesso fácil a essas soluções.

Embora isso pareça um ponto a favor da sua ideia, no final não é.

Mesmo com a criptografia, ainda seria possível saber que essas soluções secretas existem.
Uma vez que se saiba que existe uma solução secreta, impedir os jogadores de olhar para os ativos secretos seria irrelevante, pois eles ainda desejariam acessar as partes ocultas do jogo através do próprio jogo (sim, mesmo que já tenham visto todos os itens ocultos) textura / clipe / áudio / texto).

Você pode impedir o vazamento da existência de soluções secretas usando alguma técnica alheia ¹ , mas ainda assim seria suspeito (por que fazer isso se não houver soluções secretas?), Os jogadores perderiam o interesse em encontrá-las e você teria menos jogadores , não mais.
Afinal, podemos jogar mais algumas horas depois de concluir um jogo para acionar alguns ovos de Páscoa, mas não jogaremos mais um minuto se acioná-los exigir um esforço titânico!

O que você quer fazer é como um livro escrito, onde o próximo capítulo é criptografado com uma palavra do capítulo atual, para impedir que os leitores se estraguem com o final.
Pense nisso, não é inútil?

_{¹ Como o VeraCrypt, faça isso com volumes ocultos.}

Não comentarei a viabilidade comercial, no entanto, de uma perspectiva técnica pura, é um desafio divertido.

Gostaria de observar primeiro que qualquer coisa que não esteja criptografada não pode ser protegida. Você não pode bloquear a entrada em segredo, os crackers encontrarão uma maneira de contornar o portão; em vez disso, você deve tornar todo o segredo o próprio portão. Em termos de ativos, isso não precisa significar as texturas inteiras, etc ... apenas criptografar o plano e quais são usados ​​e como são suficientes, e por razões de desempenho, você desejará criptografar o mínimo de dados possível.

Em segundo lugar, você está certo de que, se a chave estiver contida no software, ela será provocada pelo software. Muitos jogos, ao proteger o conteúdo, tentam usar a segurança pela obscuridade ou por mecanismos que garantam que o software do jogo não tenha sido alterado. Essas são apenas táticas de atraso.

Sua idéia de usar a solução de um enigma como a chave é bastante interessante, no entanto, é provável que o uso da chave fornecida diretamente seja facilmente forçado. Em vez disso, trate a entrada do usuário como uma senha e use um esquema de hash de senha de última geração: o hash produzido é a chave.

No entanto, mesmo assim, há um erro na sua suposição de que a chave não está presente no jogo. Caso contrário, você não poderia direcionar seus jogadores para ele; portanto, em vez de tentar forçar o cofre com força bruta, alguém poderia fazer engenharia reversa dos ativos do jogo procurando pistas. Um quebra-cabeça em potencial em que consigo pensar é usar texturas para codificar glifos e a senha consistiria em alguns dos disponíveis no teclado, conforme revelado pelos locais que o jogador deveria ter visitado (em ordem):

• O ponto crucial do problema é que o reconhecimento de imagens ainda é um pouco difícil para os computadores
• além disso, destacamos o fato de que os crackers CAPTCHA são ajustados para letras e dígitos, não para glifos personalizados
• além disso, destacamos o fato de que, combinando várias texturas (com transparência) para revelar o glifo ao jogador, nenhum ativo isolado no jogo contém a aparência do glifo
• use outra textura (com fragmentos) em todo o lugar, mas nunca de maneira a gerar um glifo completo, exceto em locais ocultos que o jogador nunca deve conseguir

e qualquer programa para extrair automaticamente a combinação de glifos vencedor terá um dia infernal.

Em terceiro lugar, a próxima dificuldade é compartilhar. Quando a solução de um segredo for encontrada, ela será revelada. Idealmente, cada indivíduo deve receber uma versão ligeiramente diferente do software: aquela em que a chave seja exclusiva da versão do jogo. Para torná-lo prático, suponho que seria mais fácil separar o jogo (com seus ativos) dos "segredos" (criptografados) e "driver secreto" (o gerador de chaves, que coloca muitos fragmentos de textura em muitos e diferentes lugares) , algumas das quais formam as senhas).

O vetor de ataque óbvio é enganar o gerador, sempre escolhendo a mesma senha, ou enganar o verificador, sempre aceitando a mesma senha (baixando o arquivo de segredos de outra pessoa, por exemplo).

Aqui, uma solução em potencial seria vincular os arquivos à conta do usuário e salgar a senha como é geralmente recomendado:

• quando o usuário solicitar um conjunto de arquivos, gere aleatoriamente um salt e quantas senhas você tiver segredos e crie os ativos secretos (você pode limitar esse processo a uma vez / dia / usuário, por exemplo, para evitar sobrecarregar o servidor)
• armazene o registro de data e hora da geração e o sal nas informações da conta do usuário
• envie de volta o carimbo de data e hora e os arquivos secretos personalizados ao usuário

Então, quando o usuário estiver pronto para enviar uma senha:

• faça com que o usuário efetue login (se ela ainda não estiver)
• faça com que o software envie a senha do carimbo de data e hora e do glifo
• se o carimbo de data / hora for diferente daquele armazenado, informe ao usuário que ele está usando um conjunto obsoleto de arquivos secretos
• se a senha já tiver sido tentada muitas vezes, informe ao usuário que ela está usando um conjunto obsoleto de arquivos secretos
• caso contrário, faça o hash do salt + senha para produzir a chave
• caso contrário, envie a chave de volta ao usuário para que ele possa ver seus arquivos personalizados
• aumentar o número de vezes que essa senha foi tentada por esta conta

O objetivo aqui é impedir o compartilhamento da conta, tanto quanto possível:

• o compartilhamento de uma conta para gerar arquivos secretos é (a) limitado, porque apenas um pode ser gerado por dia e (b) inútil, porque o último gerado torna o outro obsoleto
• compartilhar uma conta e distribuir os arquivos secretos associados é inútil, porque uma senha específica só pode ser usada N vezes antes de não produzir mais a chave

E nós estamos quase lá.

Finalmente, mesmo lá, um cracker pode lançar uma versão modificada do jogo na qual os ativos secretos são descriptografados e diretamente integrados (ignorando seu cuidadoso esquema de verificação).

A solução é simples (e torna quase tudo acima do ¹ obsoleto ): não confie no cliente.

Crie uma tabela de classificação no seu site e acompanhe o progresso dos jogadores na conta deles. Os jogadores podem afirmar que terminaram o jogo o quanto quiserem, mas, a menos que sua conta reflita isso, todos sabem que estão trapaceando ...

... isso é chamado de pressão social;)

¹ Exceto o arquivo de posicionamento da textura, que usamos para impedir que um programa adivinhe a chave e, no entanto, possibilite que um usuário a obtenha.

É uma ideia interessante; uma variante nos discos de quebra-cabeça e nos sistemas de proteção contra cópia que digitam a palavra do manual. Eu acho que alguns dos jogos "ARG" funcionam assim, onde é entendido que os jogadores estão agindo coletivamente contra o criador do jogo.

Obviamente, quando a primeira pessoa descriptografar, a publicará na internet.

O conteúdo generativo ou processual pode funcionar da mesma maneira: você não vê o mesmo mundo que outro jogador, a menos que compartilhe uma "semente".

Não vejo nenhum problema legal com ele, embora a Apple possa rejeitá-lo em sua App Store e talvez você precise fornecer a solução para que ele seja aprovado em consoles de jogos.

Contemplar medidas extras de segurança é divertido, mas não agrega valor concreto ao seu produto - ele demonstra sua astúcia aos crackers que encontram seu produto. Por princípio, seu antagonista o alcançará.

Ao contrário dos desenvolvedores que prosperam na criatividade, os crackers são pessoas analíticas - eles podem explorar intuitivamente o seu programa. Quando os desenvolvedores tendem a tomar medidas de segurança excessivas, eles negam - que o cracker possa reverter seu esquema de proteção novamente .

Se você deseja participar dessa competição em segundo plano, essa é a sua decisão - mas não deixe que isso desvie seu produto final, o que deve agradar o cliente. Um esquema de criptografia peculiar que transforma o jogo em uma lesma não ajuda.

Mason Wheeler tem razão: você não pode fazê-lo. Alguém sempre pode fazer engenharia reversa do seu jogo, se quiser.

Você não precisa "proteger" seu jogo de qualquer maneira da maneira que descreve. Assim que uma pessoa encontra o ovo da Páscoa, o segredo está fora do saco. Se cada cópia do jogo tiver um ovo de Páscoa diferente, apenas a cópia do hacker será conhecida. Você realmente se importa que um hacker em cada 1000 pessoas tenha encontrado o ovo de Páscoa sem passar pelo jogo?

A lei de direitos autorais é tal que ninguém pode ganhar dinheiro com seu jogo sem arriscar uma ação séria; portanto, os direitos autorais o protegem.

Quanto aos usuários aleatórios colocando suas texturas no avatar do fórum, e daí? Considere publicidade de base.

Ficar obsessivo em "proteger" coisas apenas o distrairá de realidades difíceis como: fazer o jogo .

Quando vejo pessoas sem produtos falando sobre seus esquemas de proteção de IP para coisas que nem existem, é um tipo de momento para mim, porque gera uma enorme bandeira vermelha sobre o projeto inteiro.

Algumas possibilidades:

• Ofuscação de código antigo simples . Não tornará o código impossível de decodificar, mas pelo menos será difícil.

• Solução do lado do servidor. Você envia alguns comandos especiais para o servidor e o servidor pode enviar o código ... ou até mesmo baixar um DLC.

• Você pode usar a esteganografia para ocultar o código executável em outro conteúdo.

Isso não tornará seu segredo 100% seguro, mas parece que ninguém perderá dinheiro se o segredo for revelado.

É inútil, assim como qualquer outro esquema em que você armazena chave e algoritmo no cliente. Se você perguntar "onde está a chave, eu confio na entrada dos usuários e não a armazeno?", Lembre-se de que seu quebra-cabeça tem regras e recursos por suas definições - é resolvido por algum algoritmo, não por força bruta. Esse algoritmo exato e seus recursos É o algoritmo de geração de chaves que você acabou de codificar no jogo no estado ofuscado. Qualquer pessoa pode recuperar sua chave "inexistente" escrevendo um pequeno programa que resolve seu quebra-cabeça de acordo com suas regras.