Qual è l'algoritmo corretto durante il checksum di una porzione di codice?

Question

Qual è l'algoritmo corretto durante il checksum di una porzione di codice?

#1 da (1 voti)

2

Come parte della mia ricerca, mi sono imbattuto in una tecnica in un documento che applica il checksum su una porzione di codice. Voglio implementarlo. Qui è il documento di ricerca che parla della tecnologia di controllo del checksum.

Ecco il modello di guardia:

guard:
      add ebp, -checksum
      mov eax, client_addr

for:
      cmp eax, client_end
      jg end
      mov ebx, dword[eax]
      add ebp, ebx
      add eax, 4
      jmp for
end:

Come puoi vedere, qui viene eseguita solo l'aggiunta di opcode. Qualcuno può suggerire un metodo più strong per farlo? Inoltre, qualcuno ha suggerito tecniche di autenticazione dei messaggi come MAC, firme digitali, crittografia autentica? Quale sarebbe il metodo migliore?

cryptography hash integrity

posta ak0817 02.05.2016 - 08:58

fonte

1 risposta

Leggi altre domande sui tag cryptography hash integrity

Puoi dire a OpenSSH di forzare un rekey in base al limite del numero di pacchetti? Comprensione della sicurezza di uno schema a chiave pubblica federato tramite WebCrypto

score 1 · Answer 1

Spero che tu capisca che questa è sicurezza attraverso l'oscurità e non fornisce alcun livello significativo di integrità contro un avversario che sta tentando di modificare il tuo codice in memoria. Affinché ciò sia efficace in qualsiasi modo, l'unità di esecuzione della CPU dovrebbe essere quella che verifica il checksum, consentendo al codice modificato di rifiutarsi semplicemente di eseguirlo. Se il controllo è interamente in software, un utente malintenzionato potrebbe modificare banalmente il checksum stesso in modo che corrisponda al codice modificato prima che venga eseguito.

Detto questo, il metodo da usare sarebbe un hash di qualche tipo. Esistono tre tipi di hash:

Checksum implicano l'aggiunta di una rappresentazione numerica di ciascun componente dei dati, moltiplicato per un fattore di peso. I checksum sono estremamente veloci, ma non sono crittograficamente sicuri e spesso possono perdere i dati modificati anche in circostanze ideali.

Un esempio è Fletcher-64 .
Controlli ridondanti ciclici usa il resto della divisione polinomiale dei contenuti come digest. Il polinomio viene accuratamente selezionato per aumentare la possibilità di rilevare modifiche. In genere sono molto veloci, ma un attore malevolo può banalmente "romperli".

Un esempio è CRC32 .
Le funzioni hash crittograficamente sicure sono molto più lente delle altre opzioni, ma sono progettate per ridurre la possibilità che due input con contenuti diversi si risolvano nello stesso digest, indipendentemente dal modo in cui vengono generati. Le funzioni resistenti alla collisione possono avere qualsiasi dimensione del digest. Per resistere alle collisioni, hanno bisogno di dimensioni di digest più grandi, come 160 bit.

Un esempio resistente alle collisioni è SHA-256 . Un esempio non resistente alla collisione è SipHash .

Dato che stai solo scrivendo un proof of concept, dovresti usare un checksum semplice o veloce o CRC. Una corretta implementazione userebbe l'hardware personalizzato per verificare un hash crittograficamente sicuro come SHA-256 come parte di un albero hash con firma digitale. Se si ha accesso all'hardware con SSE4.2 (vedere pagina 61), è possibile utilizzare un'implementazione accelerata via hardware di CRC32c (utilizzando il polinomio 0x11EDC6F41 ). Ciò consente di generare un digest utilizzando un'istruzione per ogni QWORD di dati da elaborare, utilizzando l'istruzione crc32q . Altrimenti, vorresti utilizzare un checksum molto veloce ed estremamente semplice come CrapWow o Murmur . Sarà sufficiente per una proof-of-concept.