Hat igen. Ezzel a birkakat ( 99%-a a felhasznaloknak ) majd jol megvezetik merthogy ha a gugli titkosit ami annyit jelent, hogy elzarnak mindent egy fiokba es naluk lesz a kulcs az NSA-nak csak szepen el kell kernie...

New level... Advertising has us chasing cars and clothes, working jobs we hate so we can buy shit we don’t need

valószínűleg elkészült hozza a hátsó ajtó vagy a masterkulcs az NSA számára is.

Amazon.co.uk, £50 értékű Gift Card cserélhető/eladó

Amig nyilt forrású marad, addig rendben van, dicséretes.

Nincs rendben akkor sem mert egy kompromittalodott szolgaltato vezeti ezt be ez azt nem fogod latni, hogy a kulcsoddal mi tortenik hol tarolodik ( valoszinusitem a google-nal lesz vagy lesz egy master kulcs amivel visszaallithatnak hiszen barmikor szukseged lehet majd az elvesztett kulcsod miatt a leveleidre )

New level... Advertising has us chasing cars and clothes, working jobs we hate so we can buy shit we don’t need

Ez így van.

Eddig hogy ment a kommunikáció? titkosítatlanul. Ezentúl lesz titkosítás. Szemetek.

"Odamentem egy párhoz...négyen voltak!"

"azt nem fogod latni, hogy a kulcsoddal mi tortenik hol tarolodik"

Nem vagyok programozó, de szerintem ha elérhető az alkalmazás forráskódja, akkor egy valamire való programozó szerintem ki tudja bogarászni belőle, hogy pontosan mi történik a kulccsal, miután azt legenerálta a saját számítógépünk.

Amúgy én is szívesen használnék olyan titkosított e-mail szolgáltatást, mint mondjuk a Protonmail, de őszintén szólva nem volt még olyan e-mail beszélgetésem, amit rejtegetnem kéne a Google vagy akár az NSA elől.

Ami működik, ahhoz nem nyúlunk.

Anelkul, hogy tulsagosan vedenem a GMailt (koztudottan nem kedvelem a szolgaltatast):

- ez egy nyilt forrasu, potencialisan auditalhato szoftvernek latszik
- a kulcsok lokalisan, a kliensnel tarolodnak

Manapsag is leteznek 'feltorhetetlen' titkositasok, ha ezt a szoftvert neves biztonsagi szakertok megnezik, es leokezzak, akkor valoszinuleg nem lesz vele nagy gond. (Ha emlekeztek, pl. a DUAL EC-PRNG-rol mar bevezetesekor sem gondoltak tul jokat a bizonsagi szakemberek.)

while (!sleep) sheep++;

"A Google épp azt várja a nyilvánosságra hozataltól, hogy a fejlesztők, tesztelők segítségével még jobbá tehetik a szoftvert. Amikor elkészül, a felhasználók majd a Chrome Web Store-ból tölthetik le."

Adj játékszert az Anonnak!

> valamire való programozó szerintem ki tudja bogarászni belőle

Ez igy nem igaz azert. Attol, hogy valaki jo programozo, nem biztos, hogy meg tudja allapitani, hogy pl. egy veletlenszamgenerator tenyleg kriptografikusan biztonsagos PRNG-e vagy sem.

while (!sleep) sheep++;

Oke. A nyakam rateszem hogy lesz benne olyan feature amit emlitettem. ( kulcs elvesztesekor visszaallitas )
Innentol meg keszen is vagyunk mint a mateklecke.
Ez olyan mint amikor nalunk a felhasznalo titkosit valamit es elveszti a kulcsot de ugye ADDS-ben nalunk le van tarolva ezert vissza lehet allitani ha moricka elbasz valamit. De ugye ez azt jelenti, hogy EN mint network GOD ha visszaelnek a munkakorommel azt nezhetnek meg amit akarok.
Szoval ez csak egy szinjatek es semmi koze nincs ahhoz hogy a google mit fog hasznalni titkositasi algoritmusnak meg hogy ki mit nez/nezhet meg a kodban.
Plane hogy a titkosito algoritmusok programozasa es mukodesuk megertese olyan szinten messze esik egy mas teruleten tevekenykedo programozoi munkatol mintha laci bacsi muhelytapasztalatat es a belsoegesu motorokhoz erteset hasonlitanank ossze egy Forma 1-es mernokevel.

New level... Advertising has us chasing cars and clothes, working jobs we hate so we can buy shit we don’t need

> A nyakam rateszem hogy lesz benne olyan feature amit emlitettem.

Csak el kene olvasni a nem tul hosszu leirast, es latnad, hogy nem lesz.

Ceges kornyezetben nyilvanvalo modon szukseg van key escrow-ra, itt nincs.

while (!sleep) sheep++;

Perszepersze. Nem lesz mikor kiadjak, ezzel egyetertek. Aztan mikor megy a panaszaradat hogy reinstalltam a gepem es nem latom a regi leveleimet akkor majd benne lesz egyeni es uzleti gmailt hasznaloknak ugyszinten.

New level... Advertising has us chasing cars and clothes, working jobs we hate so we can buy shit we don’t need

Te most egy jovobeli, elkepzelt szcenariot kifogasolsz, ezzel nyilvan nem tudok vitatkozni, mindenki azt kepzel el, amit akar. (Egyebkent nem lesz, mert az onnantol pontosan olyan biztonsagos lenne, amilyen most -- ok sem nezhetik _total_ hulyenek a mediat, csak leegetnek vele magukat.)

while (!sleep) sheep++;

Amíg a kulcsok lokálisan tárolódnak (márpedig így van, és mivel a Chrome kiegészítők is nyílt forrásúak, ezért valószínűleg nem tudnák eltitkolni, ha változna), addig nem. Pont.

Az persze más kérdés, amit emvy is felhozott, hogy mint már láttunk rá példát, lehet gyengíteni a titkosítást, de bízom benne, hogy ez előbb-utóbb kiderülne (és akkor a Gmail jó híre bánná...).

[ Szerkesztve ]

Van jó híre?

while (!sleep) sheep++;

Igy van paranoias vagyok szerintem ezt tudod mar regebbi topicokbol . De legalabb nem arrol akarlak meggyozni, hogy mindenki mas hulye csak en vagyok helikopter.
Nalam a google mar reg leszerepelt es kerulom a szolgaltatasait ahol tudom es probalok meggyozni mindenkit akit tudok

New level... Advertising has us chasing cars and clothes, working jobs we hate so we can buy shit we don’t need

Attól még, hogy nyílt forrású a kulcskezelés lehet problémás...

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

OpenPGP-re épül, a kulcsokat helyben tárolja, azok nem kerülnek elküldésre sehová.

És hogy osztod meg a kulcsokat az ismerőseiddel, ismeretlenekkel? Hogy validálják az esetleges visszavonást? Mit kezd a szoftver a lejárt vagy érvénytelenített kulcsokkal titkosított tartalommal?
Enged-e titkosítani már nem érvényes kulcsra?

[ Szerkesztve ]

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

Ez egy eleg korai verzio, es nyilvan nem all rendelkezesre az a trust chain, ami az altalad vagyott szolgaltatasokhoz kell. A megosztas az nyilvan megoldhato.

[ Szerkesztve ]

while (!sleep) sheep++;

Nem csak az általam vágyott...
Titkosítás megbízhatóság nélkül csak egy játékszer. Parasztvakítás, ha úgy tetszik.

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

Oo, nem egeszen stimmel szerintem, amit mondasz. Amit ez a kiegeszites iger, az az, hogy ket GMail-es emailfiok kozott at tudsz kuldeni ugy egy uzenetet, hogy harmadik fel ezt nem olvashatja el. Ezt teljesitheti ezzel az architekturaval: a publikus kulcsodat akar papiron odadhatod a baratodnak, aki importalja a keyringbe, es onnantol kuldhetsz bizalmas uzeneteket. A kulcsok termeszetesen rendelkezhetnek lejarati idovel, ez szinten megoldhato 'egyszeruen'.

Szoval valojaban masodszor atgondolva tudhat kb. mindent, amit szeretnel. Trusted 3rd partyra meg szukseg van ahhoz, out-of-band kulcscsere nelkul elhihesd, hogy a masik fel tenyleg az, akinek mondja magat.

while (!sleep) sheep++;

Igazabol ha akarok most is tudok pgp-vel levelezni. Van ra bejaratott modszer es nem egy rocket science beuzemelni sem...

New level... Advertising has us chasing cars and clothes, working jobs we hate so we can buy shit we don’t need

Szerintem nem arról szól, hogy ezentúl googlenál általad megadott kulccsal titkosítva tárolódnak a leveleid, hanem a csatorna amin oda kerül van titkosítva. Amit nem is értek, mert https-en megy, akkor azon mit akarnak még titkosítani? Titkosítják a küldendő adatot ami titkosított csatornán megy?

"És hogy osztod meg a kulcsokat az ismerőseiddel, ismeretlenekkel?"

Azt ugye tudod, hogy ketfele kulcs van: a titkos meg a nyilvanos? 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.

"Hogy validálják az esetleges visszavonást?"

(stb)

Mivel az egesz az openPGP-re epul, es abban mar ott vannak ezek a mechanizmusok, eros a gyanum, hogy azt is fogjak felhasznalni.

(#28) Ribi: de, pont arrol van szo, hogy maga az email lesz titkositva ugy, hogy azt csak a cimzett a sajat gepen tudja dekodolni, a GMail egyaltalan nem fogja latni a plaintextet. A titkositott csatorna eddig is megvolt, mar eleg regen csak https-en mega gmail.

[ Szerkesztve ]

DRM is theft

Ja hogy beleteszik azt a titkosítási lehetőséget amit eddig kb. minden levelező tudott? Jobb későn mint soha.
dabadab: Időközben megvilágosodtam, csak valami újítást reméltem, nem egy évtizedek óta használt dolog implementálását.

Bár persze jó kérdés ilyenkor a kulcsok tárolásának biztonsága, mert anélkül az egész nem sokat ér.

[ Szerkesztve ]

Igazabol az email titkositasat (marmint a technikai reszt) a PGP megoldotta ket evtizeddel ezelott, az a resze rendben van a dolgoknak, csak eppen senki sem hasznalta, mert soha senkinek nem sikerult kellokeppen maceramentesre megcsinalni a user interface-t.

DRM is theft

nagyjából erről van szó
(a Google-lal kapcsolatos jogos aggodalmaink meg más tészta, de úgy látom, a nyílt forrás elég szépen kiüti ezeket ebben az esetben)

"fácánjava calvadosban/teljesítünk, egyre jobban " - Konok Péter

Több gép használata esetén hogy néz ki a folyamat? Ha így, kódolva küldök valakinek egy levelet, akkor ő megkapja a szükséges kódokat az olvasáshoz, automatikusan kódolva kapom tőle a válaszleveleket is, kvázi titkosított csatornát nyitva egymás között, vagy minden levél esetén külön kell ezt szabályozni?

> 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++;

Minden gepnel rendelkezned kell a privat kulcsoddal ha olvasni akarsz illetve annak a publik kulcsaval akinek kuldeni akarsz.

New level... Advertising has us chasing cars and clothes, working jobs we hate so we can buy shit we don’t need

Kozben megtalaltam a Wikipedian is, ha valakit meg erdekel:

Another potential security vulnerability in using asymmetric keys is the possibility of a "man-in-the-middle" attack, in which the communication of public keys is intercepted by a third party (the "man in the middle") and then modified to provide different public keys instead. Encrypted messages and responses must also be intercepted, decrypted, and re-encrypted by the attacker using the correct public keys for different communication segments, in all instances, so as to avoid suspicion. This attack may seem to be difficult to implement in practice, but it is not impossible when using insecure media (e.g. public networks, such as the Internet or wireless forms of communications) – for example, a malicious staff member at Alice or Bob's Internet Service Provider (ISP) might find it quite easy to carry out. In the earlier postal analogy, Alice would have to have a way to make sure that the lock on the returned packet really belongs to Bob before she removes her lock and sends the packet back. Otherwise, the lock could have been put on the packet by a corrupt postal worker pretending to be Bob, so as to fool Alice.

One approach to prevent such attacks involves the use of a certificate authority, a trusted third party responsible for verifying the identity of a user of the system. This authority issues a tamper-resistant, non-spoofable digital certificate for the participants. Such certificates are signed data blocks stating that this public key belongs to that person, company, or other entity. This approach also has its weaknesses – for example, the certificate authority issuing the certificate must be trusted to have properly checked the identity of the key-holder, must ensure the correctness of the public key when it issues a certificate, and must have made arrangements with all participants to check all their certificates before protected communications can begin. Web browsers, for instance, are supplied with a long list of "self-signed identity certificates" from PKI providers – these are used to check the bona fides of the certificate authority and then, in a second step, the certificates of potential communicators. An attacker who could subvert any single one of those certificate authorities into issuing a certificate for a bogus public key could then mount a "man-in-the-middle" attack as easily as if the certificate scheme were not used at all. Despite its theoretical and potential problems, this approach is widely used. Examples include SSL and its successor, TLS, which are commonly used to provide security for web browsers, for example, so that they might be used to securely send credit card details to an online store.

Ugyebar itt a potencialis MITM es a trusted 3rd party is a Google. Nyilvan eleg latvanyosan le lehetne vele bukni, ha megprobalkoznanak ezzel, tehat gyakorlatban en nem tartom ezt realis veszelynek (egy kulonallo csatornan A es B egyeztetnek a publikus kulcsokat, es egybol kiderulne a dolog).

while (!sleep) sheep++;

A hozzaerto kevesek mar tobb mint egy evtizede hasznaljak. Jomagam talan 98 ban hasznaltam eloszor titkositott levelezest.

New level... Advertising has us chasing cars and clothes, working jobs we hate so we can buy shit we don’t need

MITM ha jól sejtem leginkább csak SSL és hasonló szimetrikus kulcsokkal megvalósítható, mert ha én betitkosítom A publikus kulcsával a levelet, azt vissza csak A privát kulcsával lehet fejteni. Emiatt bárki tud neked levelet küldeni, de elolvasni azokat csak te tudod. MITM emiatt emailben nem igazán lehetséges. Cserébe ha már itt tartunk MITB valószínűbb, mert ugye az google termék lesz, így hiába titkosítasz bármit bármivel, ha a browser necces akkor hiába az egész.

Email támadások esetén nyilván megy a MITM, de ebben az esetben rohadtul nem érdekli a küldött levél tartalma, csak az, hogy a küldött emailben legyen valami csúnyaság. De ez meg már víruskergető téma, nem levél tartalom biztonság.

[ Szerkesztve ]

MITM ugy lehetseges, hogy te csak azt hiszed, hogy A publikus kulcsat hasznalod, valoban viszont C-et.

DRM is theft

Jaaa. Hát de ahhoz azért igencsak be kell épülni a rendszerbe, hogy az SSLt és a tanúsítványt is lecseréld. Hogy sikerül A publikus kulcsát kicserélni C-re?

Ugy, hogy a kulcscsere pillanataban mar ott vagy. Tehat

A ket fel ezt gondolja:
A <-csatorna-> B

Valojaban:
A <- csatorna - C - csatorna -> B

A elkuldi a publikus kulcsat B-nek, de ezt elkapja C. C general egy publikus kulcsot, elkuldi B-nek. B azt hiszi, hogy A publikus kulcsat kapta meg. Ugyanez lezajlik visszafele. Innentol A titkositott uzeneteket kuld B-nek, azt gondolvan, hogy B publikus kulcsaval titkosit, de valojaban C-jevel teszi ezt. Menetkozben C elkapja az uzenetet, dekodolja, (potencialisan megvaltoztatja,) ujrakodolja a sajat privat kulcsaval, es elkuldi B-nek. B dekodolja az uzenetet C publikus kulcsaval.

(Valojaban ez nem igy zajlik, mert a valo eletben a publikus/privat kulcsokat csak a handshake eseten hasznaljak, amikor elkuldik a szimmetrikus kulcsot a masik felnek, de a dolog nyilvan ettol meg ugyanugy sebezheto a fenti modon.)

Termeszetesen egy GMailen belulre korlatozott uzenetkuldo rendszernel a Google tokeletesen jatszhatna C-t, viszont egy masik csatornan keresztul torteno kulcs-egyeztetes gyorsan lebuktatna.

[ Szerkesztve ]

while (!sleep) sheep++;

Ez oké, inkább az érdekel, hogy ezt kb akkor lehet ha ezt valaki figyeli, vagy totál beautomatizálnák egy domainre. És akkor is tényleg valahol az ISPnél kell.

Mi nem?

while (!sleep) sheep++;

Ezert kell a kulcsot mas csatornan eljuttatni az emberednek es nem valahova publikalni.

New level... Advertising has us chasing cars and clothes, working jobs we hate so we can buy shit we don’t need

A publikacio lehet egy jo megoldas, peldaul a Bitcoin alatt is mukodo blockchain-be publikalni publikus kulcsokat. Hm, van mar ilyen?

while (!sleep) sheep++;

Ennyi vannabe titkosügynök jár a PH-ra? Mer nekem pl. sajnos semmi okom nincs azon aggódni, hogy az NSA megnézi a gmail-os leveleimet.

Asus P8H67M-LE; i5 3330; 2x4GB DDR3; Gigabyte GTX 1060 3GB WINDFORCE OC

Hogy a G nem bukna le a lenti MITM sema eseten? Hat de, mert ha A es B osszenezne egy masik csatornan a publikus kulcsokat, akkor latnak, hogy valami nem stimmel.

while (!sleep) sheep++;