Új hozzászólás Aktív témák

  • emvy

    nagyúr

    válasz dabadab #29 üzenetére

    > Az utobbit az, amit meg kell osztani es ennek a megosztasa nem jelent biztonsagi a problemat, a helyi tarolasnal nyilvan a titkos kulcsrol van szo.

    En felteteleztem, hogy nem errol van szo, ill. hogy nem errol kerdez. A nyilvanos kulcs termeszetesen publikalhato es megoszthato, de ennek a megosztasnak a modja sem trivialis, mert ha valaki odaallit Alice-hoz, hogy 'en vagyok Bob, itt a nyilvanos kulcsom', akkor Alice-nek el kell hinnie, hogy Bob valoban az, akinek mondja magat, es ez a resz igenyel nemi kozremukodest valami trusted 3rd party reszerol (ugyebar pl. SSL certifikaciok eseten ezek a root certificate providerek). Ebben az esetben ez a fel a Google, aki igy vagy ugy de garantalni probalja, hogy ha bob@gmail.com-rol kapsz egy levelet, az tenyleg bob es nem valami man-in-the-middle. Ha Bob privat kulcsa kompromittalodik, akkor a Google-nek biztositania kell valamilyen mechanizmust arra, hogy a publikus kulcsat ervenytelenitsek, satobbi.

    Tehat sztanozs-nak olyan ertelemben jogosak a fenntartasai, hogy az E2E pluginnek az SSL-certifikaciokhoz hasonlo mechanizmus kellene (minimum) implementalnia, hogy ezeket a funkciokat biztositsa.

    Egy kritikus pelda egyebkent, Pali - ez a te hozzaszolasodra is tobbe-kevesbe valasz: ha ket GMail user meg sosem levelezett egymassal, es a Google-n kivul nincs mas ut ahhoz, hogy elerjek egymast, akkor nem nagyon van mod arra, hogy teljesen bizalmasan kommunikaljanak. A ket fel ugyanis publikus kulcsot kell, hogy csereljen, a publikus kulcsot pedig valahogy meg kell osztani egymassal. A publikus kulcs cserejekor a Google eljatszhatja azt, hogy Apk publikus kulcsot G1pk publikus kulccsal helyettesiti, es elkuldi B-nek. B elkuldi a sajat Bpk publikus kulcsat, amit a Google G2pk publikus kulccsal helyettesit, es innentol vegig MITM-t jatszik.

    Legalabbis ha jol gondolom.

    [ Szerkesztve ]

    while (!sleep) sheep++;

Új hozzászólás Aktív témák