Implementation of a Brute Force attack on the cryptosystem D.E.S. through an infrastructure of distributed and parallel computing. Implementazione di un attacco a Forza Bruta sul Crittosistema D.E.S. tramite un’infrastruttura di calcolo distribuito e parallelo

1. Thanatos
Implementazione di un attacco a Forza Bruta sul Crittosistema D.E.S.
tramite un’infrastruttura di calcolo distribuito e parallelo
In ordine Alfabetico:
Francesco Pietralunga
Idriss Riouak
Renato Garavaglia
Tommaso Campari
Corso di Laurea in
Informatica

2. SOMMARIO
• Strumenti utilizzati
• Scopo del progetto
• DES - Implementazione in C
• Introduzione CUDA–C
• Architettura CUDA
• Implementazione DES su CUDA -C

3. Strumenti Utilizzati
Editor di testo e project manager.
Uno strumento tecnologicamente sofisticato e
all’avanguardia con la compilazione statica e
l’integrazione di uno software di versionamento.

4. Strumenti Utilizzati
Compilatore Sviluppato da Apple.
Possiede alcuni progetti di sviluppo di wrapper
per MPI come mpicc.

5. Strumenti Utilizzati
Repository e
software di
versionamento.

6. Strumenti Utilizzati
API Utilizzate nelle
applicazioni per sistemi a
memoria distribuita per
il Calcolo Parallelo

7. Strumenti Utilizzati
E’ uno package di tools per la verifica,
il profiling e il debugging di
programmi. Valgrind è in grado di
rilevare automaticamente la presenza
di memory leak.

8. Strumenti Utilizzati
API multipiattaforma per la
creazione di applicazioni
parallele su sistemi a memoria
condivisa

9. Strumenti Utilizzati

10. Strumenti Utilizzati

11. Scopo del Progetto
Lo scopo del nostro lavoro è quello non tanto di mettere in evidenza le già note vulnerabilità del crittosistema DES, ma
piuttosto quello di fare un confronto tra due approcci distinti di attacco al crittosistema che utilizzano la medesima
modalità ma con strumenti differenti, in particolare verranno utilizzate nella prima parte dei test le CPU presenti sui nodi
della rete, mentre nella seconda parte verranno utilizzate le GPU.
Il DES (Data Encryption standard ) è un Crittosistema scelto come standard dal Federal Information Processing Standard
(FIPS) per il governo degli Stati Uniti d’America nel 1976.
Si basa su chiavi a 64 bit (di cui 8 sono di controllo, quindi lo spazio dei valori si riduce a 56 bit)
e per questo si presta a un attacco a Forza Bruta. Seppur 256 chiavi siano poche, un singolo processore impiegherebbe
anni a testarle tutte, per questo già nel 1998 gli EFF’s DES cracker (Deep Crack) ruppero il DES in appena 56 ore grazie a
un supercomputer equipaggiato con 1856 chip.

12. DES -Implementazione in C
DEMO PRATICA
Il C è un linguaggio di programmazione di basso livello, per questo è spesso visto come uno dei linguaggi più ́
performanti in circolazione. Inoltre ha svariate librerie che permettono di svolgere funzioni altrimenti
complicate come il trasferimento delle chiavi dal master ai vari Worker con OpenMPI o l’esecuzione con
multithreading grazie a OpenMP.

13. Introduzione CUDA-C
Perché CUDA-C ? Noi abbiamo scelto CUDA-C in quanto si prestava
particolarmente ai nostri fini: fornisce infatti supporto a
OpenMPI e OpenMP e le parti CPU si presentano
comunque efficienti in quanto C è tra i linguaggi più
performanti.
Cos’è CUDA-C ?
Le schede grafiche con supporto a CUDA (Compute Unified Device Architecture)
sono un tipo di Hardware creato da NVIDIA per permettere l’esecuzione di
calcolo parallelo su GPU. I linguaggi di programmazione disponibili
nell’ambiente di sviluppo per CUDA, sono estensioni dei linguaggi più diffusi
per scrivere programmi. Il principale è CUDA-C (C con estensioni NVIDIA), altri
sono estensioni di Python, Fortran, Java e MATLAB.

14. Architettura CUDA
CUDA basa il suo funzionamento sul concetto di esecuzione parallela,
questo è possibile grazie a particolari funzioni marcate con la keyword
global che sono anche definite come funzioni kernel.
Una funzione kernel si presenta esattamente come una funzione C nella sua
definizione, le differenze si mostrano
infatti al momento della chiamata che è strutturata come:
kernel <<< NumBlocks, NumThreads >>> (Arguments);

15. Implementazioni DES su CUDA-C
1° Implementazione CUDA-C
2° Implementazione CUDA-C

16. PROFILING
• Profiling DES su CUDA-C
• ZeroCopyMemory
• Profiling Jetson TX1

17. NVIDIA tesla k40c con 1 GPU x Kepler GK110B e prestazioni 1.66 TFlops
(clock di GPU Boost)
Scheda Grafica K40c

18. Profiling DES su CUDA-C
Profiling dei tempi
d’esecuzione con
nvprof.

19. Profiling generate_all_subkeys. (1)
Kernel
Performance

20. Profiling generate_all_subkeys. (2)
Function Unit
Utilization

21. Profiling try_all. (1)
Kernel
Performance

22. Profiling try_all. (2)
Function Unit
Utilization

23. Profiling try_all. (3)
Stall Reasons:
Ragioni di Stallo.

24. Jetson TX1
Scheda Jetson TX1 con CPU 64-bit ARM® A57 CPUs e GPU 1 TFLOP/s 256-core with
NVIDIA Maxwell™ Architecture

25. Jetson TX1
L’università ci ha fornito l’accesso ad una scheda Jetson TX1 sulla quale
effettuare dei test.
Questa scheda, ha un’unica memoria centrale, condivisa tra CPU e GPU.
Infatti per utilizzare questa scheda, per allocare la memoria, bisogna
utilizzare il metodo d’allocazione ZeroCopy.

26. ZeroCopyMemory
Per l’implementazione è stato modificata la seconda implementazione in CUDA-C cfr(Slide 7)
Sostituendo le classiche cudaMalloc con le chiamate cudaHostAlloc fornite
dalla libreria CUDA e le cudaMemcpy con cudaGetHostDevicePointer con le seguenti
Sintassi.
cudaError_t cudaHostAlloc(void** pHost, size_t size, unsigned int flags).
cudaError_t cudaHostGetDevicePointer(void ** pDevice, void * pHost, unsigned int flags).

27. Profiling Jetson TX1
Analisi dei tempi d’esecuzione sulla macchina Jetson TX1

28. Comunicazione & Distribuzione Chiavi
• Entità Server e Client
• Scatter
• Coda
• Opzioni d’esecuzione
• Gestione delle richieste

29. Comunicazione & Distribuzione Chiavi
OpenMPI(Message Passing Interface): API per la gestione delle comunicazioni tra i vari nodi.
OpenMP(MultiProcessing): è un API multipiattaforma per la creazione di applicazioni
parallele su sistemi a memoria condivisa.

30. Comunicazione & Distribuzione Chiavi
• L’entità Server: che distribuisce blocchi di chiavi ai singoli Client e ne testa il
risultato.
• L’entità Client: che per ogni chiave del blocco passatogli prova a decifrare il
messaggio e se ha successo informa il Server che la chiave è stata trovata e
dunque il messaggio messaggio viene ridecifrato dal Server e mostra all’utente
la chiave trovata.

31. Scatter & Coda (1)
Int MPI_Scatter( const void* sendbuf,
int sendCount,
MPI_Datatype sendtype,
void* recvbuff,
int recvcount,
MPI_Datatype recvtype,
int root, MPI_Comm comm);

32. Scatter & Coda (2)
256 chiavi
255 chiavi
• Supponiamo di avere K client con CPU a disposizione
Numero di Blocchi =
255
# $%&'()
L’eventuale resto viene calcolato dall’ultimo client.
Gestito tramite coda. Slide successiva

33. Scatter & Coda (2)
225 + 224
225
224
0
Server Client
Server comunica l’offset
Una volta comunicato l’offset viene eliminato.
Una volta
ricevuto
l’offset il client
elabora le
chiavi.
Per l’opzione -cpu
sono stati utilizzati
offset d’ampiezza
262.144

34. Opzioni d’esecuzione (1)
typedef struct {long long possibileChiave;
long long processID;
double tempo;
int tipo;
} infoExec;
static MPI_Datatype Info_Type;

35. Opzioni d’esecuzione (2)
-cpu: vengono utilizzate come unica unità d’elaborazione le CPU.
-gpu: vengono utilizzate come unica unità d’elaborazione le GPU.
-zcmem: deve essere preceduta da –gpu o da -hybrid, e permette di eseguire i
test utilizzando i costrutti CudaHostAlloc e CudaGetHostDevicePointer.
-hybrid: permette di utilizzare contemporaneamente sia l’unità d’elaborazione CPU
che GPU, sfruttando dunque al massimo tutta la potenza computazionale a
disposizione.

36. Gestione delle richieste
Per poter gestire i diversi messaggi che i client devono mandare al server, utilizziamo
diversi tipi di TAG. cfr(OpenMPI)
• Key_found_tag (0): Utilizzando questo Tag, il client comunica al master che ha
trovato la chiave per decifrare il messaggio di partenza.
• New_offset_request_tag (1): Utilizzando questo Tag, il master è in grado di capire
che uno dei client ha bisogno di un nuovo blocco di chiavi da processare.
• Info_on_elaboration_tag(2): Utilizzando questo Tag, il client raccoglie il messaggio
e lo elabora per ricavare l’avanzamento totale dell’attacco.

37. GREEN COMPUTING VS GRID COMPUTING
• TESLA VS XEON VS JETSON
• ARM VS XEON
• ZeroCopyMemory
• Hybrid Function: 4K40 VS TX1
• 1998 VS 2016

38. TESLA VS XEON VS JETSON

39. TESLA VS XEON VS JETSON

40. ARM VS XEON

41. ZeroCopyMemory Testing (1)

42. ZeroCopyMemory Testing (2)

43. HYBRID FUNCTION: 4K40 VS TX1

44. 1998 VS 2016 (1)
Grafico delle chiavi testate per giorno da DESCHALL
nel 1998.
Grafico dei Client connessi in ogni giorno di elaborazione
su DESCHALL nel 1998.

45. 1998 VS 2016 (2)
In particolare osservando il seguente grafico
notiamo come nel massimo picco di potenza di
calcolo (con all’incirca 14000 Client connessi)
DESCHALL elaborasse “solo” 600 trilioni di
chiavi al giorno, mentre oggi il nostro sistema con
lo stesso numero di Client ne elaborerebbe
2,536 Quadrilioni cfr(Slide 34), garantendo quindi un
incremento delle prestazioni del 422 %