Padding - Algoritmo di crittografia

Question

Sto scrivendo un'implementazione dell'algoritmo di crittografia XXTEA che funziona su " stream " ;, ovvero, può essere usato come: crypt mykey < myfile > uscita.

Uno dei requisiti è che non ha affatto accesso al file (legge solo un blocco di dimensioni fisse fino a trovare un EOF). L'algoritmo richiede che i byte di dati siano multipli di 4, quindi è necessario aggiungere un padding.

Per il testo normale, una buona soluzione è quella di riempire con i NULL, e nella decrittazione semplicemente ignorare i NULL, ma la stessa strategia non può essere utilizzata per i flussi binari (che possono contenere NULL incorporati).

Ho letto le soluzioni comuni, come il riempimento con il numero di caratteri mancanti (se manca 3 caratteri, quindi aggiungo un 3, 3, 3 alla fine) ed ecc, ma mi chiedo: c'è una soluzione più elegante ?

Answer 1

Leggendo la domanda sembra che l'aspetto della sicurezza sia controverso. In poche parole, hai un API che prevede un multiplo di 4 byte come input, che non hai sempre.

L'aggiunta di un massimo di 3 byte su qualsiasi flusso binario è pericolosa se non è possibile garantire che al flusso binario non interessi. L'aggiunta di 0 alla fine di un file exe non ha importanza poiché i file exe hanno intestazioni che specificano le dimensioni rilevanti di tutti i bit rimanenti. L'aggiunta di 0 alla fine di un file pcx lo interromperà poiché i file pcx hanno un'intestazione che avvia un numero specifico di byte dalla fine del file.

Quindi davvero non hai scelta - non c'è scelta di byte di imbottitura magica che puoi usare che non si verificheranno mai naturalmente alla fine di un flusso binario: devi aggiungere sempre almeno uno dword aggiuntiva di informazioni che descrivono i byte di riempimento utilizzati.

Answer 2

Leggi: http://msdn.microsoft .com / it-it / library / system.security.cryptography.paddingmode.aspx

Ha un elenco di metodi di riempimento comuni, come:

PKCS7 - La stringa di riempimento PKCS # 7 è costituita da una sequenza di byte, ognuno dei quali è uguale al numero totale di byte di riempimento aggiunti.

La stringa di riempimento ANSIX923 è costituita da una sequenza di byte riempiti con zeri prima della lunghezza.

La stringa di riempimento ISO10126 è costituita da dati casuali prima della lunghezza.

Esempi:

Dati non elaborati: 01 01 01 01 01

PKCS # 7: 01 01 01 01 01 03 03 03

ANSIX923 01 01 01 01 01 00 00 03

ISO10126: 01 01 01 01 01 CD A9 03

Answer 3

Leggi su furto di testo cifrato . È probabilmente molto più elegante dell'imbottitura in testo semplice. Inoltre, suggerirei di utilizzare una dimensione del blocco maggiore di 4 byte - 64 bit è probabilmente il minimo indispensabile.

La crittografia rigorosamente parlando fai-da-te è un'idea pericolosa; è difficile battere gli algoritmi che l'intera comunità di criptovalute ha provato e non è riuscito a violare. Divertiti e considera di leggere questo , o almeno qualcosa del Schneier's quot; lettura correlata " sezione.

Answer 4

In realtà mi aspetterei che un buon codice di flusso non abbia bisogno di alcun riempimento. RC4 ad esempio non ha bisogno di imbottiture ed è un codice di flusso molto potente. Tuttavia, può essere attaccato se l'utente malintenzionato è in grado di inviare dati diversi scelti alla routine di crittografia, che utilizza sempre la stessa chiave e ha anche accesso ai dati crittografati. La scelta dei dati di input corretti e l'analisi dei dati di output possono essere utilizzati per ripristinare la chiave di crittografia, senza un attacco di forza bruta; ma a parte questo RC4 è molto sicuro.

Se necessita di riempimento, non è un codice IMHO di cifratura dello stream. Come se il pad fosse un multiplo di 4 byte o un multiplo di 16 byte, qual è la differenza enorme? E se è imbottito per essere un multiplo di 16 byte, è possibile utilizzare praticamente qualsiasi cifra di blocco. In realtà la tua cifra è una cifra a blocchi, funziona solo con blocchi a 4 byte. Era un codice di flusso su un sistema in cui ogni & Quot; simbolo & Quot; è di 4 byte (ad es. durante la crittografia del testo UTF-32, nel qual caso i dati saranno sempre un multiplo di 4, quindi non c'è mai alcun riempimento).