[JAVA] "Blindatura" di una classe

[edark]

Originariamente inviato da alka
Da quel che ho capito, in questo caso, la preoccupazione del nostro amico è data dal fatto che avendo realizzato un algoritmo per motivi di sicurezza, il fatto che questo possa essere "disassemblato" rende inutile di fatto l'algoritmo stesso, che va quindi mascherato in qualche modo.

appunto, proprio per questo, ho costruito una classe che deve descriptare delle stringhe scritte dentro un file e se in quelle stringhe decriptate che scritto un codice (licenza) abilito il programma...non c'è un modo in java per fare questo, anche se la sicurezza la 100% è pura utopia

Mah fatemi capire una cosa...ma si può risalire al codice degli algoritmi come DES - AES? In che linguaggio sono scritti?

grazie

[alka]

Originariamente inviato da Ed_Bunker
Ok, ok... Ad ogni modo la conoscenza dell'algoritmo, in crittografia, e' data per scontata.

Per gli algoritmi più diffusi, sì, per altri no.
Non è possibile generalizzare.

Se io utilizzo un sistema reversibile, il mio algoritmo non deve essere visibile altrimenti è sempre possibile effettuare, appunto, l'operazione inversa.

Se parliamo di algoritmi come MD5, allora il discorso cambia.

Originariamente inviato da edark
appunto, proprio per questo, ho costruito una classe che deve descriptare delle stringhe scritte dentro un file e se in quelle stringhe decriptate che scritto un codice (licenza) abilito il programma...non c'è un modo in java per fare questo, anche se la sicurezza la 100% è pura utopia

Se hai già implementato il tuo algoritmo, proteggilo offuscandolo. Cosa ti impedisce di scegliere questa soluzione?

Originariamente inviato da edark
Mah fatemi capire una cosa...ma si può risalire al codice degli algoritmi come DES - AES? In che linguaggio sono scritti?

Sono algoritmi, perciò sono espressi attraverso passaggi logico matematici che si possono tradurre con qualsiasi linguaggio. Non esiste un linguaggio specifico.

Ciao!

[edark]

Ma questi programma che offuscano il codice, restituiscono sempre un file .class, solamente con il codice "offuscato"?
Ma per eseguire i programmi bisogna "portarsi dietro" questo offuscatore?
grazie

[alka]

Originariamente inviato da edark
Ma questi programma che offuscano il codice, restituiscono sempre un file .class, solamente con il codice "offuscato"?

Esattamente.

Originariamente inviato da edark
Ma per eseguire i programmi bisogna "portarsi dietro" questo offuscatore?

No.

Io ne conosco solamente uno per .NET, quindi non posso dirti molto a riguardo, soprattutto in merito a Java.

Ciao!

[Ed_Bunker]

Originariamente inviato da alka
Per gli algoritmi più diffusi, sì, per altri no.
Non è possibile generalizzare.

Se io utilizzo un sistema reversibile, il mio algoritmo non deve essere visibile altrimenti è sempre possibile effettuare, appunto, l'operazione inversa.

Non e' un fatto di generalizzare o meno...
Certo anch'io se voglio fare un alg. di cifratura lo posso fare senza renderlo pubblico. Ad ogni modo per fare in modo che esso possa essere considerato ad un livello piu' ampio di quello... "casalingo"... DEVO renderlo disponibile ed aperto a studi e tentativi di "rottura'.

Un discorso e' parlare di reverse engineering ed un discorso e' parlare di funzione inversa all'algoritmo di cifratura. Cose completamente differenti.
Senza conoscere i dati in ingresso (O parte di essi: la chiave !) e' impossibile (In senso computazionale) risalire ad essi conoscendo soltanto la funzione di cifratura ed i crittogrammi da essa generati (In funzione di particolari dati in ingresso non noti).
Basti dire che nel DES decifratura e cifratura coincidono...

[edark]

ok grazie vedo se trovo qualche link

[Ed_Bunker]

[B]
Mah fatemi capire una cosa...ma si può risalire al codice degli algoritmi come DES - AES? In che linguaggio sono scritti?

grazie

Un algoritmo non dipende dal codice con cui viene scritto.
DES e AES sono pubblici, visibili e "attaccabili" da chiunque.
Anzi... se riesci a "rompere" l'AES mi sa che potresti avere un bel futuro...
Il linguaggio con cui vengono scritti e' del tutto "ininfluente"...

[alka]

Originariamente inviato da Ed_Bunker
Non e' un fatto di generalizzare o meno...
Certo anch'io se voglio fare un alg. di cifratura lo posso fare senza renderlo pubblico. Ad ogni modo per fare in modo che esso possa essere considerato ad un livello piu' ampio di quello... "casalingo"... DEVO renderlo disponibile ed aperto a studi e tentativi di "rottura'.

Sono tutti problemi esterni a ciò che stiamo discutendo, o almeno così mi pare.

Ad esempio, se ho semplicemente deciso di fare uno XOR di tutti i dati che memorizzo all'interno di un file al solo ed unico scopo di non metterli "in chiaro" ma di camuffarli, è sufficiente dare un'occhiata al codice dell'applicazione disassemblato per accorgersi del trucco, e presumo che questo sia anche il problema del nostro amico: mascherare in qualche modo l'algoritmo che interpreta il dato che consente all'applicazione di funzionare in modo che non sia possibile risalire alle modalità di interpretazione e trattamento rendendole così facilmente aggirabili.

Originariamente inviato da Ed_Bunker
Un discorso e' parlare di reverse engineering ed un discorso e' parlare di funzione inversa all'algoritmo di cifratura. Cose completamente differenti.

Lo so bene, infatti non capisco come mai continuino a saltare fuori discorsi su algoritmi di cifratura che, se ho capito bene il problema focale della discussione, non hanno nulla a che vedere con la questione.

[edark]

Originariamente inviato da alka
Sono tutti problemi esterni a ciò che stiamo discutendo, o almeno così mi pare.

Ad esempio, se ho semplicemente deciso di fare uno XOR di tutti i dati che memorizzo all'interno di un file al solo ed unico scopo di non metterli "in chiaro" ma di camuffarli, è sufficiente dare un'occhiata al codice dell'applicazione disassemblato per accorgersi del trucco, e presumo che questo sia anche il problema del nostro amico: mascherare in qualche modo l'algoritmo che interpreta il dato che consente all'applicazione di funzionare in modo che non sia possibile risalire alle modalità di interpretazione e trattamento rendendole così facilmente aggirabili.

perfettamente ragione!
Non ho trovato nulla per offuscare

[tonytalk]

La butto li :-) perchè non ho visto nessuna citazione a riguardo.

Inserire l'algoritmo in un metodo nativo dovrebbe essere "protetto" (protetto tra virgolete perchè io penso che nulla informaticamente parlando sia veramente protetto)

Ciao