2010/9/22 Claudio Telmon: [...] >> Su questo non sono affatto d'accordo, è possibilissimo in questo caso >> fare un risk assessment e non vedo quali dati ci manchino :-) > > Cioè saresti in grado di valutare il rischio che venga craccato > l'algoritmo vecchio, mantenendolo in esercizio, vs. il rischio che venga > craccato quello nuovo, sostituendo quello vecchio?
Più o meno :-) > Mi pare che l'impatto > sia pari, e quindi rimanga solo la componente probabilistica... come la > valuteresti? Non mi dire semplicemente che "quello nuovo è migliore, > quindi la probabilità è più bassa" ;) Quello vecchio sta ormai finendo i suoi giorni, quindi non dovrebbe essere difficile :-) Quello nuovo "dovrebbe" reggere se non altro per una questione di legge di Moore, ovvero, la CPU power ed i tool accessori (radio, ecc.) necessari a crakkarlo in real time non dovrebbero essere di facile/economica accessibilità per un po' di tempo. Ovviamente nel caso che venga scoperta una debolezza nell'algoritmo (come altri hanno spiegato in lista) questo tempo si abbassa notevolmente, forse su questo non si può far altro che sperare che il "Black Swan" non si verifichi. (mi sto tra l'altro leggendo il libro di Taleb, che ho trovato per caso in libreria...) >> Nel caso specifico della sicurezza informatica non mi sembra che ci >> sia molto di diverso dal tipo di risk assessment che si fa in caso di >> un progetto di disaster recovery. > > Il disaster recovery è infatti un approccio corretto. O meglio: lo è > quando ragiona per indisponibilità di risorse e non per scenari. Ma il > DR riguarda solo la disponibilità. Corretto, sono d'accordo. Se il sistema viene compromesso in modo "strutturale" allora non c'è DR che tenga >> Non credo che sia il caso della discussione circa questo protocollo, >> non vedo quale grande disastro potrebbe essere generato se questo >> algoritmo venisse crakkato > > Forse mi sono spiegato male: tu dici che l'intero sistema è pensato per > non essere fortemente dipendente dalla sicurezza del singolo algoritmo. > Io sto semplicemente dicendo che è un ottimo principio. Da quello che > vedo, gli algoritmi sono utilizzati per fornire "authentication and > radio link privacy to users on a GSM network". Se non ci fossero altre > misure al contorno, nella mia ignoranza ne dedurrei che la > compromissione degli algoritmi permetterebbe come minimo di violare la > privacy del link, il che lo considererei un impatto non da poco. [...] Sarebbe un brutto impatto, ma rimane il fatto che nessuno ha mai garantito questa privacy in primis. Non conosco i contenuti dei contratti per le concessioni delle licenze governative ma immagino che la lawful interception venga prima della privacy... Col vecchio protocollo TACACS chiunque poteva "sniffare" le conversazioni e nessuno ne era così scandalizzato. Personalmente non vedo come ad oggi la cosa possa essere diversa dal punto di vista della "user acceptance". Forse si scandalizzerebbero giusto gli utenti di questa lista ;-) Cordiali saluti -- Marco Ermini r...@human # mount -t life -o ro /dev/dna /genetic/research http://www.linkedin.com/in/marcoermini "Jesus saves... but Buddha makes incremental back-ups!" ________________________________________________________ http://www.sikurezza.org - Italian Security Mailing List
