O operador de módulo (%) fornece um resultado diferente para diferentes versões do .NET em C #

Estou criptografando a entrada do usuário para gerar uma string para senha. Mas uma linha de código fornece resultados diferentes em diferentes versões da estrutura. Código parcial com valor da tecla pressionada pelo usuário:

Tecla pressionada: 1. A variável asciié 49. Valor de 'e' e 'n' após alguns cálculos:

e = 103, 
n = 143,

Math.Pow(ascii, e) % n

Resultado do código acima:

• Em .NET 3.5 (C #)

  Math.Pow(ascii, e) % n

  dá 9.0.

• Em .NET 4 (C #)

  Math.Pow(ascii, e) % n

  dá 77.0.

Math.Pow() fornece o (mesmo) resultado correto em ambas as versões.

Qual é a causa e existe uma solução?

Math.Powfunciona em números de ponto flutuante de precisão dupla; portanto, você não deve esperar que mais do que os primeiros 15 a 17 dígitos do resultado sejam precisos:

Todos os números de ponto flutuante também têm um número limitado de dígitos significativos, o que também determina a precisão com que um valor de ponto flutuante se aproxima de um número real. Um Doublevalor tem até 15 dígitos decimais de precisão, embora um máximo de 17 dígitos seja mantido internamente.

No entanto, o módulo aritmético requer que todos os dígitos sejam precisos. No seu caso, você está computando 49 ¹⁰³ , cujo resultado consiste em 175 dígitos, tornando a operação do módulo sem sentido em ambas as suas respostas.

Para calcular o valor correto, você deve usar aritmética de precisão arbitrária, conforme fornecida pela BigIntegerclasse (introduzida no .NET 4.0).

int val = (int)(BigInteger.Pow(49, 103) % 143);   // gives 114

Edit : Conforme apontado por Mark Peters nos comentários abaixo, você deve usar o BigInteger.ModPowmétodo, que se destina especificamente a este tipo de operação:

int val = (int)BigInteger.ModPow(49, 103, 143);   // gives 114

Além do fato de que sua função de hashing não é muito boa ^* , o maior problema com seu código não é que ele retorna um número diferente dependendo da versão do .NET, mas que em ambos os casos ele retorna um número totalmente sem sentido: a resposta correta para o problema é

49 ¹⁰³ mod 143 = é 114. ( link para Wolfram Alpha )

Você pode usar este código para calcular esta resposta:

private static int PowMod(int a, int b, int mod) {
    if (b == 0) {
        return 1;
    }
    var tmp = PowMod(a, b/2, mod);
    tmp *= tmp;
    if (b%2 != 0) {
        tmp *= a;
    }
    return tmp%mod;
}

A razão pela qual seu cálculo produz um resultado diferente é que, para produzir uma resposta, você usa um valor intermediário que elimina a maioria dos dígitos significativos do número 49 ¹⁰³ : apenas os primeiros 16 de seus 175 dígitos estão corretos!

1230824813134842807283798520430636310264067713738977819859474030746648511411697029659004340261471771152928833391663821316264359104254030819694748088798262075483562075061997649

Os 159 dígitos restantes estão todos errados. A operação mod, no entanto, busca um resultado que exija que cada dígito esteja correto, incluindo os últimos. Portanto, mesmo a menor melhoria na precisão do Math.Powque pode ter sido implementado no .NET 4, resultaria em uma diferença drástica do seu cálculo, o que essencialmente produz um resultado arbitrário.

^* Uma vez que esta questão fala sobre elevar inteiros a altas potências no contexto de hashing de senha, pode ser uma boa ideia ler este _{link de} resposta antes de decidir se sua abordagem atual deve ser alterada por uma potencialmente melhor.

O que você vê é um erro de arredondamento em dobro. Math.Powtrabalha com double e a diferença é a seguinte:

.NET 2.0 e 3.5 => var powerResult = Math.Pow(ascii, e);retorna:

1.2308248131348429E+174

.NET 4.0 e 4.5 => var powerResult = Math.Pow(ascii, e);retorna:

1.2308248131348427E+174

Observe o último dígito anterior Ee isso está causando a diferença no resultado. Não é o operador de módulo (%) .

A precisão do ponto flutuante pode variar de máquina para máquina e até mesmo na mesma máquina .

Porém, o .NET faz uma máquina virtual para seus aplicativos ... mas há mudanças de versão para versão.

Portanto, você não deve confiar nele para produzir resultados consistentes. Para criptografia, use as classes que o Framework fornece, em vez de criar suas próprias classes.

Há muitas respostas sobre como o código é ruim. No entanto, por que o resultado é diferente ...

As FPUs da Intel usam o formato de 80 bits internamente para obter mais precisão para resultados intermediários. Portanto, se um valor está no registro do processador, ele obtém 80 bits, mas quando é escrito na pilha, ele é armazenado em 64 bits .

Espero que a versão mais recente do .NET tenha um otimizador melhor em sua compilação Just in Time (JIT), portanto, ela mantém um valor em um registro em vez de gravá-lo na pilha e depois lê-lo de volta da pilha.

Pode ser que o JIT agora possa retornar um valor em um registro em vez de na pilha. Ou passe o valor para a função MOD em um registro.

Consulte também a pergunta sobre Stack Overflow Quais são os aplicativos / benefícios de um tipo de dados de precisão estendida de 80 bits?

Outros processadores, por exemplo, o ARM, darão resultados diferentes para este código.

Talvez seja melhor calculá-lo sozinho usando apenas aritmética de inteiros. Algo como:

int n = 143;
int e = 103;
int result = 1;
int ascii = (int) 'a';

for (i = 0; i < e; ++i) 
    result = result * ascii % n;

Você pode comparar o desempenho com o desempenho da solução BigInteger postado nas outras respostas.