Alfonso Maruccia

SHA-1, cresce il rischio di attacchi

Gli hash crittografici generati con algoritmo SHA-1 sono sempre più a rischio, avvertono i ricercatori: la tecnologia dovrebbe essere abbandonata anche prima dei tempi previsti

Roma - Un gruppo di ricercatori ha messo insieme un cluster "economico" a base di GPU NVIDIA, usandolo poi per testare la robustezza degli hash crittografici generato con l'algoritmo SHA-1. Ed è subito SHAppening: la tecnologia non può più essere considerata sicura e va abbandonata quanto prima.

Kraken, il cluster di cui sopra, è composto da 64 GPU GeForce GTX 970 organizzate in 16 nodi, dove ogni nodo include 4 schede GTX 970, una CPU Intel Core i5-4460 (microarchitettura Haswell) e 16 Gigabyte di RAM. Con cotanto hardware, i ricercatori dicono di aver semplificato grandemente le risorse necessarie ad attaccare lo storico algoritmo SHA-1.

Il problema è di una certa gravità, dicono gli autori dello studio, visto che SHA-1 è ancora usato per firmare digitalmente i certificati SSL alla base delle comunicazioni sicure su canale HTTPS. I browser moderni non accetteranno più certificati con hash SHA-1 dopo il primo gennaio 2017, ma a quel punto potrebbe già essere troppo tardi.
I ricercatori hanno trovato il modo di semplificare la generazione di due hash SHA-1 identici per file differenti, una "collisione" che potrebbe essere sfruttata per camuffare come sicuro un software malevolo o un certificato compromesso. Usando il cloud computing, i ricercatori stimano un costo compreso fra i 75mila e i 120mila dollari per generare un attacco in grado di scardinare definitivamente SHA-1.

È il momento del panico? Non ancora, sostengono gli autori dello studio, anche se è meglio per l'industria non scherzare col fuoco: al momento la generazione di collisioni tra hash SHA-1 non è ancora provata, nondimeno l'algoritmo dovrebbe essere abbandonato in anticipo sui tempi. TrueCrypt e Microsoft (tra gli altri) lo avevano già fatto anni addietro.

Alfonso Maruccia
Notizie collegate
  • SicurezzaTrueCrypt 5.0 blinda tutto il disco rigidoLa nuova versione del celebre programma open source è in grado di cifrare l'intero hard disk, inclusa la partizione in cui risiede Windows, e di proporre la maschera di autenticazione prima dell'avvio dell'OS
  • SicurezzaMicrosoft: stop alla crittografia vulnerabileRedmond si prepara in anticipo alla futura "apocalisse" degli algoritmi crittografici insicuri annunciando l'abbandono di RC4 e SHA-1. I malware capaci di falsificare i certificati di sicurezza sono già in circolazione da anni
  • Sicurezza2016: addio a RC4I tre principali protagonisti del mercato dei browser annunciano l'abbandono della storica tecnologia crittografica in circolazione da decenni. Una decisione che dovrebbe migliorare la sicurezza del Web per tutti
73 Commenti alla Notizia SHA-1, cresce il rischio di attacchi
Ordina
  • ok questo è un certificato (addirittura da CA) firmato (sono buono) con una chiave da soli 1024 bit (pensa che facile!)
    E con sha-1 (più facile di così!!)
    Certificate:
        Data:
            Version: 3 (0x2)
            Serial Number: 14683129934516880912 (0xcbc4f4e181c88610)
        Signature Algorithm: sha1WithRSAEncryption
            Issuer: C=IT, ST=123state, O=123Pollo, OU=pollo123, CN=prova123 treppunti hhhh ecc/emailAddress=bah@123.com
            Validity
                Not Before: Oct 12 15:03:07 2015 GMT
                Not After : Oct 11 15:03:07 2018 GMT
            Subject: C=IT, ST=123state, O=123Pollo, OU=pollo123, CN=prova123 treppunti hhhh ecc/emailAddress=bah@123.com
            Subject Public Key Info:
                Public Key Algorithm: rsaEncryption
                    Public-Key: (1024 bit)
                    Modulus:
                        00:af:2c:93:62:68:9e:5d:4d:0f:8b:84:ad:4c:77:
                        f3:e9:b0:46:d8:58:ec:b2:36:b4:57:55:71:96:81:
                        f1:07:9e:68:c3:ea:d8:02:19:24:83:2c:9c:ce:de:
                        cf:39:9a:9e:64:9f:8c:40:44:dc:0e:06:9d:55:48:
                        8b:be:ca:5c:af:d0:38:23:64:bb:e8:79:36:a1:1d:
                        4a:62:f9:02:7a:d1:2c:59:30:79:49:84:4e:c6:08:
                        1d:38:b5:a1:aa:c5:0f:7c:e1:09:4a:14:b9:49:4e:
                        e4:dd:7f:9b:31:3c:1d:ec:bc:88:76:a7:e0:4c:b0:
                        c4:30:37:03:af:f4:74:db:bb
                    Exponent: 65537 (0x10001)
            X509v3 extensions:
                X509v3 Subject Key Identifier:
                    C5:EC:44:98:0F:54:6B:A8:F5:75:1B:D1:5B:AD:9A:0B:C8:5A:BF:8E
                X509v3 Authority Key Identifier:
                    keyid:C5:EC:44:98:0F:54:6B:A8:F5:75:1B:D1:5B:AD:9A:0B:C8:5A:BF:8E

                X509v3 Basic Constraints:
                    CA:TRUE
        Signature Algorithm: sha1WithRSAEncryption
             28:5b:a8:fc:ac:30:b7:cf:63:2d:ea:41:21:47:db:09:59:84:
             65:29:e5:99:ac:8a:57:69:f2:fa:0f:94:db:7e:04:4e:59:ab:
             26:08:74:38:29:cf:cb:e7:24:2d:c8:6c:0b:2c:8f:4a:42:6c:
             ad:f4:89:87:e6:f2:fe:57:78:c2:8c:70:2f:b9:90:41:23:d6:
             75:6d:8d:1e:1d:ed:5b:8b:c1:bb:5b:53:1a:a2:77:e9:04:2f:
             d9:c0:ab:32:69:dd:ae:bd:91:eb:7c:41:15:60:00:09:ec:35:
             1b:5f:a8:7e:eb:f0:13:16:9c:2d:8d:78:d5:17:62:c3:06:7f:
             2e:b8
    -----BEGIN CERTIFICATE-----
    MIIC4DCCAkmgAwIBAgIJAMvE9OGByIYQMA0GCSqGSIb3DQEBBQUAMIGIMQswCQYD
    VQQGEwJJVDERMA8GA1UECAwIMTIzc3RhdGUxETAPBgNVBAoMCDEyM1BvbGxvMREw
    DwYDVQQLDAhwb2xsbzEyMzEkMCIGA1UEAwwbcHJvdmExMjMgdHJlcHB1bnRpIGho
    aGggZWNjMRowGAYJKoZIhvcNAQkBFgtiYWhAMTIzLmNvbTAeFw0xNTEwMTIxNTAz
    MDdaFw0xODEwMTExNTAzMDdaMIGIMQswCQYDVQQGEwJJVDERMA8GA1UECAwIMTIz
    c3RhdGUxETAPBgNVBAoMCDEyM1BvbGxvMREwDwYDVQQLDAhwb2xsbzEyMzEkMCIG
    A1UEAwwbcHJvdmExMjMgdHJlcHB1bnRpIGhoaGggZWNjMRowGAYJKoZIhvcNAQkB
    FgtiYWhAMTIzLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAryyTYmie
    XU0Pi4StTHfz6bBG2Fjssja0V1VxloHxB55ow+rYAhkkgyyczt7POZqeZJ+MQETc
    DgadVUiLvspcr9A4I2S76Hk2oR1KYvkCetEsWTB5SYROxggdOLWhqsUPfOEJShS5
    SU7k3X+bMTwd7LyIdqfgTLDEMDcDr/R027sCAwEAAaNQME4wHQYDVR0OBBYEFMXs
    RJgPVGuo9XUb0VutmgvIWr+OMB8GA1UdIwQYMBaAFMXsRJgPVGuo9XUb0VutmgvI
    Wr+OMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADgYEAKFuo/Kwwt89jLepB
    IUfbCVmEZSnlmayKV2ny+g+U234ETlmrJgh0OCnPy+ckLchsCyyPSkJsrfSJh+by
    /ld4woxwL7mQQSPWdW2NHh3tW4vBu1tTGqJ36QQv2cCrMmndrr2R63xBFWAACew1
    G1+ofuvwExacLY141RdiwwZ/Lrg=
    -----END CERTIFICATE-----
    Se riesci a forgiarlo e a scriverlo qui sotto hai ragione...
    A bocca aperta

    In caso contrario .... beh cosa vuoi che ti dica......
    P.S.
    Fammi sapere quando hai finito così che tutti possiamo verificare....

    A bocca apertaA bocca aperta
    non+autenticato
  • Non ho mai visto un certificato scritto così. Ma sei sicuro o stai scrivendo cose a venvera?
    non+autenticato
  • - Scritto da: hhhh
    > Non ho mai visto un certificato scritto così. Ma
    > sei sicuro o stai scrivendo cose a
    > venvera?
    Cioè non conosci la coodifica PEM?
    Rotola dal ridereRotola dal ridere
    Beh lo pui verificare tu stesso bata che provi a falo leggere da un volgare browser mica difficile neh?!?
    Rotola dal ridereRotola dal ridere
    non+autenticato
  • Preferivi questo?
    Sta anche nel tuo browser nella lista di default...
    A bocca aperta
    -----BEGIN CERTIFICATE-----
    MIIHTzCCBTegAwIBAgIJAKPaQn6ksa7aMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYD
    VQQGEwJFVTFDMEEGA1UEBxM6TWFkcmlkIChzZWUgY3VycmVudCBhZGRyZXNzIGF0
    IHd3dy5jYW1lcmZpcm1hLmNvbS9hZGRyZXNzKTESMBAGA1UEBRMJQTgyNzQzMjg3
    MRswGQYDVQQKExJBQyBDYW1lcmZpcm1hIFMuQS4xKTAnBgNVBAMTIENoYW1iZXJz
    IG9mIENvbW1lcmNlIFJvb3QgLSAyMDA4MB4XDTA4MDgwMTEyMjk1MFoXDTM4MDcz
    MTEyMjk1MFowga4xCzAJBgNVBAYTAkVVMUMwQQYDVQQHEzpNYWRyaWQgKHNlZSBj
    dXJyZW50IGFkZHJlc3MgYXQgd3d3LmNhbWVyZmlybWEuY29tL2FkZHJlc3MpMRIw
    EAYDVQQFEwlBODI3NDMyODcxGzAZBgNVBAoTEkFDIENhbWVyZmlybWEgUy5BLjEp
    MCcGA1UEAxMgQ2hhbWJlcnMgb2YgQ29tbWVyY2UgUm9vdCAtIDIwMDgwggIiMA0G
    CSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCvAMtwNyuAWko6bHiUfaN/Gh/2NdW9
    28sNRHI+JrKQUrpjOyhYb6WzbZSm891kDFX29ufyIiKAXuFixrYp4YFs8r/lfTJq
    VKAyGVn+H4vXPWCGhSRv4xGzdz4gljUha7MI2XAuZPeEklPWDrCQiorjh40G072Q
    DuKZoRuGDtqaCrsLYVAGUvGef3bsyw/QHg3PmTA9HMRFEFis1tPo1+XqxQEHd9ZR
    5gN/ikilTWh1uem8nk4ZcfUyS5xtYBkL+8ydddy/Js2Pk3g5eXNeJQ7KXOt3EgfL
    ZEFHcpOrUMPrCXZkNNI5t3YRCQ12RcSprj1qr7V9ZS+UWBDsXHyvfuK2GNnQm05a
    Sd+pZgvMPMZ4fKecHePOjlO+Bd5gD2vlGts/4+EhySnB8esHnFIbAURRPHsl18Tl
    UlRdJQfKFiC4reRB7noI/plvg6aRArBsNlVq5331lubKgdaX8ZSD6e2wsWsSaR6s
    +12pxZjptFtYer49okQ6Y1nUCyXeG0+95QGezdIp1Z8XGQpvvwyQ0wlf2eOKNcx5
    Wk0ZN5K3xMGtr/R5JJqyAQuxr1yW84Ay+1w9mPGgP0revq+ULtlVmhduYJ1jbLhj
    ya6BXBg14JC7vjxPNyK5fuvPnnchpj04gftI2jE9K+OJ9dC1vX7gUMQSibMjmhAx
    hduub+84Mxh2EQIDAQABo4IBbDCCAWgwEgYDVR0TAQH/BAgwBgEB/wIBDDAdBgNV
    HQ4EFgQU+SSsD7K1+HnA+mCIG8TZTQKeFxkwgeMGA1UdIwSB2zCB2IAU+SSsD7K1
    +HnA+mCIG8TZTQKeFxmhgbSkgbEwga4xCzAJBgNVBAYTAkVVMUMwQQYDVQQHEzpN
    YWRyaWQgKHNlZSBjdXJyZW50IGFkZHJlc3MgYXQgd3d3LmNhbWVyZmlybWEuY29t
    L2FkZHJlc3MpMRIwEAYDVQQFEwlBODI3NDMyODcxGzAZBgNVBAoTEkFDIENhbWVy
    ZmlybWEgUy5BLjEpMCcGA1UEAxMgQ2hhbWJlcnMgb2YgQ29tbWVyY2UgUm9vdCAt
    IDIwMDiCCQCj2kJ+pLGu2jAOBgNVHQ8BAf8EBAMCAQYwPQYDVR0gBDYwNDAyBgRV
    HSAAMCowKAYIKwYBBQUHAgEWHGh0dHA6Ly9wb2xpY3kuY2FtZXJmaXJtYS5jb20w
    DQYJKoZIhvcNAQEFBQADggIBAJASryI1wqM58C7e6bXpeHxIvj99RZJe6dqxGfwW
    PJ+0W2aeaufDuV2I6A+tzyMP3iU6XsxPpcG1Lawk0lgH3qLPaYRgM+gQDROpI9CF
    5Y57pp49chNyM/WqfcZjHwj0/gF/JM8rLFQJ3uIrbZLGOU8W6jx+ekbURWpGqOt1
    glanq6B8aBMz9p0w8G8nOSQjKpD9kCk18pPfNKXG9/jvjA9iSnyu0/VU+I22mlaH
    FoI6M6taIgj3grrqLuBHmrS1RaMFO9ncLkVAO+rcf+g769HsJtg1pDDFOqxXnrN2
    pSB7+R5KBWIBpih1YJeSDW4+TTdDDZIVnBgizVGZoCkaPF+KMjNbMMeJL0eYD6MD
    xvbxrN8y8NmBGuScvfaAFPDRLLmF9dijscilIeUcE5fuDr3fKanvNFNb0+RqE4QG
    tjICxFKuItLcsiFCGtpA8CnJ7AoMXOLQusxI0zcKzBIKinmwPQN/aUv0NCB9szTq
    jktk9T79syNnFQ0EuPAtwQlRPLJsFfClI9eDdOTlLsn+mCdCxqvGnrDQWzilm1De
    fhiYtUU79nm06PcaewaD+9CL2rvHvRirCG88gGtAPxkZumWK5r7VXNM21+9AUiRg
    OGcEMeyP84LG3rlV8zsxkVrctQgVrXYlCg17LofiDKYGvCYQbTed7N14jHyAxfDZ
    d0jQ
    -----END CERTIFICATE-----
    In forma text....
    Certificate:
        Data:
            Version: 3 (0x2)
            Serial Number: 11806822484801597146 (0xa3da427ea4b1aeda)
        Signature Algorithm: sha1WithRSAEncryption
            Issuer: C=EU, L=Madrid (see current address at www.camerfirma.com/address)/serialNumber=A82743287, O=AC Camerfirma S.A., CN=Chambers of Commerce Root - 2008
            Validity
                Not Before: Aug 1 12:29:50 2008 GMT
                Not After : Jul 31 12:29:50 2038 GMT
            Subject: C=EU, L=Madrid (see current address at www.camerfirma.com/address)/serialNumber=A82743287, O=AC Camerfirma S.A., CN=Chambers of Commerce Root - 2008
            Subject Public Key Info:
                Public Key Algorithm: rsaEncryption
                    Public-Key: (4096 bit)
                    Modulus:
                        00:af:00:cb:70:37:2b:80:5a:4a:3a:6c:78:94:7d:
                        a3:7f:1a:1f:f6:35:d5:bd:db:cb:0d:44:72:3e:26:
                        b2:90:52:ba:63:3b:28:58:6f:a5:b3:6d:94:a6:f3:
                        dd:64:0c:55:f6:f6:e7:f2:22:22:80:5e:e1:62:c6:
                        b6:29:e1:81:6c:f2:bf:e5:7d:32:6a:54:a0:32:19:
                        59:fe:1f:8b:d7:3d:60:86:85:24:6f:e3:11:b3:77:
                        3e:20:96:35:21:6b:b3:08:d9:70:2e:64:f7:84:92:
                        53:d6:0e:b0:90:8a:8a:e3:87:8d:06:d3:bd:90:0e:
                        e2:99:a1:1b:86:0e:da:9a:0a:bb:0b:61:50:06:52:
                        f1:9e:7f:76:ec:cb:0f:d0:1e:0d:cf:99:30:3d:1c:
                        c4:45:10:58:ac:d6:d3:e8:d7:e5:ea:c5:01:07:77:
                        d6:51:e6:03:7f:8a:48:a5:4d:68:75:b9:e9:bc:9e:
                        4e:19:71:f5:32:4b:9c:6d:60:19:0b:fb:cc:9d:75:
                        dc:bf:26:cd:8f:93:78:39:79:73:5e:25:0e:ca:5c:
                        eb:77:12:07:cb:64:41:47:72:93:ab:50:c3:eb:09:
                        76:64:34:d2:39:b7:76:11:09:0d:76:45:c4:a9:ae:
                        3d:6a:af:b5:7d:65:2f:94:58:10:ec:5c:7c:af:7e:
                        e2:b6:18:d9:d0:9b:4e:5a:49:df:a9:66:0b:cc:3c:
                        c6:78:7c:a7:9c:1d:e3:ce:8e:53:be:05:de:60:0f:
                        6b:e5:1a:db:3f:e3:e1:21:c9:29:c1:f1:eb:07:9c:
                        52:1b:01:44:51:3c:7b:25:d7:c4:e5:52:54:5d:25:
                        07:ca:16:20:b8:ad:e4:41:ee:7a:08:fe:99:6f:83:
                        a6:91:02:b0:6c:36:55:6a:e7:7d:f5:96:e6:ca:81:
                        d6:97:f1:94:83:e9:ed:b0:b1:6b:12:69:1e:ac:fb:
                        5d:a9:c5:98:e9:b4:5b:58:7a:be:3d:a2:44:3a:63:
                        59:d4:0b:25:de:1b:4f:bd:e5:01:9e:cd:d2:29:d5:
                        9f:17:19:0a:6f:bf:0c:90:d3:09:5f:d9:e3:8a:35:
                        cc:79:5a:4d:19:37:92:b7:c4:c1:ad:af:f4:79:24:
                        9a:b2:01:0b:b1:af:5c:96:f3:80:32:fb:5c:3d:98:
                        f1:a0:3f:4a:de:be:af:94:2e:d9:55:9a:17:6e:60:
                        9d:63:6c:b8:63:c9:ae:81:5c:18:35:e0:90:bb:be:
                        3c:4f:37:22:b9:7e:eb:cf:9e:77:21:a6:3d:38:81:
                        fb:48:da:31:3d:2b:e3:89:f5:d0:b5:bd:7e:e0:50:
                        c4:12:89:b3:23:9a:10:31:85:db:ae:6f:ef:38:33:
                        18:76:11
                    Exponent: 65537 (0x10001)
            X509v3 extensions:
                X509v3 Basic Constraints: critical
                    CA:TRUE, pathlen:12
                X509v3 Subject Key Identifier:
                    F9:24:AC:0F:B2:B5:F8:79:C0:FA:60:88:1B:C4:D9:4D:02:9E:17:19
                X509v3 Authority Key Identifier:
                    keyid:F9:24:AC:0F:B2:B5:F8:79:C0:FA:60:88:1B:C4:D9:4D:02:9E:17:19
                    DirName:/C=EU/L=Madrid (see current address at www.camerfirma.com/address)/serialNumber=A82743287/O=AC Camerfirma S.A./CN=Chambers of Commerce Root - 2008
                    serial:A3:DA:42:7E:A4:B1:AE:DA

                X509v3 Key Usage: critical
                    Certificate Sign, CRL Sign
                X509v3 Certificate Policies:
                    Policy: X509v3 Any Policy
                     CPS: http://policy.camerfirma.com

        Signature Algorithm: sha1WithRSAEncryption
    non+autenticato
  • capisco che sarà un "duro colpo" per te che di certificati "ne hai visto" pur non essendone conscio e pur non avendo idea di come e perchè differiscano da un piatto di bucatini...... mah.... vedi se tu esporti (ad esempio da chrome) un certificato la codifica PEM (che è uno standard) è esattamente quella in cui lo esporterà...
    Rotola dal ridereRotola dal ridere
    P.S.
    Il text è solo per aiutare la lettura ovviamente il certificato è solo in pezzo compreso tra begin e end...
    P.P.S
    Hint....
    "openssl asn1parse -i -inform PEM -dump <(filename col contenuto PEM)" ti fa pure il parsing del famoso ASN1 (che non conosci) e te lo spiattella bel bello su "standard output" (il video nel tuo caso).....
    Rotola dal ridereRotola dal ridereRotola dal ridere
    oh.... è facile è e possono verificarlo tutti... in meno del tempo che ci vuole a dire 123
    Rotola dal ridereRotola dal ridereRotola dal ridere
    P.P.P.P.S.
    La prossima volta che parli di cose che non conosci fermati prima di fare figure irreparabili.
    Occhiolino
    non+autenticato
  • tranquillo, un paio di giorni e te lo ritrovi ancora qui a sputar sentenze.

    cheers e grazie per il servizio impagabileSorride
    non+autenticato
  • non so se ridere o piangere....
    Il rischio di collisione in un certificato è sostanzialmente irrilevante.
    In un certificato sono inclusi il nome di un signer e il nome di un subject e sono informazioni "clear text".
    Ottenere una collisione può anche essere relativamente facile ma ottenere una collisione "sensata" non lo è affatto.
    In pratica si ottiene una collisione su una stringa insensata e chiaramente priva di alcun significato che hanno un senso (ad esempio oltre ai nomi le date di scadenza) se c'è un caso in cui una collisione è di fatto non sfruttabile è proprio nei certificati....
    non+autenticato
  • - Scritto da: hakker123

    > Ottenere una collisione può anche essere
    > relativamente facile ma ottenere una collisione
    > "sensata" non lo è
    > affatto.

    Non è così: le collisioni sensate esistono e consistono nel mettere la parte 'causale' in un luogo preciso del messaggio senza toccare tutta la restante parte.
    E' già stato fatto per esempio su altri più deboli algoritmi di HASH, semplicemente per accodamento, ovvero il messaggio è quello significativo (e falso), poi si accoda una parte non significativa di pochi bit forgiata in modo da far tornare la firma.
    Nulla vieta di fare lo stesso coi certificati, mettendo la parte forgiata in un campo che non è importante per la verifica (e ce ne sono a bizzeffe in un certificato).
    non+autenticato
  • - Scritto da: hhhh
    > - Scritto da: hakker123
    >
    > > Ottenere una collisione può anche essere
    > > relativamente facile ma ottenere una
    > collisione
    > > "sensata" non lo è
    > > affatto.
    >
    > Non è così: le collisioni sensate esistono e
    > consistono nel mettere la parte 'causale' in un
    > luogo preciso del messaggio senza toccare tutta
    > la restante
    > parte.
    > E' già stato fatto per esempio su altri più
    > deboli algoritmi di HASH, semplicemente per
    > accodamento, ovvero il messaggio è quello
    > significativo (e falso), poi si accoda una parte
    > non significativa di pochi bit forgiata in modo
    > da far tornare la firma.
    Invece è così un certificato non è fatto di stringhe a caso bensì un pezzo di informazione strutturata e in più con una sintassi precisa ASN 1 che ti piaccia o meno.
    Tanto e vero che in un contest assai noto (blackhat) nessuno è riuscito a superare la prova di handshaking e col compito assai facilitato (il vecchio MD5).
    Credere che basti "far tornare la firma" è da poveri ingenui...
    Comunque grazie ho sciolto il dubbio...

    Nel tuo caso c'è da ridere.

    A bocca aperta
    non+autenticato
  • - Scritto da: hakker123

    > Invece è così un certificato non è fatto di
    > stringhe a caso bensì un pezzo di informazione
    > strutturata e in più con una sintassi precisa


    struttura che lascia spazio libero in parecchi punti, come dovresti sapere se sai com'è fatta.
    Ma è evidente che non lo sai Sorride
    non+autenticato
  • - Scritto da: hhhh
    > - Scritto da: hakker123
    >
    > > Invece è così un certificato non è fatto di
    > > stringhe a caso bensì un pezzo di
    > informazione
    > > strutturata e in più con una sintassi precisa
    >
    >
    > struttura che lascia spazio libero in parecchi
    > punti, come dovresti sapere se sai com'è
    > fatta.
    > Ma è evidente che non lo sai Sorride
    Non lascia alcuno spazio ogni dato è identificato da un OID e dalla specifica di contenuto e lunghezza è proprio una proprietà di base dell'ASN1 che evidentemente non conosci.
    Come evidentemente non conosci il fatto che non esiste alcun caso conosciuto di collisioni (proprio per quel motivo) su un certificato x509 anche con algoritmi debolissimi (vedasi md5).
    non+autenticato
  • Comunque io ho una memoria fotografica e gli algoritmi li ho ben stampati in testa.
    non+autenticato
  • - Scritto da: hakker123
    > Comunque io ho una memoria fotografica e gli
    > algoritmi li ho ben stampati in
    > testa.
    Ne dubito treppunti... ne dubito e fino a ora hai sempre confermato e giustificato per iscritto i dubbi...
    A bocca aperta
    non+autenticato
  • Hai qualche documento/guida dove approfondire come avviene l'handshake con i certificati? Ne so molto poco e vorrei approfondire.
    Tu considera che so cos'è un hash, ma mi sfugge tutto il discorso del fatto che non basta far collider due hash.
    non+autenticato
  • - Scritto da: Luca

    > Tu considera che so cos'è un hash, ma mi sfugge
    > tutto il discorso del fatto che non basta far
    > collider due
    > hash.

    il discorso è semplice: lui dice (giustamente) che non basta far collidere due HASH.
    Infatti se anche un documento ha la firma giusta ma non ha il significato giusto (ovvero formato e dati contenuti), non serve a nulla, verrà rigettato come certificato non valido (per via del formato o per via dei dati non validati).

    Quello che non dice, però è che basta poter agire su pochi bit non significativi (per la precisione all'incirca un numero di bit pari alla lunghezza della firma) per potersi garantire la possibilità di un file valido e con la stessa firma.
    E' chiaro che il problema di trovare la collisione in una situazione vincolata (puoi agire solo su certi bit) è più complesso, ma non è detto.
    Come ho già scritto, già da anni esistono sistemi per avere la stessa firma di alcuni algoritmi hash deboli, semplicemente accodando dati ad un file arbitrario (quindi assolutamente non casuale).
    Certo, questo nel caso dei certificati non basta (a meno che il programma che riceve il certificato abbia una validazione scadente), ma tutto ciò è indicativo, ovvero è falso quanto dice il tucu qui sopra che è impossibile avere una collisione con un documento significativo (cioè non pseudocasuale).
    non+autenticato
  • - Scritto da: hhhh

    > ma
    > tutto ciò è indicativo, ovvero è falso quanto
    > dice il tizio qui sopra che è impossibile avere
    > una collisione con un documento significativo


    e infatti, qui ci sono esempi di exe (ovvero file sia strutturati che significativi) diversi ma con la stessa firma (md5 che è più debole di sha-1)
    http://www.mscs.dal.ca/~selinger/md5collision/
    non+autenticato
  • - Scritto da: hhhh
    > - Scritto da: hhhh
    >
    > > ma
    > > tutto ciò è indicativo, ovvero è falso quanto
    > > dice il tizio qui sopra che è impossibile
    > avere
    > > una collisione con un documento significativo
    >
    >
    > e infatti, qui ci sono esempi di exe (ovvero file
    > sia strutturati che significativi) diversi ma
    > con la stessa firma (md5 che è più debole di
    > sha-1)
    > http://www.mscs.dal.ca/~selinger/md5collision/
    Un exe non è una sintassi e può contenere qualunque stringa di bit al suo interno a differenza di una struttura ASN1 (cosa di cui pare ovvio che tu non conosca il significato).
    non+autenticato
  • Giusto iniziare l'abbandono di SHA-1, ma è una cosa normale; qualunque lunghezza di chiavi e/o hashing un giorno sarà attaccabile, quindi anche i successori di SHA-1 avranno una "scadenza".
    Normale evoluzione insomma.
  • - Scritto da: pentolino
    > Giusto iniziare l'abbandono di SHA-1, ma è una
    > cosa normale; qualunque lunghezza di chiavi e/o
    > hashing un giorno sarà attaccabile, quindi anche
    > i successori di SHA-1 avranno una
    > "scadenza".
    > Normale evoluzione insomma.

    Non è questione di lunghezza nominale ma di possibilità di riduzione dei reali bit di complessità.
    La lunghezza nominale (160 bit per sha-1) è la robustezza teorica di un algoritmo perfetto, ma di fatto non esistono algoritmi perfetti per cui basandosi su studi ed osservazioni si riduce il numero di bit reali.

    160 bit in realtà sarebbero tantissimi, equivale a 2^160=2^64*2^64*2^32.
    In pratica vuole dire che se avessimo 4 miliardi di cpu (2^32), ognuna delle quali fa 2^64 (4 miliardi * 4 miliardi) elaborazioni di crack al secondo (e nessuna cpu o gpu nemmeno si avvicina ad un miliardesimo di questa potenza), servirebbero 2^64 secondi, ovvero 4 miliardi * 4 miliardi secondi, ovvero 584.942.417.355 anni.

    Il punto quindi non è la lunghezza dell'hash, ma la sua reale robustezza.
    Se paradossalmente avessimo un hash da 120 bit ma perfetto basterebbe fino a quando non arrivano gli alieni.
    non+autenticato
  • giusto ma il risultato è lo stesso, ciò che è sicuro oggi potrebbe non esserlo domani: hai due modi per renderlo più robusto: allungare la chiave o migliorare l'algoritmo.
  • - Scritto da: pentolino
    > giusto ma il risultato è lo stesso, ciò che è
    > sicuro oggi potrebbe non esserlo domani: hai due
    > modi per renderlo più robusto: allungare la
    > chiave o migliorare
    > l'algoritmo.

    Ni: nulla vieta che l'algoritmo ottimo sia già uno di quelli usati, e quindi non vada migliorato affatto Occhiolino
    non+autenticato
  • Il Keccak è una funzione di hashing "tweakable"
    Significa che puoi modificare i parametri per renderlo più o meno sicuro (a runtime!), consumando piu' o meno CPU e generando hash di lunghezze diverse (il consumo di memoria è invece fisso e davvero molto basso). Attualmente lo standard ha come parametri: r=1024, c=576 per l'SHA-3.
    In futuro sentirai parlare sempre più stesso di questo algoritmo...
    non+autenticato
  • - Scritto da: Voglio il Keccak
    > Il Keccak è una funzione di hashing "tweakable"
    > Significa che puoi modificare i parametri per
    > renderlo più o meno sicuro (a runtime!),
    > consumando piu' o meno CPU e generando hash di
    > lunghezze diverse (il consumo di memoria è invece
    > fisso e davvero molto basso). Attualmente lo
    > standard ha come parametri: r=1024, c=576 per
    > l'SHA-3.
    > In futuro sentirai parlare sempre più stesso di
    > questo
    > algoritmo...
    hummmm.... e chi ti impedisce di usarlo?
    Giusto per sapere eh....
    non+autenticato
  • Nessuno.
    Solo che non scelgo io se usare questo o quell'altro algoritmo per firmare i certificati o nei programmi. Certo, in quelli open source potrei mettermi ad aggiungere l'algoritmo per uso personale ma fintanto che non è accettato e messo in upsteam l'utilizzo che se ne puo' fare è limitato.
    Bisogna attendere che venga adottato in massa.
    Questa notizia non farà che spingere avanti il Keccak.
    non+autenticato
  • - Scritto da: Voglio il Keccak
    > Nessuno.
    > Solo che non scelgo io se usare questo o
    > quell'altro algoritmo per firmare i certificati o
    > nei programmi. Certo, in quelli open source
    > potrei mettermi ad aggiungere l'algoritmo per uso
    > personale ma fintanto che non è accettato e messo
    > in upsteam l'utilizzo che se ne puo' fare è
    > limitato.
    > Bisogna attendere che venga adottato in massa.
    > Questa notizia non farà che spingere avanti il
    > Keccak.
    Traduzione... tu non vuoi il Keccak vuoi che lo usino gli altri....
    Ammesso (non concesso) che tu avessi ragione forse ti sfugge che già ora vengono usati molti e diversi algoritmi senza che questo significhi che tutti debbono usarli....
    Lo sapevi?
    Occhiolino
    non+autenticato
  • Per esempio.
    I file .torrent hanno all'interno l'SHA1 del/dei file a cui fa riferimento spezzettato/i per blocchi. Solo l'SHA1 è l'hash che contata in questo caso, nessuna eccezione. Basterebbe corrompere un blocco con una collisione e chi ti invia quella parte di file, può inviartela danneggiata. Se pensi a una immagine di un DVD: ti tocca riscaricare tutto il file da capo perchè non puoi sapere quale parte del file è danneggiato (in quanto avviene una collisione e anche ricontrollando il file non te ne puoi accorgere). Inoltre puoi scoprire che il file è danneggiato solo dopo che il download è completato controllando manualmente che l'hash dell'interno file corrisponda... sempre che ci sia da scaricare anche l'hash dell'intero file dal sito web/ftp da cui hai preso il torrent (questo perchè è altamente improbabile che una collisione creata all'interno di un blocco sia anche una collisione contro l'intero file). Altrimenti ti accorgi che il file è danneggiato solo mentre lo provi! E magari non te ne accorgi nemmeno, lo masterizzi e poi il problema viene fuori una settimana dopo quando accedi per la prima volta alla parte di contenuto danneggiata.

    Ora: si potrebbe usare il Keccak al posto dell'SHA1 perché è più veloce e più sicuro. Per questo dico che voglio il Keccak. E chi non lo vuole sbaglia, perchè l'SHA1 puo' fare degli scherzi....
    Che poi il Keccak in sé esista da anni, questo è risaputo.
    E' anche ora di usarlo in massa pero'. Privatamente ti puoi inventare una funzione di hashing crittografico tua (che sia perfetta o faccia schifo è indifferente) e poi la puoi usare, ma ovviamente quello che ci puoi fare in questo caso è proprio poca roba, un minimo delle applicazione per cui le funzioni di hashing crittografico vengono usate.
    non+autenticato
  • - Scritto da: Voglio il Keccak

    > Ora: si potrebbe usare il Keccak al posto
    > dell'SHA1 perché è più veloce e più sicuro. Per
    > questo dico che voglio il Keccak. E chi non lo
    > vuole sbaglia, perchè l'SHA1 puo' fare degli
    > scherzi....
    E chi ti impedisce di usarlo?
    è un semplice OID... non vedo la difficoltà
    Infatti ogni protocollo degno di questo nome non dipende da un algoritmo o un altro è una semplice specifica che contiene appunto la indicazione del protocollo usato quindi se vuoi usare il Keccak fallo esattamente come nessuno ti vieta di usare RIPEMD-160 o whirlpool a prescindere da quanti lo usano.
    Certo se tutti i protocolli dipendessero strettamente da un solo algoritmo staremmo freschi...
    Vuoi il gelato?
    Mangialo e non scassare gli zebedei.
    Magari ad alcuni il gelato non piace o gli fa pure male....
    Il che non significa che debbano imedire a te di mangiarlo o che debbano per forza mangiarlo loro.
    non+autenticato
  • Quanti giorni ci hanno impiegato per ottenere la collisione?
  • - Scritto da: evilripper
    > Quanti giorni ci hanno impiegato per ottenere la
    > collisione?
    Non mi pare poi tanto rilevante il punto è che sia fattibile.
    Il rischio vale non certo per le informazioni "strutturate" e con una sintassi (certificati) ma per il dati non strutturati in cui è relativamente semplice ottenere collisioni e nascondere (data la assenza di sintassi strutturale) bit aggiuntivi.
    Il problema non è certo quello dei certificati ma di cosa si firma.. se non ha struttura.
    non+autenticato
  • - Scritto da: hakker123

    > Il problema non è certo quello dei certificati ma
    > di cosa si firma.. se non ha
    > struttura.

    Non finisci mai di raccontarne:
    http://www.mscs.dal.ca/~selinger/md5collision/

    Negli esempi
    due exe per windows diversi con la stessa firma
    due exe per linux diversi con la stessa firma

    ora vienimi a raccontare che gli exe non sono strutturati Rotola dal ridereRotola dal ridereRotola dal ridere
    non+autenticato
  • - Scritto da: hhhh
    > - Scritto da: hakker123
    >
    > > Il problema non è certo quello dei
    > certificati
    > ma
    > > di cosa si firma.. se non ha
    > > struttura.
    >
    > Non finisci mai di raccontarne:
    > http://www.mscs.dal.ca/~selinger/md5collision/
    >
    > Negli esempi
    > due exe per windows diversi con la stessa firma
    > due exe per linux diversi con la stessa firma
    >
    > ora vienimi a raccontare che gli exe non sono
    > strutturati
    > Rotola dal ridereRotola dal ridereRotola dal ridere
    Non te lo racconto lo constato dimmi cosa ti impedisce di mettere in un exe qualunque stringa tu voglia... gli exe contengono anche dati non solo codice o ti sfugge questo dettagliuzzo?
    In una struttura ASN1 invece questo non è possibile perchè si tratta (lo dice la parola stessa) di sintassi ogni cosa è descritta e ha una lunghezza a sua volta descritta nella sintassi stessa.
    Ma evidentemente non sai cosa sia una struttura ASN1.
    non+autenticato
  • - Scritto da: voglio il gelato123

    > In una struttura ASN1 invece questo non è
    > possibile

    Dimmi, quante date sono contenute nel certificato, quanti bit usano, e quali sono i vincoli di validità?
    Orsù, sono tutt'orecchie.
    non+autenticato
  • - Scritto da: hhhh
    > - Scritto da: voglio il gelato123
    >
    > > In una struttura ASN1 invece questo non è
    > > possibile
    >
    > Dimmi, quante date sono contenute nel
    > certificato, quanti bit usano, e quali sono i
    > vincoli di
    > validità?
    > Orsù, sono tutt'orecchie.
    Le date in un certificato sono quante io voglio mettercene (di solito quelle che identificano la validità sono 2) un certificato è una "sequence of sequence" il che significa che posso metterci qualunque cosa (anche un milione di date) purchè ne descriva sintatticamente la struttura in ASN1.
    Non c'è nulla che non possa essere messo in un certificato alla sola PICCOLA CONDIZIONE che sia descritto sintatticamente.
    Così come non esiste NULLA che io possa mettere in modo arbitrario senza averlo descritto strutturalmente.
    Non è difficile no?
    Occhiolino
    non+autenticato
  • - Scritto da: voglio il gelato123

    > Le date in un certificato sono quante io voglio
    > mettercene (di solito quelle che identificano la
    > validità sono 2)


    E non capisci che il certificato farlocco può essere forgiato con la struttura perfettamente dichiarata, ma, per esempio, con un numero di date necessarie a garantirsi un numero di bit variabili (basta rispettare i vincoli di validità di ogni data, per il resto tutti i bit delle date sono modificabili)?

    Il tizio con gli exe ha fatto la stessa cosa, solo alcuni bit dell'exe erano diversi, quelli in una stringa all'interno di un IF
    non+autenticato
  • - Scritto da: hhhh
    > - Scritto da: voglio il gelato123
    >
    > > Le date in un certificato sono quante io
    > voglio
    > > mettercene (di solito quelle che
    > identificano
    > la
    > > validità sono 2)
    >
    >
    > E non capisci che il certificato farlocco può
    > essere forgiato con la struttura perfettamente
    > dichiarata, ma, per esempio, con un numero di
    > date necessarie a garantirsi un numero di bit
    > variabili (basta rispettare i vincoli di validità
    > di ogni data, per il resto tutti i bit delle date
    > sono
    > modificabili)?
    Niente affatto non sono per nulla modificabili forse non sai ne cosa sia ASN1 ne una "sequence of sequence"
    non+autenticato
  • - Scritto da: voglio il gelato123

    > Niente affatto non sono per nulla modificabili
    > forse non sai ne cosa sia ASN1 ne una "sequence
    > of
    > sequence"

    Fai finta di non capire? Crei un certificato valido, compatibile con l'ASN-1 dichiarato E in cui puoi cambiare alcuni bit per poter avere l'hash uguale a quello dle certificato che devi falsificare.
    Se cambi dei bit delle date (senza sforare eventuali vincoli > o < che si sono per alcune date), la validazione sia strutturale che semantica la passi senza problemi.
    O mi stai dicendo che se ho due certificati, un che ha una data di fine validità leggermente diversa dall'altro, allora hanno una struttura dichiarata ASN-1 diversa?
    IMPOSSIBILE.
    non+autenticato
  • - Scritto da: hhhh
    > - Scritto da: voglio il gelato123
    >
    > > Niente affatto non sono per nulla
    > modificabili
    > > forse non sai ne cosa sia ASN1 ne una
    > "sequence
    > > of
    > > sequence"
    >
    > Fai finta di non capire? Crei un certificato
    > valido, compatibile con l'ASN-1 dichiarato E in
    > cui puoi cambiare alcuni bit per poter avere
    > l'hash uguale a quello dle certificato che devi
    > falsificare.
    Non puoi cambiare "alcuni bit" e sopratutto i bit in questione non possono essere "appesi" (come si fa con il metodo noto come tunnelling per trovare le collisioni) perchè devono essere descritti nella stessa struttura.
    non+autenticato
  • - Scritto da: voglio il gelato123

    > Non puoi cambiare "alcuni bit"

    Ah, adesso non posso cambiare alcuni bit di una data? Rotola dal ridere
    Ma sai come sono codificate le date? Rotola dal ridere
    Come se ne dovrebbe accorgere il validatore che ho cambiato una data (hash escluso OVVIAMENTE)?
    Basta che non sforo con i vincoli di quelle dichiarate nella struttura, no?
    E comunque la struttura dichiarata di un certificato dove sta? Rotola dal ridere


    > e sopratutto i bit
    > in questione non possono essere "appesi"

    Mai detto che nel caso in questione vadano appesi.
    Era un esempio di un altro genere che non c'entra coi cert.
    non+autenticato
  • per gli spioni di stato è un costo infinitesimo.

    "i 75mila e i 120mila dollari per generare un attacco in grado di scardinare definitivamente SHA-1."

    Sì, si parla comunque di UNA istanza e si parla di costo computazionale (per ogni istanza).

    Quello che si potrebbe fare?
    Obbligare l'ISP a redirigere il traffico (via IP) di un certo sito (TOR?) verso un sito copia gestito da spioni.
    Quando l'utente (o meglio tutti gli utenti che usano l'ISP) scarica la versione del programma, via HTTPS, nonostante il sito sia falso, il browser non rivelerà nessun problema di identità e l'utente installerà il programma in versione 'ovetto di pasqua'.

    Ma secondo voi gli spioni di stato che spendono un miliardo di dollari per creare "l'SMS invisibile" per gli smartphone, hanno problemi a mettere insieme 64 gpu e programmarle meglio di quanto han fatto i ricercatori?

    Più verosimile che abbiano un cluster da 6400 gpu (stando bassi) e tutti i tempi, pertanto, vanno divisi per 100.
    non+autenticato
  • eccerto divisi per 100
    Rotola dal ridereRotola dal ridere
    Lo sanno tutti che è una funzione LINEARE no?
    Rotola dal ridereRotola dal ridere
    1 gpu diviso uno 2 gpu diviso 2 ecc. ecc..
    Rotola dal ridereRotola dal ridere
    non+autenticato
  • - Scritto da: hakker123
    > eccerto divisi per 100
    > Rotola dal ridereRotola dal ridere
    > Lo sanno tutti che è una funzione LINEARE no?
    > Rotola dal ridereRotola dal ridere
    > 1 gpu diviso uno 2 gpu diviso 2 ecc. ecc..
    > Rotola dal ridereRotola dal ridere

    glielo vai tu a spiegare ai tizi che minano bitcoin che non è così?
    Rotola dal ridereRotola dal ridereRotola dal ridereRotola dal ridereRotola dal ridereRotola dal ridereRotola dal ridereRotola dal ridere
    non+autenticato
  • - Scritto da: hakker123
    > eccerto divisi per 100
    > Rotola dal ridereRotola dal ridere
    > Lo sanno tutti che è una funzione LINEARE no?
    > Rotola dal ridereRotola dal ridere
    > 1 gpu diviso uno 2 gpu diviso 2 ecc. ecc..
    > Rotola dal ridereRotola dal ridere

    Eh, probabilmente si !
    A meno che non prendi i risultati parziali, li fai transitare sul bus a 64 bit, li trasferisci magari in RAM e li passi ad un'altra GPU.
    Direi che non è efficiente. Per logica mi sa che suddividono i task di brute force linearmente sulle singole GPU ... per logica eh !
    non+autenticato
  • - Scritto da: LoHackker
    > - Scritto da: hakker123
    > > eccerto divisi per 100
    > > Rotola dal ridereRotola dal ridere
    > > Lo sanno tutti che è una funzione LINEARE no?
    > > Rotola dal ridereRotola dal ridere
    > > 1 gpu diviso uno 2 gpu diviso 2 ecc. ecc..
    > > Rotola dal ridereRotola dal ridere
    >
    > Eh, probabilmente si !
    Eggià come no infatti è proprio così per calcolare una funzione crittografica con 2 processori al posto di uno vai veloce il doppio!!!!
    Ceeeertooooo
    Mi dovresti spiegare però per quale misterioso motivo se devo cifrare con una chiave (scegli pure un algoritmo a piacere) su un biprocessore (a parità di clock) non ci metto la metà del tempo che ci metto col monoprocessore....
    Mistero della fede?
    Rotola dal ridereRotola dal ridere
    non+autenticato
  • - Scritto da: voglio il gelato123

    > Mi dovresti spiegare però per quale misterioso
    > motivo se devo cifrare con una chiave (scegli
    > pure un algoritmo a piacere) su un biprocessore
    > (a parità di clock) non ci metto la metà del
    > tempo che ci metto col
    > monoprocessore....

    perché l'input va scorso dall'inizio alla fine.
    Nel caso dell'hash, l'input (il certificato da forgiare) è breve è può essere messo in RAM, VRAM, e dato in pasto in parallelo ad ogni gpu.
    non+autenticato
  • - Scritto da: hhhh

    > perché l'input va scorso dall'inizio alla fine

    (e gli stati intermedi sono indispensabili per proseguire la crittografia)
    non+autenticato
  • - Scritto da: hhhh
    > - Scritto da: hhhh
    >
    > > perché l'input va scorso dall'inizio alla
    > fine
    >
    > (e gli stati intermedi sono indispensabili per
    > proseguire la
    > crittografia)
    Lo stesso vale per calcolare un hash (qualsiasi algoritmo) e verificare che ci sia una collisione.
    non+autenticato
  • - Scritto da: voglio il gelato123

    > Lo stesso vale per calcolare un hash (qualsiasi
    > algoritmo) e verificare che ci sia una
    > collisione.

    lo so perfettamente (visto che ne ho implementati personalmente), ma la differenza tra un file generico ed un certificato è che il secondo lo puoi far stare in RAM (anzi in cache) e puoi eseguire il calcolo variando ALGORITMICAMENTE una porzione del file senza generare necessariamente l'intero file in RAM.
    In pratica non puoi calcolare un hash alla velocità doppia, ma puoi calcolare due hash contemporaneamente (di due varianti del file) con due processori.
    Il risultato è lo stesso.
    Chiaramente l'esempio che hai fatto tu (file unico) era bellamente sviante e non c'entrava un tubo Rotola dal ridere
    non+autenticato
  • - Scritto da: hhhh
    > - Scritto da: voglio il gelato123
    >
    > > Lo stesso vale per calcolare un hash
    > (qualsiasi
    > > algoritmo) e verificare che ci sia una
    > > collisione.
    >
    > lo so perfettamente (visto che ne ho implementati
    > personalmente),
    Rotola dal ridereRotola dal ridere
    Peccato che il duplicare il dato (o il file) non aiuti per nulla lo devi processare per ogni variante cercata anche se fosse di soli 8 bit
    Rotola dal ridereRotola dal ridere
    Il fatto è che ogni "variante" come la chiami tu sta in relazione con il cleartext di cui cerchi la collisione quindi e quindi non è parallelizzabile in modo lineare.
    non+autenticato
  • - Scritto da: voglio il gelato123

    > Peccato che il duplicare il dato (o il file) non
    > aiuti per nulla lo devi processare per ogni
    > variante cercata

    Assolutamente no.
    Il file lo tieni in RAM in copia UNICA, ma quando vai a leggere una certa parte dell'array del file usi alcuni bit generati al volo ALGORITMICAMENTE al posto dei bit originali.
    E' banalissimo solo che a te mancano la basi di programmazione...
    non+autenticato