La endianness utilizzata con un algoritmo di crittografia influisce sulla sua sicurezza?

Innanzitutto, assicuriamoci di ottenere endianness:

// needs a C99 compiler like gcc. Will work with msvc as well.
#include <stdint.h>
#include <stdio.h>

union endian_test
{
    struct 
    {
        uint8_t a;
        uint8_t b;
        uint8_t c;
        uint8_t d;
    };
    uint32_t x;
};


int main(int argc, char** argv)
{
    union endian_test e;
    e.x = 0xAABBCCDD;
    printf("%x %x %x %x", e.a, e.b, e.c, e.d);
}

Se il tuo sistema è little endian, riceverai DD CC BB AA come output e big endian ti darà il contrario. Tutto quello che stiamo facendo qui è permettere al processore di rappresentare un intero in qualsiasi endianness che usa, quindi usare un piccolo trucco per emettere i byte nell'ordine in cui sono rappresentati in memoria.

AES funziona su blocchi a 128 bit, il che è abbastanza comodo, in realtà, poiché se moltiplichi per quattro tutte le dimensioni del campo in quell'unione, otterrai un blocco di input AES.

Quindi ora la tua domanda si riduce a:

If I were to reverse the order of the input of my block, would that create a security problem?

Bene, questo dipende dall'output. Assumiamo qualcosa di ingenuo, come invertire l'ordine dell'input produce un testo cifrato invertito, quindi se l'input è AABBCCDD che crittografa a 12345678 e DDCCBBAA crittografa a 78563412.

Questo è un problema per una certa classe di vulnerabilità crittografica chiamata CCA2 , o un attacco di testo cifrato adattivo scelto. Come risultato del fatto che il testo cifrato è malleabile puoi quindi richiedere varie operazioni di decrittografia da eseguire e mentre non conosci il testo in chiaro, potresti dedurne qualcosa. Ti potrebbe interessare leggere un po 'su indentazione del testo cifrato .

Come tale, uno schema crittografico non dovrebbe essere influenzato da endianness. Se è, o è malleabile, ha alcuni problemi di sicurezza che potrebbero dover essere affrontati (e sono, in alcune implementazioni, per esempio, non fornendo un oracolo di decrittazione).

L'AES è definito come operativo su blocchi da 16 byte. Tale blocco è una sequenza di byte ordinata : c'è un primo byte, un secondo byte e così via, fino al sedicesimo byte. Spesso diciamo che il primo byte è più a sinistra e l'ultimo byte più a destra perché siamo occidentali che usano un alfabeto latino e scrivono da sinistra a destra, e noi solo ciecamente e supponiamo implicitamente che le persone che scrivono da destra a sinistra siano semplicemente sbagliate.

Endianness riguarda l'interpretazione di una sequenza di byte come valore intero; per esempio, una sequenza di quattro byte, interpretata come un numero intero compreso tra 0 e 4294967295. Per fare una tale interpretazione, decidiamo che uno dei byte è per le unità (moltiplichiamo il suo valore numerico di 1), un altro deve essere moltiplicato per 256, un altro per 65536 (che è 256 * 256), e ancora un altro per 16777216 (cioè 256 * 256 * 256). La convenzione little-endian si ha quando viene prima il byte per unità, seguito dal byte del valore 256, quindi il byte del valore 65536 e infine il byte del valore 16777216. Convenzione big-endian è quando i byte sono nell'ordine opposto.

All'interno di AES, non c'è interpretazione delle sequenze di byte in interi più grandi, quindi l'endianità non si applica. Tuttavia, anche per gli algoritmi che fanno implicano l'interpretazione di sequenze di byte in numeri interi, la specifica dell'algoritmo definisce l'endianità da utilizzare. Spetta quindi alla implementazione seguire quella convenzione definita, indipendentemente dal fatto che corrisponda a ciò che la CPU fa o no. Ad esempio, nella funzione di hash MD5 , il messaggio di input (una sequenza di byte), dopo il riempimento, viene diviso in 64 -byte blocks, e ogni blocco è diviso in 16 sequenze a 4 byte, e ogni sequenza è interpretata come un intero con la convenzione little-endian . MD5 è MD5; è deterministico e il suo output per un determinato file di input non deve dipendere dal fatto che il computer usi una CPU x86, ARM, PowerPC o Sparc. Pertanto, le implementazioni che girano sulla CPU big-endian devono includere le necessarie fasi di scambio dei byte per eseguire correttamente il calcolo.

Tre punti aggiuntivi:

• L'importanza di endianness per le prestazioni è sopravvalutata. Anche per MD5, che è molto veloce (sul mio computer, elabora più di 400 megabyte al secondo), il byteswap per CPU big-endian implica un sovraccarico non superiore al 15%. Questo è il motivo per cui le solite funzioni hash SHA-1 / SHA-256 possono utilizzare le convenzioni big-endian (è così che sono state definite), contrariamente a ciò che un PC di base fa in modo nativo, e non è ancora un grosso problema.

• Se il tuo codice C deve essere reso consapevole di endianness, allora fa cose sbagliate. Il codice C che non è endian neutral è un codice C che accede agli stessi oggetti di memoria di entrambi i gruppi di byte e interi. Tale codice rompe le regole di aliasing rigorose , il che significa che il codice potrebbe smettere di funzionare correttamente quando compilato con una versione del compilatore diversa o con diverse opzioni del compilatore. Questa è una programmazione sciatta.

• Oltre a little-endian e big-endian, esistono altre convenzioni, spesso chiamate mixed-endian . Questi sono per lo più scomparsi. Tuttavia, le architetture big-endian e little-endian sono ancora fiorenti, quindi, per la sola portabilità, il codice dovrebbe essere endian neutral.

AES lavora su sequenze di byte. La prima cosa che dovresti fare è convertire i byte nell'ordine dei byte canonici, quindi puoi eseguire la decrittografia. La crittografia deve essere eseguita nell'applicazione, con i dati dell'applicazione. In altre parole, è necessario correggere l'ordine dei byte in uno strato inferiore di astrazione rispetto alla crittografia.