Nvidia Logan, Kepler alla conquista del mobile

Re: Sicurpas freeware 4.0 Professional

il post sul vettore di inizializzazione del Rijndael e gli altri strafalcioniNon sai leggere. Non c'è nessuno strafalcione. L'IV serve per il concatenamento dei blocchi, ma ormai suppongo sicurpas usi l'ECB. Il vettore di inizializzazione non serve per il cifrario (per il cipher). Infatti non è mai stato detto che l'IV serve come input per il Rijndael.Se Sicurpas usasse l'IV, chiedevo da dove lo generava. Perchè deve essere casuale, ma in questo raro caso può anche essere molto-"pseudo" e poco-"casuale" perché dopotutto l'IV può anche essere pubblico in quanto la sicurezza dei dati cifrati ricade solo sulla chiave - infatti l'IV è usualmente salvato in chiaro. Se poi il software genera anche le chiavi con la stessa funzione random allora un problema c'è, anzi due. La domanda era comunque pertinente, mi immagino che nella prossima versione Sicurpas genererà come IV qualcosa di derivato dalla password. Bel metodo per vanificare l'utilità dell'IV! Ovviamente sto' speculando, ma d'altronde come si puo' sapere come funziona un software closed?Ecco, i commenti degli altri utenti sono in realtà tutti giusti. E' la classica abitudine da italiano con la coda di paglia quella di non accettare le giuste critiche, a un software che lascia molto a desiderare.Non lavoro all'INAF (sai poi che referenza!) ma sono un crittoanalista. Ed è già tanto che non ti ho criticato l'uso del rijndael al posto del serpent; ma nemmeno sapresti che differenza c'è tra la struttura dei due cifrari e la sicurezza derivante dal maggior numero di clicli di round del serpent. Ora mi verrai a dire che ho detto che il rijndael è insicuro... ovviamente non ho detto questo. Potrei chiedere se il rijndael da te implementato passa l'autotest o se l'hai scaricato da internet, se usa l'aes-ni (ma penso di no), se usa il concatenamento counter ed è multihtread o altre cose, ma ad ogni modo l'unico avvertimento che do' agli altri utenti è di diffidare di sofware come questo, cioè closed source e perlopiù sviluppato da chi non è evidentemente un esperto del settore. La critica sulla generazione delle password è valida. Il programma le genera male... ma visto che mi hai infastidito non ti dico il perchè né come risolvere. E poi... un software fatto in delphi nel 2013? il delphi è conosciuto solo perché utile per le interfaccie grafiche col suo IDE+RAD, l'ho usato in un'epoca remota, ma chi mai si sognerebbe di sviluppare qualcosa in delphi nel 2013 o di continuare lo sviluppo di un software non-commerciale in delphi ad oggi. E' morto circa nel 2004, mi ricordo vagamente che ormai non lo usavo più da tempo quando uno sviluppatore delphi mi ha detto che sarebbe passato al c++ perchè dopo il tempo della borland o già codegear il delphi era finito. Vero, infondo.Inutile dire che un software di crittografia deve fare solo quello. Ho poi visto sul sito che questo cerca di contrastare anche i keylogger. Ma truecrypt fa una cosa del genere? GPG? OpenSSL? PGP? No! Perché quando un host è compromesso non c'è niente da fare - chi manovra un trojan scarica il file quando è decifrato o infetta l'exe dei programmi e fa quello che vuole, senza "infettare" che sembra una parola molto da giornalista usualmente un semplice dll injection da un createremotethread basta già ma si può anche usare un rootkit a ring0 o un driver come keylogger.Poi sul key stretching non si è saputo niente così come sul resto...Bon. Alla fine, non mi rimane se non da notare...che non c'è motivo per un software come questo per rimanere closed-source. Non viene venduto (chi lo userebbe mai altrimenti?), non è un software unico al mondo e sicuramente non è il migliore nel suo genere quindi tanto vale che lo rendi open source e poi magari in futuro qualcuno te lo aggiusterà.Sono ovviamente d'accordo sul fatto che dicevo io in realtà, meglio usare GPG. Ma in questo giro aggiungo KeePass(X) per la gestione delle password.