Quanto è strong una semplice crittografia XOR con IV casuale?

I'd like to implement some kind of simple (yet as strong as possible) encryption > for my client-server application network traffic. Data to be encrypted can be both textual, and binary.

Stai implementando una cifra Vigenère modificata modificata. Questo potrebbe essere un problema in quanto qualsiasi sequenza sufficientemente grande di dati ripetitivi (con gli zeri binari che sono i più evidenti), o dati strutturati (es. JSON) come indicato da Polynomial, rivelerà la lunghezza della chiave e l'algoritmo che stai utilizzando e, banalmente, consente la decrittazione di informazioni utili per un paio di lunghezze chiave.

Esistono diversi approcci crittanalitici che possono essere adattati al tuo caso. Un semplice test di distribuzione rivelerà che vale la pena eseguire un attacco.

A parte questo, hai una vulnerabilità permanente nella distribuzione delle chiavi: o hai una chiave (o un insieme finito di chiavi) cablate sia sul client che sul server, oppure devi provvedere allo scambio di chiavi sicure.

using certificates and big libs like OpenSSL is just overkill for my project.

Per favore non prendertela male, ma ti stai avvicinando a questo nel modo sbagliato. Sono d'accordo che attuazione OpenSSL sarebbero ordini di grandezza più difficile che andare Vigenère (o Vernam / OTP, che è il passo logico successivo). Ma non è necessario farlo: devi solo utilizzare una libreria esistente. Dopo che sarete sani e salvi e sarà effettivamente godere non solo più sicurezza , che può essere superfluo, ma maggiore semplicità di codice e maggiore manutenibilità .

A seconda della configurazione, puoi farlo semplicemente facendo cadere un proxy SSL come Stunnel davanti al tuo semplice servizio HTTP:

                       |
HTTP service --- PROXY | === SSL channel === SSL client (browser)
                       |

e essere in grado di entrambi testare il tuo sistema in HTTP e fornire i tuoi client in modo sicuro in HTTPS.

Altri server Web (sia Apache e Nginx) che bilanciamento del carico consentono di SSLificare i servizi lato server.

Il problema numero uno con lo schema che hai proposto è che hai ignorato completamente lo scambio di chiavi sicure.

Il prossimo problema è che l'output non sarà casuale come Iserni indicato out ed è quindi suscettibile di numerosi attacchi.

Il prossimo problema dopo è che non è autenticato, il che può portare ad attacchi di modifica del testo cifrato e oracoli di riempimento come POODLE.

Questo schema è troppo semplicistico e ha troppe poche considerazioni per avere proprietà di sicurezza significative per l'uso online come delineato.

Come Stephen Touset citato in il suo commento , vuoi che i tuoi dati siano protetti dagli intercettatori o no. Se lo fai, crittografa i dati correttamente. Se non lo fai, non preoccuparti di criptarlo affatto.

TLS gestiva tutti i problemi complessi come lo scambio e l'autenticazione delle chiavi e l'implementazione di algoritmi veramente forti per te. Senza risolvere questi problemi, non hai la sicurezza, quindi non cercare di ingannare te stesso nel pensare di farlo aggiungendo qualche complessità arbitraria e chiamandolo algoritmo di crittografia. Lascia solo i dati non crittografati e sarà esattamente sicuro come lo sarebbe con lo schema che hai proposto.

TLS non lo è, come lo hai definito "teoricamente indistruttibile". In effetti ha alcune vere debolezze nei punti. Tuttavia, è abbastanza sicuro, e già implementato in molte librerie. Il tuo schema non è "abbastanza buono", ma in realtà sembra essere mal progettato, e per tutti gli effetti inutilizzabile senza molto più lavoro.

In pratica stai parlando dell'implementazione di un " one time pad " - (con alcune modifiche).

Per eseguire una volta sola, è necessario:

• assicurarsi che ci siano dati casuali sufficienti (che in pratica è la chiave);
• ha bisogno di avere proprietà casuali crittograficamente forti;
• devi distribuire questa chiave in modo sicuro a tutte le parti che devono decrittografarlo;
• è necessario proteggere la chiave nella memoria (tra la distribuzione e la decrittografia); e devi assicurarti che la chiave non sia mai, MAI riutilizzata ...
• quindi la tua chiave deve essere più lunga dei dati crittografati.

La linea di fondo è - SE è possibile implementarlo correttamente, è estremamente strong (probabilmente infrangibile, escludendo la crittoanalisi dei tubi di gomma).
TUTTAVIA è un enorme "se" - cioè è più semplice implementare semplicemente la crittografia regolare, dal momento che le pre-condizioni per implementarlo sono così difficili e rigorose.
(Cioè, se si dispone di un meccanismo per distribuire e proteggere così tanti dati in modo sicuro, si potrebbe anche utilizzare tale meccanismo sui dati segreti stessi, anziché sulla chiave).