Mikä on XTS: n etu CBC-tilaan nähden (diffuusorilla)?
On marraskuu 30, 2020 by adminMinulla on joitain ongelmia ymmärtää AES-XTS: n ”etua” verrattuna diffuusorilla varustettuun CBC: hen.
Luin jotain aiheesta FileVault , tässä artikkelissa he mainitsevat kaksi toimintamoodia XTS ja CBC (hajottimella) ja XTS: n edut.
Molemmat tilat salaavat datayksiköt melkein samalla tavalla. CBC: lle sektorinumeroa käytetään jotenkin IV: n rakentamiseen, XTS: lle on ”säätöarvo”, joka sisältää (jotenkin) myös lohkonsiirron, joten jokainen tietolohko voidaan salata itsenäisesti (on järkevää salattaessa kiintolevyjä / osiot). En todellakaan näe XTS: n etua.
Nyt he kirjoittavat seuraavan XTS: stä:
Vaihtoehtoihin on useita etuja kuten AES CBC: ssä: alustusvektoria ei vaadita (säätöavain voidaan johtaa lohkon numerosta); kukin lohko on salattu eri tavalla (koska säätöarvo on erilainen); ja toisin kuin AES-CBC, AES-XTS estää hyökkääjää vaihtamasta yhtä tiettyä bittiä tietoyksikössä tekemällä jokaisen AES-tulon eri salatun niputetun version kanssa.
Ehkä he vain vertaavat XTS: ää CBC: hen (ilman diffuusoria) … jos on, tietääkö kukaan mitään XTS: n etua?
Ja voisiko joku selittää toisen edun: ”AES- XTS estää hyökkääjää vaihtamasta yhtä tiettyä bittiä tietoyksikössä tekemällä jokaisen AES-tulon eri salatun nipistetyn version kanssa. ”?
Kommentit
- Mikä ' s " diffuusori "? " sektorin numero on jotenkin " miten? ' et kuvannut järjestelmää selkeästi. Jos algoritmi on ennustettavissa, se johtaa heikkouksiin ja arvaamaton algoritmi on kallista.
- @CodesInChaos Mielestäni viittaus on Microsoftin ' s Elephant-diffuusoriin BitLockerissa ( download.microsoft.com/download/0/2/3/… – varoitus: lataa PDF ).
- Tervetuloa Cryptography Stack Exchangeen. Kysymyksesi siirrettiin tänne, koska se ei liity suoraan ohjelmistokehitykseen (Stack Overflow -aihe), ja koska olet enemmän aiheesta täällä. Rekisteröi tilisi myös täällä, jotta voit kommentoida ja hyväksyä vastauksen.
Vastaa
XTS vs. jakamaton CBC. Tässä on kysymys muovattavuus . Sekä XTS että CBC estävät hyökkääjää oppimasta tietoja salatuista tiedoista. Kumpikaan ei kuitenkaan onnistu estämään hyökkääjää peukaloimasta salattuja tietoja.
On kuitenkin epäilemättä helpompaa manipuloida (jakamatonta) CBC-salaustekstiä kuin on tarkoitus manipuloida XTS-salaustekstiä. Sanotaan, että hyökkääjä sattuu tietämään, että jokin viesti sanoo
”blah blah Anna Alice \ 400 dollaria … blah blah blah ”.
Jos tämä viesti on salattu CBC: llä, hyökkääjä voi muuttaa salaustekstiä siten, että se purkaa nyt salauksen
”blah blah! ^% @ ^^ Anna Alice \ 800 dollaria blah blah blah”
\ $ 400: sta on tullut \ $ 800. Tähän viittaa lainaus ”AES-XTS estää hyökkääjää muuttamasta yhtä tiettyä bittiä datayksikössä”. Tässä kirjoitan! ^% @ ^^ osoittaakseni, että edellisestä 16-tavuisesta lohkosta tulee katkera, kun se puretaan, ja tämä katkeruus on hyökkääjän valvonnan ulkopuolella.
Toisaalta XTS: n käyttö Estää tämän hyökkäyksen. Hyökkääjä voi vioittaa viestin muuttamalla minkä tahansa 16-tavun lohkon satunnaiseksi katkelmaksi, mutta hän ei voi hallita samaa tasoa kuin CBC-esimerkissä.
Mutta Microsoft päätti olla käyttämättä XTS: ää joka tapauksessa. Syynä on se, että kyky vioittaa 16-tavuinen lohko saattaa silti olla vahingollista. Tässä on linkki paperisen dchestin linkistä:
Esimerkiksi voi olla määritystiedosto (tai rekisterimerkintä), jonka arvo on 0, kun se asetetaan arvoon 0, mikä luo käyttöjärjestelmään suojausreiän. Levyllä asetus näyttää olevan ”enableSomeSecuritySetting = 1”. Jos arvon alku putoaa 16-tavun rajalle ja hyökkääjä satunnaistaa selväkielisen arvon, on $ 2 ^ {16} $ mahdollisuus, että kaksi ensimmäistä tavua selkeän tekstin arvo on 0x30 0x00, joka on merkkijono, joka koodaa ASCII-arvon 0.
(Tämä lainaus viittaa LRW-säätöön, mutta XTS: ssä käytetyllä muokattavalla XEX-salauksella on sama ongelma).
Hajottimen lisääminen. Käyttäminen diffuusori on Microsftin ratkaisu tähän ongelmaan.Ajatuksena on ”sekoittaa” selkokielinen teksti ennen sen salaamista, jotta hyökkääjä ei voi muuttaa \ $ 400 arvosta \ $ 800 — sekoittuminen osaan salaustekstiä muuttaa melkein koko tekstintekstin, ei vain pieniä osia siitä.
Tämä kuulostaa hyvältä, mutta saalis on: Kukaan ei todellakaan tiedä, onko Microsoftin diffuusori todella suojattu. Tietääkseni se ei ole saanut mitään julkaistua muodollista analyysiä kryptografeilta. Tämä tarkoittaa, että sinun pitäisi olla skeptinen luottaa siihen. Microsoft myöntää tämän:
Haittapuolena on, että hajotin on uusi todistamaton algoritmi, ja tämä johtaa väistämättä kysymyksiin. Ilman laajaa julkista valvontaa ja algoritmin analysointia on perusteltu skeptisyys sen turvallisuudesta. Ihmiset ovat haluttomia luottamaan uusiin algoritmeihin. Joten miksi valitsimme tämän vaihtoehdon joka tapauksessa? Viimeisessä analyysissämme päätimme, että tämä oli parempi valinta tuotteellemme. Vaihtoehtojen suorituskyvyn nousu oli riittävän tärkeä ylittämään uuden diffuusori-algoritmin haitat. Aika näyttää, valitsimmeko oikein.
Alarivi. XTS on vähemmän muokattavissa kuin hajauttamaton CBC. CBC + Diffuser on kuitenkin todennäköisesti vähemmän muokattavissa kuin XTS, ainakin käytännön tarkoituksiin.
Tärkeä sivutapa. id = ”9f54c2e66d”>
CBC: tä tai XTS: ää ei ole suunniteltu muovattaviksi. Sen varmistaminen, ettei salakirjoituksia peukaloida, on erillinen ongelma, joka on ratkaistava käyttämällä MAC-koodeja, kuten HMAC-SHA256. Syyt MAC-tiedostojen käyttämättä tyypillisesti koko levyn salausalgoritmeihin ovat (1) suorituskykyongelmat ja (2) MAC: n käyttäminen edellyttää ylimääräisten tietojen tallentamista salaustekstiin, mikä tekee niiden lisäämisestä läpinäkyvästi hieman hankalaa.
Keskitie MAC-laitteiden ja diffuusorien välillä olisi käyttää laaja-alaista salaustilaa, kuten CMC, EME tai HEH. Voit ajatella näiden olevan ”sisäänrakennettu” diffuusori, mikä tekee niistä muovattomat. Toisin kuin Microsoftin diffuusori, näillä algoritmeilla on muodolliset turvallisuusmääritelmät ja vertaisarvioidut matemaattiset todisteet. Ne ovat turvallisia olettaen, että AES on turvallinen. Microsoft päätti olla käyttämättä näitä (1) suorituskykyongelmien ja (2) patenttien vuoksi.
Kommentit
- Levysalauksen yhteydessä yksinkertainen MAC-tiedostot eivät ole tarpeeksi hyviä '. Tarvitset ' hashtree-todennetun juuren.
- kiitos tästä upeasta vastauksesta !!! tämä teki kaiken selväksi … 5 *****
- Todennäköisesti tämä voitti ' t, mutta voitti ' t muovattavuuden ongelma voidaan ratkaista salaamalla sama tieto kahdesti eri salasanoilla ja / tai erilaisilla algoritmeilla? Joten sen sijaan, että käyttäisit todistamatonta diffuusori-algoritmia, miksi et käyttäisi todistettua AES: ää uudelleen?
- @Yura Se riippuu AES: n käytöstä (esimerkiksi XTS rakennetaan yleensä AES: n päälle). Jos käytät CTR-AES-tilaa kahdesti, tulos ei ' t muutu vähemmän muokattavaksi (bitin kääntäminen salaustekstissä kääntää silti vastaavan bitin selkeässä tekstissä). Jos käytät CBC-AES-tilaa kahdesti, voit silti tehdä saman hyökkäyksen, jonka mainitsin vastauksessani, mutta hallitsemattoman satunnaisen " roskan pituus " -osio kaksinkertaistuu. Lopuksi, AES: n käyttö suojatussa " wideblock " -tilassa olisi joka tapauksessa suunnilleen yhtä nopea kuin jompikumpi näistä ratkaisuista. Joten voi yhtä hyvin tehdä sen sijaan.
- Päivitys: Windows 10 tarjoaa mahdollisuuden käyttää XTS-tilaa. Vielä isompi / huonompi päivitys: Windows 8: ssa Microsoft POISTI hajottimen. Joten Windows 8 -bitlockerilla ei ole ' edes hajotinta.
Vastaa