Codice adatto per la crittografia SMS

Vi esorto a rivedere la vostra premessa. Se entrambi gli endpoint dispongono di un'app, i criteri per la scelta dell'algoritmo non sono validi: l'app gestirà la crittografia / decrittografia, non l'utente. La crittografia a chiave pubblica può potenzialmente fornire una migliore sicurezza in questo contesto; per esempio, può abilitare la gestione delle chiavi trust-on-first-use (SSH-like). Inoltre, ti suggerisco di iniziare pensando prima al modello di minaccia. La prima domanda non dovrebbe essere, quale algoritmo crittografico devo usare? La tua prima domanda dovrebbe essere: quali minacce sto cercando di difendere?

Se è necessario utilizzare la crittografia simmetrica per i messaggi SMS, AES in modalità CBC con rubare il testo cifrato è una scelta plausibile. Il furto del ciphertext eviterà sprechi se il messaggio da crittografare non è un multiplo pari di 16 byte. Avrai ancora bisogno di una flebo, che occuperà un po 'di spazio. Per risparmiare spazio, è possibile inviare un contatore e utilizzare la crittografia AES del contatore come IV.

Se esiste un modo per evitare il trasporto di testi cifrati tramite SMS, evitalo. 160 caratteri sono molto limitanti. Puoi trasportare messaggi su Internet?

Se puoi evitare il tunneling tramite SMS, puoi esplorare un modello in cui l'app ha la sua chiave privata / pubblica e mantiene una chiave pubblica per ogni contatto. Quando si contatta qualcuno di nuovo, l'app invia la propria chiave pubblica, riceve una chiave pubblica dall'altra persona, ricorda quella chiave pubblica e invia il messaggio crittografato con quella chiave pubblica. Questo è ovviamente vulnerabile agli attacchi man-in-the-middle, ma potrebbe essere più facile da usare.

Se stai cercando una varietà di marche e modelli, semplicemente non funzionerà, anche se molti smartphone consentono a software di terze parti di inviare messaggi SMS tramite gateway Internet, tutti tranne i sistemi operativi telefonici più aperti non consentire a software di terze parti di gestire i messaggi SMS in arrivo.

Tuttavia, se ignoriamo l'impossibilità, 128 AES dovrebbe funzionare bene. Questo ti darà un testo cifrato non più grande del testo in chiaro; 8 dei quali possono essere inseriti in un SMS a 140 byte. Usando la codifica dei caratteri di SMS, significa che hai ancora 146 caratteri di messaggio.

Dato che hai specificato la crittografia simmetrica, sono più che felice di lasciare a te il problema della distribuzione delle chiavi!

Dovrai utilizzare AES o una combinazione di AES + RSA. Ora arriva il problema di 160 caratteri. In realtà il carico utile disponibile è solo di 140 byte. Nei cellulari (GSM o CDMA); 140 byte disponibili sono codificati in codifica a 7 bit, consentendo quindi di inserire 160 caratteri in 140 byte.

Ora dato che SMS è il canale e la crittografia deve essere eseguita, la modalità di comunicazione non può più essere un messaggio di testo ma un messaggio binario. Un messaggio binario richiederà 7 byte extra per UDH (User Data Header). Quindi il numero di caratteri su cui puoi operare è solo 133.

Penso che se stai usando un canale SMS, allora hai bisogno di una APP in entrambe le estremità. È possibile utilizzare la messaggistica basata sulla porta; utilizzando il quale il messaggio verrà elaborato direttamente dall'applicazione finale e non dalla posta in arrivo nativa.

Un vantaggio del canale SMS è il protocollo di archiviazione e inoltro, significa che le possibilità che l'altra parte ricevano il messaggio è alta, il problema è il ritardo e le limitazioni del carico utile. Utilizzando la segmentazione a livello di applicazione puoi anche inviare messaggi lunghi.

Un altro vantaggio del canale SMS, è che in una comunicazione a due vie, verrà confermato che la vera parte di fiducia è coinvolta solo nella messaggistica. A può essere falsificato da B mentre invia un SMS a C; ma quando C risponde andrà sempre su A. Quindi utilizzando le negoziazioni a 2 vie è possibile creare un algoritmo di generazione e condivisione delle chiavi per la comunicazione reciproca.