Risposta breve: Qualsiasi crittografia simmetrica moderna considerata sicura è soddisfacente. Basta usare AES con una modalità operativa sicura, come CBC o GCM.
Gli attacchi di testo in chiaro noti sono una parte standard della crittanalisi; qualsiasi cifra che sia anche marginalmente più debole nei loro confronti è altrimenti considerata crittograficamente compromessa.
Risposta più lunga: si tratta di un rischio eccellente da considerare, ma si sta ponendo la domanda sbagliata. Lasciando da parte il perché (cioè, perché stai provando a lanciare il tuo schema di crittografia dei dati, quando ne esistono già tanti? ), dovresti probabilmente considerare dove il presupposto che
this makes finding the key with brute force easier
viene da. Anche se HMAC i dati con una chiave diversa (non possibile se si utilizza uno schema di crittografia autenticato come AES-GCM), se tu hai un modo per determinare una chiave corretta da una non corretta (come un hash della chiave, o del testo in chiaro, o anche solo perché si presuppone che se decrittografa in JSON sintatticamente valido la chiave è probabilmente giusta), un utente malintenzionato può fare la stessa cosa. Essere in grado di convalidare quasi istantaneamente la correttezza della chiave corretta si presume che sia sempre il caso.
La difficoltà della crittografia forzata brutale non è dovuta al fatto che non hai un testo in chiaro parziale nei sistemi che lo usano, o perché è difficile sapere quando hai indovinato la chiave giusta. È perché lo spazio chiave è così grande che, se hai costruito un intero datacenter pieno di hardware top-of-the-line che non ha fatto altro che provare un attacco distribuito per forzare brute-force una singola chiave AES a 128 bit e potrebbe girare all'infinito, le macchine in quel data center sarebbero assurdamente improbabili da indovinare la chiave giusta prima che il sole si espandesse per inghiottire la terra.
A proposito, non è un'iperbole; l'intuizione umana è davvero pessima ai grandi numeri e 2 ^ 128 è un numero estremamente grande. Diciamo che hai messo un milione di CPU (OK, 2 ^ 20) nell'hardware in quel data center. Supponiamo inoltre che ognuno di loro possa controllare 32 miliardi (2 ^ 35) di chiavi possibili al secondo (che è più veloce anche delle migliori CPU moderne con accelerazione hardware di cui sono a conoscenza, ma hai un po 'di hardware personalizzato di fantasia) . Ciò significa che l'intero datacenter può controllare 2 ^ 55 (circa 32 quadrilioni) di chiavi possibili al secondo. Super veloce, giusto? A quel ritmo, e assumendo che in media devi solo cercare metà dello spazio delle chiavi, avrai bisogno di (2 ^ 127) / (2 ^ 45) = 2 ^ 82 secondi per avere una probabilità del 50% di trovare la chiave.
Ci si aspetta che il sole inghiottisca la terra in circa 7,6 miliardi di anni (da o migliaia di millenni). In secondi, questo è 2.4x10 ^ 17, scritto anche come 2.4e17. Prendi il logaritmo in base 2 di quel numero e ottieni un po 'meno di 58. 2 ^ 82/2 ^ 58 è 2 ^ 24, o circa 16 milioni. Saresti all'incirca un sei milionesimo di percento del cammino fatto.
Inoltre, non fa parte della tua domanda, ma: stai prendendo in considerazione l'integrità (rilevando la manomissione del testo cifrato, che la maggior parte della crittografia fornisce poca o nessuna protezione contro) e anche generando vettori di inizializzazione univoci per i tuoi file, giusto? Fare la crittografia è difficile. Esistono già (tonnellate di) programmi che eseguono la crittografia simmetrica di file (o altri blob di dati).