Programma di criptazione/decriptazione (Parte 2)

[M1n021]

nel momento in cui mi assicuri che la tua analisi fotografa esattamente il funzionamento del metodo usato dall'autore, per dare un'opinione la lettura del suo codice mi basta. Viceversa, se tu il codice non lo hai letto a questo punto non comprendo come fai a sostenerlo.

Semplice, dopo la chiusura dell'altro topic l'ho contattato per inquadrare meglio dal punto di vista matematico la proprietà che aveva riscontrato, in modo da poterci ragionare su seriamente ed eventualmente dimostrarla o confutarla; poi parlando si è passati anche alla parte crittografica e dopo varie domande mirate sono giunto all'analisi qui riportata, che costituisce la formalizzazione del suo metodo. E a tal riguardo, come già detto, potrebbe benissimamente accadere che il metodo in generale sia corretto, ma la messa in pratica fatta dall'autore no.

In ogni caso, il topic è partito da quel programma ed è a quello che mi riferisco. Se vuoi un giudizio sul post specifico è inutile che insisti a chiederlo a me, devi aspettare che lo faccia qualcun altro: è il motivo per cui la discussione rimane aperta.

Però una curiosità devi togliermela... perché ti sei rifiutato (e continui a rifiutarti) in ogni modo di valutare il metodo che ho descritto in questo post? Ammettiamo pure che esso non rispecchi quello dell'autore e che sia un metodo a parte, perché ti ostini così tanto a non volerlo giudicare? Posso saperlo?

 

[BAT]

perché ti ostini così tanto a non volerlo giudicare?

su che base teorica? crittografia non è fattorizzare un semiprimo
Avrei sempre voluto approfondire teoria dei numeri (meno crittografia, mi interessa senza appassionarmi), ma da dopo la laurea mi è sempre mancato il tempo materiale per affrontare lo studio di qualunque cosa, quindi solo letture divulgative. Avrei pure dei libri: totale di pagine lette 4! (quattro, non quattro fattoriale, che oltretutto fa 24, quindi poche).
Se è un metodo a parte crittograficamente valido, può essere evidente per qualche studente moderno, non per me.
In altri termini: un mio giudizio "positivo" non vale nulla, un giudizio negativo non vale ugualmente nulla! Quindi devi chiedere a chi ne ha la competenza.

Mentre "programmicchiando a tempo perso", se guardo un codice di programmazione qualche evidente magagna la posso ancora vedere.

 

[M1n021]

Se è un metodo a parte crittograficamente valido, può essere evidente per qualche studente moderno, non per me.
In altri termini: un mio giudizio "positivo" non vale nulla, un giudizio negativo non vale ugualmente nulla! Quindi devi chiedere a chi ne ha la competenza.

Mentre "programmicchiando a tempo perso", se guardo un codice di programmazione qualche evidente magagna la posso ancora vedere.

Ok, come vuoi.

abbiamo un programma che usa semiprimi hard-coded inseriti in un file e usati a scopo cifratura;

il precalcolo obbliga l'hard-coding di informazioni, l'hard coding manda la segretezza a rotoli.

Come già detto non ho letto il codice, ma da quello che ho capito i semiprimi vanno a costituire la chiave pubblica, quindi quale sarebbe il problema di sicurezza?
Chiedo da profano della crittografia.

 

[BAT]

quale sarebbe il problema di sicurezza?

parlo del codice: la chiave di decifrazione hard-coded dovrebbe essere nota solo all'utente, invece qui è nota anche al programmatore che l'ha generata.

 

[BAT]

disse quello che pensa che i byte esistano da 6 bit e 7 bit, citando il tuo sito

toh, dopo la mia segnalazione pare che abbia finalmente corretto, ora il byte ha riguadagnato la sua dignità completa tornando trionfalmente a 8 bit, hip-hip hurrà!
@piergiac-1 devi pure eliminare la frase "Quando si parla di Byte e bit, è facile confondersi." ti garantisco che dal 1963 circa, il byte è da 8 bit, l'unico a confondersi eri tu...
e per amor di precisione, byte si scrive con la "b" minuscola, la maiuscola si usa solo per l'abbreviazione (cioè o dici 1 byte o dici 1 B a patto che la B venga usata in un contesto in cui inequivocabilmente indica che si parla di unità di misura digitali legate a quantità di informazione).

 

[Skills07]

Non sono entrato a capofitto mi sono però, preso la briga di analizzare il codice scritto da @piergiac-1 che si ostiene a dire di aver trovato soluzione di fattorizzazione e bla bla bla.
Io faccio il developer sono un senior, lavoro da 13 anni nel settore, ho studiato all'università, ho preso 2 lauree, e non parlo tanto per dare fiato.
Voglio dare un suggerimento reale e formativo valido per tutti.

Parto con l'analisi del codice python fornito dove elenco tutte le criticità, mi sono preso un paio di ore, penso che con un altro paio di ore questo algoritmo lo cracco e ne faccio vedere l'instabilità (devo solo avere il tempo, ma con una bimba piccola ammalata è difficile).

Punto 1:
- codice scritto male ed italianizzato (concetto di programmazione assente). Un qualsiasi codice sorgente deve essere scritto in metodi, separato in classi etc , il suo è scritto tutto in un unico mappazzone privo di sintassi e logica. Che non si venga a dire è python si scrive cosi perchè non è vero e posso dimostrarlo con una mia repo github.

Punto 2:
- la gestione dei path dove ci sono righe come:

os.path.exists(f"{controllo1}")

permettono di fornire percorsi privi di sanitizzazione e quindi ottenere attacchi. Attacchi di che tipo?

1. Attacchi di traversata del percorso: Se un utente malintenzionato può inserire un percorso relativo (ad esempio, ../../etc/passwd), potrebbe accedere a file al di fuori della directory prevista.
   
   
2. Scrittura arbitraria di file: Il programma scrive dati di configurazione su file senza verificare che i percorsi siano sicuri o validi.
   
   
3. Mancanza di validazione degli input: Non viene applicata alcuna validazione agli input dell'utente (come controllo1 e controllo2), il che potrebbe consentire l'elaborazione di dati imprevisti o dannosi, portando a potenziali problemi di sicurezza o stabilità.

Punto 3:
- Gestione insicura dei file: Quando si aprono file come CsCfg per la scrittura, il programma non verifica le autorizzazioni corrette o il rischio di sovrascrittura. Se l'applicazione viene eseguita con privilegi elevati, potrebbe sovrascrivere file sensibili.

Punto 4:
- Uso di eval o operazioni simili non sicure: Anche se non è chiaro dal frammento visibile, qualsiasi uso di eval, exec o funzioni simili per elaborare input dell'utente introdurrebbe seri rischi di sicurezza, consentendo l'esecuzione di codice arbitrario.

Punto 5:
- Nessuna gestione degli errori per le operazioni sui file: Operazioni come l'apertura e la scrittura di file non hanno gestione delle eccezioni. Ad esempio:

1. Se il file non può essere scritto (ad esempio, per problemi di permessi), l'applicazione fallirà senza fornire un messaggio di errore chiaro.
   
   
2. Operazioni crittografiche hardcoded: Il metodo di crittografia non è completamente visibile, ma se viene utilizzata una crittografia personalizzata (ad esempio, "Fermat 128bit/GC57" menzionata nell'interfaccia utente), potrebbe non essere sicura. Algoritmi di crittografia personalizzati o deboli possono portare a vulnerabilità, specialmente se non si basano su librerie crittografiche ben testate.
   
   
3. Informazioni sensibili nei messaggi: Assicurati che i percorsi dei file o altri dati sensibili non vengano mostrati direttamente all'utente nei messaggi di errore.

Spero di essere stato un pò esaustivo su cosa non funziona in codesto algoritmo

 

[M1n021]

Però non capisco perché vi siete affrettati a chiudere l'altro topic e ora utilizzate questo da me creato per commentare il codice di @piergiac-1 ?!

 

[Skills07]

l'argomento è correlato quindi non vedo il problema

 

[M1n021]

Il punto è che nonostante il topic l'abbia aperto io, si è parlato più delle cose riportate nell'altra discussione che di quelle da me qui introdotte, ma vabbè fa niente, fate pure.

In ogni caso ne approfitto per chiedere una cosa.
Dall'idea che mi sono fatto sul metodo dell'autore, ho capito che alla fine tutta questa impostazione è finalizzata al fatto di poter criptare ogni messaggio utilizzando una chiave di criptazione diversa (nel senso che essa viene pescata tra migliaia/milioni di chiavi di criptazione possibili). A detta dell'autore ciò dovrebbe conferire al metodo una maggiore sicurezza, visto che il confronto tra più messaggi criptati con la stessa chiave potrebbe far emergere uno schema che eventuali malintenzionati potrebbero sfruttare per decriptarli (tutti o in parte).
E' fondato questo presupposto?

 

[Skills07]

A parte i vecchi algoritmi di cryptazione, qualsiasi algoritmo moderno confronta e cifra il messaggio solitamente con la stessa chiave pubblica e diverse chiavi private.
Le chiavi private però vengono calcolate runtime, mentre purtroppo per l'autore di suddetto algoritmo sono stoccate in un file per questo continuiamo a ripetere che non è SICURO, in quanto usa chiavi HARDCODED predefinite.

A lui sarebbe bastato ad esempio estendere uno SHA256 o simili senza cercare di reinventare l'acqua calda o la ruota, che aimè già esistono.
Anche il 3DES nasce dall'implementazione stessa del DES (ad esempio).
Oppure estendere RSA che fa esattamente questo:

L'algoritmo RSA si basa sulla difficoltà di fattorizzare un numero molto grande in due numeri primi. Quindi, anche se qualcuno ha accesso all'informazione cifrata e alla chiave pubblica, è molto difficile per loro scoprire la chiave privata che è necessaria per decodificare il messaggio. Questa caratteristica rende l'algoritmo RSA molto sicuro e per questo viene utilizzato per proteggere molte comunicazioni online, come per esempio i pagamenti online o le comunicazioni via e-mail.

 

[M1n021]

Non ho capito, tralasciando quello che fa l'autore, la risposta alla mia seguente domanda

Dall'idea che mi sono fatto sul metodo dell'autore, ho capito che alla fine tutta questa impostazione è finalizzata al fatto di poter criptare ogni messaggio utilizzando una chiave di criptazione diversa (nel senso che essa viene pescata tra migliaia/milioni di chiavi di criptazione possibili). A detta dell'autore ciò dovrebbe conferire al metodo una maggiore sicurezza, visto che il confronto tra più messaggi criptati con la stessa chiave potrebbe far emergere uno schema che eventuali malintenzionati potrebbero sfruttare per decriptarli (tutti o in parte).
E' fondato questo presupposto?

sarebbe sì? E per il motivo che ho descritto?

Le chiavi private però vengono calcolate runtime, mentre purtroppo per l'autore di suddetto algoritmo sono stoccate in un file per questo continuiamo a ripetere che non è SICURO, in quanto usa chiavi HARDCODED predefinite.

Parlo in base a quello che ho capito e da profano della crittografia.
Il file contiene l'elenco dei semiprimi, tutti fattorizzabili con la chiave c ; quest'ultima viene scambiata in modo sicuro tra i due utenti che vogliono stabilire una comunicazione. A questo punto, se uno degli utenti vuole inviare un messaggio all'altro, viene prelevato uno dei tanti semiprimi, il quale viene fattorizzato con la chiave c , e in seguito il messaggio viene criptato col maggiore A dei due primi che costituiscono il suddetto semiprimo. A questo punto il destinatario del messaggio, una volta noto il semiprimo utilizzato, potrà fattorizzarlo anche lui ed utilizzare lo stesso primo A per decriptare il messaggio.
Dove si preconfigura il problema di sicurezza nello scenario appena descritto? Cioè anche se il file coi semiprimi fosse pubblico, come potrebbe essere utilizzato per bucare la sicurezza? Non sto dicendo che non sia possibile farlo, chiedo semplicemente come praticamente potrebbe essere fatto.

 

[Skills07]

Un file contiene l’elenco e un altro la chiavi.
Ti ho appena spiegato che un algoritmo di cifratura (tra cui rsa) che è uno dei più sicuri. Usa 2 chiavi. Una pubblica, è una privata.
Quella pubblica la decide chi invia il messaggio è una la decide chi lo riceve. Nel mezzo vengono calcolate delle chiavi private a runtime dell’algoritmo. In maniera tale che se anche una delle due chiavi pubbliche viene interecettata sarà impossibile decifrare il messaggio.
Se tu queste chiavi le stocchi in un file/ registro a qual si voglia, e soprattutto mantieni le criticità che ho elencato al post precedente un malintenzionato può tranquillamente decifrare il tuo file.
Ti allego come funziona l’ algoritmo RSA e così può studiarlo dal punto di vista matematico