Kysymys:
Epäsymmetriset vs. symmetriset salauksen vertailuarvot
user31481
2014-05-08 05:01:27 UTC
view on stackexchange narkive permalink

Olen löytänyt nämä vertailuarvot Crypto ++ -sivustolta. http://www.cryptopp.com/benchmarks.html

Mutta en ole rehellisesti sanottuna täysin varma siitä, miten niitä tulkitaan.

Etsin todella joukko vertailuarvoja tai tutkimusta, joka osoittaa, kuinka epäsymmetrinen salaus on hitaampaa (ja laskennallisesti kalliimpaa) kuin symmetrinen salaus.

Pohjimmiltaan jotain, joka vertaa heitä suoraan toisiaan vastaan ​​ja osoittaa epäsymmetristen salausten hitaampaa suorituskykyä.

Voisiko kukaan linkittää minut sellaiseen? Google-haut ovat osoittautuneet turhiksi.

Lähettämäsi linkki sisältää sekä symmetrisiä että epäsymmetrisiä operaatioita - mitä muuta etsit?
Hei @David. Kyllä, mutta minusta tuntuu, että heitä ei 'luokitella' samalla tavalla. Kuten sanotaan lopussa: ** MB / sekunti ** jokaisesta salauksesta, hash-funktiosta ja MAC: stä ja ** operaatiot / sekunti ** jokaisesta asymmetrisestä operaatiosta. Haluaisin jotain, joka vertaa niitä suoraan?
Epäsymmetrinen salaus tehdään yhdelle arvolle kerrallaan, symmetrisiä salauksia käytetään yleensä yhteen tai useampaan lohkoon. Koska ne eivät ole keskenään vaihdettavissa, on vaikea tehdä enemmän vertailua kuin asiakirjassa.
@David Näen. No, jos kirjoitan vastauksen näiden vertailuarvojen avulla, miten voisin perustella lausunnon, että "epäsymmetrinen salaus on hitaampaa ja laskennallisesti raskas kuin symmetrinen"? Kuinka voisin käyttää näitä tuloksia verrata niitä?
Symmetrisillä ja epäsymmetrisillä salauksilla on erilaiset tarkoitukset ja käyttötarkoitukset. Joten on turhaa verrata niitä, vaikka niiden suorituskyky olisi vertailukelpoinen.
Aiheeseen liittyvä kysymys CryptoSE: ssä: 2015-11-23: [* Kuinka epäsymmetrinen salaus tarkalleen on? *] (Https://crypto.stackexchange.com/questions/30777/exactly-how-slow-is-asymmetric-encryption)
Kolme vastused:
Tom Leek
2015-09-26 20:18:22 UTC
view on stackexchange narkive permalink

Itse asiassa väitteellä, jonka mukaan epäsymmetrinen salaus on hitaampaa kuin symmetrinen, ei ole paljon järkeä. He eivät tee samaa. Mitä epäsymmetrinen salaus tekee, symmetrinen salaus ei voi tehdä; vähemmän intuitiivisesti tämä toimii myös päinvastoin: mitä symmetrinen salaus tekee, epäsymmetrinen salaus ei voi tehdä.

Asymmetrinen salaus sallii salausavaimen julkistamisen paljastamatta salauksen avainta; tämä on epäsymmetrisen salauksen ilmeinen etu symmetriseen salaukseen nähden, ja syy miksi se keksittiin ensinnäkin.

Toiseen suuntaan: epäsymmetrinen salaus käsittelee vain rajoitetun kokoisia viestejä ja aiheuttaa kiinteäkokoinen yleiskustannus. Esimerkiksi 2048-bittisellä RSA-avaimella ja noudattaen PKCS # 1 -standardia ( RSAES-PKCS1-v1_5 ) syötesanomat eivät voi ylittää 245 tavua pitkä, ja silti tuottaa 256 tavun ulostulon. On epäselvää, kuinka pidempi viesti tulisi jakaa alaviesteihin, jotka käsitellään erikseen RSA: n kanssa; tämä näyttää pinnallisesti "ketjutus" -ongelmalta lohkosalaimilla, joille on määritelty toimintatilat, mikä sallii syötetietojen joukkokäsittelyn. Lohkosalaukset ovat kuitenkin helppoja: ne toimivat hienoilla bittisekvensseillä, ja salattuja lohkoja ei voida erottaa yhtenäisestä satunnaisuudesta. Sama ei päde esimerkiksi RSA: han, jossa salatut viestit ovat kokonaislukuja modulo iso kokonaisluku, joka ei ole 2: n teho, mikä aiheuttaa puolueellisuutta. Tätä RSA-salausten ketjutuksen ongelmaa ei ole tutkittu hyvin, eikä sillä näytä olevan ilmeisen turvallisia ratkaisuja.

Epäsymmetrisen salauksen yleiskustannukset ovat olennaisia ​​sen epäsymmetrialle: koska salausavain on julkinen, kaikki voivat yrittää salata tietoja salausavaimella. Jos salaus on deterministinen, se sallii välittömän raakavoiman hyökkäyksen selväkieliseen tekstiin (hyökkääjä yrittää mahdollisia selväkielisiä arvoja, kunnes osuma on löydetty). Tämän estämiseksi salauksen PITÄÄ olla ei-deterministinen, mikä puolestaan ​​merkitsee koon kasvua ( kyyhkysreikien vuoksi).

Raaka seuraus on, että epäsymmetrinen salaus ei ole hyvä joukkosalaus. Kun salattava data on suurempi kuin algoritmin alkeiskoko, emme todellakaan tiedä, miten se tehdään turvallisesti, mutta meillä on melko perustavanlaatuiset syyt uskoa, että se olisi kallista verkon kaistanleveyden kannalta.


Mikään yllä olevista ei koske laskennallisia kustannuksia. Laskennalliset kustannukset huomioon ottava mielekäs vertailu on tehtävä tilanteessa, jossa symmetrisen ja epäsymmetrisen salauksen välillä on todellakin valintaa. Pohjimmiltaan tämä olisi tilanne, jossa:

  • Haluat epäsymmetrisen salauksen viestille m.
  • Voit halutessasi käyttää ns. "hybridisalaus": epäsymmetrinen salaus satunnaisen avaimen K salaamiseksi, jota käytetään sitten tietojen käsittelyyn symmetrisen salausalgoritmin avulla.
  • Viesti m voidaan käsitellä suoraan epäsymmetrisen salausalgoritmin avulla.

Kolmas ehto tarkoittaa, että m on tarpeeksi pieni toimiakseen yhtenä epäsymmetrisen salausalgoritmin kutsuna, koska muuten et tiedä miten sitä käsitellään. Siinä tapauksessa raaka epäsymmetrinen salaus välttämättä voittaa, koska valinta on "yhden asymmetrisen salauksen" ja "yhden asymmetrisen salauksen ja jonkin verran symmetrisen salauksen välillä". Toisaalta, jos m koko voi olla suurempi kuin mitä voidaan käsitellä yhdellä kutsulla salausalgoritmille, olet palannut ketjutusongelmaan ja puhuminen suorituskyvystä on parhaimmillaan ennenaikaista: määritä ensin, mitä haluat tehdä, katso, onko se turvallinen, ja sitten (vasta sitten) voimme puhua nopeudesta.


Vertailun tekemiseksi: voit kysyä, mikä ajoneuvo on nopeammin, tämän välillä:

Red Ferrari

ja tämä:

Fishing boat

Jos luulet vastauksen olevan selvä, aja ajo Ferrarillasi järvelle ...

Käskitkö vain mennä kalaan?
Erinomainen vastaus ratkaistavaan ongelmaan, vaikka se väistääkin varsinaisen kysymyksen.
StackzOfZtuff
2015-07-16 19:09:33 UTC
view on stackexchange narkive permalink

Pois päältäni:

  • Yksi raaka RSA-viesti voi olla korkeintaan moduulin pituinen.
  • Yksi kypsennetty RSA-viesti vaatii täytteen ollakseen turvallinen . RSA PKCS # 1.5 -pehmuste tarvitsee vähintään 11 ​​tavua täytettä.

Ja oletan, että rsa2048. 2048 bittiä on 256 tavua raaka. Miinus 11 täyte antaa 245 tavua käytettäväksi.

CryptoPP-sivusto antaa:

  • RSA 2048 Allekirjoitus 6,05 millisekuntia / operaatio
  • RSA 2048 Vahvistus 0,16 millisekuntia / toiminta

Laskenta

  • RSA 2048 Allekirjoitus 6,05 millisekuntia / operaatio

    • (1000 ms / s) / (6,08 ms / op) == 164,47 op / s
    • 164,47 op / s * 245 tavua / op == 40296 tavua / s
  • RSA 2048 -varmistus 0,16 millisekuntia / toiminta

    • (1000 ms / s) / (0,16 ms / op) == 6250 op / s
    • 6250 op / s * 245 tavu / op == 1 531 250 tavua / s

Joten: Noin 1,5 Mt / s tarkistusta (/ salausta) varten. Ja 40 kt / s merkille (/ salauksen purkamiselle).

Ja "AES / CTR (128-bittinen avain)" CryptoPP-taulukossa on noin 100 Mt / s.

Erinomainen vastaus kysymykseen, vaikka se väistääkin ratkaistavan ongelman.
Olen eri mieltä. OP halusi * jotain, joka vertaa heitä suoraan toisiaan vastaan ​​ja osoittaa epäsymmetristen salausten hitaampaa suorituskykyä. * Vastaukseni tekee niin. Katso Tom Leekin ja Markin vastauksista, miksi suoralla pistolla ei ole mitään järkeä. ;)
Mark
2014-12-17 11:51:41 UTC
view on stackexchange narkive permalink

Symmetrisiä salakirjoja (jopa niitä, joita kuvataan nimellä "lohkosalaus") käytetään yleensä virran kaltaisella tavalla, salaamalla tai purkamalla mielivaltaisen pituisten tavujen sarja. Niiden nopeuden mittaaminen MB / s: ssä on siis hyödyllinen asia.

Epäsymmetrisiä salauksia käytetään yleensä lohkomaisesti, salaamalla tai purkamalla yksittäinen pieni pala tietoa. Tämä toiminto vie saman määrän aikaa riippumatta siitä, onko kyseessä yksi bitti, 32-tavuinen hash vai enimmäiskokoinen lohko. Näin ollen niiden nopeuden mittaaminen operaatioissa on hyödyllinen asia.

Voit selvittää epäsymmetrisen salauksen virtauksen kaltaisen nopeuden selvittämällä sen maksimilohkon koon ja kertomalla toiminnan nopeudella. / s. Koska epäsymmetrisiä salauksia ei melkein koskaan käytetä suoramaisesti, tämä ei ole kovin hyödyllinen asia.



Tämä Q & A käännettiin automaattisesti englanniksi.Alkuperäinen sisältö on saatavilla stackexchange-palvelussa, jota kiitämme cc by-sa 3.0-lisenssistä, jolla sitä jaetaan.
Loading...