Open Whisper brengt desktopclient voor beveiligde chatapp Signal uit

Open Whisper Systems heeft een desktopclient uitgebracht voor zijn beveiligde chatapp Signal. De client werkt niet standalone, maar is een Chrome-toepassing die in de Chrome Web Store zal komen te staan. Donderdag is de bèta uitgekomen.

De testversie is echter niet zomaar te installeren, maar Open Whisper Systems vereist dat gebruikers zich aanmelden voor de bèta via de site, waarna ze in een wachtrij komen. Bovendien moeten gebruikers momenteel Signal gebruiken op een Android-telefoon. De ondersteuning voor iOS volgt later. De broncode van de desktopclient staat op GitHub.

Signal gebruikt end-to-end-encryptie, wat inhoudt dat informatie door de verzender wordt versleuteld en alleen door de ontvanger gelezen kan worden. Het maakt voor berichten gebruik van het TextSecureprotocol met deniability en forward secrecy. Dit betekent onder andere dat niet kan worden bewezen dat er een onversleuteld bericht bestaat en dat een gekraakte sleutel er niet toe leidt dat eerdere berichten ook te lezen zijn. Er wordt geen gebruikgemaakt van diensten van derden.

Het feit dat Signal end-to-end-encryptie gebruikt, betekent nog niet dat de communicatie honderd procent veilig verloopt. Het is alleen zo veilig als het apparaat dat voor die communicatie wordt gebruikt. Klokkenluider Edward Snowden laat via Twitter weten dat hij Signal dagelijks gebruikt.

Reacties (44)

[Beuzelarij]

Klokkenluider Edward Snowden laat via Twitter weten dat hij Signal dagelijks gebruikt.

Ik ben erg benieuwd in welke 'variant' Snowden Signal gebruikt. Signal is open source, dus eenieder kan de broncode nakijken en controleren of er backdoors o.i.d. aanwezig zijn. Voor iemand in de positie van Snowden natuurlijk cruciaal.

Opmerkelijk is echter dat het voor de push-functionaliteit van het officiële Signal op Android vereist is dat Google Cloud Messaging, en dus Google Play Services, op je toestel aanwezig is. Daar worden door sommigen logischerwijs veel vraagtekens bij gezet, maar Moxie Marlinspike heeft daar nooit een echt goed antwoord op gegeven, en de discussie daaromtrent simpelweg afgekapt. Zie https://github.com/WhisperSystems/TextSecure/issues/127

Het is raar dat een messenger die als speerpunten veiligheid en privacy heeft, voor volledige functionaliteit de voorwaarde hanteert dat Google Cloud Messaging en Google Play Services op het toestel aanwezig dienen te zijn. Dat valt niet met elkaar te rijmen.
Ook al hoef je daarbij geen Google-account aan te maken, je hebt die spyware(?) wel aan boord. Vraagteken omdat je niet weet wat GCM allemaal uitvreet, omdat het immers niet Open Source is.

Toch is Textsecure/Signal ook te gebruiken zonder GCM. Omdat het Open Source is, kan het makkelijk geforked worden, en dat is dan ook gedaan. F-Droid (dat geen software wil opnemen met afhankelijkheid van Google Play Services, GCM, of iets dergelijks) heeft uiteindelijk besloten om deze fork niet zelf op te nemen, zie topic https://f-droid.org/forums/topic/textsecure/ , maar je kunt de fork zelf eenvoudig toevoegen aan F-Droid: https://fdroid.eutopia.cz/. Deze fork gebruikt WebSocket in plaats van GCM.

Dit roept nog meer vraagtekens op bij de keuze van Moxie Marlinspike: Hij schrijft dus een heel mooi stukje software, dat omdat het Open Source is ook door iedereen gecontroleerd kan worden, maar blijft daarbij tegelijk hardnekkig vasthouden aan afhankelijkheid van gesloten Google-techniek (dat zijn geld voornamelijk met persoonsgegevens verdient), terwijl er een prima functionerend alternatief voorhanden is.
Je kunt als gebruiker weliswaar (laten) controleren of Textsecure/Signal via GCM iets kwaads in de zin heeft, dat zal vrijwel zeker niet het geval zijn anders was dat wel ontdekt, maar feit blijft dat je niet weet wat dat GCM allemaal buiten Textsecure/Signal om uitvreet.

Jammer, maar in zijn geval wel begrijpelijk, dat Snowden in zijn tweet niet precies aangeeft hoe hij Signal gebruikt, maar het lijkt mij niet erg waarschijnlijk dat het de officiële variant i.c.m. GCM is. Misschien wel de officiële variant maar dan zonder GCM, waarbij hij afziet van de push-functionaliteit en op gezette tijden zelf berichten checkt. Waarschijnlijk zal ie toch niet permanent online zijn.

[YaPP]

Opmerkelijk is echter dat het voor de push-functionaliteit van het officiële Signal op Android vereist is dat Google Cloud Messaging, en dus Google Play Services, op je toestel aanwezig is. Daar worden door sommigen logischerwijs veel vraagtekens bij gezet, maar Moxie Marlinspike heeft daar nooit een echt goed antwoord op gegeven, en de discussie daaromtrent simpelweg afgekapt. Zie https://github.com/WhisperSystems/TextSecure/issues/127

bull.

Gezien de thread heeft hij daar heel uitgebreid antwoord op gegeven heeft, en meerdere malen uitlegt waarom hij FDroid en Cyanogenmod heel onveilig vind - en de play store veiliger is voor de gewone gebruiker. Het is een compromis, waarbij hij de focus heeft voor gewone gebruikers die niet custom dingen kunnen installeren.

Signal vereist Play services omdat:
* deze fatsoenlijke key signing hebben
* updates veilig doorvoeren. Developers kunnen offline packages signen, FDroid signt zelf alle packages en is dus vatbaar voor hackpogingen en MTM aanvallen.
* geen run-as-root processen hebben zoals Cyanogenmod.

Signal draait daarom veiliger op Google's Android dan op de alternatieven. Als commenters die feiten blijven negeren om hun wensen te blijven doordrammen, zal ik mijn geduld ook verliezen en de discussie sluiten.

[Reactie gewijzigd door YaPP op 28 juli 2024 10:56]

[Beuzelarij]

Gezien de thread heeft hij daar heel uitgebreid antwoord op gegeven heeft, en meerdere malen uitlegt waarom hij FDroid en GCM heel onveilig vind

Waarom dan toch zo halsstarrig blijven vasthouden aan GCM wanneer je dat onveilig vindt?

en de play store veiliger is voor de gewone gebruiker. Het is een compromis, waarbij hij de focus heeft voor gewone gebruikers die niet custom dingen kunnen installeren.

Alsof het ene het andere uitsluit...
Het punt is niet zozeer het uitbrengen in de Play Store, maar de afhankelijkheid van GCM. Vervang, net als in genoemde fork, GCM door WebSocket. Dat is alles!
Ook dan kun je die app gewoon in de Play Store zetten voor de doorsnee gebruiker, en de losse apk bijvoorbeeld op je eigen website voor diegenen die geen Play Store (en GCM) op hun toestel (willen) hebben. Mensen die zelf zo'n apk willen installeren weten doorgaans best wat ze aan het doen zijn, zet ter controle de MD5-hash van de apk erbij.

Het is gewoon opmerkelijk. Hij schrijft op zich mooie software, maar altijd zitten er elementen aan vast die niet te controleren zijn. De afhankelijkheid van het gesloten Google-ecosysteem bij Signal zelf. De geclaimde versleuteling van Open Whisper Systems bij Whatsapp is al helemaal niet door gebruikers zelf te controleren, want daar is alles gesloten, plus ook daar is er weer de afhankelijkheid van het gesloten Google-ecosysteem voor de push-berichten.
Nogmaals, Signal is een toepassing met als speerpunten privacy en veiligheid. Het zou minder raar zijn als er geen alternatieve methodes voorhanden zouden zijn, maar die zijn er dus gewoon!


Moxie Marlinspike bouwt als het ware ondoordringbare voordeuren. Iedereen mag dat ook controleren. Alleen vereist hij zelf dat om die mooie veilige voordeur goed te kunnen gebruiken, dat je tegelijk ook een gammel achterdeurtje in je huis inbouwt, waarvan je niet weet wie daarvan de sleutel heeft en wat er allemaal doorheen, in- en uitgaat.

[Verwijderd]

Goede ontwikkeling, maar is het nou zo dat om deze app op je desktop of laptop te gebruiken, je ook je telefoon in de buurt moet hebben? (net als die draak van een webversie van Whatsapp)

Zo ja, dan laat maar zitten ;{ Het grote voordeel van een desktop client of webversie vind ik juist dat je niet meer afhankelijk bent van je telefoon.

En dat kan prima veilig met end-to-end encryptie, en toch toegang hebben tot je berichten op al je devices, door je private encryptie key af te leiden uit een login + password (bijvoorbeeld).

[WhatsappHack]

En dat kan prima veilig met end-to-end encryptie, en toch toegang hebben tot je berichten op al je devices, door je private encryptie key af te leiden uit een login + password (bijvoorbeeld).

Zoals ik onder het andere artikel al aan je reageerde, lijkt het me niet dat dat ooit lekker gaat werken.
Daarnaast betekend wat jij wil dat ook al je berichten, inclusief end-to-end encrypted communicatie, in de cloud opgeslagen moet worden. ... Brrrrr, liever niet zeg!
Dan hebben ze *en* je sleuteltjes, *en* al je encrypted chats...
Nee dan heb ik toch liever dat die berichten totaal niet opgeslagen worden, behalve op m'n eigen toestel!

Als het aan login + password wordt gegenereerd, betekend dat dat al je gesprekken te decrypten zijn door je wachtwoord succesvol te achterhalen. Gezien dat wachtwoord opgeslagen meestal staat op de servers van de dienstverlener, is je encryptie theoretisch gezien geen donder meer waard; vooral als je niet weet hoe dat wachtwoord precies gehashed is, en hoe de server beveiliging in elkaar steekt.
Als het enkel om een "local password" gaat, dat je dus moet intikken *na ontvangst* van de sleutels zou het mogelijk een ander verhaal zijn... Ware het niet dat die sleutels alsnog in de cloud staan en iemand dus ook "local" kan gaan proberen te decrypten.
Ik haal het straks nog een keer aan, maar dat valt wel te vergelijken met het opslaan van een KeePass bestandje in een random cloud. Het is, mits je een heel sterk wachtwoord hebt, nagenoeg ondenkbaar dat die gekraakt wordt... Maar ALS ie gejat wordt: dan pas je toch liever de wachtwoorden die erin staan aan... En met goede reden. Het enige voordeel van zo'n bestand is dat je tijd zat hebt om je wachtwoorden aan te passen omdat ze het nooit in korte tijd kunnen kraken... Op de lange termijn: dat is echter het probleem.

Hetzelfde is hier eigenlijk van toepassing... Je kan al je sleutels wel leuk en met een super sterk wachtwoord encrypt naar een cloud sturen; maar vanaf dat moment hebben ze alle tijd om rustig te blijven proberen te brute-forcen. Maar die sleutels kan je niet meer wijzigen... Dat is niet zo'n prettig idee, tenzij die keys minstens 1 keer per jaar zouden wijzigen misschien. (Net als je wachtwoorden? )


Dan kan je nog per gesprek een wachtwoord instellen. Maar dan moet je per gesprek al die wachtwoorden onthouden, en deze ook nog eens delen met je gesprekspartner. (En hoe ga je dat doen dan...?) Dat is een stuk ongebruiksvriendelijker dan "je moet een verbinding actief hebben met je toestel."
Je zou wel de sleutels kunnen importeren naar een andere device, maar dat geeft 2 problemen:
1.) Als de sleutel vanuit "de cloud" zou worden geserveerd, blijkt dat die sleutels dus inzichtelijk zijn voor de dienstverlener.
2.) Als de sleutel vanaf een andere device moet komen (die dit uiteraard netjes end-to-end encrypt uitwisselen) moet je per device waar je je op wilt aanmelden alsnog een device bij de hand hebben die de sleutels naar je kan overpompen. En dat elke keer weer, voor elk gesprek weer. Lijkt me ook niet zo heel handig.

Wat wellicht wél weer zou kunnen (and the plot thickens...), is dat je sleuteltjes in de cloud worden opgeslagen met sterke encryptie en je deze kan binnenhalen op je device; waarna je je decryptie master-sleutel moet intikken. Dan is je wachtwoord alsnog het single point of failure, maar omdat het wachtwoord op geen enkele wijze bij de dienstverlener opgeslagen is, heb je wel een wat betere veiligheid; vergelijkbaar met bijvoorbeeld een KeePass bestand. (Maarja, als van mij een KeePass bestand gejat zou worden: dan zou ik alsnog alle wachtwoorden gaan wijzigen.)
Punt blijft dat als het wachtwoord ooit achterhaald wordt, al is het maar door een virus, door recycling of wat dan ook: dan worden *al* je gesprekken decrypt: want dan hebben ze meteen toegang tot al je sleutels van al je gesprekken! Walgelijk. Het is niet voor niets dat er per gesprek zo'n key wordt gegenereerd! En bij een KeePass bestandje kan je de wachtwoorden die erin staan nog eens wijzigen, maar bij al jou encrypted chats + alle sleutels kan dat achteraf NIET. Dus als iemand geduldig is (en rekenkracht neemt alleen maar toe.) dan kunnen ze uiteindelijk al jou communicatie lezen... Het kan wellicht een paar jaar duren: maar het kan wel. En de inhoud van je encrypted berichten? Die kan je NIET meer wijzigen! Dat is het grote verschil. Als ze na 10 jaar een password file weten te encrypten, dan hebben ze je wachtwoorden van 10 jaar geleden... Woopdidoo, als ze daar nog iets mee kunnen is dat geheel je eigen schuld, hehe. Maar als ze na 10 jaar al jou gesprekken weten te decrypten... Ai ai ai, dan is je encryptie dus in 1 klap waardeloos geworden.

Per gesprek een apart wachtwoord zou dan een nog betere optie zijn.
Nee, nee... Er is een reden dat diensten als Telegram geen cloud functionaliteit kunnen bieden bij secret-chats, en waarom diensten als WhatsApp en Signal (zelfde encryptie trouwens, vandaar zelfde systeem.) je forceren om een verbinding met je toestel open te houden... Al je sleutels opslaan in een cloud is gewoon een heel erg slecht plan, die moeten tussen de initiele devices uitgewisseld worden en daarmee klaar; nergens anders meer naar toe zenden, en al helemaal niet opslaan op een server!

Signal en WhatsApp zijn dan ook geen cloud diensten. Dat is ook heel erg prettig.
Dat zijn dus twee redenen om een verbinding met je toestel te eisen:
1.) Je berichten staan nergens anders dan veilig, encrypted, op je telefoon
2.) De end-to-end encryptie blijft functioneren, terwijl de sleutels je toestel *nooit* verlaten. (Na exchange )

Dit is gewoon een win-win oplossing...
Signal's uitvoering, en daarmee ook die van WhatsApp, is in mijn ogen gewoon de allerbeste oplossing... Het werkt, mensen kunnen bij hun berichten via andere devices.
Nee, het werkt niet super gebruiksvriendelijk... Maar kijk eens naar de veiligheid die er tegenover staat!

Ik heb liever de veiligheid van de webclient van WhatsApp en nu ook Signal (nogmaals: in principe hetzelfde systeem.), dan dat al m'n berichten (dus ook de end-to-end encrypted berichten) in een cloud buiten mijn controle worden opgeslagen, en m'n decryprtie sleutels daar blijkbaar ook nog bij worden opgeslagen... Ik bedoel... Encrypt dan gewoon niet.

Misschien vinden mensen m'n "cloud is evil" te overdreven hoor, maar ik zie dat echt niet zitten; en heb veel liever deze opzet van Signal...
(En final note: er zijn nog wel wat andere methodes, maar ik leg hier een aantal valkuilen en problemen bloot met wat jij voorstelt... Ik behandel niet alle opties (zowel gebruiks/ongebruiksvriendelijk). Maar het punt blijft gewoon dat opslag op externe locatie met zeer hoge veiligheid gewoon niet hand in hand kan gaan met gebruiksvriendelijkheid, en dan is dit van Signal/WhatsApp gewoon *de* oplossing om een middenweg te bewandelen.)

[Reactie gewijzigd door WhatsappHack op 28 juli 2024 10:56]

[Myliobatis]

Je e-mails heb je ook niet op een server staan? Of durf je daar alleen een klein risico voor te lopen en laat je ze direct verwijderen na het ophalen waardoor verschillende apparaten / software over fracties van je e-mails beschikken?

Persoonlijk heb ik via e-mail veeeel vertrouwelijkere informatie verstuurd dan welk chat programma dan ook. En nog bij Google ook, hoewel ik me wel oriënteer op alternatieven.

Deels begrijp je "cloud is evil" idee wel, maar net alsof er nooit iets op een server werd opgeslagen wat tegenwoordig heel hip en hype "cloud" wordt genoemd.

Trouwens, waarom zou het in de cloud opgeslagen moeten worden?
Een desktop applicatie kan toch prima op zichzelf draaien, zonder connectie met een smartphone, zonder cloudopslag, zonder Chrome extensie maar gewoon een "volledig" programma voor verschillende besturingssystemen (eventueel een Windows Universal App).
Gesprekken kunnen dan alleen (automatisch) niet gesynchroniseerd blijven, maar wel encryptie sleutels lokaal opgeslagen per device.

[Reactie gewijzigd door Myliobatis op 28 juli 2024 10:56]

[WhatsappHack]

Je e-mails heb je ook niet op een server staan? Of durf je daar alleen een klein risico voor te lopen en laat je ze direct verwijderen na het ophalen waardoor verschillende apparaten / software over fracties van je e-mails beschikken?

Op eigen servers met encryptie.

Persoonlijk heb ik via e-mail veeeel vertrouwelijkere informatie verstuurd dan welk chat programma dan ook. En nog bij Google ook, hoewel ik me wel oriënteer op alternatieven.

E-mail encryptie wordt helaas veels te weinig gebruikt, dat is wel jammer.

Deels begrijp je "cloud is evil" idee wel, maar net alsof er nooit iets op een server werd opgeslagen wat tegenwoordig heel hip en hype "cloud" wordt genoemd.

Klopt, cloud is een marketingterm voor iets dat al jaaaaaaren ervoor bestond.
Iedereen begrijpt echter waar je het over hebt als je de term gebruikt, dus dat scheelt.

Trouwens, waarom zou het in de cloud opgeslagen moeten worden?
Een desktop applicatie kan toch prima op zichzelf draaien, zonder connectie met een smartphone, zonder cloudopslag, zonder Chrome extensie maar gewoon een "volledig" programma voor verschillende besturingssystemen (eventueel een Windows Universal App).
Gesprekken kunnen dan alleen (automatisch) niet gesynchroniseerd blijven, maar wel encryptie sleutels lokaal opgeslagen per device.

Het niet synchroniseren tussen devices was nou net het probleem wat aangekaart werd...
Natuurlijk zijn er zat chat apps die enkel op je PC of enkel op je telefoon draaien, maar de stelling was: we moeten zorgen dat ze tussen alle devices synchroniseren zonder dat een van de andere devices actief moet zijn. Daar reageerde ik op.

[Verwijderd]

Zoals ik onder het andere artikel al aan je reageerde, lijkt het me niet dat dat ooit lekker gaat werken.
Daarnaast betekend wat jij wil dat ook al je berichten, inclusief end-to-end encrypted communicatie, in de cloud opgeslagen moet worden. ... Brrrrr, liever niet zeg!
Dan hebben ze *en* je sleuteltjes, *en* al je encrypted chats...
Nee dan heb ik toch liever dat die berichten totaal niet opgeslagen worden, behalve op m'n eigen toestel!

Ik heb net daar ook gereageerd op je

Nou en of dat prima 100% veilig kan werken. Berichten staan alleen encrypted op de server / in de cloud. Encryptie keys van de berichten staan óók alleen encrypted in de cloud, encrypted met de public keys van de gesprekspartners. Private keys van gesprekspartners staan nergens opgeslagen, die worden lokaal afgeleid uit login+password.

Als het aan login + password wordt gegenereerd, betekend dat dat al je gesprekken te decrypten zijn door je wachtwoord succesvol te achterhalen.

Correct.

Gezien dat wachtwoord opgeslagen meestal staat op de servers van de dienstverlener,

FOUT, de client stuurt alleen een hash naar de server, om bij later opnieuw inloggen (of vanaf een ander apparaat inloggen) die hash op te vragen en zo lokaal te kunnen checken of je password goed is. Is het goed, dan decrypt je client lokaal de berichten. Denk je slim te zijn met een geforgde client die ieder password goedkeurt, dan genereer je een andere private key en kun je de encrypted content van de server alsnog niet lezen.

Je kan al je sleutels wel leuk en met een super sterk wachtwoord encrypt naar een cloud sturen; maar vanaf dat moment hebben ze alle tijd om rustig te blijven proberen te brute-forcen.

Brute force is niet feasible. Die hele brute force mythe is wel het minste waar je je zorgen om hoeft te maken. Een simpele supersnelle sha256 (met salt) zou al volstaan. Dat brute forcen is echt volslagen ondenkbaar. Maar haal er even iets als Scrypt overheen waardoor het op een gemiddeld apparaat 1 seconde duurt om te hashen, en dan wordt het nóg eens een factor biljoen keer sterker (en kan bovendien meeschalen met sneller wordende hardware).

Maar die sleutels kan je niet meer wijzigen... Dat is niet zo'n prettig idee, tenzij die keys minstens 1 keer per jaar zouden wijzigen misschien. (Net als je wachtwoorden? )

Die sleutels kun je wel wijzigen. Je kunt je eigen password lokaal wijzigen, en de client zou de keys van de berichten waar jij toegang toe hebt, zelfs automatisch periodiek kunnen wijzigen.

Dan kan je nog per gesprek een wachtwoord instellen. Maar dan moet je per gesprek al die wachtwoorden onthouden, en deze ook nog eens delen met je gesprekspartner. (En hoe ga je dat doen dan...?)

Je client voegt gewoon een kopie van de gesprekskey toe voor iedere chatpartner, encrypted met diens public key. Ik hoef zelf natuurlijk niets te onthouden, alleen het ene password van mijn account.

Dat is een stuk ongebruiksvriendelijker dan "je moet een verbinding actief hebben met je toestel."
Je zou wel de sleutels kunnen importeren naar een andere device, maar dat geeft 2 problemen:
1.) Als de sleutel vanuit "de cloud" zou worden geserveerd, blijkt dat die sleutels dus inzichtelijk zijn voor de dienstverlener.
2.) Als de sleutel vanaf een andere device moet komen (die dit uiteraard netjes end-to-end encrypt uitwisselen) moet je per device waar je je op wilt aanmelden alsnog een device bij de hand hebben die de sleutels naar je kan overpompen. En dat elke keer weer, voor elk gesprek weer. Lijkt me ook niet zo heel handig.

Nee dus zie boven.

Punt blijft dat als het wachtwoord ooit achterhaald wordt, al is het maar door een virus, door recycling of wat dan ook: dan worden *al* je gesprekken decrypt: want dan hebben ze meteen toegang tot al je sleutels van al je gesprekken!

Zoals al uitgelegd kun je je wachtwoord dus wijzigen, en kan je client de gesprekssleutels zelf periodiek autoamtisch wijzigen, en je zou zelfs een soort forward secrecy kunnen doen door een sequence van decryptie keys lokaal te bewaren die je dan zelf eens in de zoveel tijd zelf moet backuppen, die verder nergens staan.
Dat is echt compleet paranoia, maar het zou desgewenst optioneel kunnen.

De rest van je bericht ging geloof ik niet uit van bovenstaand scenario. Als ik een chat app zou maken zou ik het zo doen in ieder geval.

[Verwijderd]

[...]
Nou en of dat prima 100% veilig kan werken. Berichten staan alleen encrypted op de server / in de cloud.
[...]

Het punt is dat alle encryptie methoden, ook de momenteel meest veilige, vroeg of laat te kraken zijn.

Als je je systeem zo inricht dat berichten opgeslagen worden dan is het heel makkelijk om die berichten (al dan niet per ongeluk) te laten staan, in een backup te zetten, of door een hacker/boze medewerker te laten kopieren. Deze berichten kunnen op termijn dan een risico vormen.

Voor veel toepassingen is dat een wellicht acceptabel risico, maar als je pretendeert de veiligste messenger te zijn dan past dat niet in het plaatje. Al was het maar omdat zogenaamde onveilige messengers zoals iMessage en Telegram's Securechat dat risico ook niet nemen.

[Verwijderd]

Voor veel toepassingen is dat een wellicht acceptabel risico, maar als je pretendeert de veiligste messenger te zijn dan past dat niet in het plaatje. Al was het maar omdat zogenaamde onveilige messengers zoals iMessage en Telegram's Securechat dat risico ook niet nemen.

Hoe voorkomen iMessage en Telegram's Securechat dat een boze medewerker expres in het geniep (of een domme medewerker, per ongeluk) op de server waar die berichten via worden verstuurd, toch een kopietje bewaart? Wat dan later deze eeuw als de encryptie gebroken is, rustig gekraakt kan worden.

[Verwijderd]

Helemaal te voorkomen is dat natuurlijk niet, maar het wordt ze in elk geval niet makkelijker gemaakt.

Als jij 2 maanden aan berichten wil kopieren zul je bij iMessage 2 maanden lang toegang tot de server moeten hebben. Bij een messenger die berichten opslaat heb je aan 1 minuut toegang waarschijnlijk al voldoende.

[Verwijderd]

Ook bij eenmalige toegang kun je natuurlijk iets in die server stoppen dat alle voorbijkomende berichten (zonodig nog eens encrypted met een andere key, voor onherkenbaarheid of plausible deniability) naar een externe server doorstuurt.

Ik heb persoonlijk meer vertrouwen in oerdegelijke encryptie (zonodig meerdere soorten encryptie cascaded over elkaar, de ketting is dan zo sterk als zijn sterkste schakel) dan in het uitsluiten van malafide of domme medewerkers, al dan niet onder druk van overheden of geheime diensten.

De aanname dat alle encryptie binnen afzienbare tijd gekraakt wordt, vind ik ook nog niet zo zeker. Als ik vandaag iets encrypt met Twofish, Salsa20, Serpent, XTea, Threefish, RC6, en AES over elkaar heen (allemaal met andere keys natuurlijk, die wel mogen zijn afgeleid met zware KDF's vanuit 1 lange seed), durf ik te wedden dat dat deze eeuw niet meer gekraakt wordt.

[Reactie gewijzigd door Verwijderd op 28 juli 2024 10:56]

[Armin]

allemaal met andere keys natuurlijk

Dezelfde keys is in diverse gevallen veiliger

Anders zijn de encrypties namelijk mathematisch onafhankelijk en vatbaar voor een 'Meet in the Middle' aanval waar men rekenkracht en opslagruimte kan uitwisselen.

Het idee van twee of meer lagen encryptie is een standaard concept (als rekenkracht geen rol speelt) om te voorkomen dat bij het kraken van één algorithme de inhoud meteen beschikbaar is.

Maar de vraag is natuurlijk hoe zinnig dat is. Hoe belangrijk is de data, en/of is er een tijdslimiet. In deze context, mijn super geheime chats over afspreken bij de Starbucks mag men best over 30 jaar lezen

[Verwijderd]

Ik weet niet of ik die 'Meet in the Middle' aanval helemaal begrijp
Als ik plaintext data heb, en die encrypt ik eerst met AES met key X, en die encrypted data encrypt ik vervolgens nog een keer met Salsa20 met key Y. In welk scenario zou het dan veiliger zijn (of resistenter tegen aanvallen) als x en y dezelfde keys zijn?

Merk op dat een aanvaller in deze situatie nog helemaal niets met de AES encrypted data kan doen, alvorens eerst de Salsa20 te hebben gekraakt (want tot die tijd is de AES encrypted data nog niet beschikbaar). En als het iemand al lukt om die tweede (buitenste) laag succesvol te decrypten, lijkt het me in alle opzichten veiliger als de AES laag daaronder niet met dezelfde key is versleuteld.

[Armin]

In welk scenario zou het dan veiliger zijn (of resistenter tegen aanvallen) als x en y dezelfde keys zijn?

Als je dezefde key gebruikt, zijn beide encryptie-algorithmen niet langer onafhankelijk.

Zijn ze wel onafhankelijk, kun je de één van de algorithmen kraken met een lookup table.

Het lijkt tegen-intuitief dat dezelfde sleutel minder veilig is, maar in sommige gevallen is dat zo. Crypto is hard

[Verwijderd]

In welk scenario zou het dan veiliger zijn (of resistenter tegen aanvallen) als x en y dezelfde keys zijn?

Als je dezefde key gebruikt, zijn beide encryptie-algorithmen niet langer onafhankelijk.

Zijn ze wel onafhankelijk, kun je de één van de algorithmen kraken met een lookup table.

Sorry daar begrijp ik niets van
Sterker nog, mijn eerste intuïtieve reactie is: daar geloof ik geen reet van, maar je lijkt goed te weten waar je het over hebt dus ik ben nu wel erg nieuwsgierig

Het kraken van een degelijk encryptie-algoritme met een lookup table zie ik niet voor me. Ik ken alleen rainbow tables, voor hashes van wachtwoorden zonder salt, maar fatsoenlijke encryptie (met ook een fatsoenlijke key) laat zich toch op geen enkele manier kraken met een lookup table?

Maar dan nog, wat bedoel je met onafhankelijk? Data die encrypted wordt met een bepaald algoritme en een bepaalde key, levert random garbage op. Twee verschillende algoritmes (bijvoorbeeld TwoFish en Serpent) leveren totaal verschillende garbage, ook al is de key toevallig hetzelfde.

Ook al zou je weten dat de binnenste laag met dezelfde key is encrypted als de buitenste, dan heb je nog steeds geen idee hoe de data na de eerste (binnenste) encryptielaag er uit ziet, dus helpt dat ook niets bij het kraken van de tweede (buitenste).
Maar met twee verschillende keys kun je helemáál niets zinnigs zeggen over die binnenste laag. Sterker nog, ook al zou je weten dat de binnenste laag is encrypted met AES en de key daarvan kennen, zelfs dan nog helpt dat niet bij het openbreken van de buitenste laag (mits die encrypted is met een andere key natuurlijk).

Correct me if I'm wrong

[Reactie gewijzigd door Verwijderd op 28 juli 2024 10:56]

[Armin]

Correct me if I'm wrong

Wikipedia geeft een goede uitleg.

"When trying to improve the security of a block cipher, a tempting idea is to simply use several independent keys to encrypt the data several times using a sequence of functions (encryptions). Then one might think that this doubles or even n-tuples the security of the multiple-encryption scheme, depending on the number of encryptions the data must go through."

Het artikel legt vervolgens uit waarom dat niet zo is.

[Verwijderd]

Ah juist, ja ik zie nu wat ze doen. Al begrijp ik nog niet helemaal waarom die attack met dezelfde keys geen optie zou zijn, DEC_k(C) is dan nog steeds gelijk aan ENC_k(P).

Maar die attack is met de opzet die ik beschreef sowieso geen optie. Het is waar dat je de search space van 2²ⁿ zou kunnen reduceren naar 2ⁿ⁺¹ bij encrypties met n-bit keys. Maar dat lijkt me irrelevant, aangezien 2¹²⁸ brute forcen al infeasible is (lees: volstrekt onmogelijk met hardware van vandaag de dag, ook met serverparken zoals die van google of overheden) en 2²⁵⁶ lijkt tot in lengte der dagen überhaupt nooit een optie te worden.

Verder heb je voor deze attack zelfs in het 'slechts' 128-bit geval al triljarden keren meer opslagruimte nodig dan er op aarde is. En voor een lookup table van 2²⁵⁶ is niet genoeg materie in het universum

Met meerdere 256-bit encrypties over elkaar zie ik dit dus nooit gebeuren. Het meest reële risico blijft toch dat er in een encryptie-algoritme vroeg of laat een zwakke plek wordt gevonden (wat ook tot informatie over de betreffende key zou kunnen leiden). In dat geval zit je met een stuk of 6 onafhankelijke encryptie lagen over elkaar dus extreem veilig.

[Kaastosti]

Wat ik heb gelezen is dat er nu al versleutelde data wordt opgeslagen om daar later, met quantum computing nog eens een poging tot decryptie te doen. Dat is natuurlijk nooit uit te sluiten. Vroeger was MD5 helemaal de bom, daar hoef je nu ook niet meer mee aan te komen.

Aan de andere kant... als jouw chats zo ongelooflijk gevoelig en belangrijk zijn om daar zoveel capaciteit aan te besteden, is het waarschijnlijker dat men je even persoonlijk opzoekt, telefoon afpakt en dwingt te unlocken (als dat al nodig is).

[Verwijderd]

Wat ik heb gelezen is dat er nu al versleutelde data wordt opgeslagen om daar later, met quantum computing nog eens een poging tot decryptie te doen. Dat is natuurlijk nooit uit te sluiten.

Da's waar, maar ook quantum computing is geen heilige graal. Sommigen lijken te denken dat straks met quantumcomputers ineens alles te kraken is, doordat alles exponentieel sneller kan. Dat is niet het geval. En bovendien nogmaals: natuurwetten

Aan de andere kant... als jouw chats zo ongelooflijk gevoelig en belangrijk zijn om daar zoveel capaciteit aan te besteden, is het waarschijnlijker dat men je even persoonlijk opzoekt, telefoon afpakt en dwingt te unlocken (als dat al nodig is).

Het over elkaar heengooien van een handje vol ijzersterke encrypties kost niet veel capaciteit, en ook geen opslag.

Maar het gaat vooral om het volgende. Mijn berichten zijn niet specifiek zo ongelooflijk gevoelig, en sowieso is geen enkele encryptie bestand tegen rubber-hose cryptanalysis of de bekende $5 wrench. Echter dat is op individueel niveau. Wat je wilt voorkomen is dat men semi geautomatiseerd alle encryptie kan slopen, en in één klap alle communicatie kan onderscheppen en iedereens privacy kan schenden. Het beruchte 'sleepnet data verzamelen' waar geheime diensten zo gek op zijn.

[Kaastosti]

Mee eens. Dat er in de toekomst technieken komen die de boel een stuk kunnen versnellen houdt niet in dat het automatisch een eitje wordt. Natuurwetten kunnen we inderdaad vooralsnog niet omheen.

Alle diensten waarvoor data centraal wordt opgeslagen krijgen hiermee te maken. Het is zoals gewoonlijk weer eens een trade-off tussen gebruikersgemak en veiligheid.

Persoonlijk vind ik het heel prettig dat ik Telegram schoon kan installeren en meteen terug kan zoeken in historie. Om dat te kunnen doen moeten gegevens inderdaad centraal worden opgeslagen, al is dat versleuteld. Als die versleuteling gekraakt kan worden, kunnen al die berichten gelezen worden.

Om een alternatief te bieden voor gevoelige info heb je dan ook Secret Chat, die alleen lokaal wordt opgeslagen. En sluit je 'm af, dan is het weg.

Je kunt jammergenoeg niet 100% van beide hebben. Meer gemak kost altijd veiligheid, meer veiligheid kost altijd gemak.

[vSchooten]

Het punt is dat alle encryptie methoden, ook de momenteel meest veilige, vroeg of laat te kraken zijn.

Als dat het geval is dan is het aan de developers telkens de nieuwere encryptie methodes te implementeren. Dit is overal zo, security staat nooit stil.

[Matthijs8]

Signal doet het beter dan WhatsApp:
https://moderncrypto.org/...essaging/2014/001022.html

[Matthijs8]

In tegenstelling tot bij WhatsApp, gaat de web/desktop versie niet via je telefoon.
https://moderncrypto.org/...essaging/2014/001022.html

[Verwijderd]

Dat klinkt al beter. Ik heb de web/desktop client nog niet geprobeerd (sta nog in de queue voor beta) maar ik ga hem zeker eens bekijken.

Hoop wel dat er snel universele support komt voor alle grote platforms, want tot die tijd is het interessant in theorie, maar geen werkbaar alternatief in de praktijk.

[Kura]

Goede ontwikkeling, maar is het nou zo dat om deze app op je desktop of laptop te gebruiken, je ook je telefoon in de buurt moet hebben? (net als die draak van een webversie van Whatsapp)

Zo ja, dan laat maar zitten ;{ Het grote voordeel van een desktop client of webversie vind ik juist dat je niet meer afhankelijk bent van je telefoon.

Hoop het niet. Maar als dit een veiligere app is is daar mee te leven. Bij Whatsapp / Facebook weet je dat alles 1 op1 doorgaat naar derde partijen en dan zit je nog met een gehandicapte webversie ook. Geen privacy + slechte interface. Dubbel gepakt

[Reactie gewijzigd door Kura op 28 juli 2024 10:56]

[Verwijderd]

Wacht dus je moet eerst spyware van Google installeren en een Google account hebben om een privacyvriendelijke chatapp te kunnen installeren?

[WhatsappHack]

Ik gok dat je ook met andere browsers uiteindelijk gebruik moet kunnen maken van het systeem; net als dat WhatsApp Web bijvoorbeeld functioneert op Safari, IE, Chrome/Chromium(-derivaten) en Firefox.

[Dasprive]

Das nou ook het eerste wat ik me bedacht: vreemd dat het een Chrome App is. Zal vast een goede reden voor zijn en Moxie Marlinspike staat bij mij hoog in het vaandel wat betreft gebruik juiste crypto en beveiliging, maar vond het toch vreemd.

[Justgivemeaname]

Ten eerste is het uiteraard nog in Bèta, dus er moest wel een specifieke browser gekozen worden om mee te beginnen, binnen de oplossing die ze gekozen hebben (een browser-extensie). De reden dat ze gekozen hebben voor Chrome is dat FireFox-extensies meer op die van Chrome gaan lijken. Zo heb ik het tenminste begrepen uit de Signal mailing list.

[cyberstalker]

Waar staat dat dan? Je kunt de extensie toch gewoon in Chromium installeren? Daar heb je ook geen account voor nodig lijkt me.

[Verwijderd]

Voor de Chrome Web Store heb je dacht ik een Google account nodig.

[MiesvanderLippe]

Plugins zijn standalone te installeren. Drag&drop zelfs.

Meestal werken Chrome plugins ook in andere webkit browsers, Vivaldi bijvoorbeeld.

[Jaahp]

Chrome apps zijn voor de duidelijkheid dus wel zonder Google account vanuit de Chrome store te installeren.

[Verwijderd]

Oké, bedankt voor de verbetering Ik was daar niet van op de hoogte het is jaren geleden sinds ik voor het laatst Chrome gebruikt heb, ik ben niet zo'n fan van Google en prefereer Firefox. Wat ik me kon herinneren moest je ingelogd zijn met je Google account in Chrome om de Web Store te gebruiken, maar ik zal het wel verwart hebben met iets anders.

[dwizzy]

"Er wordt geen gebruikgemaakt van diensten van derden."
Ik weet niet waarom dat daar staat. Signal is afhankelijk van push berichten via Google Cloud Message (GCM) respectievelijk iCloud, en alleen ('officieel') te downloaden via Google Play en de Apple App Store.

[SL600]

Ik vertrouw het ook niet helemaal. Een hashed bericht op de ingang via Google Chrome en dezelfde hashed bericht aan de uitgang via Google Android. Ondanks dat een derde partij als Google of NSA niet de berichten kunnen ontsleutelen, kunnen ze wel achterhalen wie met wie communiceert. Dus deniability gaat hier niet helemaal op.

[Armin]

Dat is dan ook iets heel anders. Je moet niet twee problemen verwarren. Dit systeem zorgt ervoor dat de inhoud niet leesbaar is.

Het probleem dat men weet met wie je spreekt is een ander probleem.

Sommige mensen hebben beide problemen, de meesten echter enkel/vooral het eerste. Dus is het logisch dat men eerst dat aanpakt.

[nanoChip]

iOS volgt later? Deze staat al in de App Store

@Tk55 scherp, ik ging er vanuit dat de app nog helemaal niet voor iOS beschikbaar was.

[Reactie gewijzigd door nanoChip op 28 juli 2024 10:56]

[Tk55]

Om de desktop app te kunnen gebruiken, heb je Android nodig. Met iOS kan het nog niet.

[Morress]

"Het is alleen zo veilig als het apparaat dat voor die communicatie wordt gebruikt. "

Wat houdt dit praktisch in?

[Matthijs8]

Geldt voor elke applicatie; je kan het transporteren van data zo zwaar versleutelen als je wilt maar het moet toch op het apparaat van de ontvanger ontsleuteld worden zodat de gebruiker het kan lezen. Als er dus malware op het ontvangende apparaat staat zou die dat mee kunnen lezen. Zelfde geld voor verzendende apparaat uiteraard.