Uma criptografia totalmente homomórfica pode ser usada para execução de código inconsciente?

Depois de ler esta resposta há algum tempo, me interessei pela criptografia totalmente homomórfica. Depois de ler a introdução da tese de Gentry, comecei a me perguntar se o esquema de criptografia dele poderia ser usado para a execução de código inconsciente, conforme definido no terceiro parágrafo.

Em um esquema de criptografia totalmente homomórfica, geralmente criptografamos alguns dados, enviando-os para um ambiente hostil onde uma determinada função é computada nos dados, cujo resultado é então enviado de volta (criptografado), sem que o adversário descubra quais são os dados recebidos ou o resultado da função é

Com a execução de código inconsciente, quero dizer que criptografamos um código projetado para resolver algum problema e o enviamos para um ambiente hostil. O adversário quer usar para resolver , mas não queremos que ele saiba como funciona. Se ele tiver uma entrada para , ele poderá criptografar e, em seguida, usar (algum esquema de criptografia) com , que retornará a saída (a solução de para a entrada I ) (não criptografada).$C$$P$$C$$P$$C$$I$$P$$I$$C$$I$$O$$P$$I$) O esquema de criptografia garante que o adversário nunca descubra como o código funciona, ou seja, para ele funciona como um oráculo.

O principal uso prático (eu posso pensar) para esse esquema de criptografia seria tornar a pirataria mais difícil ou até impossível.

A razão pela qual acho que isso pode ser possível usando um esquema de criptografia totalmente homomórfica é porque podemos executar circuitos arbitrários em dados criptografados, em particular uma máquina de Turing universal. Poderíamos então criptografar o código como se fossem dados e, em seguida, usar o circuito para uma máquina de Turing universal nesses dados criptografados para executar o código.

Faço isso como uma pergunta aqui, porque não sei se essa idéia é utilizável: nunca fui muito além da introdução da tese de Gentry, e meu conhecimento sobre criptografia é limitado. Além disso, não sei se já existe um termo frequentemente usado para execução de código inconsciente: tentei pesquisar no Google pela ideia, mas sem saber o termo adequado, não encontrei nada.

Posso pensar em vários problemas que podem causar problemas com essa abordagem. Primeiramente, se usarmos uma criptografia totalmente homomórfica sem modificação, o resultado da computação ( ) será criptografado. Seria, portanto, inútil para o adversário que pretenda utilizar o seu código para resolver P . Embora isso ainda possa ser útil para, digamos, a computação em nuvem, não é isso que eu quero alcançar.$O$$P$

Em segundo lugar, porque estamos usando circuitos e não máquinas de Turing arbitrárias, não podemos usar quantidades arbitrárias de memória: estamos limitados a uma quantidade predeterminada de memória. Isso significa que, se quisermos executar um programa dessa maneira, o espaço ocupado pela memória será sempre o mesmo, ou seja, o pico de uso da memória.

Por fim, as constantes envolvidas quase certamente eliminariam qualquer uso prático desse sistema, mas acho que a idéia é interessante.

Infelizmente, há um resultado que proíbe teoricamente a "execução de código inconsciente":

Boaz Barak, Oded Goldreich, Russell Impagliazzo, Steven Rudich, Amit Sahai, Salil Vadhan e Ke Yang. Sobre a (im) possibilidade de programas ofuscantes , AVANÇOS NA CRIPOLOGOLOGIA - CRYPTO 2001.

Aqui estão os links:

• http://www.wisdom.weizmann.ac.il/~oded/p_obfuscate.html
• http://eprint.iacr.org/2001/069
• http://www.springerlink.com/content/telalqdcx3n600uf/

O resumo diz:

Informalmente, um ofuscador é um "compilador" (eficiente, probabilístico) que recebe como entrada um programa (ou circuito) P e produz um novo programa O ( P ) que tem a mesma funcionalidade que P e ainda é "ilegível" em algum sentido . Os ofuscadores, se existirem, teriam uma ampla variedade de aplicativos criptográficos e teóricos da complexidade, desde a proteção de software à criptografia homomórfica até os análogos teóricos da complexidade do teorema de Rice. A maioria dessas aplicações é baseada na interpretação da condição de "ilegibilidade" na ofuscação, significando que O ( P $\cal O$$P$$\cal O(P)$$P$$\cal O(P)$é uma "caixa virtual negro", no sentido de que nada se pode de forma eficiente calcular dada , pode-se também de forma eficiente computar dado acesso oráculo para P .$\cal O(P)$$P$

Neste trabalho, iniciamos uma investigação teórica de ofuscação. Nosso principal resultado é que, mesmo sob formalizações muito fracas da intuição acima, a ofuscação é impossível. Provamos isso construindo uma família de funções que são inerentemente imperceptíveis no seguinte sentido: existe um predicado π tal que (a) dado qualquer programa que calcule uma função f em F , o valor π ( f ) pode ser calculado com eficiência , (b) dado acesso do Oracle a uma função (selecionada aleatoriamente) f em F , nenhum algoritmo eficiente pode calcular π ( f $\cal F$$\pi$$f$$\cal F$$\pi(f)$$f$$\cal F$$\pi(f)$ muito melhor do que adivinhação aleatória.

$\rm{TC}$ $0$

De fato, embora a criptografia totalmente homomórfica seja muito útil para executar código entre várias partes não confiáveis ​​(veja, por exemplo, este documento ), você precisa de algum tipo de interação, quando a parte que calcula a saída criptografada a envia para a parte que conhece a chave secreta .

A noção que você procura parece suspeitamente próxima à ofuscação do software, pela qual provamos um resultado impossível, mencionado acima. Também escrevi uma vez uma visão geral informal desse artigo, que algumas pessoas podem achar útil.

Dado esse resultado de impossibilidade, há duas maneiras (não disjuntas) de relaxar a definição: restringindo as classes de programas / funções, é necessário que você ofusque ou dando uma noção mais vaga de segurança.

A segunda abordagem talvez seja possível, e comentamos sobre algumas noções fracas do tipo ofuscação em nosso artigo. No entanto, observe que nosso ataque recupera completamente o código fonte original de algum programa, não importa como ele seja ofuscado. Então, você teria que, de alguma forma, fazer uma definição de segurança que trivialize para o caso de nossos contra-exemplos.

A primeira abordagem foi feita para todas as funcionalidades restritas (por exemplo, funções pontuais), mas, novamente, é preciso garantir que a classe não contenha nosso contra-exemplo, o que significa aproximadamente que ela não deve conter funções pseudo-aleatórias.