Como você pode forçar uma parte a ser honesta (obedecer às regras do protocolo)?
Eu já vi alguns mecanismos, como compromissos, provas e etc., mas eles simplesmente não parecem resolver todo o problema. Parece-me que a estrutura do design do protocolo e esses mecanismos devem fazer o trabalho. Alguém tem uma boa classificação disso?
Editar
Ao projetar protocolos seguros, se você forçar uma parte a ser honesta, o design seria muito mais fácil, embora essa imposição tenha seu próprio pagamento. Eu vi, ao projetar protocolos seguros, os designers assumirem algo que não me parece realista, por exemplo, assumir todas as partes honestas na pior das hipóteses ou assumir a honestidade do servidor que mantém os dados do usuário. Mas, ao analisar o design de protocolos em modelos mais rígidos, você raramente vê essas suposições (pelo menos eu não a vi - eu estudo os protocolosEstrutura UC de Canetti, que eu acho que ainda não está totalmente formalizada). Eu queria saber, existe alguma boa classificação das maneiras pelas quais você pode forçar uma parte a ser honesta ou existe algum compilador que possa converter o protocolo de entrada em uma com partes honestas?
Agora vou explicar por que acho que isso simplesmente não funciona, embora possa parecer irrelevante. Ao projetar protocolos na estrutura da UC, que se beneficia do paradigma ideal / real, todos os links de comunicação no modelo ideal são autenticados, o que não é verdade no modelo real. Portanto, os projetistas de protocolos buscam métodos alternativos para implementar esse canal por meio de suposição de PKI ou um CRS (Common Reference String). Mas ao projetar protocolos de autenticação, assumindo que os canais autenticados estão errados. Suponha que estamos projetando um protocolo de autenticação na estrutura da UC, há um ataque no qual o adversário falsifica a identidade de uma parte, mas devido à suposição de links autenticados no modelo ideal, esse ataque não é assumido nessa estrutura! Você pode consultarModelagem de ataques internos a protocolos de troca de chaves de grupo . Você pode notar que Canetti, em seu trabalho seminal, noções universalmente composíveis de troca de chaves e canais seguros menciona uma noção anterior de segurança chamada SK-Security, que é simplesmente o suficiente para garantir a segurança dos protocolos de autenticação. De alguma forma, ele confessa (afirmando que esse é o problema da tecnicidade) que a definição de UC nesse contexto é muito restritiva e fornece uma variante relaxada chamada oráculo de não informação (o que me confundiu, porque eu não vi esse modelo de segurança em nenhum lugar , Não posso corresponder esse padrão de segurança a nenhum outro padrão de segurança, provavelmente minha falta de conhecimento: D).
[Como uma observação lateral, é quase possível converter qualquer protocolo Sk-secure para um protocolo UC seguro, independentemente do tempo do simulador. Por exemplo, você pode apenas remover as assinaturas das mensagens e fazer com que o simulador simule todas as interações de maneira simulada. Consulte Troca de chaves de grupos contributivos universalmente compostas para obter provas! Agora, suponha que este seja um protocolo de troca de chaves de grupo com muitas partes polinomialmente, qual seria a eficiência do simulador? Esta é a origem da minha outra pergunta neste fórum .]
De qualquer forma, devido à falta de comprometimento no modelo simples (sobre UC), procurei outros meios de tornar o protocolo seguro, ignorando a necessidade desse relaxamento. Essa ideia é muito básica em minha mente e me ocorreu apenas por ter estudado o mais recente esquema de compromisso de canetti no modelo simples: dureza adaptativa e segurança compostável no modelo simples a partir de premissas padrão .
BTW, não busco provas de conhecimento nulo porque, devido a razões que não conheço, sempre que alguém as utilizou em um protocolo simultâneo (na estrutura da UC), os outros mencionaram o protocolo como ineficiente (pode ser devido ao rebobinamento do simulador).