Alfonso Maruccia

Datagate, da Lavabit a Israele

Le vittime del Datagate si organizzano e portano le autorità USA in tribunale, mentre nuove rivelazioni sulle attività dell'intelligence evidenziano i contatti (passati) con Microsoft e le collaborazioni (presenti) con Israele

Roma - Le ripercussioni dello scandalo Datagate sono destinate a farsi sentire ancora a lungo, soprattutto in merito a chi come Ladar Levison è praticamente ancora agli inizi della sua battaglia personale - e professionale - contro il trattamento ricevuto dalle autorità federali degli Stati Uniti.

Levison è entrato nelle cronache sulla sorveglianza globale della NSA e delle altre agenzia USA a tre cifre dopo essere stato costretto a chiudere Lavabit, servizio di email cifrate usato, tra gli altri, dallo stesso Edward Snowden per le sue comunicazioni "sensibili" con i giornalisti attivi sul caso Datagate.

Levison ha sempre sostenuto di aver voluto interrompere la fornitura del servizio piuttosto che divenire complice di un "crimine" contro i cittadini americani, un crimine di cui non può nemmeno discutere apertamente con il pubblico senza rischiare la galera.
L'imprenditore ha ora avviato una causa legale contro le autorità statunitensi, e mentre i dettagli della faccenda sono - neanche a dirlo - segreti, il diretto interessato dice che un eventuale esito favorevole aprirebbe la strada alla "resurrezione" di Lavabit come azienda con sede negli Stati Uniti.

Per una vicenda connessa al Datagate che si sviluppa - augurabilmente - alla luce del sole, un'altra emerge come semplice indiscrezione, ancorché dalla portata potenzialmente molto significativa: in passato, dicono le indiscrezioni, gli agenti dell'FBI avrebbero chiesto a Microsoft di inserire backdoor funzionanti all'interno del software di cifratura BitLoker, ennesimo tentativo di compromissione delle tecnologie crittografiche a cui gli ingegneri al tempo impiegati presso Redmond si sono apparentemente opposti.

Chi infine non ha mai avuto bisogno di backdoor per accedere ai dati altamente sensibili raccolti dalla NSA è l'intelligence israeliana, rivelano i documenti di Snowden consultati dal Guardian, visto che il Mossad ha la possibilità di consultare le informazioni "grezze" senza limitazioni legali di sorta. Anche sui cittadini statunitensi, la cui privacy, nelle assicurazioni del presidente Barack Obama, è tenuta in massima considerazione dagli spioni a stelle e strisce.

Alfonso Maruccia
Notizie collegate
14 Commenti alla Notizia Datagate, da Lavabit a Israele
Ordina
  • Senza dire che l'indebolimento del random pool per la generazione delle chiavi è sempre stata la tecnica favorita e ai come oggi pare essere la generazione dell'entropia e l'inizializzazione dei vettori rnd l'anello debole su cui si sta puntando.

    Numerosi casi si possono contare che hanno riguardato sia il mondo closed, che quello open, dai computer ai device.

    Alcuni algoritmi risentono meno di un deficit nella generazione random come RSA altri molto di più come il key exchange basato su DH o la generazione di chiavi Elgamal e DSS per quanto la cifratura assimmetrica e nella maggiorparte di quella simmetrica.

    Il fatto che il NIST prema per l'adozione delle implementazioni ECC dei rispettivi DH e DSS è un dato oggettivo e sospetto visto il caso Dual_EC_DRBG che a detta NSA era NIST SP 800-90 compilant and highly recommended.

    La necessità di avere un generazione di numeri casuali non prevedibile nella produzione di chiavi ECC-DH ECC-DS (già disponibili nella beta di gpg2), e della maggior parte degli algoritmi per la cifratura simmetrica di dispositivi e connessioni è fondamentale.

    Torvalds ha bollato con il suo inconfondibile stile la petizione contro l'adozione delle istruzioni RDRAND (che interfacciano i TRNG on chip) di Intel nel kernel linux, adducendo che sono solo uno dei tanti metodi per l'acquisizione dell'entropia necessaria, il che è indubbiamente vero, ma il fatto che Intel offra un hardware apposito nei suo prodotti danno certo uno spunto di riflessione.

    "I am so glad I resisted pressure from Intel engineers to let /dev/random rely only on the RDRAND instruction" celebre frase pubblicata dallo sviluppatore del kernel Theodore Ts'o ha dato da pensare a molti.

    Personalmente continuerò ad usare RSA 4096 finchè mi sentirò sicuro, disabiliterò RDRANDR quando ne avrò la possibilità non farò affidamento all'harware di Intel per la generazione dell'entropia, lascierò che sia ancora la mia scheda audio a farlo, e per la cifratura dei blocchi mi affiderò ancora a serpent-xts-512 e userò Whirpool per l'hashing, e Camellia per le connessioni ssl-tls quando dovrò implementarla.
    non+autenticato
  • - Scritto da: just to fill the blank
    > Personalmente continuerò ad usare RSA 4096 finchè
    > mi sentirò sicuro,

    Questa è un'ottima scelta. RSA 1024 bit IMO va oggi considerato craccato.
    Tuttavia vorrei farti notare che i tizi dell'NSA parlavano di un "importante svolta". Dubito che parlassero di qualche sabotaggio di standard o della possibilità di rompere una determinata lunghezza di chiave di RSA... è più probabile abbiano scoperto qualche proprietà importante in qualche algoritmo a chiave pubblica (RSA? Curve Elittiche? DiffieHellman?) che gli permette di decifrare con sforzo accettabile qualsiasi lunghezza di chiave. Purtroppo non ci è dato di sapere di che parlassero.
    Tuttavia, d'altro canto, da altre rivelazioni sembra invece che abbiano accesso a qualche CA e quindi possano crearsi i propri certificati a piacere per impersonare qualsiasi sito WEB... questo però sembra contraddire l'interpretazione di "importante svolta" che ho dato sopra.
    Perciò al momento stiamo girando ancora a vuoto.

    > disabiliterò RDRANDR quando ne
    > avrò la possibilità non farò affidamento
    > all'harware di Intel per la generazione
    > dell'entropia, lascierò che sia ancora la mia
    > scheda audio a farlo, e per la cifratura dei
    > blocchi mi affiderò ancora a serpent-xts-512 e
    > userò Whirpool per l'hashing, e Camellia per le
    > connessioni ssl-tls quando dovrò
    > implementarla.

    RDRAND non può influire nella generazione dei numeri casuali in Linux, per farlo dovrebbe essere stato sviluppato di proposito per far fallire l'algoritmo usato da Linux (quindi non funzionerebbe su Windows né su altri sistemi operativi, né funzionerebbe se l'algoritmo usato da Linux cambiasse) e avrebbe bisogno di riuscire a prevedere i dati ricevuti da altre fonti (per esempio leggendo la cache della CPU e riuscendo a distinguere tali dati) per poterle "annullare" nella XOR con cui quei dati vengono miscelati a quelli ricevuti da RdRand. Sarebbe un lavoro piuttosto complesso che influenzerebbe molte altre parti del processore, con pochissime garanzie e facilmente annullabile cambiando algoritmo.
    Non c'è alcuna ragione di sospettare che tale istruzione fornisca sequenze prevedibili ma, anche se fosse, ugualmente non avrebbe alcuna influenza in Linux (per le ragioni esposte sopra). Disabilitarlo IMO sarebbe un errore. Non solo perché ti rallenta la generazione dei numeri casuali, ma anche perché ti toglie una fonte di entropia.

    Snowden non ha mai parlato di Intel. Perché te la prendi con RdRand ma non con il generatore hardware di VIA ad esempio? O quelli della Quantis? O quelli nelle smartcard? O quelle dei vari token disponibili? Perché proprio quello di Intel? Ti stupisce il fatto che finalmente i microprocessori stiano supportando la generazione in hardware dei numeri casuali? Perché mai dato che sono sempre più usati (sia lato server, che client, che smartphone, che tablet, ecc)? È perfettamente normale che Intel cominci ad interessarsi, avrebbe dovuto farlo da lungo tempo.

    Supponiamo che lo standard per la generazione dei numeri pseudocasuali in software sia davvero fallato, che abbia davvero delle debolezze... disabilitando un generatore hardware non faresti altro che il gioco dell'NSA rendendo di fatto prevedibili i tuoi numeri pseudocasuali. In altre parole finiresti per spararti da solo sui piedi.

    Nello spezzone che citi di Theodore Ts'o dovresti, per completezza, anche citare le risposte di David Johnston (il tizio che ha fisicamente realizzato RdRand nei processori Intel) che garantisce di:
    1) aver realizzato l'istruzione al meglio delle sue conoscenze/capacità
    2) di non aver mai ricevuto alcuna pressione da chicchessia durante lo sviluppo dell'istruzione stessa né alcun ordine segreto da parte di nessuno
    3) di aver verificato il funzionamento di RdRand con microscopio elettronico e microprobes una volta realizzato fisicamente
    oltre alle risposte di un altro ex-ingegnere Intel che assicura che qualsiasi modifica allo schema del Chip avrebbe fatto scattare allarmi impossibili da ignorare e che una modifica post-progettazione è molto complessa e difficilmente passerebbe non vista (grazie ad almeno un centinaio di persone esperte [e di svariate nazionalità] che ci lavorano e ai sistemi automatici di verifica lungo tutta la linea di produzione).

    Fra l'altro... perché te la prendi con RdRand quando è l'intera CPU che potrebbe interferire con la generazione dei numeri pseudocasuali? Magari è l'istruzione XOR che attiva un comportamento "fallato" quando la CPU identifica determinate sequenze di istruzioni... che facciamo... disabilitiamo anche XOR?

    In altre parole a me sembra che qui ci si stia facendo prendere dalla paranoia e che questa paranoia stia spingendo più di qualcuno a fare scelte a dir poco premature se non addirittura contro-producente.
  • >RDRAND non può influire nella generazione dei numeri casuali in Linux
    è esattamente quello che fa e ad un ritmo direi impressionante
    rngtest: input channel speed: (min=998.814; avg=2191.053; max=41392.283)Kibits/s
    rngtest: FIPS tests speed: (min=34.935; avg=124.483; max=160.321)Mibits/s

    Il fatto che si siano fatte pressioni perchè fosse l'unica sorgente di entropia per /dev/random, per me è abbsatanza, non ho problemi di entropia sul pc come potrebbe averne un server con milioni di connessioni da gestire.

    Non è di per se del generatore che mi preoccupo, anzi benvenga un TRNG, è buona cosa, che comunque essendo standardizzato e inserito nella cpu può essere tranquillamente sfruttato in condizioni fault based in modo sistematico alterandone le condizioni di esercizio agendo per esempio sui voltaggi in modo preciso, ricostruendo quelle condizioni che per esempio hanno portato alla recente violazione di RSA1024 agendo sull'alimentatore di un pc.

    Perchè Via non ha mai fatto pressioni sugli sviluppatori kernel, perchè il metodo di generazione dipende da componenti fisiche che non vengono
    rilevate, i primi TRNG di Via sui C3 del 2003 già implementava 4 e dico 4 freerunning oscillators a cascata ciascuno, i generatori sono 2, esterni alla cpu, in posizione e orientamento diverso e infine i bit vengono mischiati, e non hanno implementato delle istruzioni proprietarie di cui non si conoscono i dettagli ma sono disponibili nell'hardware come /dev/tpm.

    Di tutti gli altri sistemi non faccio uso non ho device di sorta tranne un vecchio gsm, ma ho avuto due Epia una con C7 e una con Nano, e ci sono molte differenze tra quello che offre Via e quello che offre Intel.

    Il TRNG di intel soprattutto nella parte entropy source mi piace, il debiasing un po' meno, la sua collocazione non mi piace per niente.

    Quello di cui mi preoccupo è proprio RDRAND poichè non ho accesso a /dev/tpm0 l'hardware che sta generando l'entropia ma devo affidarmi alle istruzioni Intel che sta fornendo l'entropia in un operazione vitale per l'efficacia dell chiavi crittografiche che vengono prodotte e che mai come oggi può compromettrene completamente la sicurezza.

    Gli pseudorandom non c'entrano, qui si sta parlando della qualità del seed per /dev/random, che personalmente continuerò ad affidare a sensori analogici. Appoggiare a pseudorandom la generazione delle chiavi è da suicidi.

    Bannerò i driver.
    non+autenticato
  • > Il fatto che si siano fatte pressioni perchè
    > fosse l'unica sorgente di entropia per
    > /dev/random, per me è abbsatanza, non ho problemi
    > di entropia sul pc come potrebbe averne un server
    > con milioni di connessioni da
    > gestire.

    Secondo me il Ts'o sta esagerando quando dice "si sono fatte pressioni".
    Semplicemente l'ingegnere che ha progettato il generatore random è così sicuro del suo lavoro che vorrebbe fosse adottato "as is" a prescindere dalle altre sorgenti. Si tratta semplicemente di over-confidence nel proprio lavoro e nelle proprie capacità che in questo caso è sfociata in un suggerimento poco sensato. Se leggi la discussione su Google+ fra Ts'o e David Johnston probabilmente capirai meglio di che parlo... il tizio è semplicemente così orgoglioso del suo lavoro che prende quasi come un insulto personale il fatto che qualcuno non si fidi di lui. È un po' come quando ti criticano tuo figlio... anche se le osservazioni che fanno sono legittime tu le vedi come insulti a lui e a te.

    > Non è di per se del generatore che mi preoccupo,
    > anzi benvenga un TRNG, è buona cosa, che comunque
    > essendo standardizzato e inserito nella cpu può
    > essere tranquillamente sfruttato in condizioni
    > fault based in modo sistematico alterandone le
    > condizioni di esercizio agendo per esempio sui
    > voltaggi in modo preciso, ricostruendo quelle
    > condizioni che per esempio hanno portato alla
    > recente violazione di RSA1024 agendo
    > sull'alimentatore di un pc.

    Se quelli dell'NSA hanno accesso all'alimentatore del tuo PC sono sicuro che la generazione dei numeri casuali sono l'ultimo dei tuoi problemi.
    IMO è una cosa buona che i generatori di numeri random siano creati direttamente in hardware nelle CPU. Questo permette di avere una sorgente di dati casuali ad alte prestazioni che aiutano gli algoritmi in software pseudocasuali a generare sequenze molto migliori. Alla fine questo tenderà ad aumentare la sicurezza dei sistemi correntemente in uso che magari oggigiorno si basano solo su algoritmi in software e pochi bit casuali recuperati da altre fonti (pensa ad esempio ad un server che non ha alcun input fisico con il mondo reale come tastiere, mouse, ecc). Non puoi per esempio pretendere che il server su cui fai girare la tua pagina PHP sia dotato di una scheda RNG in hardware (anche perché sono tendenzialmente costose)... ma se tale RNG è implementato nella CPU lo ottieni "gratis". Così i flussi di dati crittati fra te e quel server saranno più sicuri.

    Se ci si fa prendere dal "panico" irrazionalmente si finisce appunto per fare scelte sbagliate e preferire tecnologie qualitativamente inferiori per meri sospetti. Ripeto, non ci sono oggettivamente prove di alcun tipo a sostegno della tesi che l'istruzione RDRAND delle CPU Intel delle nuove generazioni sia in qualche modo compromessa. Ts'o non voleva accusare Intel di aver voluto sabotare l'algoritmo di generazione di numeri casuali di Linux, ha semplicemente detto che dopo le rivelazioni dell'NSA è contento di non aver fatto come alcuni ingegneri Intel suggerivano ovvero di affidarsi unicamente al loro generatore hardware quando disponibile (e le ragioni per cui l'hanno fatto l'ho spiegato sopra, almeno per come la vedo io). Questa non è la stessa cosa di dire "l'RDRAND di Intel è stato sabotato".

    > Perchè Via non ha mai fatto pressioni sugli
    > sviluppatori kernel, perchè il metodo di
    > generazione dipende da componenti fisiche che non
    > vengono
    > rilevate, i primi TRNG di Via sui C3 del 2003
    > già implementava 4 e dico 4 freerunning
    > oscillators a cascata ciascuno, i generatori sono
    > 2, esterni alla cpu, in posizione e orientamento
    > diverso e infine i bit vengono mischiati, e non
    > hanno implementato delle istruzioni proprietarie
    > di cui non si conoscono i dettagli ma sono
    > disponibili nell'hardware come
    > /dev/tpm.

    Ciò non toglie che possano essere sabotati. La CPU VIA potrebbe per esempio sostituire i bit ricevuti dal generatore hardware e sostituirli con bit farlocchi (magari quando riconosce determinati pattern nel codice o quando riceve un segnale esterno particolare, tieni conto che qualsiasi software tu lanci in esecuzione alla fine è sempre e solo la CPU che svolge le azioni richieste... e non hai modo di sapere se le sta svolgendo correttamente o se si sta comportando in modo "bizzarro")... il fatto che la CPU/chipset VIA è una black-box né più né meno di quella Intel. Puoi solo fidarti delle loro descrizioni... a meno che tu non sia in possesso delle conoscenze necessarie e di un microscopio elettronico...

    Ma IMO ci stiamo preoccupando troppo di queste cose. Fare "carognate" del genere è costoso, con poche garanzie, e moltissimi rischi per le aziende che si prestano a questi giochetti. Se un giorno dovesse venire fuori che Intel (o VIA) ha sabotato i suoi processori per favorire l'NSA sarebbe un disastro economico (forse mortale) per lei perché nessuno si fiderebbe più dei suoi prodotti.

    È enormemente più semplice installare da remoto un Trojan nel tuo PC (vedi recente caso FreeHosting e la facilità con cui l'hanno fatto) e bypassare così qualsiasi software di cifratura tu usi che impelagarsi in improbabili attacchi che richiedono la corruzione di centinaia di professionisti (ognuno dei quali potrebbe parlare e presentare prove, anche via TOR per proteggere la propria incolumità). È enormemente più semplice inserire un proprio "agente in borghese" ad alti livelli dentro Microsoft, o Google, o Apple e poter inserire backdoor qui o lì o inserire "spie" in grado di vedere quello che fai _dopo_ che la cifratura ha fatto il suo lavoro (ovvero ha trasportato i dati in modo sicuro da casa tua al loro datacenter). O anche inserire backdoor in hardware o software nel tuo router e poter accedere alla tua rete locale a piacere dall'esterno.

    Siamo circondati dalla tecnologia, e purtroppo noi europei siamo stati stupidi a sufficienza da "delegare" la fabbricazione dei nostri chip ad aziende in nazioni estere poco affidabili (USA, Cina, ...). E ora ci troviamo in una posizione di debolezza che ci sta lasciando con le braghe calate. Abbiamo persino permesso che Microsoft si comprasse Nokia...

    Quello che dobbiamo fare ora è mettere su le NOSTRE aziende di chip, le NOSTRE aziende di software e sistemi operativi e dire agli USA "grazie ma no grazie, facciamo da noi, non ci fidiamo più dei vostri prodotti, ringraziate l'NSA". Paradossalmente l'NSA potrebbe aver fatto proprio quello che cercava di evitare... ovvero con le loro azioni hanno di fatto danneggiato gli USA più di quello che poteva fare qualsiasi beduino afgano.
  • - Scritto da: just to fill the blank
    > >RDRAND non può influire nella generazione dei
    > numeri casuali in
    > Linux
    > è esattamente quello che fa e ad un ritmo direi
    > impressionante
    >
    > rngtest: input channel speed: (min=998.814;
    > avg=2191.053;
    > max=41392.283)Kibits/s
    > rngtest: FIPS tests speed: (min=34.935;
    > avg=124.483;
    > max=160.321)Mibits/s
    >
    > Il fatto che si siano fatte pressioni perchè
    > fosse l'unica sorgente di entropia per
    > /dev/random, per me è abbsatanza

    Non ne sono sicuro, ma credo che Ts'o si riferisca a questo thread:
    https://lkml.org/lkml/2013/9/5/212

    Se si tratta di questo thread dire che "ha ricevuto pressioni" IMO è decisamente un'esagerazione. Semplicemente un tizio (che pare lavorare per RadHat) ha inviato una patch che permettesse all'utente di usare l'RNG in hardware di cui si fidasse direttamente tramite un'opzione (fra l'altro l'opzione mi pare non fosse nemmeno specifica per RDRNG).

    Io sono sempre stato un forte sostenitore delle "opzioni". Trovo per esempio molto sensato quello che Linus diceva di Gnome quando sosteneva che "se create un DE per stupidi solo gli stupidi useranno il vostro DE".
    IMO la facoltà di scegliere è fondamentale, preferisco sempre un software che mi da la possibilità di personalizzare il più possibile piuttosto che uno che invece ragiona stile Gnome ovvero "quest'opzione confonderebbe i nostri utenti quindi non la mettiamo".

    Se si tratta di questo thread ritengo la reazione di Ts'o ampiamente esagerata anche perché non puntava nemmeno a modificare il comportamento "di default" di Linux e del suo RNG.
    -----------------------------------------------------------
    Modificato dall' autore il 16 settembre 2013 17.15
    -----------------------------------------------------------
  • > In altre parole a me sembra che qui ci si stia
    > facendo prendere dalla paranoia e che questa
    > paranoia stia spingendo più di qualcuno a fare
    > scelte a dir poco premature se non addirittura
    > contro-producente.

    http://www.cryptography.com/public/pdf/Intel_TRNG_...

    Non mi piace:

    We did not have access to Ivy Bridge parts, so Intel provided us with testing data from pre - production chips. These chips allow access to the raw ES output, a capability which is disabled in production chips.

    As a result,some runs (in particular, the spikenear the right side of the plot) show artifactswhere the testing machine began reading before
    the ES turned on. After discussing these artifacts with Intel, we believe that they cannot happen during operation.
    --off course--

    If the frequency ratio varies slightly, or the ES is only mostly stuck at 1, then the part may pass the health checks despite having little entropy.
    In our experiments, many samples pass the health checks even if the ES is
    96% stuck at 1. Such a failure would go undetected, and would bring the system outside its design margins. Since production parts cannot examine the ES’s raw output, software would not be able to detect this failure either.

    In addition, developers should be aware that the RNG instruction
    can be virtualized, and could be intercepted to deliver nonrandom data to applications.

    Dato che l'Entropy Source non è accessibile, e il TRNG non è un hardware accessibile, ha tutte le caratteristiche di una black-box.
    non+autenticato
  • - Scritto da: just to fill the blank
    > > In altre parole a me sembra che qui ci si stia
    > > facendo prendere dalla paranoia e che questa
    > > paranoia stia spingendo più di qualcuno a fare
    > > scelte a dir poco premature se non addirittura
    > > contro-producente.
    >
    > http://www.cryptography.com/public/pdf/Intel_TRNG_
    >
    > Non mi piace:
    >
    > We did not have access to Ivy Bridge parts, so
    > Intel provided us with testing data from pre -
    > production chips. These chips allow access to the
    > raw ES output, a capability which is disabled in
    > production chips.
    >
    >
    > As a result,some runs (in particular, the
    > spikenear the right side of the plot) show
    > artifactswhere the testing machine began reading
    > before
    > the ES turned on. After discussing these
    > artifacts with Intel, we believe that they cannot
    > happen during
    > operation.
    > --off course--
    >
    > If the frequency ratio varies slightly, or the ES
    > is only mostly stuck at 1, then the part may pass
    > the health checks despite having little
    > entropy.
    > In our experiments, many samples pass the health
    > checks even if the ES
    > is
    > 96% stuck at 1. Such a failure would go
    > undetected, and would bring the system outside
    > its design margins. Since production parts cannot
    > examine the ES’s raw output, software would not
    > be able to detect this failure
    > either.
    >
    > In addition, developers should be aware that the
    > RNG
    > instruction
    > can be virtualized, and could be intercepted to
    > deliver nonrandom data to
    > applications.
    >
    > Dato che l'Entropy Source non è accessibile, e il
    > TRNG non è un hardware accessibile, ha tutte le
    > caratteristiche di una
    > black-box.

    Dice anche:
    In conclusion, we believe the Ivy Bridge RNG is well designed, with a wide margin of safety, and the output is appropriate to use directly for cryptographic keys, secret nonces, and other sensitive values. However, the most prudent approach is always to combine any other available entropy sources to avoid having a single point of failure. For OS implementations that maintain an entropy pool, we recommend the frequent incorporation of RNG outputs as an additional input into the OS entropy pool. The exceptional performance of the Intel design also enables direct mixing of data from the Ivy Bridge RNG outputs with output delivered from other RNGs. In all cases, users should check the carry flag after each call to the RNG to verify that it is working properly and the random data received is valid.


    Per ciò che riguarda la virtualizzazione... ovviamente l'istruzione può essere virtualizzata e di conseguenza essere manomessa dal software di virtualizzazione... ma se giri in un ambiente virtualizzato ci sono mille altri modi in cui il tuo sistema potrebbe non essere sicuro come dice anche il PDF che hai lincato.
  • ehmmm.. sucubi .. menomale tutto attaccato.. senò .. comprendo da come scrivi il livello culturale delle tue affermazioni.. Sorride
    non+autenticato
  • Se gli U.S.A. hanno questo rapporto con israele è la dimostrazione dell'opinione che gli U.S.A. non hanno una propria identità culturale (e sono sucubi dei libri sacri Ebraici di 5.000 anni fa)... menomale che l'Europa ha impedito il libero scambio dei film tra U.S.A. ed Europa (senò ci ritrovavamo, tra qualche anno, una serie di plagi da far paura!)... comunque, non penso che la Gran Bretagna sia messa meglio degli U.S.A.
    non+autenticato
  • E ti pareva che non poteva mancare la frecciatina antisemita? (o antisionista o contro un governo israeliano di turno -è lo stesso-) "Gli ebrei di quà, gli ebrei di là...".
    E' singolare (ma prevedibile) che lei dimostri che "il rapporto degli U.S.A. con Israele [esiste] perché non hanno una propria identità culturale (e sono suc(c)ubi dei libri sacri Ebraici di 5.000 anni fa)", rapporto sul semplice fatto che Israele è un Paese civile, democratico, diga dei diritti umani e di civiltà in mezzo ad un oceano di paesi islamici violenti e teocratici.
    Insomma, dalle sue esternazioni, si evince che la presenza di lacune in un Paese Occidentale, è da "imputarsi" alla presenza di Israele (e dunque degli ebrei).
  • in passato, dicono le indiscrezioni, gli agenti dell'FBI avrebbero chiesto a Microsoft di inserire backdoor funzionanti all'interno del software di cifratura BitLoker, ennesimo tentativo di compromissione delle tecnologie crittografiche a cui gli inegneri al tempo impiegati presso Redmond si sono apparentemente opposti.

    In passato naturalmente per la parte "In presente" e "In futuro" potete stare tranquilli...
    Quando Microsoft fa queste cose le fa sempre "In passato"...
    A bocca aperta
    non+autenticato
  • - Scritto da: tucumcari
    > in passato, dicono le indiscrezioni, gli agenti
    > dell'FBI avrebbero chiesto a Microsoft di
    > inserire backdoor funzionanti all'interno del
    > software di cifratura BitLoker, ennesimo
    > tentativo di compromissione delle tecnologie
    > crittografiche a cui gli inegneri al tempo
    > impiegati presso Redmond si sono apparentemente
    > opposti.
    >
    > In passato naturalmente per la parte "In
    > presente" e "In futuro" potete stare
    > tranquilli...
    >
    > Quando Microsoft fa queste cose le fa sempre "In
    > passato"...
    > A bocca aperta
    eheheh... "peccato" pero' che quello che si oppose fieramente all'illazione ,e a testa del progetto, era Niels Ferguson .. l'amicone dell'"idolo degli anti-nsa" Schenier... allora anche Schenier e' parte del Gomblotto?
    non+autenticato
  • Schneier ... (non so piu scrivere)
    non+autenticato
  • - Scritto da: bubba
    > - Scritto da: tucumcari
    > > in passato, dicono le indiscrezioni, gli agenti
    > > dell'FBI avrebbero chiesto a Microsoft di
    > > inserire backdoor funzionanti all'interno del
    > > software di cifratura BitLoker, ennesimo
    > > tentativo di compromissione delle tecnologie
    > > crittografiche a cui gli inegneri al tempo
    > > impiegati presso Redmond si sono apparentemente
    > > opposti.
    > >
    > > In passato naturalmente per la parte "In
    > > presente" e "In futuro" potete stare
    > > tranquilli...
    > >
    > > Quando Microsoft fa queste cose le fa sempre "In
    > > passato"...
    > > A bocca aperta
    > eheheh... "peccato" pero' che quello che si
    > oppose fieramente all'illazione ,e a testa del
    > progetto, era Niels Ferguson .. l'amicone
    > dell'"idolo degli anti-nsa" Schenier... allora
    > anche Schenier e' parte del
    > Gomblotto?
    se si volesse stilare una classifica anti-NSA il primo posto sarebbe del più famoso tra gli ex-NSA whitfield diffie
    Occhiolino
    non+autenticato