Un segreto precondiviso è sufficiente per la crittografia?

Sì!

I Cyphers possono prendere tutti i tipi di forme. Per definizione, un segreto è tutto ciò che è necessario.

Non significa che sarà abbastanza sicuro ...

link

EDIT: Se stai proponendo di implementare qualcosa di simile in produzione, ripeterò il consiglio esperto in altri post. Utilizza algoritmi e librerie già provati. Questo di solito significa che, nel tuo scenario, A crittografa con la chiave pubblica B e B decodifica con la chiave privata B.

Inoltre, considera una volta che A o B cade, è un disastro completo. Gli aggressori possono simulare qualsiasi punto della rete, creare messaggi o leggere qualsiasi messaggio che sia mai passato attraverso la rete o lo sarà mai.

La crittografia della chiave privata è abbastanza strong da proteggerti dato che

1. Stai utilizzando un algoritmo sufficientemente potente
2. Hai abbastanza bit nella chiave
3. Sei abbastanza sicuro che le tue macchine endpoint non vadano perse o rubate
4. Non devi occuparti di troppi dipendenti scontenti che potrebbero rubare la chiave
5. Affrontare # 3 e amp; # 4, hai qualche mezzo per lanciare la chiave e distribuirne di nuove in risposta agli eventi di sicurezza e anche in modo proattivo su base regolare (frequenza in base alla dimensione della chiave)

Sembra che tu abbia alcuni fraintendimenti importanti. Un sale non fa parte della crittografia, è una parte dell'hashing. C'è un concetto simile nella crittografia chiamato IV o vettore di inizializzazione che viene utilizzato in un codice di flusso per renderlo così l'output del codice di flusso è più difficile da analizzare, ma fornisce un vantaggio solo se ogni blocco di un messaggio dipende da il blocco dipendente precedente per il suo output (cioè, è una modalità di concatenamento).

La premessa di base della crittografia è che un messaggio (testo normale) viene mutato attraverso un segreto (una chiave) in un modulo che è difficile da capire senza la chiave (testo cifrato). Ci sono stati molti di questi sistemi nel corso degli anni con diversi livelli di sicurezza, da quelli che possono essere banalmente ridotti a quelli che sono molto difficili (o addirittura impossibili) da violare se correttamente seguiti.

La forza della protezione offerta dipende dalla casualità della chiave e dalla forza dell'algoritmo stesso per resistere all'analisi, e questa è la parte che è davvero, davvero difficile da capire.

Ci sono sicuramente problemi nel protocollo, non necessariamente nello schema di crittografia del richiedente.

Il protocollo consente attacchi di riproduzione, ovvero un'entità R può catturare messaggi inviati da A a B, quindi invia nuovamente i messaggi senza sapere cosa c'è in quei messaggi, anche se A potrebbe non averne l'intenzione di inviarli. Quindi si riduce a ciò che è contenuto in quei messaggi. Ad esempio, supponiamo che A e B siano computer e A invia un messaggio a B per riavviarsi e un'altra entità E la cattura. Ora, semplicemente riproducendo il messaggio e osservando il comportamento di B, E non solo può causare che B si comporti come vuole, ma capisce anche cosa significa il messaggio anche se non può vedere il contenuto.

Un secondo tipo di attacco è che un'altra entità M può falsificare A e iniziare a inviare B con molti messaggi. Poiché B non sa se provengono da una fonte attendibile, B tenterà di decrittografarli, consumando così risorse. M potrebbe non avere bisogno di tante risorse quante tutte le operazioni di M devono creare e inviare dati casuali, ma B inizierà a esaurire le risorse, questo è un attacco DOS.

Un altro attacco implica che M catturi i messaggi che A invia a B e risponde con ACK per conto di B, che ha catturato in uno scambio precedente. B non riceve mai i messaggi effettivi e non sa che non ha ricevuto il messaggio. A non si sa mai che non era B che ha ACKed il messaggio, invece era E.

Ci sono altri attacchi più sofisticati che possono essere costruiti in questo modo. Quelli che ho elencato qui sono in genere gli attacchi introduttivi che vengono esaminati quando si progettano protocolli sicuri.

La sicurezza arriva con una miriade di cose, non solo la crittografia. La crittografia risolve un aspetto, anche se il più importante, intorno alla sicurezza. Ma nel tuo caso, stai anche progettando un protocollo, che non è sicuro, e quindi potresti anche usare un protocollo esistente.

Ecco dove arrivano i protocolli di sicurezza che eseguono strette di mano appropriate, autenticazione (per garantire che l'altra parte sia quella corretta), fornire protezione contro gli attacchi di riproduzione ecc. Gli attacchi man-in-the-middle potrebbero ancora essere una vulnerabilità (se non ti fidare dell'infrastruttura a chiave pubblica, cioè), anche se nel tuo caso, puoi risolverlo perché A e B hanno un segreto condiviso (in realtà, presumo che tu stia iniziando con il segreto condiviso principalmente perché A e B fanno non fidarti di nessun altro al mondo - di solito una buona ragione per avere segreti condivisi.)

Btw, una volta che disponi di tali protocolli di sicurezza, dati tutti i dati che devono inviare tra loro, ti ritroverai con token di sicurezza per garantire che tutte le parti abbiano una comprensione reciproca di ciò che è contenuto in esso, come sia codificato, ecc. (ad esempio nonce, chiavi, dati crittografati, firma digitale, ecc.)

In sostanza, IMO, stai tentando di creare il tuo protocollo di sicurezza e, come qualcuno ha già menzionato, potresti stare meglio tentando di iniziare con un protocollo esistente.