Questo sito utilizza cookies solo per scopi di autenticazione sul sito e nient'altro. Nessuna informazione personale viene tracciata. Leggi l'informativa sui cookies.
Postato originariamente da Thejuster: Che metodo utilizzate solitamente per questo tipo di cifrari?
Niente di sofisticato, cripto e decripto con una chiave, questo è il metodo che avevo usato nel progetto 2048, scriito insieme ad Ultimo e Mikelius è in C# ma il concetto è valido.
La chiave la puoi allungare o accorciare a piacere:
i % ChiaveArray.Length // fa si che la chiave sia ciclicamente applicata.
Con una chiave random lunga come il testo da criptare la decodifica non è più possibibile senza conoscere la chiave, ma già con una chiave lunga una decina di caratteri la decodifica è fuori portata ai più.
Non ci sono controlli di overflow.
Ultima modifica effettuata da Carlo il 17/05/2024 alle 21:37
A me intriga un metodo che usa come chiave un file qualsiasi, purché di grandi dimensioni e contenente byte con valori che coprano l'intera gamma 0x00-0xFF (un brano musicale, un filmato, un'immagine…), seguendo questi passi:
1) considera un byte alla volta i dati che si intende criptare
2) estrae a sorte una posizione qualsiasi nel file della chiave
3) scorre il file della chiave dal punto estratto fino a incontrare un byte identico a quello considerato in 1) (se il byte non viene trovato a partire dalla posizione estratta, continua la ricerca dall'inizio)
4) memorizza l'indice al byte trovato nella versione codificata dei dati
5) ripete il tutto col byte successivo dei dati che si intende criptare, finché se ne raggiunge la fine
In questo modo si ottiene una serie di valori che sono assolutamente privi di senso se non si dispone del file della chiave.
È vero che in fase di codifica può capitare che un certo byte non sia presente nella chiave, ma in quel caso basta cambiare chiave. Comunque sia, con i file di grandi dimensioni si tratta di un caso molto raro (in genere contengono ogni particolare byte una quantità di volte).
Per evitare che un certo valore possa essere legato in modo univoco a una singola posizione (può capitare che il byte della chiave presenti un certo byte in una ed una sola posizione), si può prevedere una funzione che verifichi preventivamente che la chiave contenga almeno una quantità minima a piacere di occorrenze per ogni byte.
Per decodificare:
1) considera un valore alla volta i valori contenuti nel file codificato
2) rileva dal file della chiave il byte che si trova nella posizione appena letta dal file codificato
3) ripete il tutto col valore successivo tra quelli contenuti nel file codificato, finché se ne raggiunge la fine
Il difetto più evidente di questo metodo è che ogni byte da codificare richiede una quantità maggiore di byte nel file codificato. Ad esempio, se si usano indici a 32 bit, ogni byte da codificare richiederà quattro byte nel file codificato.
Non ho idea del grado di affidabilità della codifica in termini di "inviolabilità", ma credo possa essere molto alto. Ovvio che se un "pirata" si intromette nel meccanismo e si impossessa del file della chiave, salta tutto e i contenuti in chiaro finiscono per essere facilmente esposti.
Che ne dici?
ATTENZIONE! Sono un hobbista e l'affidabilità delle mie conoscenze informatiche è molto limitata. Non prendere come esempio il codice che scrivo, perché non ho alcuna formazione accademica e rischieresti di apprendere pratiche controproducenti.
Postato originariamente da Thejuster: Ma se provo ad aggiungere all'econdedChar ulteriori parametri del tipo
(c ^ hash) * 2 esempio, non riesco più a risalire alla stringa originale. Nonostante sia che l'encode / decode siano uguali.
Ritengo che moltiplicando per 2 in alcuni casi il valore ecceda 255, in questo caso in C non hai errori ma viene memorizzato il valore x-256.
Quando fai l'inverso il valore restituito non sarà lo stesso dell'originale.
Non ho fatto prove vado a naso.
Ultima modifica effettuata da Carlo il 17/05/2024 alle 23:28
Ciao, premetto che non so nulla di questi argomenti e che le seguenti osservazioni si basano sul ragionamento e sulle mie basi di C/C++:
- ha senso utilizzare per la chiave una variabile a 16 bit dal momento che i singoli char di cui è costituita la stringa ne hanno solo 8?
Testo quotato
Postato originariamente da Thejuster: Ma se provo ad aggiungere all'econdedChar ulteriori parametri del tipo
(c ^ hash) * 2 esempio, non riesco più a risalire alla stringa originale. Nonostante sia che l'encode / decode siano uguali.
Moltiplicare per 2 equivale ad uno scorrimento a sinistra di un posto, il che si traduce nel perdere ogni informazione sul primo bit (a sinistra) del carattere da criptare.
La pecora è vissuta per tutta la vita con la paura del lupo, ma alla fine se l'è mangiata il pastore!
Forse sarebbe meglio se l'Occidente la smettesse di essere così "generoso"... a furia di esportare democrazia, ne rimane sempre meno per noi!
Ciao Nippolo ben risentito. Grazie per il contributo.
AldoBaldo è sceso nei meandri scherzosi della paranoia funzionale...
Thejuster invece si è tenuto nel criptaggio decodificabile dai software che contano statisticamente la ripetizione dei caratteri.
Con l'xor statico, per uno stesso carattere in chiaro hai sempre lo stesso carattere criptato.
In un testo lungo il conteggio delle ripetizioni porta statisticamente a trovare l'dentità dei caratteri, con il ricavo facile dello spiazzamento (fisso).
In un testo corto, la prova di tutti i possibili spiazzamenti (256) porta alla decodifica facile del testo originale.
Nel caso che il testo criptato non contenga parole con senso compiuto, il metodo è valido.
Di seguito il codice di Thejuster modificato per la codifica tramite chiave che non da lo stesso carattere criptato per lo stesso carattere in ingresso, tale metodo inficia il conteggio statistico dei caratteri:
Codice sorgente - presumibilmente C++
#include <iostream>
#include <sstream>
// chiave allungabile/accorciabile, attenzione a valori troppo alti, testare
// attenzione a caratteri con codice ascii troppo alto, testare
string original ="nel mezzo del cammin di nostra vita mi ritrovai in una selva oscura, poiche' la retta via era smarrita";
string encoded = EncodeString(original);
string decoded = DecodeString(encoded);
cout<< original << endl << endl;
cout<< encoded << endl << endl;
cout<< decoded << endl;
return0;
}
Quanta sicurezza abbiamo?
La sicurezza è molto elevata per l'invio di un messaggio criptato intercettabile da un malintenzionato.
Come nessuno ci ha ripetutamente insegnato, è inutile adottare un criptaggio se nel pc è installato un software che internamente decodifica, il malintenzionato capace andrà a leggere i registri della CPU mentre avviene la decodifica, ricavando in un attimo la chiave.
In questo caso l'approcio di AldoBaldo potrebbe mettere in difficoltà il malintenzionato se la chiave è lunga megabyte ed usata in modo arzigogolato.
Ultima modifica effettuata da Carlo il 18/05/2024 alle 13:05
Quello che volevo ottenere è una lista di hash generati a runtime, ovviamente impossibile da saperli.
perché nell'esempio l'ho settato manualmente.
int16_t increment = 0x0105;
Ma intendevo fare un generatore in quella posizione.
una lista che tiene conto quali hash sono stati utilizzati, usata a ritroso per riconvertire il valore.
non è un file che và salvato, ma semplicemente una stringa contenente dei valori che deve essere scambiata online.
ovviamente dati sensibili che devono essere nascosti.
ma speravo nell'implementare un generatore random su increment.
Anche il metodo di carlo sembra efficiente.
@Nippolo Si infatti era questo il problema.
I char diventano illeggibili e quindi si perde il valore del char.
Cercavo un esempio o un qualche sistema per poter ulteriormente modulare una hash per codificare del testo.
Presumo che si, da debugger possa riuscire a risalire che calcolo esegue. Ma senza conoscere il corrispondente hash usato penso sia impossibile risalire al valore esatto.
Ultima modifica effettuata da Thejuster il 18/05/2024 alle 18:40
Salve ragazzi qualcuno ha già realizzato un cifrario in passato?
ciao, anni e anni fa feci alcune implementazioni di vecchi cifrari esistiti nella storia... in particolare, in c++ avevo fatto il cifrario di playfair... sicuramente non serve al tuo scopo, perché è un cifrario superato, ma per mera curiosità eccolo qui:
Allora... visto che mi si dà del paranoico (non senza qualche ragione), pongo una questione "seria": tramite il mezzo informatico, presumere l'inviolabilità è un assurdo. In una situazione "media" si può ipotizzare di procurare agli spioni qualche addebito sulla bolletta dell'ENEL, necessario per tenere acceso il sistema addetto alla decrittazione per quel po' di tempo in più che serve per trovare la quadra. Se si è particolarmente attenti si può costringere lo spione a metodi di intrusione più complessi, tali da procurare qualche mal di testa, ma difficilmente si potrà andare oltre. Se lo spione è lo Stato, basta un mandato e una pattuglia per ingabbiare il criptatore e forzarne la loquacità con metodi leciti e/o illeciti. A volte non serve neppure un mandato.
Scusate il pessimismo.
Resta comunque il divertimento del baloccarsi con questo genere di passatempo (io stesso lo faccio di quando in quando).
P.S. per Carlo: ho capito benissimo (e apprezzato) l'intento scherzoso della tua citazione.
Ultima modifica effettuata da AldoBaldo il 19/05/2024 alle 22:05
ATTENZIONE! Sono un hobbista e l'affidabilità delle mie conoscenze informatiche è molto limitata. Non prendere come esempio il codice che scrivo, perché non ho alcuna formazione accademica e rischieresti di apprendere pratiche controproducenti.
| 
