Quanto è sicura la nuova crittografia del sito Mega?

I dettagli sono relativamente scarsi, ma la sezione 5 della ht pagina degli sviluppatori viene linkata per descrivere il tipo di crittografia che applicano . Bottom-line: non lo dicono esplicitamente, ma è fondamentalmente modalità CCM , anche se con alcune semplificazioni nella gestione IV . Non parlano di padding e lunghezza codifica, e questo potrebbe essere un problema.

Inoltre, il file è suddiviso in blocchi, ognuno dei quali ha il proprio MAC, in modo da poter "elaborare" i blocchi singolarmente. Tuttavia, sembra che non vi sia alcun numero di sequenza nella cosa MAC; per quanto riguarda il testo, l'IV per il MAC del secondo blocco è il CBC-MAC del primo blocco, il che è negativo perché potrebbe essere modificato da un individuo malintenzionato. In pratica, ciò significa che il MAC per chunk è utile solo se si esegue il flusso dei dati dall'inizio , nell'ordine dovuto; l'accesso casuale sarebbe suscettibile agli attacchi.

Il concetto principale dell'uso di una chiave per file è corretto, ma richiede un'attenta gestione delle chiavi e non ci sono abbastanza dettagli sulla pagina per decidere se le cose sono state fatte correttamente o meno. L'intera cosa puzza di una costruzione fatta in casa ed è noto che le costruzioni fatte in casa sono terreno fertile per le vulnerabilità.

sembra che oggi ci sia una stampa che delinea difetti di sicurezza con l'approccio alla sicurezza adottato da Mega, vedi questo articolo che commenta la ricerca di Alan Woodward.

Riepilogo dei principali difetti:

1. lunghezza della chiave per la chiave SSL
2. Affidati agli amministratori di Mega che le chiavi non possono essere catturate da una modifica del server nella javascript
3. generazione di numeri casuali prevedibili
4. password persa = dati persi

La sola crittografia non protegge le tue informazioni, indipendentemente da ciò che MEGA o altri dicono. Immagino che MEGA stia usando la stessa crittografia di chiunque altro. Probabilmente Full Disk Encryption (FDE / AES) per i dati a riposo nel cloud MEGA combinato con Internet Protocol Security (IPsec) che protegge la comunicazione tra il cloud storage PC / MEGA. Entrambe le forme di crittografia utilizzano chiavi a 128 bit o 256 bit.

La triste notizia è che la crittografia a 128 bit o 256 bit sono stati entrambi violati. Infatti, recentemente alcuni hacker israeliani hanno rotto la chiave GSM 128bit in 2 ore. Quindi l'hacking della forza bruta è una sfida (che esegue numeri sequenziali finché non si ottiene una corrispondenza) o irrompendo nell'archivio delle chiavi situato nella casella di destinazione. FDE funziona utilizzando un keystore incorporato nella memoria. Rompere nella memoria si ottiene la chiave utilizzata per lo sblocco. Quindi ci sono un paio di modi in cui i buoni hacker possono violare la crittografia. La buona notizia è che la maggior parte dei dati crittografati mantiene circa il 90% della popolazione. Tuttavia, è il 10% di cui devi preoccuparti. :)

Il codice AES 128 viene esaminato dagli utenti in modo che l'alta qualità dell'implementazione possa essere garantita. Progetto principale qui ma sulla crittografia di Mega here . Blog sullo sviluppo qui

Code transparency is being provided progressively. SDK code has been available since 2014 and we are now disclosing code for our web client and browser extensions.

Modifiche 2016 in cryptopp.h

• decodeintarray funzione
• serializekey funzione

Modifiche 2016 in cryptopp.cpp

• AsymmCipher::serializeprivkforjs molta pulizia nel cifrario asimmetrico; costante statica molto facilmente da indovinare (0123456789abcdef);
• molta pulizia e codici più leggibili (nomi di variabili, struttura ecc.)

sdk/tests/paycrypt_test.cpp

• lunghezza fissa BASE64_IV, BASE65_ENCKEY, BASE64_HMACKEY, CHIAVI
• test principale PayCrypter:hybridEncrypt

test

Solo un singolo test principale con un solo contributore nella crittografia. Codice sdk / test / paycrypt_test.cpp . Test principale PayCrypter:hybridEncrypt

//Test PayCrypter:hybridEncrypt()
string finalResult;
string contentString = CONTENT;
ASSERT_TRUE(payCrypter.hybridEncrypt(&contentString, pubkdata, pubkdatalen, &finalResult, false));

che sembra utilizzare uno schema chiave asimmetrico, ovvero potrebbe essere inefficiente con messaggi molto lunghi. Il rischio principale ( Wikipedia ) è apparentemente nell'incapsulamento chiave e nella sua definizione di sicurezza in cui l'incapsulamento dei dati deve essere leggermente più strong. Questo fatto sembra essere il caso nel codice confrontando l'inizializzazione delle chiavi.