2009-06-17 29 views
19

Voglio scrivere un piccolo programma in C/C++ che legge un piccolo file di testo e lo crittografa, usando un tasto "interno". Poi voglio anche scrivere un altro piccolo programma che può decodificare il file crittografato usando internamente la stessa chiave.Crittografia e decrittografia di un piccolo file usando openssl

Ho guardato il sito openSSL e ho cercato su Google ma non ho trovato un esempio semplice, qualcuno ha mai provato a fare questa cosa?

+0

Una domanda con un esempio simile http://stackoverflow.com/questions/3141860/aes-ctr-256-encryption-mode-of- operation-on-openssl – enthusiasticgeek

+0

Dovresti usare le funzioni 'EVP_ *'. Le funzioni 'EVP_ *' usano l'hardware, come AES-NI (se disponibile). Vedi [Codifica simmetrica EVP e decrittografia] (https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption) sul wiki OpenSSL.In effetti, probabilmente dovresti utilizzare la crittografia autenticata perché fornisce * sia * riservatezza e autenticità. Vedi [Crittografia e decodifica autenticata EVP] (https://wiki.openssl.org/index.php/EVP_Authenticated_Encryption_and_Decryption) sul wiki OpenSSL. – jww

risposta

0

OpenSSL riguarda specificamente l'implementazione di SSL e TLS che sono protocolli per la crittografia dei dati su una rete. Dato che stai solo cercando di criptare un file, è possibile usare OpenSSL ma non è l'ideale.

Invece, vorrei usare qualcosa come BeeCrypt o Crypto++® Library 5.6.0 che entrambi forniscono esempi per il loro uso.

+4

OpenSSL ha sia memoria che file 'BIO', che sono un'astrazione. La libreria funziona bene con buffer di memoria, buffer di file, socket e altri oggetti I/O. La parte di crittografia della libreria ('libcrypto.a') può essere utilizzata da sola; e la porzione SSL ('libssl.a') è costruita sulla parte superiore della crittografia. – jww

20

Idealmente, si potrebbe utilizzare uno strumento già esistente, come ccrypt, ma qui va:

#include <openssl/aes.h> 

/* ... */ 


{ 
    int bytes_read, bytes_written; 
    unsigned char indata[AES_BLOCK_SIZE]; 
    unsigned char outdata[AES_BLOCK_SIZE]; 

    /* ckey and ivec are the two 128-bits keys necesary to 
    en- and recrypt your data. Note that ckey can be 
    192 or 256 bits as well */ 
    unsigned char ckey[] = "thiskeyisverybad"; 
    unsigned char ivec[] = "dontusethisinput"; 

    /* data structure that contains the key itself */ 
    AES_KEY key; 

    /* set the encryption key */ 
    AES_set_encrypt_key(ckey, 128, &key); 

    /* set where on the 128 bit encrypted block to begin encryption*/ 
    int num = 0; 

    while (1) { 
    bytes_read = fread(indata, 1, AES_BLOCK_SIZE, ifp); 

    AES_cfb128_encrypt(indata, outdata, bytes_read, &key, ivec, &num, 
      AES_ENCRYPT); 

    bytes_written = fwrite(outdata, 1, bytes_read, ofp); 
    if (bytes_read < AES_BLOCK_SIZE) 
    break; 
    } 
} 

decrittografia è fatto chiamando AES_cfb128_encrypt con AES_DECRYPT come ultimo parametro. Si noti che questo codice non ha ricevuto nulla di più del più elementare dei test e che è necessario utilizzare i dati casuali appropriati di 8 bit per ckey e ivec.

EDIT: Sembra AES_cfb128_encrypt accetta i dati di lunghezza arbitraria, in modo che non sei tenuto a crittografare in blocchi di AES_BLOCK_SIZE (16) byte.

+0

Alcune direzioni da aes help doc, dicendo che: Non tutte le possibili variazioni di dimensioni e modalità operative della chiave sono fornite da questa libreria. Per questo motivo e altri, le applicazioni devono utilizzare le funzioni di livello superiore L ecc., Anziché chiamare direttamente le funzioni AES. – solotim

+0

@Michiel Budding ': ho usato il tuo codice e ho bisogno di inizializzare int num; alla dimensione ivec affinché funzioni correttamente. – Macarse

+0

Il tuo codice segfaults bigtime. – user99545

13

Le risposte precedenti ti hanno indicato come fare ciò che hai chiesto.

Vorrei aggiungere una parola sul motivo per cui lo non si dovrebbe fare questo.

Si parla di "crittografia simmetrica" ​​(la stessa chiave viene utilizzata per crittografare e decifrare, in contrapposizione alla crittografia asimmetrica in cui tutto ciò che viene crittografato con una chiave può essere decifrato solo da una controparte specifica).

Disassemblare un file eseguibile per determinare una chiave hardcoded in uso è quasi banale. Ciò significa che chiunque riesca a mettere le mani su uno dei tuoi eseguibili, mai, può rompere la crittografia di qualsiasi messaggio mai scambiato.

A meno che l'applicazione che hai in mente sia molto specifica, questo significa che l'installazione potrebbe "sembrare" sicura, ma non lo è. In questi casi, di solito è meglio non cifrare affatto, in modo che nessuno coinvolto cada per quel falso senso di sicurezza ...

È molto buona cosa si sta cercando librerie standard per fare la crittografia (invece di implementare/creazione di un algoritmo da soli), ma la protocoll (come le applicazioni, chiavi e messaggi vengono utilizzate e scambiate) è importante almeno quanto il codice stesso. Potresti volere che le tue idee vengano testate da qualcuno che si occupa di crittografia, per dirti quali sono i punti deboli. (Sono sicuro che ce ne siano già abbastanza di StackOverflow. ;-))

+0

+1 per il buon consiglio. Ma, a differenza di quello che dici, almeno due risposte suggerivano di NON fare la crittografia simmetrica (Andrew Austin e la mia). – bortzmeyer

+0

Ammetto che non ho seguito i collegamenti per scoprire di cosa si trattasse. ;-) – DevSolar

+2

Devo dissentire un po '(e ovviamente lo farei); non abbiamo idea di cosa l'OP abbia in mente. Se la crittografia e la decrittografia vengono eseguite su computer diversi, una chiave interna è protetta. Se vuole solo giocare con le librerie SSL, la sicurezza è irrilevante. Ti darò il +1 per il consiglio, ma "non dovresti farlo" è un riassunto un po 'troppo forte. –

Problemi correlati