Spiegazione della sicurezza rispetto alle prestazioni a un superiore non tecnico

4

Mi è stato affidato il compito di implementare una sorta di codifica / decodifica basata su password in un'applicazione Android da parte del mio SO non tecnologico. Mi ha anche mostrato questo elenco di fornitori di sicurezza Android . Naturalmente, ha scelto quello con il maggior numero di sigle e numeri più alti ( PBEWITHSHA256AND256BITAES-CBC-BC ) con cui andare.

Come faccio a spiegargli (in parole povere) che il fornitore è piuttosto eccessivo per l'app e potrebbe causare un calo di rendimento?

    
posta Community 25.12.2011 - 15:46
fonte

4 risposte

9

La crittografia basata su password, con la crittografia dei dati e una firma per dimostrare che i dati non possono essere modificati da chiunque senza la password, utilizzando chiavi più lunghe, è una buona scelta.

PBE = crittografia basata su password. Non è questo quello che ti serve?

WITHSHA256 = SHA-256 è un algoritmo di hash moderno e viene utilizzato per dimostrare che i dati non possono essere stati modificati da chiunque abbia la password a portata di mano. Gli hash a 256 bit sono lo standard moderno, con 512 bit di hash per quelli di noi che vogliono solo un po 'più di rassicurazione. La famiglia di funzioni hash SHA-2 è il più recente diger standard NIST.

AND256BITAES = AES-256 è un algoritmo di crittografia moderno. La dimensione della chiave a 256 bit è per quelli di noi che vogliono solo un po 'più di rassicurazione, anche se una dimensione della chiave a 128 bit può essere sufficiente per molti usi. Le famiglie di funzioni AES sono le più recenti crittografie a blocchi standard NIST.

CBC = La modalità CBC per la crittografia è la scelta predefinita per trasformare un cifrario a blocchi in un codice di flusso. I codici di flusso sono necessari quando uno ha un flusso di dati di lunghezza arbitraria da codificare. AES in modalità CBC è una scelta più moderna di RC4.

BC = La scelta della libreria provider di crittografia. Scegli una libreria crittografica affidabile e performante. BouncyCastle è implementato in Java, quindi il JIT potrebbe essere in grado di ottimizzarlo. OpenSSL è implementato in C e il provider di crittografia potrebbe avere collegamenti alle funzioni C, ma il JIT non è in grado di ottimizzare le funzioni C.

Se è necessario crittografare, esiste una necessità equivalente di crittografare con algoritmi e tecniche moderni. Usali, a meno che non vi sia una ragione specifica, dimostrabile e comprovata.

    
risposta data 25.12.2011 - 20:13
fonte
2

Senza ulteriori informazioni, non è possibile per noi dire se quell'algoritmo è eccessivo. Potrebbe essere giusto. È necessario esaminare i requisiti di prestazioni e di rischio per determinare l'algoritmo. E tali requisiti dovrebbero essere concordati tra azienda e sicurezza: il compromesso determinerà i requisiti IT.

    
risposta data 25.12.2011 - 16:22
fonte
2

" PBEWITHSHA256AND256BITAES-CBC-BC " non è una cattiva scelta (vedi la risposta di @ Justice). Non dice tutto su ciò che verrà fatto a livello crittografico; ovvero, "PBE" significa "Crittografia basata su password", il che implica che una password verrà trasformata in una chiave di crittografia (una chiave a 256 bit, poiché il sistema di crittografia è AES-256) utilizzando una funzione di hash. Tale trasformazione è soggetta ad alcuni parametri configurabili (conteggio di iterazioni, sale ...) e c'è ampio spazio per le cose di botching. Eppure SHA-256 e AES-256 sono scelte valide. AES-128 è in qualche modo preferibile poiché è già abbastanza sicuro contro la tecnologia non extra-terrestre ed è circa il 29% più veloce di AES-256, ma tale miglioramento della velocità è solo nelle condizioni ideali, quando la crominatura simmetrica è il collo di bottiglia e tutto il resto nell'applicazione software è veloce e fluido; questo accade raramente. Nell'elenco di algoritmi a cui fai il link, questo rappresenterebbe un caso per PBEWITHSHA256AND128BITAES-CBC-BC .

Il vero problema è che il tuo SO non tecnologico sembra essere uno scimpanzé: fa delle scelte di sicurezza basate sulla bellezza dell'acronimo. Lo farà ancora occasionalmente, anche se solo per pura fortuna, come nel caso specifico. Eppure, in generale, questo è preoccupante. Per convincerlo a modificare le sue scelte, è improbabile che le argomentazioni scientifiche razionali siano efficaci: la scienza funziona solo su persone che stanno già sottomettendo alla sua grandezza, e qualcuno che va all'acronimo più appariscente è non pronto ad accettare che la Scienza si applichi. Ti suggerisco di provare a dargli una banana invece. Nel tuo caso, il gustoso frutto avrebbe il seguente aspetto: emettere l'ipotesi che AES-128 ridurrebbe i costi del (fino al) 29%; è una menzogna sfacciata (le questioni finanziarie sono solo estremamente vagamente legate alla velocità di crittografia grezza), ma almeno è brillante.

(Per essere onesti con il tuo SO, è abbastanza probabile che cerchi solo di calmare un'altra scimmia che si trova più in alto nella gerarchia, ma in realtà non cambia la situazione.)

    
risposta data 26.12.2011 - 21:48
fonte
-1

Potresti provare a mostrargli che è molto più lento di qualsiasi altro algoritmo in quella lista.

Esegui semplicemente ogni algoritmo un milione di volte e mostragli la differenza di orario. Quindi spiega che quello più veloce è perfettamente sicuro.

    
risposta data 25.12.2011 - 15:51
fonte

Leggi altre domande sui tag