Transmit ciphers utilizzando HTTP semplice

Sembra che tu stia cercando di inventare una specie di clone "DropBox".

Security of a single encryption algorithm is well studied, while stacking multiple ones is unknown (e.g. NaCl() vs. AES(NaCl())

Penso che questo non si applica. Non riesco a formulare una dura argomentazione matematica qui, ma per le crittografie indipendenti, con chiavi completamente non correlate, la forza della crittografia composta NON può affatto scendere. E sarà almeno PIÙ strong quanto il più debole delle due crittografie. È tutto. Sta solo impedendo la semplice aggiunta di due lunghezze chiave. Nel peggiore dei casi si finisce con la più bassa delle due lunghezze chiave nella pila. Questo è solo per le chiavi indipendenti. Che possiamo assumere per una combinazione di crittografia at-rest e crittografia TLS-session-key. (Correggimi se sbaglio, Sec: SE.)

Simplicity (at rest == in transit)

Penso che questo sarà notevolmente compensato dalla complessità del tuo schema di autenticazione / firma.

Increased server load (zero-copy sendfile(2) vs. copying to RAM for TLS encrypt).

Penso che l'impatto sulla latenza e il throughput saranno trascurabili. Forse nemmeno misurabile. Insisterei su un punto di riferimento. (- > Vedi link )

E ancora: non ho idea di quale impatto avrà lo schema di autenticazione.

Server validates token (to prevent reuse) then streams encrypted archive files to/from disk.

Ciò significa che il server NON è più una memoria stupida.

Invece che dire di impostare le cose come un mirror per una distribuzione Linux? Archivi firmati su dumb (S) FTP? Poiché esegui comunque la verifica lato client.

Quando si esegue la crittografia end-to-end, il canale per inviare i testi cifrati avanti e indietro è già considerato non sicuro. L'unica ragione per cui potresti volere che il tunnel SSL / TLS sia racchiuso tra i ciphertexts è di convalidare l'identità del server, che a seconda del caso potrebbe non essere necessaria.

Puoi anche fare un ulteriore passo avanti e inviare i dati direttamente su TCP (o UDP se si adatta). Ciò consente di risparmiare alcuni costi generali. In effetti alcune app di chat fanno esattamente questo (Telegram). Ovviamente questo implica che devi occuparti dell'autenticazione e della privacy dei messaggi da solo.

Dopo aver esaminato diversi modelli di attacco, ho trovato due possibili rischi:

1. Recupero lento (Denial of Service)

   MiTM sul canale HTTP può falsificare la trasmissione lenta, negando all'utente un servizio di qualità.

2. Gestione dei messaggi danneggiati

   Using HTTPS
   corrupt packets    → MiTM
   corrupt ciphertext → corrupt parties (can be the server)
   
   Using HTTP
   no way to distinguish since packet == ciphertext 
   

   Sapendo che la distinzione è preziosa, il programma può fare l'azione giusta (ad esempio riprova più tardi una volta che il canale è protetto o scarta subito il messaggio)

Lastpass fa qualcosa di simile, e funzionerebbe altrettanto bene su HTTP semplice come nella loro implementazione.

Utilizzano HTTPS per l'autenticazione, come specificato nell'OP.
Tutte le tue password vengono trasmesse e archiviate utilizzando il loro algoritmo di crittografia.

Tutta la crittografia e la decrittografia vengono eseguite sul tuo PC, quindi non hanno un carico del server imposto dal processo di crittografia.

Dove differiscono da questo post è che continuano a utilizzare anche HTTPS per le comunicazioni e l'autenticazione.

Non è chiaro il motivo per cui si vorrebbe evitare HTTPS. E poiché l'OP dice di usare HTTPS per l'autenticazione, allora perché non continuare a usarlo per il resto della sessione. Con i processori moderni, il carico del server imposto dall'utilizzo di HTTPS è molto limitato.

Il più grande rischio nell'utilizzo di HTTP è in un attacco di replay in cui il database lastpass potrebbe danneggiarsi o bloccarti.

Credo che abbiano il modello migliore per comunicazioni e archiviazione sicure.

Sì, funzionerebbe su HTTP semplice ad eccezione dell'autenticazione.

Spero che questo aiuti.