L'operatore modulo (%) fornisce un risultato diverso per le diverse versioni di .NET in C #

Sto crittografando l'input dell'utente per generare una stringa per la password. Ma una riga di codice fornisce risultati diversi nelle diverse versioni del framework. Codice parziale con valore del tasto premuto dall'utente:

Tasto premuto: 1. La variabile asciiè 49. Il valore di "e" e "n" dopo alcuni calcoli:

e = 103, 
n = 143,

Math.Pow(ascii, e) % n

Risultato del codice sopra:

• In .NET 3.5 (C #)

  Math.Pow(ascii, e) % n

  dà 9.0.

• In .NET 4 (C #)

  Math.Pow(ascii, e) % n

  dà 77.0.

Math.Pow() fornisce il risultato corretto (lo stesso) in entrambe le versioni.

Qual è la causa e c'è una soluzione?

Math.Powfunziona su numeri in virgola mobile a doppia precisione; quindi, non dovresti aspettarti che più delle prime 15-17 cifre del risultato siano accurate:

Tutti i numeri in virgola mobile hanno anche un numero limitato di cifre significative, che determina anche la precisione con cui un valore in virgola mobile approssima un numero reale. Un Doublevalore ha fino a 15 cifre decimali di precisione, sebbene internamente venga mantenuto un massimo di 17 cifre.

Tuttavia, l'aritmetica del modulo richiede che tutte le cifre siano accurate. Nel tuo caso, stai calcolando ⁴⁹¹⁰³ , il cui risultato è composto da 175 cifre, rendendo l'operazione modulo priva di significato in entrambe le tue risposte.

Per calcolare il valore corretto, è necessario utilizzare l'aritmetica a precisione arbitraria, come fornito dalla BigIntegerclasse (introdotta in .NET 4.0).

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

Modifica : come sottolineato da Mark Peters nei commenti seguenti, dovresti usare il BigInteger.ModPowmetodo, che è inteso specificamente per questo tipo di operazione:

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

A parte il fatto che la tua funzione di hashing non è molto buona ^* , il problema più grande con il tuo codice non è che restituisce un numero diverso a seconda della versione di .NET, ma che in entrambi i casi restituisce un numero completamente privo di significato: la risposta corretta al problema è

49 ¹⁰³ mod 143 = è 114. ( collegamento in Wolfram Alpha )

Puoi usare questo codice per calcolare questa risposta:

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;
}

Il motivo per cui il tuo calcolo produce un risultato diverso è che per produrre una risposta, usi un valore intermedio che elimina la maggior parte delle cifre significative del numero ⁴⁹¹⁰³ : solo le prime 16 delle sue 175 cifre sono corrette!

1230824813134842807283798520430636310264067713738977819859474030746648511411697029659004340261471771152928833391663821316264359104254030819694748088798262075483562075061997649

Le restanti 159 cifre sono tutte sbagliate. L'operazione mod, tuttavia, cerca un risultato che richieda che ogni singola cifra sia corretta, comprese le ultime. Pertanto, anche il più piccolo miglioramento della precisione di Math.Powquello potrebbe essere stato implementato in .NET 4, comporterebbe una drastica differenza nel calcolo, che essenzialmente produce un risultato arbitrario.

^* Poiché questa domanda parla dell'innalzamento di numeri interi a potenze elevate nel contesto dell'hashing delle password, potrebbe essere un'ottima idea leggere questo _{link di} risposta prima di decidere se il tuo approccio attuale dovrebbe essere cambiato per uno potenzialmente migliore.

Quello che vedi è un errore di arrotondamento in doppio. Math.Powfunziona con double e la differenza è la seguente:

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

1.2308248131348429E+174

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

1.2308248131348427E+174

Notare l'ultima cifra prima Ee che sta causando la differenza nel risultato. Non è l'operatore modulo (%) .

La precisione in virgola mobile può variare da macchina a macchina e anche sulla stessa macchina .

Tuttavia, .NET crea una macchina virtuale per le tue app ... ma ci sono modifiche da versione a versione.

Pertanto non dovresti fare affidamento su di esso per produrre risultati coerenti. Per la crittografia, utilizzare le classi fornite dal Framework anziché eseguire il rollio delle proprie.

Ci sono molte risposte sul modo in cui il codice è cattivo. Tuttavia, per quanto riguarda il motivo per cui il risultato è diverso ...

Le FPU di Intel utilizzano internamente il formato a 80 bit per ottenere una maggiore precisione per risultati intermedi. Quindi, se un valore è nel registro del processore, ottiene 80 bit, ma quando viene scritto nello stack viene memorizzato a 64 bit .

Mi aspetto che la versione più recente di .NET abbia un ottimizzatore migliore nella sua compilazione Just in Time (JIT), quindi mantiene un valore in un registro piuttosto che scriverlo nello stack e poi leggerlo dallo stack.

È possibile che il JIT ora possa restituire un valore in un registro anziché nello stack. Oppure passare il valore alla funzione MOD in un registro.

Vedi anche Domanda sull'overflow dello stack Quali sono le applicazioni / i vantaggi di un tipo di dati a precisione estesa a 80 bit?

Altri processori, ad esempio ARM, daranno risultati diversi per questo codice.

Forse è meglio calcolarlo da soli usando solo l'aritmetica dei numeri interi. Qualcosa di simile a:

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

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

È possibile confrontare le prestazioni con le prestazioni della soluzione BigInteger pubblicata nelle altre risposte.