MgpF <mf@???> writes:
> non riesco a capire come le discussioni tecniche su HM siano diventate così
> di poco tecniche
Sono tanto d'accordo, ma non ho mai contribuito veramente da potermi
permettere di dirlo. Vediamo se riesco a rimediare.
> * Un occhio ai sorgenti, avrebbe almeno risposto che quasi tutta la
> crittografia è gestita con la lib crypto di NodeJs[1]. Davvero basta
> leggere i sorgenti...
NodeJs è lato server però no? Mi pare si parlasse dello stato delle
sorgenti di entropia lato client.
> * Ove non possibile usare il nativo, usa il CSPRNG derivato da Salsa20[2],
La questione mi pareva fosse ferma ancora sul come reperire l'entropia sul
browser. Il csprng usato non c'entra, quello la spalma e basta.
Sinceramente, non so quali browser forniscano entropia dal sistema
operativo al motore javascript, ma direi la maggior parte.
Dire che le app nel browser non hanno abbastanza entropia è un discorso
da benvenuti nel 2007.
Oltretutto, cercando l'interfaccia Crypto sviluppata da mozilla, mi sono
imbattuto su:
<
https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#dfn-Crypto>
che perlomeno mi rassicura sul fatto che ci si sta muovendo verso una
standardizzazione.
> dimostrato crittograficamente sicuro almeno sino a 128-bit contro gli
> attacci di crittanalisi differenziale[3].
In realtà vorrei puntualizzare che, no.
Salsa20 è 128 o 256-bit. Cosa buol dire "sino"?
Cosa vuol dire "dimostrato crittograficamente sicuro contro gli attacchi
di crittanalisi differenziale"? Si parla di stime probabilistiche no?
Mi pare di capire che il paper studia la sicurezza dei cifrari ARX,
proponendo delle nuove *stime* sulla "caratteristica differenziale" (che
non so cosa sia). Come esempio propongono una versione *modificata* a 3
round di Salsa20.
Poi Salsa20 è stato fatto da djb, e le difficoltà trovate già nello
studiare 3 round mi fanno ragionevolmente pensare che sia affidabile nella
versione a 20 round, quindi magari in fondo vogliamo dire la stessa cosa.
Nota a margine: porca troia usano perl per fare i test hahaha.
> * Un occhio agli autori delle presentazioni portate ad eseprio a riprova
> dell'insicurezza della crittografia su Javascript e sulla generazione dei
> numeri casuali avrebbe mostrato che si citano 2 talk di... Nadim Kobeissi
> (@kaepora).... l'AUTORE di Cryptocat...
Credo fosse di proposito. No?
> Comunque sia nella Score Card della EFF[4] sulla sicurezza dei sistemi di
> messaggistica, Cryptocat ha il livello massimo atribuibile, insieme a
> TextSecure, OTR etc, più alto di GPG per Mac e Windows, btw.
Non trovo più nessun riferimento a supporto, ma ricordo che alcuni tra
quelli che seguo su twitter lamentavano le valutazioni di EFF a
riguardo.
Per rispondere infine alla domanda iniziale. Personalmente non mi piace
cryptocat, perché mi ha dato un po' di sfiducia quando è successo
questo: <
http://tobtu.com/decryptocat.php>, e perché credo di poter
badare alla mia sicurezza meglio senza di esso.
--
µ.
