Moto G, lo smartphone low-cost pensa in grande

Motorola lascia intendere che il suo nuovo device non teme concorrenti, per blasonati che siano. Costo contenuto, esperienza Android il più possibile fedele all'originale

Roma – C’è tutto o quasi quello che ci si aspetta da uno smartphone oggi: schermo ampio, fotocamera con flash, batteria capiente e processore quad-core. Solo che il nuovo Motorola Moto G non costa 729 euro come l’iPhone 5S , non costa 629 euro come iPhone 5C e neppure 349 euro come il Nexus 5: se i prezzi annunciati per il mercato USA saranno confermati anche per l’Italia, ce ne si potrà portare a casa uno con 16GB di memoria a 199 euro , forse addirittura qualcosa in meno, mettendosi in tasca un terminale con caratteristiche hardware e software interessanti.

Il Moto G incarna una nuova visione della fascia medio-bassa del mercato degli smartphone, fin qui molto ben rappresentata per esempio dal Nokia Lumia 520: prodotti dalle capacità buone, con performance velocistiche superiori a quanto ci si sarebbe aspettato pochi anni fa in questo comparto, ma che scende a compromessi in termini assoluti. Così, ad esempio , il Moto G monta un quad-core per CPU, ma si tratta solo di uno Snapdragon 400 da 1,2GHz di Qualcomm invece del più potente 800 che finisce per esempio nel Nexus 5. La RAM è da 1GB, la GPU una Adreno 305, la fotocamera da 5 megapixel (con flash), la batteria da oltre 2.000mAh e accreditata di oltre 14 ore di conversazione. Lo schermo, diagonale da 4,5 pollici, è 720p invece che un più fastoso 1080p: ma la sua densità, ci tiene a precisare Motorola , è superiore a quella dell’iPhone. E lo stesso dicasi delle prestazioni di avvio, di lancio delle app, paragonate e annunciate superiori a quelle del Galaxy S4 . Come dire: questo G sarà pure un prodotto economico, ma non vuol dire che debba essere considerato un prodotto scadente.

Moto G è poi qualcosa di più di una versione economica del costoso Moto X , pur i due terminali condividendo chiaramente parecchie caratteristiche estetiche innanzi tutto. Ad esempio Motorola pone parecchio l’accento sulla versione di Android installata, 4.3 che sarà aggiornata a Kitkat 4.4 entro gennaio (“garantito” recita il sito), e che poco o nulla aggiunge all’aspetto base del sistema operativo come lo si vede sui Nexus, e sul fatto che il prodotto sia privo di blocchi operatore o SIM essendo pensato per la vendita diretta al pubblico (ma sarà anche offerto tramite abbonamento). L’esperienza è pressoché analoga a quella che si potrebbe ottenere su un prodotto ufficiale di Google, e la cosa non stupisce più di tanto visto che Motorola ora appartiene a Mountain View e il responsabile del progetto è un uomo che viene dal Googleplex.

Per fare appello alla clientela più giovane e non solo, poi, il Moto G ha le cover posteriori intercambiabili per cambiare colore con l’umore, 50GB su Google Drive offerti per due anni, la radio FM. Tutto nelle intenzioni di Motorola fa intendere che l’azienda punti a vendere questo prodotto a coloro i quali vogliono uno smartphone ma fino a oggi potevano permettersi solo un telefonino smart (i cosiddetti feature phone ): in altre parole, si tratta di un terminale che viene venduto a un prezzo calmierato senza il bisogno di essere sostenuto dai sussidi degli operatori, che offre sulla carta un ottimo rapporto qualità-prezzo e che potrebbe costringere (se avrà successo il successo sperato) anche altri marchi a ripensare le proprie strategie in fatto di posizionamento di prezzo. Per competere, non è un fattore da trascurare, anche nei paesi emergenti .

Luca Annunziata

La tua email sarà utilizzata per comunicarti se qualcuno risponde al tuo commento e non sarà pubblicato. Dichiari di avere preso visione e di accettare quanto previsto dalla informativa privacy

  • M.R. scrive:
    Si, perché...
    ... la loro crittografia è affidabilissima e soprattutto PRIVA DI QUALSIASIVOGLIA BACKDOOR NSA.Ma fatemi il piacere di guardarvi allo specchio prima di criticare gli altri.
    • tucumcari scrive:
      Re: Si, perché...
      - Scritto da: M.R.
      ... la loro crittografia è affidabilissima e
      soprattutto PRIVA DI QUALSIASIVOGLIA BACKDOOR
      NSA.

      Ma fatemi il piacere di guardarvi allo specchio
      prima di criticare gli
      altri.Magari ci si guardano pure il problema è che magari quando si "guardano" viene fuori questo:[yt]hMLcKtVwF-A[/yt]
      • tucumcari scrive:
        Re: Si, perché...
        - Scritto da: tucumcari
        - Scritto da: M.R.

        ... la loro crittografia è affidabilissima e

        soprattutto PRIVA DI QUALSIASIVOGLIA BACKDOOR

        NSA.



        Ma fatemi il piacere di guardarvi allo
        specchio

        prima di criticare gli

        altri.
        Magari ci si guardano pure il problema è che
        magari quando si "guardano" viene fuori
        questo:
        [yt]hMLcKtVwF-A[/yt]Oppure un macaco. Può venire fuori di tutto.
        • tucumcari fante lesto scrive:
          Re: Si, perché...
          - Scritto da: tucumcari
          - Scritto da: tucumcari

          - Scritto da: M.R.


          ... la loro crittografia è
          affidabilissima
          e


          soprattutto PRIVA DI QUALSIASIVOGLIA
          BACKDOOR


          NSA.





          Ma fatemi il piacere di guardarvi allo

          specchio


          prima di criticare gli


          altri.

          Magari ci si guardano pure il problema è che

          magari quando si "guardano" viene fuori

          questo:

          [yt]hMLcKtVwF-A[/yt]

          Oppure un macaco. Può venire fuori di tutto.naahhh non ci sono filmati "developpers developpers" di gente che saltella sul palco con un lupetto nero!
  • king volution scrive:
    buffoni
    sono quantomeno dei buffoni*qualsiasi* crittografia è vulnerabile se le chiavi non sono esclusivamente nelle mani di chi la usa... chi ha le chiavi dei sistemi (sic!) WIn8+ARM con il "SecureBoot" *non* disabilitabile? gli utilizzatori? nooooooo... le ha *solo* M$ (e, come minimo, anche la NSA, ovviamente...)
    • unaDuraLezione scrive:
      Re: buffoni
      contenuto non disponibile
      • tucumcari scrive:
        Re: buffoni
        bisogna vedere a cosa ti riferisci il termine "attaccare" privo di contesto non ha senso.Facciamo un esempio concreto:Poniamo che io trovi una "collisione" su sha-1 pensi che sia sufficiente?Il problema è non tanto trovare una collisione ma una collisione su un "plain text" con un signifcato e non con un "signficato a caso" ma con qualcosa che sia esattamente lo scopo che mi prefiggo.Esempio pratico :ti mando un messaggio con scritto "ci vediamo martedì sera con il pacchetto dei soldoni illegali"Ebbene se il mio scopo è cambiare la data da "martedì" a "venerdì" per indurti in trappola la mia unica speranza pratica è che io trovi una collisione (ovvero generi un hash identico) a partire da un testo che non solo contenga "venerdì" e una serie di caratteri a caso ma qualcosa che continui ad avere un senso compiuto e ti induca a portare con te i "soldoni illegali"... il che è francamente del tutto inverosimile.Basta che il messaggio sia firmato (oltre che cifrato) e la cosa non funziona mai.Quanto alla crittografia devo invece trovare una collisione su una chiave (quella pubblica che è verificabile "outbound" cioè per altra via ad esempio un messaggio precedente o un repository pubblico) che oltre a essere tale (cioè una chiave) corrisponda in modo biunivoco alla parte pubblica (e viceversa) perchè altrimenti non cifra ne decifra una ceppa.L'algoritmo di hash (one way) è solo una parte e non la più rilevante di un protocollo basato su chiavi asimmetriche.Il fatto che siano teoricamente possibili collisioni non significa che le collisioni in questione (se non hai una fortuna sfacciata e quasi del tutto impossibile) siano utilizzabili.È molto più semplice vincere il jack-pot del lotto.Questo non significa che il problema non esista sul piano "teorico" significa solo che gli scenari "apocalittici" sono del tutto fuori luogo.Puoi tranquillamente fidarti dei messaggi spediti con un "weak" hash.Quello di cui non puoi fidarti invece sono le back door e in quel caso puoi avere l'algoritmo più "strong" del mondo ma ti fregano comunque.Ora:Fatti una domanda e valuta quale dei 2 problemi costituisce un rischio maggiore una piattaforma "proprietaria" fatta in "accordo" con NSA o i messaggi che usano sha-1 (che peraltro comunque nessuno ti obbliga a usare dato che hai a disposizione sha-256 e 512 e molti altri).Fatto? ;)
        • tucumcari scrive:
          Re: buffoni
          E in più c'è sempre il problema del man in the middle.
        • unaDuraLezione scrive:
          Re: buffoni
          contenuto non disponibile
          • tucumcari scrive:
            Re: buffoni
            - Scritto da: unaDuraLezione
            - Scritto da: tucumcari

            Dipende da chi è l'avversario.
            Se l'avversario è NSA c'è poco da fare per chi
            usa prodotti chiusi (e anche perm olti degli
            altri), ma se l'avversario è più piccolo, gli
            potrebbe tornare molto utile poterti installare
            certificati falsi ma
            validi.Se l'avversario è piccolo, rimane da capire come abbia potuto installarmi certificati falsi senza che me ne accorgessi. :DForse tanto piccolo non è.È meglio partire dal presupposto che dall'altra parte c'è la NSA, sempre.
          • tucumcari fante lesto scrive:
            Re: buffoni
            - Scritto da: tucumcari
            Forse tanto piccolo non è.Ma sì che è piccolo lo sappiamo!(rotfl)(rotfl)[yt]H1vJM7QaH1E[/yt]
          • fante lesto scrive:
            Re: buffoni
            - Scritto da: unaDuraLezione
            - Scritto da: tucumcari



            Ebbene se il mio scopo è cambiare la data da

            "martedì" a "venerdì" per indurti in
            trappola
            la

            mia unica speranza pratica è che io trovi una

            collisione (ovvero generi un hash identico) a

            partire da un testo che non solo contenga

            "venerdì" e una serie di caratteri a caso ma

            qualcosa che continui ad avere un senso
            compiuto

            e ti induca a portare con te i "soldoni

            illegali"... il che è francamente del tutto

            inverosimile.


            Nel caso migliore (per l'attaccante ovviamente) è
            possibile comporre un 'messaggio' (e stiamo
            comunque paralndo di dati binari) forgiato
            partendo da un messaggio arbitrario (quindi
            l'attaccante sceglie il contenuto) in cui solo
            pochi byte (le cui posizioni sceglie sempre
            l'attaccante) vengono modificati dall'algoritmo
            di cracking per far quadrare la firma
            hash.Problema :1) il contenuto lo dovresti conoscere per attuare quello che dici... il problema è che non è così (altrimenti non c'è alcuna necessità di "attaccare")2) non c'è alcun "algoritmo di cracking" ma solo collisioni (una o più) e purtroppo bisogna che siano "collisioni sensate"... non "collisioni a caso".
            Quindi, basta che questi pochi bye stiano in un
            punto in cui un numero vale l'altro (chessò, la
            versione del certificato,
            ...)Ammesso (e non conXXXXX) cambiare il version number non ti è per nulla utile.E ripeto non è che puoi cambiare un numero x di bit a piacere deve "tornare" l'hash di tutto l'oggetto .



            L'algoritmo di hash (one way) è solo una
            parte
            e

            non la più rilevante di un protocollo basato
            su

            chiavi

            asimmetriche.


            questo sì.Lo credo bene... altrimenti perchè sbattersi a disegnare protocolli?


            Questo non significa che il problema non
            esista

            sul piano "teorico" significa solo che gli

            scenari "apocalittici" sono del tutto fuori

            luogo.

            Beh, dipende da quanta libertà ti lascia il
            metodo di cracking sulla forgiatura del
            messaggio.Ripeti con me non c'è alcun "metodo di cracking" ma solo collisioni!Le funzioni (persino il vituperato MD5) sono "genuinamente" one way!Un conto è che ci siano collisioni un altro che l'algoritmo sia (matematicamente parlando) "farlocco".Mentre del fatto che una funzione sia "one way" poui ottenere la dimostrazione matematica (chiedere lumi a diffie nel caso o leggere) del fatto che non esistano collisioni possibili non avrai mai dimostrazione matematica.Al massimo puoi ridurne la probabilità.In parole povere nessuno a questo mondo ti può garantire che sha-256 è privo di collisioni (anzi potrei sostenere ragionevolmente il contrario) ti si può solo garantire che la funzione è "one way" e che la possibilità di collisione è inferiore a quella di md5 o sha-1.Tutto qui
            Io onestamente non conosco il caso di cui si
            parla, ma se è venuto fuori, posso supporre che
            il metodo di cracking lasci molta libertà
            all'attaccante.Ancora?Di quale "metodo di cracking" vai cianciando?



            Fatti una domanda e valuta quale dei 2
            problemi

            costituisce un rischio maggiore una
            piattaforma

            "proprietaria" fatta in "accordo" con NSA o i

            messaggi che usano sha-1 (che peraltro
            comunque

            nessuno ti obbliga a usare dato che hai a

            disposizione sha-256 e 512 e molti

            altri).

            Fatto?

            Dipende da chi è l'avversario.
            Se l'avversario è NSA c'è poco da fare per chi
            usa prodotti chiusi (e anche perm olti degli
            altri), ma se l'avversario è più piccolo, gli
            potrebbe tornare molto utile poterti installare
            certificati falsi ma
            validi.E come farebbe di grazia? tu "installi" certificati in base a quale ragionamento?E sopratutto sei sicuro di avere dei motivi per metterli nella tua "trust list" e perchè?Se è per quello te ne posso mandare un milione di certificati (veri falsi mezzi veri e mezzi falsi a tuo e mio piacimento) la questione resta... se i valori sono (come sono) differenti da quelli che hai (o avevi) in precedenza perchè dovresti crederci? :DPoi per carità se quando installi un certificato non ci guardi dentro... puoi installare qualunque cosa tanto vale che tu scarichi direttamente il programma di crittografia dal sito della NSA.Fai prima... :D
          • unaDuraLezione scrive:
            Re: buffoni
            contenuto non disponibile
          • tucumcari fante lesto scrive:
            Re: buffoni
            - Scritto da: unaDuraLezione
            - Scritto da: fante lesto

            - Scritto da: unaDuraLezione


            - Scritto da: tucumcari


            Problema :


            2) non c'è alcun "algoritmo di cracking" ma
            solo

            collisioni

            secondo te le collisioni sono trovate per caso
            oppure calcolate a
            mano?
            Evidentemente no. Si sfrutta la debolezza
            dall'hash di turno per individuare un
            metodo.
            Il metodo è l'algoritmo.
            E tale algoritmo ha ben diritto di chiamarsi
            algoritmo di
            cracking.Il "metodo" non esiste in termini di "algoritmo" esiste solo la ricerca di collisioni e il problema è che i bit (pochi o tanti) devono essere uguali TUTTI!E partire dalla stessa stringa di hash (quindi lo stesso plain text) di cui vorresti "falsificare" l'hash.L'entropia che introduci (e questo è dimostrato matematicamente) cambiando un solo bit equivale a quella introdotta cambiandoli tutti.Non mi pareva difficile da capire (leggi ripeto).






            Quindi, basta che questi pochi bye
            stiano in
            un


            punto in cui un numero vale l'altro
            (chessò,
            la


            versione del certificato,


            ...)


            E ripeto non è che puoi cambiare un numero x
            di

            bit a piacere deve "tornare" l'hash di tutto

            l'oggetto

            gli hash sono firme di pochi bit, quindi, nel
            caso peggiore possibile (perchè l'algoritmo è
            pessimo), ti bastano altrettanti bit in un luogo
            a tua
            scelta.Leggi sopra e ricomincia da capo!

            Basta pensare al più scarso degli algoritmi
            possibili, ovvero la parità: un bit/byte/quello
            che vuoi come firma di tutto e si scardina
            esattamente con un bit/byte/quello che vuoi in un
            punto arbitrario del messaggio arbitrariamente
            forgiato.Peccato che non sia un algoritmo one way!Ci sarà o no secondo te un motivo (leggere fa bene) se si usano quegli algoritmi?
            SO che gli HASH seri sono fatti ni modo che non
            debba succedere, ma visto che stiamo parlando di
            debolezze...No stiamo parlando di collisioni non di "debolezze" è proprio questo che non ti entra in testa.L'algoritmo MD5 in se non ha nulla che non va!





            Ripeti con me non c'è alcun "metodo di
            cracking"

            ma solo

            collisioni!


            Ripeti con me: "le collisioni non si trovano per
            magia, ma con un metodo che sfrutta le
            caratteristiche del sistema di
            HASH"Non esiste tale "metodo" è un mero calcolo probabilistico quello che devi applicare.


            del

            fatto che non esistano collisioni possibili
            non

            avrai mai dimostrazione

            matematica.

            Infatti si dimostra in due passaggi il CONTRARIO:
            basta contare i membri dell'insieme delle
            stringhe prima dell'hash (2^numero arbitrario) e
            quello delle stringhe HASH (2^lunghezza della
            firma).
            Il primo insieme ha un numero nifinitamente
            maggiore di elementi, quindi moltissimi elementi
            del primo insieme NECESSARAMENTE vengono mappati
            nello stesso elemento del secondo
            insiemeLa "lunghezza della firma" (o meglio dell'hash cifrato con la chiave pubblica) non c'entra nulla quello che ti interessa è la lunghezza dell'Hash.E la probabilità di collisione in una funzione "one way" (proprio perchè è "one way") è tutt'altro che "esponenzialmente proporzionale" alla sua lunghezza come tu sostieni.È semplice matematica fammi un favore leggi prima di lanciarti in ipotesi ok?



            Al massimo puoi ridurne la probabilità.

            In parole povere nessuno a questo mondo ti
            può

            garantire che sha-256 è privo di collisioni
            (anzi

            potrei sostenere ragionevolmente il
            contrario)

            Ragionavolmente?
            Suvvià è una banale questione di cardinalità
            è qui che ti sbagli altrimenti non ci sarebbe alcun bisogno che la funzione fosse "one way" (cioè non reversibile).il problema ripeto non è "trovare una collisione a caso".è trovare quella "giusta" è li che cessa di essere un banale problema di "cardinalità".
          • unaDuraLezione scrive:
            Re: buffoni
            contenuto non disponibile
          • tucumcari fante lesto scrive:
            Re: buffoni
            - Scritto da: unaDuraLezione
            - Scritto da: tucumcari fante lesto


            Il "metodo" non esiste in termini di
            "algoritmo"

            esiste solo la ricerca di collisioni

            non ho tempo (ne fiato), mi fermo qui.
            Sappi solo che ciò che hai scritto fa ribaltare
            nella bara i fondatori dell'informatica
            teorica.Direi che è vero per quello che hai scritto più che altro.
            La ricerca delle collisioni, COMUNQUE AVVENGA, è
            un metodo, quindi traducibile in algoritmo,
            quindi implementabile (ancora non hai risposto,
            lo fanno a
            mano????).Se per "a mano" intendi "brute force" si!Lo fanno "a mano" e il "brute force" non è un algoritmo ne un metodo!Per questo motivo ci hanno messo tanto a verificare che le collisioni erano possibili in MD5 e ancora più in SHA-1.
            Che termini presto, tardi o non termini affatto
            il suo lavoro è un altro paio di maniche e
            dipende dalla bontà dall'algoritmo di HASH e
            dalla bontà del metodo di rilevamento delle
            collisioni.Ripeto non c'è alcun "metodo".Il "brute force" non è un "metodo" è un mezzo (esattamente come una calcolatrice invece che carta e penna).


            edit: solo un ppunto sull'ultima frase:

            il problema ripeto non è "trovare una
            collisione a
            caso".

            è trovare quella "giusta" è li che cessa di
            essere


            un banale problema di "cardinalità".

            falso: se il messaggio forgiato è modificabile
            per una quantità di bit superiore alla lunghezza
            della firma (HASH è sottointeso, non stiamo
            parlando di crottgrafia ma solo dell'HASH) allora
            <b
            la parte variabile del messaggio
            </b
            ha una cardinalità almeno uguale a
            quella dell'insieme delle firme HASH
            possibili.
            Quindi era e rimane una mera questione di
            cardinalità.No la cardinalità non è affatto quella la cardinalità (in senso stretto) anche se ti bastasse è pari alla lunghezza dell'Hash e alla lunghezza del plain text sommati.ad esempio se hai una cardinalità di 2048 bit (pari a 256 miseri byte di testo) che è 160 (bit di sha1)+2048 per un totale di 2^2208 si ti sembra poco accomodati pure!Vedi il problema è che non contano "solo" i bit della funzione di hash ma TUTTI i bit come ti ho già spiegato!I bit "minimi" che contano sempre la somma di tutto ciò che devi cambiare più quelli di hash!E la lunghezza appunto rimane invariata qualunque cosa tu faccia a meno che tu non trovi la funzione "inversa" a quella di hash ma in tal caso non sarebbe per definizione una funzione "one way".Il che ripeto è un fatto dimostrabile matematicamente e non ha nulla a che vedere con la lunghezza del valore generato dalla funzione che di per se sarebbe pure "abbordabile" in alcuni casi 128 bit per md5 che renderebbero possibile persino un "birthday attack"... peccato che ci siano anche gli "altri" bit... quelli del "plaintext" e ripeto non possono essere bit a caso.Per darti una idea di quanto queste cose siano una "novità" ti cito questo pezzetto tratto da Schneier:"Nel 1996 Dobbertin annunciò una collisione della funzione di compressione MD5. Anche se non rappresentava un attacco alla funzione hash MD5 completa, fu sufficiente a molti crittografi per raccomandare di passare ad un sostituto come il WHIRLPOOL, SHA-1 o RIPEMD-160".Il che è una semplice misura di "manutenzione" non una "catastrofe".N.B.Ron Rivest pubblicò MD5 nel 1991 e viene tutt'ora usato (per alcune cose) senza che nessuno abbià trovato il modo "pratico" di sfruttare concretamente le collisioni per contenuti "sensati"...Non casualmente viene correntemente usato come check ad esempio sul codice dei programmi eseguibili.Il che è più che sensato dato che non puoi (ammesso che trovi una collisione) fare eseguire codice binario "a caso" anche se "collidente" dato che non funziona.
          • unaDuraLezione scrive:
            Re: buffoni
            contenuto non disponibile
          • tucumcari fante lesto scrive:
            Re: buffoni
            - Scritto da: unaDuraLezione
            - Scritto da: tucumcari fante lesto


            Direi che è vero per quello che hai scritto
            più

            che

            altro.

            vediamo.



            La ricerca delle collisioni, COMUNQUE

            AVVENGA,

            è


            un metodo, quindi traducibile in
            algoritmo,


            quindi implementabile (ancora non hai

            risposto,


            lo fanno a


            mano????).



            Se per "a mano" intendi "brute force" si!


            1) Il brute force <b
            è un metodo
            </b
            ed <b
            è un algoritmo
            </b
            , prendi
            nota.
            2) incidentalmente il brute force è L'ULTIMO
            algoritmo per efficienza e si usa praticamente
            solo se l'agoritmo di HASH è PERFETTO (se la
            lunghezza dell'HASH è elevata l'HASH è
            'incraccabile').
            MA l'ipotesi (da cui nasce l'articolo) è che
            sha-1 NON sia
            perfetto.Non è che sia "perfetto" e la "perfezione" non ha nulla a che vedere con la lunghezza!è un fatto MA-TE-MA-TI-CO.. capisci?Facciamo un esempio a caso ...Prendidamo una banale istruzione x86 in assembler :jmp dword 0x3b6ein esadecimale è:E9C0130000o se preferisci il binario è:1110100111000000000100110000000000000000per un totale di 5 Bytes o se credi 40 miserrimi bit!Supponiamo (ti voglio facilitare la vita) di usare MD5 (solo 128 bit e 16 miserrimi bytes)...Il valore di hash generato da md5 ha appunto lunghezza fissa (128 bit) dipende in senso "stretto" per come costruita matematicamente la funzione (una banale equazione) dai 5 bytes di cui sopra in pratica è la x (valore incognito) della equazione e sia matematicamente dimostrato (come nel caso di MD5) che mentre esiste f(x) non esiste la funzione inversa (ovvero f alla meno 1 di (x)).abbiamo un totale 128+40 = 168 bit.Se la funzione fosse (come dici tu) "perfetta" (termine quantomai sballato in questo caso) non avresti nessuna possibilità di trovare in 2^168 valori possibili nessuna collisione.Ovvero nessun valore in cui a partire dai 40 bit in questione ottieni lo stesso output.Ovvero è indistinguibile da una pura sequenza "randomica".Questo significa che su 2^168 valori possibili (uno su x cioè 1/748288838313422294120286634350736906063837462003712) non trovi altri 5 bytes che producono lo stesso output!Non dimenticare che il tuo scopo è sostituire "quei" 5bytes! :)Ora supponiamo (uso sempre la stessa tua espressione) che non sia "perfetta" la funzione...Il mio scopo è trovare almeno una collisione.... (n.b. ci vollero circa un paio di ore nel 2006 sul più grosso cluster IBM dell'epoca) ... la trovo!Peccato che il valore che trovo NON è (ripeto NON) un JMP DWORD ma un valore che pur generando lo stesso output in MD5 non è (ripeto NON) un codice macchina eseguibile ...Devo proseguire nella speranza di trovare (prima o dopo) qualcosa di eseguibile (magari proprio JMP) che vada a un indirizzo che mi fa "comodo".... @^Ci riuscirò mai?(newbie)(newbie)Perchè vedi il mio problema "reale" (non teorico) è che io ci devo mettere quel che "mi serve" come scopo non il primo valore a caso della prima collisione che trovo! 8)Questo è il problema...A prescindere che su qualunque manuale trovi scritto che con questo esempio ti ho facilitato in modo "non previsto" la vita...(una funzione di hash one-way si applica sempre solo a un contenuto di lunghezza minima pari a quello della lunghezza in bit dell'output della funzione stessa altrimenti va a monte tutta la cosa... quindi avrei dovuto dirti un pezzo di codice di almeno 128 bit e non solo 40)...La questione reale è appunto non trovare una collisione "a caso" ma una che "ha senso"...In parole povere se devi controllare un programma e la sua integrità (infinitamente più bit) ti serve una collisione non "teorica" ma pratica ovvero in cui tu rimpiazzi un valore con qualcosa (ammesso e non conXXXXX che esista) che effettivamente ti serve per metterci il tuo ipotetico "malware"...Ti è chiaro perchè il problema non è in astratto senza fondamento "teorico" ma perchè non è questione di "metodi" o "debolezze"? :)Nella sostanza il trovare una collisione non genera alcun "utile" dal tuo punto di vista di "attaccante"... ma trova (udite udite una "collisione")... :(Capirai!Tralascio per umana pietà le XXXXXXX che hai scritto dopo... e vado all'ultima...
            Questo può essere, non lo nego, il succo di tutto
            è: quanto è debole realmente sha-1? perché lo
            vogliono fare
            fuori?
            A me fa pensare che abbiano trovato un metodo per
            ridurre enormemente i calcoli necessari a trovare
            Non ha bisogno di "pensare o supporre" è pieno di testi in rete e accademici su questa faccenda (si la questione sha-1 è tutto fuorchè una novità sono da 2 anni e passa che si sa delle collisioni) ti conviene leggere i papers relativi.ad esempio questo...http://csrc.nist.gov/groups/ST/hash/documents/Wang_SHA1-New-Result.pdfNon c'è nulla da "supporre" è tutto nero su bianco!Da un pezzo (ripeto).La questione è che alla fine...ti spiegano che il problema non è trovare una o più collisioni ma trovare quella "giusta" e purtroppo di quella "giusta" non è neppure garantita la esistenza stessa!Statte bbuono DuraLeziò ;)
          • unaDuraLezione scrive:
            Re: buffoni
            contenuto non disponibile
          • tucumcari fante lesto scrive:
            Re: buffoni
            - Scritto da: unaDuraLezione
            - Scritto da: tucumcari fante lesto



            Devo proseguire nella speranza di trovare

            (prima o dopo) qualcosa di eseguibile

            (magari proprio JMP) che vada a un indirizzo
            che mi fa
            "comodo"....

            Indiavolato

            Ci riuscirò mai?

            Non ci riuscirai se l'algoritmo di HASH è buono.
            Ma se è sballato come per esempio se un folle
            utilizzasse come algoritmo di HASH la parità, ci
            riusciresti
            eccome.Non è un argomento stiamo parlando di "one-way" ci arrivi o non ci arrivi?La parità (o qualunque altra cosa) hanno (esattamente al contrario di un funzione ONE WAY) lo scopo di "ricostruire" vorrei che questa diciamo "piccola differenza" ti fosse chiara!
            Ovvero tu continui ad assumere che l'algoritmo di
            HASH sia buono, ma questo è proprio ciò che è in
            discussione: Ti mordi la
            coda.Non lo assumo è dimostrato (ripeto) matematicamente.In pratica (per darti una idea di come stanno realmente le cose) non ti garantisce (in realtà non è quello lo scopo) che non ci sono collisioni ti garantisce che non hai alcuna certezza che tra quelle che trovi non ce ne è nessuna che corrisponda al tuo scopo con una probabilità che è funzione DIRETTA (capisci la parola diretta?) di quanti bit hai nel plain text + quelli di hash.Tutto qua..In linea di principio funziona come una "compressione" ripetuta tante volte (sul plain text) quanto ti serve per raggiungere la lunghezza prevista (128 md5 160 sha-1 256 sha-256 e via dicendo) "perdendoti" però "volontariamente" i dati che ti servono a tornare indietro (plain text) diciamo che come "compresione" è "molto lossy"... :DAnzi più è lossy e meglio è.Ora ripeto la questione va ribaltata il tuo problema non si risolve alla prima (e neanche alla seconda o alla n-esima) "collisione" con plain text a caso che trovi nella spazio totale (in bit) della stringa perchè il tuo problema è quello opposto trovare tra le n possibili collisioni che stanno in quello spazio esattamente quella "che serve a te" e questo non solo non telo garantisce la esistenza di n-collisioni ma anzi si dimostra esattamente che di una collisione in quella forma non è affatto garantita la esistenza potresti cercarla per la intera durata della vita dell'universo e non trovarla affatto!Ripeto a te non serve (come nei paper accademici) dimostrare che puoi cambiare un bit individuando quelli che non generano "entropia sufficiente" serve cambiare i bit come tu intendi cambiarli.Se leggi al link che ti ho dato scopri che puoi cambiare (con le "conditions" elencate) alcuni bit in un messaggio con sha-1... il problema è che quei bit probabilmente (anzi certamente) non corrsipondono affatto al cambiamento che tu "vorresti" come attaccante!è chiaro così?


            Rinuncio.
            Poi però dimmi cosa ti hanno detto riguardo alla
            definizione di algoritmo, mi
            raccomando.Che il brute force è esattamente come il calcolo a mano cambia solo il mezzo!Purtroppo 2+2 non è un algoritmo che tu lo faccia a mano o lo faccia con un computer sempre quello è e resta 2+2...Peccato!Si chiama "aritmetica" non "algoritmo" e si chiamava così già ai tempi di Pitagora.Mi spiace!
            Che è proprio la parte che hai omesso dicendo
            'evito di commentare per
            pietà'.Dovevi approfittarne!Io l'occasione te la avevo data! ;)
          • unaDuraLezione scrive:
            Re: buffoni
            contenuto non disponibile
          • orchidea scrive:
            Re: buffoni
            Il problema di tucumcari è che ha le consocenze tecniche ma poi le applica male o senza fantasia.Il suo ragionamento è corretto se vogliamo prendere un file, modificare alcuni o pochi bit come sostiene lui, e poi ottenere lo stesso hash. Ma non ha ancora capito che la cosa è relativamente più semplice: si prende un file, lo si modifica come ci fa comodo e dopo aggiungiamo quel che serve per ottenere lo stesso hash di prima. Questo lui non arriva a concepirlo, non riesce a immaginare del testo aggiunto che il computer non "processi", parte da quell'assunto e su quello rimane. Facciamocelo rimanere, uno zombie in più da usare ;-)
          • tucumcari fante lesto scrive:
            Re: buffoni
            - Scritto da: orchidea
            Il problema di tucumcari è che ha le consocenze
            tecniche ma poi le applica male o senza
            fantasia.
            Il suo ragionamento è corretto se vogliamo
            prendere un file, modificare alcuni o pochi bit
            come sostiene lui, e poi ottenere lo stesso hash.
            Ma non ha ancora capito che la cosa è
            relativamente più semplice: si prende un file, lo
            si modifica come ci fa comodo e dopo aggiungiamo
            quel che serve per ottenere lo stesso hash di
            prima. Questo lui non arriva a concepirlo, non
            riesce a immaginare del testo aggiunto che il
            computer non "processi", parte da quell'assunto e
            su quello rimane. Facciamocelo rimanere, uno
            zombie in più da usare
            ;-)Hai altre perle del genere, o hai già esaurito la vena? :D:DAd esempio, mi dici come si fa a modificare "come ci fa comodo" un file che non è ancora accessibile al nemico?Dimmi dimmi, petunia: sono tutt'orecchi. (rotfl)(rotfl)
        • orchidea scrive:
          Re: buffoni
          - Scritto da: tucumcari
          bisogna vedere a cosa ti riferisci il termine
          "attaccare" privo di contesto non ha
          senso.
          Facciamo un esempio concreto:
          Poniamo che io trovi una "collisione" su sha-1
          pensi che sia
          sufficiente?Si, ad esempio puoi forgiare un certificato digitale spacciandoti per qualcun altro.
          Il problema è non tanto trovare una collisione ma
          una collisione su un "plain text" con un
          signifcato e non con un "signficato a caso" ma
          con qualcosa che sia esattamente lo scopo che mi
          prefiggo.
          Si, ma non devi pensare agli algoritmi di hashing solo come impronte di file (o messaggi) che tu vuoi modificare, l'hashing ha un ruolo fondamentale per le firme digitali, ad esempio nell'uso dei certificati.
          Esempio pratico :
          ti mando un messaggio con scritto "ci vediamo
          martedì sera con il pacchetto dei soldoni
          illegali"

          Ebbene se il mio scopo è cambiare la data da
          "martedì" a "venerdì" per indurti in trappola la
          mia unica speranza pratica è che io trovi una
          collisione (ovvero generi un hash identico) a
          partire da un testo che non solo contenga
          "venerdì" e una serie di caratteri a caso ma
          qualcosa che continui ad avere un senso compiuto
          e ti induca a portare con te i "soldoni
          illegali"... il che è francamente del tutto
          inverosimile.
          Basta che il messaggio sia firmato (oltre che
          cifrato) e la cosa non funziona
          mai.Se il messaggio è cifrato non funziona finchè non si rompe qualche altro protocollo crittografico, se il messaggio è in chiaro e tu sei in grado di accedervi per modificarlo, probabilmente hai anche tutto il tempo e possibilità di allegare l'impronta diversa che geenera, non è questo il caso di utilizzo.
          Quanto alla crittografia devo invece trovare una
          collisione su una chiave (quella pubblica che è
          verificabile "outbound" cioè per altra via ad
          esempio un messaggio precedente o un repository
          pubblico) che oltre a essere tale (cioè una
          chiave) corrisponda in modo biunivoco alla parte
          pubblica (e viceversa) perchè altrimenti non
          cifra ne decifra una
          ceppa.si, rimane il punto che posso generare certificati non validi, perchè posso generare firme digitali con la stessa impronta di una CA ma che in realtà contengono la chiave pubblica mia.
          L'algoritmo di hash (one way) è solo una parte e
          non la più rilevante di un protocollo basato su
          chiavi
          asimmetriche.E' quello che firma, fa te se non è importante. Se no usavano CRC ti pare?
          Il fatto che siano teoricamente possibili
          collisioni non significa che le collisioni in
          questione (se non hai una fortuna sfacciata e
          quasi del tutto impossibile) siano
          utilizzabili.ammazza se lo sono, ci sono un sacco di applicazioni dove si usa hashing, dalla conservazione/passaggio delle password all'integrità dei db ecc ecc...
          È molto più semplice vincere il jack-pot del
          lotto.si, perchè tu continui a pensare di modificare un contento e ricalcolare l'hash, ma tu il contenuto nuovo lo puoi completamente inventare in alcuni casi.
          Questo non significa che il problema non esista
          sul piano "teorico" significa solo che gli
          scenari "apocalittici" sono del tutto fuori
          luogo.Però MD5 non lo usa più nessuno se non per il controllo di integrità abbastanza blandi guarda caso.
          Fatti una domanda e valuta quale dei 2 problemi
          costituisce un rischio maggiore una piattaforma
          "proprietaria" fatta in "accordo" con NSA o i
          messaggi che usano sha-1 (che peraltro comunque
          nessuno ti obbliga a usare dato che hai a
          disposizione sha-256 e 512 e molti
          altri).
          Fatto?
          ;)Sulla domanda non entro nel merito, diciamo che a me sembra che sia tu che stai avvantaggiando NSA nel momento in cui consigli di continuare pure ad usare SHA-1
          • tucumcari fante lesto scrive:
            Re: buffoni
            - Scritto da: orchidea

            verificabile "outbound" cioè per altra via ad

            esempio un messaggio precedente o un
            repository

            pubblico) che oltre a essere tale (cioè una

            chiave) corrisponda in modo biunivoco alla
            parte

            pubblica (e viceversa) perchè altrimenti non

            cifra ne decifra una

            ceppa.

            si, rimane il punto che posso generare
            certificati non validi, perchè posso generare
            firme digitali con la stessa impronta di una CA
            ma che in realtà contengono la chiave pubblica
            mia.Peccato che la "chiave pubblica" proproprio perchè "pubblica" è nota!Quindi non è "un contenuto a caso".Peccato!

            E' quello che firma, fa te se non è importante.
            Se no usavano CRC ti
            pare?Appunto è proprio quello il problema!Non è un "contenuto a caso" deve avere un senso!


            Il fatto che siano teoricamente possibili

            collisioni non significa che le collisioni in

            questione (se non hai una fortuna sfacciata e

            quasi del tutto impossibile) siano

            utilizzabili.

            ammazza se lo sono, ci sono un sacco di
            applicazioni dove si usa hashing, dalla
            conservazione/passaggio delle password
            all'integrità dei db ecc
            ecc...Le password ? il db?Stiamo parlando di contenuti appunto non a caso se il valore non fa il match con "plain text" della sola collisione non te ne fai nulla!


            È molto più semplice vincere il
            jack-pot
            del

            lotto.

            si, perchè tu continui a pensare di modificare un
            contento e ricalcolare l'hash, ma tu il contenuto
            nuovo lo puoi completamente inventare in alcuni
            casi.Davvero?Prendiamo un codice eseguibile.. Ovvero una applicazione...Secondo te riesci a eseguire un contenuto "a caso" su una macchina? (rotfl)(rotfl)Ovvero se io trovo una collisione (produco lo stesso valore di hash) partendo da una sequenza di bit "a pera" riesco a eseguire tali bit "a pera" sul proXXXXXre x o y?I casi in cui puoi "inventarti" il risultato sono ininfluenti dato che se puoi inventarli significa 2 cose (che devono verificarsi entrambe contemporaneamente bada bene) .1) Il contenuto (plain text) non era conosciuto o conoscibile prima 2) il "senso" del contenuto non è rilevante ai fini di eseguire una certa azione.In pratica (concreta non teorica) questo non è mai vero.Se il "senso" del contenuto non è rilevante (aka non contiene informazione "reale") non ha senso cifrarlo nel 99.99999999999% dei casi. È per quello che si "disegnano" i protocolli che sono in realtà la descrizione delle relazioni che ci sono tra un dato e un altro!In sicurezza (e crittografia) tutto ciò che non ha "senso" (aka è inutile in termini informativi) non solo è "inutile" ma introduce "vulnerabilità" e debolezze non prevedibili.

            Questo non significa che il problema non
            esista

            sul piano "teorico" significa solo che gli

            scenari "apocalittici" sono del tutto fuori

            luogo.

            Però MD5 non lo usa più nessuno se non per il
            controllo di integrità abbastanza blandi guarda
            caso.Niente affatto Md5 è usatissimo per la autenticità del codice il che è sensatissimo dato che non può essere fatto con "valori a caso".Non è questione di "blandizie".


            Fatti una domanda e valuta quale dei 2
            problemi

            costituisce un rischio maggiore una
            piattaforma

            "proprietaria" fatta in "accordo" con NSA o i

            messaggi che usano sha-1 (che peraltro
            comunque

            nessuno ti obbliga a usare dato che hai a

            disposizione sha-256 e 512 e molti

            altri).

            Fatto?

            ;)

            Sulla domanda non entro nel merito, diciamo che a
            me sembra che sia tu che stai avvantaggiando NSA
            nel momento in cui consigli di continuare pure ad
            usare
            SHA-1Mai detto che lo "consiglio" sto semplicemente dicendo che la cosa (per ciò che è già stato fatto in passato prima di "rottamare la topolino" ovvero sha-1) non è affatto una "apocalisse".Cambiare da un algoritmo meno sicuro a uno più sicuro è normale regola di "manutenzione" non significa che devi continuare a viaggiare con la topolino se puoi usare la bmw!Poi se vuoi continuare a usare sha-1 o MD5 non te lo vieta nessuno devi solo fare attenzione a usarlo in situazioni dove non rappresenti una "criticità".L'esempio che ti ho fatto per il codice eseguibile mi pare lampante!La possibilità che hai di trovare un codice eseguibile (addirittura malware) che generi una collisione è talmente bassa da non valerela pena di prenderla in considerazione perchè è (matematicamente) haslength/binarymalwarecodelelength il tutto espresso in bit il che se mi permetti rende più probabile che tu riesca a contare il numero di stelle dell'universo in una giornata.
          • orchidea scrive:
            Re: buffoni


            Peccato che la "chiave pubblica" proproprio
            perchè "pubblica" è
            nota!
            Quindi non è "un contenuto a caso".

            Peccato!Non sai come è fatto un certificato vero? C'è una firma sulla chiave pubblica che garantisce il proprietario della chiave privata (e pubblica), io non ho scritto che non si può leggere la chiave, ho scritto che puoi farti un tuo certificato facendo finta di essere una CA o qualcun altro

            Appunto è proprio quello il problema!
            Non è un "contenuto a caso" deve avere un senso!si, ma non per forza partendo da un significato originale.

            ammazza se lo sono, ci sono un sacco di

            applicazioni dove si usa hashing, dalla

            conservazione/passaggio delle password

            all'integrità dei db ecc

            ecc...

            Le password ? il db?
            Stiamo parlando di contenuti appunto non a caso
            se il valore non fa il match con "plain text"
            della sola collisione non te ne fai
            nulla!
            Veramente è proprio questo il punto: caso semplice, passo una password in formato di hash ad una applicazione che detiene la password in chiaro sulla quale ricalcola l'hash, se io conosco l'hash posso inserire come password un testo diverso ma che mi genera lo stesso hash.
            Davvero?
            Prendiamo un codice eseguibile.. Ovvero una
            applicazione...
            Secondo te riesci a eseguire un contenuto "a
            caso" su una
            macchina?
            (rotfl)(rotfl)No, ma tu continui a prendere dei casi non è inutile un attacco di collisione e da questo concludi che non è un problema. Tu devi pensare invece a tutti quei casi dove il problema può essere sfruttato, e sono parecchi.
            Ovvero se io trovo una collisione (produco lo
            stesso valore di hash) partendo da una sequenza
            di bit "a pera" riesco a eseguire tali bit "a
            pera" sul proXXXXXre x o
            y?
            I casi in cui puoi "inventarti" il risultato sono
            ininfluenti dato che se puoi inventarli significa
            2 cose (che devono verificarsi entrambe
            contemporaneamente bada bene)
            .
            1) Il contenuto (plain text) non era conosciuto o
            conoscibile prima

            2) il "senso" del contenuto non è rilevante ai
            fini di eseguire una certa
            azione.
            In pratica (concreta non teorica) questo non è
            mai
            vero.
            Se il "senso" del contenuto non è rilevante (aka
            non contiene informazione "reale") non ha senso
            cifrarlo nel 99.99999999999% dei casi.

            È per quello che si "disegnano" i protocolli che
            sono in realtà la descrizione delle relazioni che
            ci sono tra un dato e un
            altro!
            In sicurezza (e crittografia) tutto ciò che non
            ha "senso" (aka è inutile in termini informativi)
            non solo è "inutile" ma introduce "vulnerabilità"
            e debolezze non
            prevedibili.
            Tutto quelo che vuoi, però intanto, lo ripeto MD5 non si usa quasi più... chissà perchè
            Niente affatto Md5 è usatissimo per la
            autenticità del codice il che è sensatissimo dato
            che non può essere fatto con "valori a
            caso".
            Non è questione di "blandizie".
            E lo usi tu che sei stolto perchè MD5 è un protocollo rotto, cambio codice a mio piacimento e poi aggiungo robe a caso per generare lo stesso hash, lo capisci o no??? affar tuo guarda.
            Mai detto che lo "consiglio" sto semplicemente
            dicendo che la cosa (per ciò che è già stato
            fatto in passato prima di "rottamare la topolino"
            ovvero sha-1) non è affatto una
            "apocalisse".
            Cambiare da un algoritmo meno sicuro a uno più
            sicuro è normale regola di "manutenzione" non
            significa che devi continuare a viaggiare con la
            topolino se puoi usare la
            bmw!
            Poi se vuoi continuare a usare sha-1 o MD5 non te
            lo vieta nessuno devi solo fare attenzione a
            usarlo in situazioni dove non rappresenti una
            "criticità".
            L'esempio che ti ho fatto per il codice
            eseguibile mi pare
            lampante!
            La possibilità che hai di trovare un codice
            eseguibile (addirittura malware) che generi una
            collisione è talmente bassa da non valerela pena
            di prenderla in considerazione perchè è
            (matematicamente)
            haslength/binarymalwarecodelelength il tutto
            espresso in bit il che se mi permetti rende più
            probabile che tu riesca a contare il numero di
            stelle dell'universo in una
            giornata.Se così fosse allora il protocollo sarebbe ancora sicuro, così non è, leggi la notizia.
          • tucumcari fante lesto scrive:
            Re: buffoni
            - Scritto da: orchidea



            Peccato che la "chiave pubblica" proproprio

            perchè "pubblica" è

            nota!

            Quindi non è "un contenuto a caso".



            Peccato!


            Non sai come è fatto un certificato vero? C'è una
            firma sulla chiave pubblica che garantisce il
            proprietario della chiave privata (e pubblica),
            io non ho scritto che non si può leggere la
            chiave, ho scritto che puoi farti un tuo
            certificato facendo finta di essere una CA o
            qualcun
            altroQuesto lo puoi fare senza bisogno di collisioni!Basta che la controparte ci creda!In parole povere chi accetta quel certificato deve NON CONOSCERE la vera chiave (e sul certificato vero è scritta in chiaro "plaintext") e quindi non deve avere letto da nessuna parte il certificato "vero" che invece si chiama "pubblico" proprio perchè tale è!Mi sa che sei tu a non aver mai visto un certificato!O perlomeno non sai cosa significhi "pubblico".Non ci puoi mettere un "valore a caso" ma solo "quel valore". :DFare "finta" è sempre possibile non dipende mica dall'algoritmo di hash ma dalla credulità (o dal credito) che hai presso la "controparte" che deve "fidarsi".Secondo te prendi per buono un certificato firmato con una chiave qualsiasi?Allora tanto vale che non lo usi affatto a prescindere dall'algoritmo di hash!
            si, ma non per forza partendo da un significato
            originale.In quel caso invece si!DEVE essere l'originale! è PUBBLICO!e poi...Originale o meno deve contenere un valore "informativo" che tu "processi"Non un valore a caso!Altrimenti è un valore inutile!Ergo inutilizzabile per qualunque operazione di "trust".


            Le password ? il db?

            Stiamo parlando di contenuti appunto non a
            caso

            se il valore non fa il match con "plain text"

            della sola collisione non te ne fai

            nulla!



            Veramente è proprio questo il punto: caso
            semplice, passo una password in formato di hash
            ad una applicazione che detiene la password in
            chiaro sulla quale ricalcola l'hash, se io
            conosco l'hash posso inserire come password un
            testo diverso ma che mi genera lo stesso
            hash.Infatti pochi usano delle password semplicemente hashate e basta non a caso ci sono delle policy (lunghezza e altro ecc.) in qualunque sistema "decente" tanto è vero che le password continuano a essere correntemente usate (a volte anche semplicemente col vecchio MD5) senza particolari problemi.Non fosse così non servirebbero dizionari o altro per craccare i siti il problema delle password continua (non a caso) a essere quello delle "weak" password (tipo 123456) non certo quello del "weak hash".Non è una mia illazione ma un fatto che puoi riscontrare nella vita di tutti i giorni.Fosse facile come la descrivi nessuno userebbe più password a questo mondo.


            Davvero?

            Prendiamo un codice eseguibile.. Ovvero una

            applicazione...

            Secondo te riesci a eseguire un contenuto "a

            caso" su una

            macchina?

            (rotfl)(rotfl)

            No, ma tu continui a prendere dei casi non è
            inutile un attacco di collisione e da questo
            concludi che non è un problema. Tu devi pensare
            invece a tutti quei casi dove il problema può
            essere sfruttato, e sono
            parecchi.Sono la totalità se si parla di trust!Non "parecchi".Se invece si parla di casi puramente teorici e modelli matematici possiamo discuterne! :D


            Ovvero se io trovo una collisione (produco lo

            stesso valore di hash) partendo da una
            sequenza

            di bit "a pera" riesco a eseguire tali bit "a

            pera" sul proXXXXXre x o

            y?

            I casi in cui puoi "inventarti" il risultato
            sono

            ininfluenti dato che se puoi inventarli
            significa

            2 cose (che devono verificarsi entrambe

            contemporaneamente bada bene)

            .

            1) Il contenuto (plain text) non era
            conosciuto
            o

            conoscibile prima



            2) il "senso" del contenuto non è rilevante
            ai

            fini di eseguire una certa

            azione.

            In pratica (concreta non teorica) questo non
            è

            mai

            vero.

            Se il "senso" del contenuto non è rilevante
            (aka

            non contiene informazione "reale") non ha
            senso

            cifrarlo nel 99.99999999999% dei casi.



            È per quello che si "disegnano" i
            protocolli
            che

            sono in realtà la descrizione delle
            relazioni
            che

            ci sono tra un dato e un

            altro!

            In sicurezza (e crittografia) tutto ciò che
            non

            ha "senso" (aka è inutile in termini
            informativi)

            non solo è "inutile" ma introduce
            "vulnerabilità"

            e debolezze non

            prevedibili.



            Tutto quelo che vuoi, però intanto, lo ripeto MD5
            non si usa quasi più... chissà
            perchèSbagliato è usatissimo (è nato nel lontano 1991 da una "pensata" di Ron Rivest) chiediti appunto il perchè continua a essere così usato.dai repository software a tanti altri casi.



            Niente affatto Md5 è usatissimo per la

            autenticità del codice il che è sensatissimo
            dato

            che non può essere fatto con "valori a

            caso".

            Non è questione di "blandizie".



            E lo usi tu che sei stolto perchè MD5 è un
            protocollo rotto, cambio codice a mio piacimento
            e poi aggiungo robe a caso per generare lo stesso
            hash, lo capisci o no??? affar tuo
            guarda.No non lo uso io.. lo usano tutti!Il "codice a tuo piacimento" non genera collisioni "a tuo piacimento" e per sostituire il codice (appunto) devono essere vere ENTRAMBE LE CONDIZIONI!Ripeto non solo devi trovare una collisione ma deve essere generata da un codice ESEGUIBILE che raggiunga i tuoi scopi e non quelli del software originario!I bit a caso non vengono eseguiti da alcun proXXXXXre!Non è che qualunque combinazione a pera di bit sono un programma eseguibile non te ne eri mai accorto?(rotfl)(rotfl)In caso contrario puoi mettere una scimmia a scrivere "Malware" hai le stesse probabilità di ottenere un risultato "utile".A te sfugge completamente la relazione tra la funzione di hash e il plain text .Ripeto il "plain text" non può essere un valore a caso!DEVE avere un SENSO perchè qualcuno (umano o macchina che sia) lo processa!E gira gira non hai trovato un solo caso (dicasi uno) da indicarmi in cui questo non sia vero!Dopo di che ripeto passare da un more vecchio e che inquina a uno nuovo che funziona a celle di combustibile è "normale manutenzione" non "una tragedia". ;)
          • orchidea scrive:
            Re: buffoni

            A te sfugge completamente la relazione tra la
            funzione di hash e il plain textNon ho voglia di rispondere a tutto perchè vedo che ti mancano le basi, ad esempio non hai ancora capito a cosa serve il protocollo di hashing all'interno di un certificato, oppure trovi così impossibile aggiungere bit a caso in un file perchè "verranno processati", se lo aggiungi quindi in un commento cosa succede??Ma non importa, non ho tempo nè voglia di convincerti, ti lascio solo con qualche link:http://en.wikipedia.org/wiki/Collision_attacke soprattutto questo:http://www.win.tue.nl/hashclash/rogue-ca/Naturalmente tu ne sai più di loro, quindi magari dagli una letta e mandagli le correzioni.
          • tucumcari fante lesto scrive:
            Re: buffoni
            - Scritto da: orchidea

            A te sfugge completamente la relazione tra la

            funzione di hash e il plain text

            Non ho voglia di rispondere a tutto perchè vedo
            che ti mancano le basi, ad esempio non hai ancora
            capito a cosa serve il protocollo di hashing
            all'interno di un certificato, oppure trovi così
            impossibile aggiungere bit a caso in un file
            perchè "verranno processati", se lo aggiungi
            quindi in un commento cosa
            succede??
            Ma non importa, non ho tempo nè voglia di
            convincerti, ti lascio solo con qualche
            link:

            http://en.wikipedia.org/wiki/Collision_attack

            e soprattutto questo:

            http://www.win.tue.nl/hashclash/rogue-ca/

            Naturalmente tu ne sai più di loro, quindi magari
            dagli una letta e mandagli le
            correzioni.Ovvio che ne so più di loro, la wikipedia non la scrivono mica gli esperti di sicurezza informatica, sono dei bimbominkia, dei perdigiorno.Io ho salvato l'Europa con una petizione online, vedi qui:http://punto-informatico.it/b.aspx?i=3789780&m=3790798#p3790798Tu puoi dire altrettanto?In caso contrario, buono lì.
      • Andrea B. scrive:
        Re: buffoni
        "SHA-1 è attaccabile da chiunque"?Non sai di cosa stai parlando.Problemi imminenti non ce ne sono... Certo è che ci sono alcuni segnali che fanno ipotizzare una compromissione più seria a medio-lungo termine. Potendo, già oggi ci si butta, nei progetti nuovi, su SHA-2 o 3.
        • unaDuraLezione scrive:
          Re: buffoni
          contenuto non disponibile
          • tucumcari fante lesto scrive:
            Re: buffoni
            - Scritto da: unaDuraLezione
            - Scritto da: Andrea B.

            "SHA-1 è attaccabile da chiunque"?

            Non sai di cosa stai parlando.



            Problemi imminenti non ce ne sono...

            ok.
            Falso allarme allora.
            Si vede che avevano voglia di fare gli spiritosi.In pratica si Per dirne una MD5 continua a essere usato semplicemente si va progressivamente (e giustamente) verso la sua "prudenziale" sostituzione.Un po' come se avevi una topolino tutto sommato quando vai a rottamarla la cambi con una nuova 500 o una bmw.Questa roba è da "fud quotidiano" quel tanto che basta a diffondere l'impressione di una NSA "onnipotente" e a fari pensare che tanto "perso per perso" ti conviene restare immerso nello "snake-oil" delle back door proprietarie.Il "tanto sono tutte uguali" è da sempre una argomento diffuso ad arte dalle "intelligence" fin dai tempi di giulio cesare.Del resto abbiamo numerosi e storicamente documentati esempi nella prima e seconda guerra mondiale (oltre che ai tempi del "de bello gallico").
        • orchidea scrive:
          Re: buffoni
          - Scritto da: Andrea B.
          "SHA-1 è attaccabile da chiunque"?
          Non sai di cosa stai parlando.

          Problemi imminenti non ce ne sono... Certo è che
          ci sono alcuni segnali che fanno ipotizzare una
          compromissione più seria a medio-lungo termine.
          Potendo, già oggi ci si butta, nei progetti
          nuovi, su SHA-2 o
          3.Se qualcuno avesse l'articolo infatti MS parla dal 2016, se fosse già rotto l'esclusione dovrebbe avvenire in maniera più rapida, qua si parla di 2 anni buoni
        • collione scrive:
          Re: buffoni
          - Scritto da: Andrea B.
          "SHA-1 è attaccabile da chiunque"?
          Non sai di cosa stai parlando.

          Problemi imminenti non ce ne sono... Certo è che
          ci sono alcuni segnali che fanno ipotizzare una
          compromissione più seria a medio-lungo termine.
          Potendo, già oggi ci si butta, nei progetti
          nuovi, su SHA-2 o
          3.molto medio in effetti2^80 è certo un numero molto grande, ma col gpgpu si è accorciata la vita di parecchi algoritmi che credevamo inattaccabilimeglio pararsi ******* prima che sia tardi
Chiudi i commenti