O desafio
Apresento a vocês outro desafio de espião contra espião, colocando ofuscadores versus crackers. Nesse caso, no entanto, o dado a ser protegido não é uma entrada, mas uma saída .
As regras do desafio são simples. Escreva uma rotina com as seguintes especificações:
- A rotina pode ser escrita em qualquer idioma, mas não pode exceder 320 bytes.
- A rotina deve aceitar três números inteiros assinados de 32 bits como entradas. Pode assumir a forma de uma função que aceita 3 argumentos, uma função que aceita uma única matriz de 3 elementos ou um programa completo que lê 3 números inteiros de qualquer entrada padrão.
- A rotina deve gerar um número inteiro de 32 bits assinado.
- Sobre todas as entradas possíveis, a rotina deve gerar entre 2 e 1000 valores exclusivos (inclusive). O número de valores exclusivos que uma rotina pode gerar é chamado de chave .
Como exemplo, o programa C
int foo( int i1, int i2, int i3 ) {
return 20 + (i1^i2^i3) %5;
}
tem uma chave de 9, desde que (espera-se) só pode produzir os valores nove 16
, 17
, 18
, 19
, 20
, 21
, 22
, 23
, e 24
.
Algumas limitações adicionais são as seguintes:
- A rotina deve ser totalmente determinística e invariável no tempo, retornando saídas idênticas para entradas idênticas. A rotina não deve fazer chamadas para geradores de números pseudoaleatórios.
- A rotina pode não depender de "variáveis ocultas", como dados em arquivos, variáveis do sistema ou recursos de linguagem esotérica. Por exemplo, as rotinas geralmente não devem se referir a constantes, a menos que as constantes estejam claramente definidas no próprio código. Rotinas que dependem de peculiaridades do compilador, saídas de operações matematicamente indefinidas, erros aritméticos etc. também são fortemente desencorajadas. Em caso de dúvida, pergunte.
- Você (o codificador) deve saber exatamente quantas saídas exclusivas a rotina pode produzir e deve poder fornecer pelo menos uma sequência de entrada que produza cada saída. (Como pode haver centenas de saídas exclusivas, esse conjunto só seria solicitado no caso de sua chave ser contestada.)
Como esse problema apresenta muito menos semelhança com a criptografia clássica do que a anterior, espero que seja acessível a um público mais amplo.
Quanto mais criativo melhor.
A pontuação
O menor número de envios sem rachaduras por contagem de bytes será declarado o (s) vencedor (es).
Se houver alguma confusão, não hesite em perguntar ou comentar.
O Contra-Desafio
Todos os leitores, incluindo aqueles que enviaram suas próprias rotinas, são incentivados a "quebrar" as submissões. Um envio é quebrado quando sua chave é postada na seção de comentários associados. Se uma inscrição persistir por 72 horas sem ser modificada ou quebrada, ela será considerada "segura" e qualquer sucesso subsequente na quebra será ignorada por causa do concurso.
Apenas uma tentativa de quebra por submissão por leitor é permitida. Por exemplo, se eu enviar ao usuário X: "sua chave é 20" e eu estiver errado, o usuário X rejeitará meu palpite como incorreto e não poderei mais enviar sugestões adicionais para esse envio.
Os envios rachados são eliminados da disputa (desde que não sejam "seguros"). Eles não devem ser editados. Se um leitor deseja enviar uma nova rotina, deve fazê-lo em uma resposta separada.
A pontuação de um cracker é o número de envios (compatíveis ou não) que ele obtém. Para crackers com contagens idênticas, a classificação é determinada pela contagem total de bytes em todos os envios quebrados (quanto maior, melhor).
Os crackers com a maior pontuação serão declarados vencedores, juntamente com os desenvolvedores das rotinas vencedoras.
Por favor, não decifre sua própria inscrição.
Boa sorte. :)
Entre os melhores
Última atualização em 2 de setembro, 10:45 EST
Barreiras imóveis (envios sem rachaduras):
- CJam, 105 [Dennis]
Forças imparáveis (crackers):
- Dennis [ Java, 269 ; C 58 ; Mathematica, 29 ]
- Martin Büttner [ Java, 245 ]
return
etc ...