Mega reageert op kritiek op toegepaste cryptografie
Mega heeft gereageerd op kritische geluiden over de gebruikte encryptiemethoden bij zijn onlangs geopende cyberlockerdienst. De start-up van Kim Dotcom zegt niet onder de indruk te zijn van de kritiek, maar belooft toch enkele aanpassingen te zullen doorvoeren.
Onder andere in een artikel op Ars Technica werd ingegaan op de gehanteerde clientside-encryptiemethoden. Volgens de schrijver hebben de ontwikkelaars van Mega een aantal fundamenteel verkeerde keuzes gemaakt bij de toegepaste encryptie op de opgeslagen data. Zo zou de toegepaste entropie bij het genereren van de aes-128 master key, tegelijk het wachtwoord voor Mega, onvoldoende zijn. De javascriptfunctie math.random zou onvoldoende willekeurige waardes genereren, die daarom geraden kunnen worden. Het gebruik van javascript voor cryptografie wordt in het algemeen al afgeraden. Volgens Mega klopt de kritiek deels en zal er naast entropie die is verkregen via muis- en toetsenbordbewegingen een optie aan de sleutelgenerator worden toegevoegd om nog voor het genereren van de sleutel extra entropie toe te voegen.
Mega gaat ook in op de kritiek dat er geen werkend mechanisme is voor het herstellen van een wachtwoord. Volgens de cyberlocker is dit inherent aan het gebruikte encryptieproces. Het is mogelijk om een nieuw wachtwoord aan te maken, maar bestanden die met de oude sleutel zijn versleuteld, blijven logischerwijs ontoegankelijk. Mega wijst naar de mogelijkheid om de gebruikte encryptiesleutels te exporteren.
De vernieuwde cyberlockerdienst van Mega gaat ook in op enkele opmerkingen uit een verhaal van Forbes. Zo stelt Mega dat het alleen 'zwakke' 1024bit-sleutels gebruikt voor statische content, terwijl voor gebruikersdata de als veilig omschreven 2048bit-rsa-encryptie wordt toegepast. Forbes schreef echter dat Mega uitsluitend 1024bit-encryptie heeft toegepast. Verder claimt de cyberlockerdienst javascriptcode te verifiëren voordat deze binnen de browser wordt gedraaid.
Ten slotte gaat Mega kort in op de tool MegaCracker. Met deze tool wordt een brute force-aanval ingezet op de hashcode die Mega per mail naar gebruikers stuurt. De MegaCracker-tool gebruikt standaard-dictionary-aanvallen, volgens Mega een goede reden om geen eenvoudig raadbare wachtwoorden te gebruiken.
Reacties (119)
In de terms of service staat :
8. Our service may automatically delete a piece of data you upload or give someone else access to where it determines that that data is an exact duplicate of original data already on our service. In that case, you will access that original data.
maar dit kunnen ze toch helemaal niet als alles geencrypt is?
8. Our service may automatically delete a piece of data you upload or give someone else access to where it determines that that data is an exact duplicate of original data already on our service. In that case, you will access that original data.
maar dit kunnen ze toch helemaal niet als alles geencrypt is?
Volgens mij is de hash dan ook precies hetzelfde?
Misschien dat ze client site hashes maken en vergelijken. Je weet dan nog steeds niet wat voor data het is, maar wel dat het dezelfde data is...
Even een mogelijk scenario:
Misschien zit het wel iets ingewikkelder in elkaar en is de gebruikersleutel niet de encryptie sleutel voor de data. Bijvoorbeeld: je maakt een hash van de data, die hash code gebruik je om de data te versleutelen en vervolgens berg je de hash op in een container die je met de gebruikerssleutel versleuteld. Vervolgens sla een een andere hash code van die data op voor het vergelijken. Je hebt nu 3 elementen:
Als een andere client met dezelfde data komt dan is het eenvoudig. Bepaal hashcode_1 en hashcode_2 met de te uploaden data en zoek of de data al bestaat. Zo ja, maak een nieuwe container met hashcode_1 en hashcode_2 en versleutel die met de gebruikerssleutel.
Die hashes zijn zelf ook crypto sleutels, je kan ze alleen bepalen als je zelf de data hebt. Zo kun je dus data enkelvoudig versleuteld opslaan zonder dat je weet wat het is. Uiteraard als je hashcode_1 hebt kun je de data ontcijferen, maar dat is dan nutteloos want die data had je toch immers al want anders kon je hashcode_1 niet bepalen.
Dit is maar een idee, ik weet natuurlijk niet of het zo werkt maar in deze richting zou je kunnen denken. Misschien dat je nog veel ingewikkelder constructies kan bedenken om hetzelfde te bereiken, geen idee hoe Mega het doet. Maar in elk kan versleutelen, het vinden van duplicaten en het onbekend blijven van de inhoud bij Mega op een dergelijke manier wel.
Even een mogelijk scenario:
Misschien zit het wel iets ingewikkelder in elkaar en is de gebruikersleutel niet de encryptie sleutel voor de data. Bijvoorbeeld: je maakt een hash van de data, die hash code gebruik je om de data te versleutelen en vervolgens berg je de hash op in een container die je met de gebruikerssleutel versleuteld. Vervolgens sla een een andere hash code van die data op voor het vergelijken. Je hebt nu 3 elementen:
- Maak van de gebruiker data 2 hashes: hashcode_1 en hashcode_2
- Versleutel de data met hashcode_1
- Maak een container met hashcode_1 en hashcode_2 en versleuteld die met de gebruikers sleutel
- Maak van hashcode_2 een link naar de versleutelde data
Als een andere client met dezelfde data komt dan is het eenvoudig. Bepaal hashcode_1 en hashcode_2 met de te uploaden data en zoek of de data al bestaat. Zo ja, maak een nieuwe container met hashcode_1 en hashcode_2 en versleutel die met de gebruikerssleutel.
Die hashes zijn zelf ook crypto sleutels, je kan ze alleen bepalen als je zelf de data hebt. Zo kun je dus data enkelvoudig versleuteld opslaan zonder dat je weet wat het is. Uiteraard als je hashcode_1 hebt kun je de data ontcijferen, maar dat is dan nutteloos want die data had je toch immers al want anders kon je hashcode_1 niet bepalen.
Dit is maar een idee, ik weet natuurlijk niet of het zo werkt maar in deze richting zou je kunnen denken. Misschien dat je nog veel ingewikkelder constructies kan bedenken om hetzelfde te bereiken, geen idee hoe Mega het doet. Maar in elk kan versleutelen, het vinden van duplicaten en het onbekend blijven van de inhoud bij Mega op een dergelijke manier wel.
Daar komt het grofweg inderdaad op neer als je het artikel op Ars Technica mag geloven. Het artikel noemt 'Convergent Encryption' als een manier van encryptie die de mogelijkheid biedt unieke sleutels uit te delen en toch identieke bestanden op dezelfde manier te versleutelen. Op de pagina Is Convergent Encryption really secure? wordt min of meer dezelfde methode beschreven als jij hierboven beschrijft.Dit is maar een idee, ik weet natuurlijk niet of het zo werkt maar in deze richting zou je kunnen denken.
Er wordt tevens een belangrijk nadeel genoemd en dat is dat iedereen die bekend is met de encryptie methode (niet de sleutel) of in staat is daar gebruik van te maken en hetzelfde bronbestand bezit in staat is om aan te tonen wat de inhoud van het bronbestand is. In encryptie wordt dat als een ernstige tekortkoming gezien en dat is het in dit geval zeker ook.
Praktisch gezien komt het er op neer dat als ik een encrypted versie van bijvoorbeeld een overheidsdocument op mijn schijf heb bewezen kan worden dat het om het betreffende document gaat zonder de noodzaak om mijn encrypted versie te decrypten. De overheid bezit het document immers al en kan door dit simpelweg op dezelfde manier te encrypten mijn encrypted data reproduceren. Dat is voldoende bewijs.
Wat zou dat praktisch inhouden voor mega.co.nz? Dat ze eigenlijk weer terug zijn waar ze met Mega Upload waren. Zodra er een verzoek komt om een bepaald bestand te verwijderen zijn ze er daarmee ook van op de hoogte welke andere uploaders hetzelfde bestand hebben geupload. Verwijderen ze nu net als mega upload alleen de verwijzing of sleutel van de gebruiker waarover ze een melding ontvangen dan volgen ze dezelfde werkwijze als mega upload. In dat geval verwacht ik dat het ook hetzelfde met mega.co.nz af zal lopen als met mega upload.
Zie http://en.wikipedia.org/wiki/Data_deduplication
Op het moment dat je inlogt of een link shared dan wordt jouw 50 GB private home directory gemount. Op dat moment kan bijvoorbeeld ZFS (ik noem maar iets) deduplication uitvoeren op die specifieke data.
Op het moment dat je inlogt of een link shared dan wordt jouw 50 GB private home directory gemount. Op dat moment kan bijvoorbeeld ZFS (ik noem maar iets) deduplication uitvoeren op die specifieke data.
Inhoudelijke response op kritiek, opzich wekt dat vertrouwen in het bedrijf. Veel andere bedrijven laten hun PR-afdeling een antwoordje schrijven waar de (potentiële) klanten het maar mee moeten doen.
Of je hebt geen geld om een fatsoenlijke PR erop na te houden dan wel genoeg grootheidswaan om te denken dat je het allemaal zelf beter kan, van het laatste heeft meneer Schmitz al vele malen aangetoond dit te bezitten.
[Reactie gewijzigd door Tijger op woensdag 23 januari 2013 16:27]
Je vergeet het doel van "meneer Schmitz", namelijk dat Mega niet kan weten welke data is opgeslagen.
Het is geen beveiliging voor de gebruiker maar bescherming van de site. Dat is het enige doel. Alle cloud diensten kunnen op dit moment gedwongen worden om inzage in de data te geven. Ook Mega, maar Mega kan alleen de geencrypte zooi laten zien en daaruit kun je helemaal niets opmaken. Mega kan niet worden gewongen om de bestanden te decrypten want dat kunnen ze gewoon niet. Je kan van een provider niet eisen om bestanden te gaan kraken met wat voor tool ook, zelfs al zou dat mogelijk zijn. En niemand kan de provider verwijten dat ze hadden kunnen weten dat er copyright beschermde bestanden op staan want dat kan de provider niet weten zonder niet eerst de beveiliging van elk bestand te kraken, iets wat je onmogelijk kan eisen.
Zolang de versleuteling daarvoor goed genoeg is en Mega nooit de beschikking krijgt over sleutels is het doel bereikt. Dus sleutels kraken, verspreiden enz is allemaal okay, zolang je ze maar niet aan Mega geeft. Ik vindt de oplossing van "meneer Schmitz" behoorlijk slim.
Als je bang bent voor privacy dan upload je gewoon een TrueCrypt volume maar die site, kun je ook bij Dropbox, SkyDrive of wat ook doen.
Het is geen beveiliging voor de gebruiker maar bescherming van de site. Dat is het enige doel. Alle cloud diensten kunnen op dit moment gedwongen worden om inzage in de data te geven. Ook Mega, maar Mega kan alleen de geencrypte zooi laten zien en daaruit kun je helemaal niets opmaken. Mega kan niet worden gewongen om de bestanden te decrypten want dat kunnen ze gewoon niet. Je kan van een provider niet eisen om bestanden te gaan kraken met wat voor tool ook, zelfs al zou dat mogelijk zijn. En niemand kan de provider verwijten dat ze hadden kunnen weten dat er copyright beschermde bestanden op staan want dat kan de provider niet weten zonder niet eerst de beveiliging van elk bestand te kraken, iets wat je onmogelijk kan eisen.
Zolang de versleuteling daarvoor goed genoeg is en Mega nooit de beschikking krijgt over sleutels is het doel bereikt. Dus sleutels kraken, verspreiden enz is allemaal okay, zolang je ze maar niet aan Mega geeft. Ik vindt de oplossing van "meneer Schmitz" behoorlijk slim.
Als je bang bent voor privacy dan upload je gewoon een TrueCrypt volume maar die site, kun je ook bij Dropbox, SkyDrive of wat ook doen.
[Reactie gewijzigd door pe1dnn op woensdag 23 januari 2013 17:48]
Maar wat noem jij fatsoenlijke PR? Ik bedoel juist te zeggen dat de antwoorden die de gemiddelde PR-afdeling bij andere bedrijven schrijft (zelfs xs4all helaas) soms huilen met de pet op zijn. Dat is dan wel geen grootheid - maar wel compleet waanzinnig. Dan doet Megaupload het toch een stuk beter.
Ik vind het best goed, die beveiliging van Mega. Er zit echter ook een staartje aan. Wanneer het echt zo goed is beveiligd als beweerd dan zal het netwerk binnen de kortste keren zeer zeker worden gebruikt door criminelen die daar hun data veilig kunnen opslaan zonder dat er ooit iemand bij kan. Aangezien Mega geen controle heeft, kan niemand er ooit bij. Dat is heel leuk en aardig, maar wanneer vanuit daar een leuk netwerk wordt opgezet voor kinderporno of erger, dan vind ik dat een schadelijke zaak. Zo zouden ook de maffia en dergelijke daar belangrijke bestanden kunnen leggen, aangezien het niet gekraakt kan worden.
Enige wat wel fijn is, is dat ze Java hebben gebruikt. Java is zo lek als een mandje wat betreft beveiliging. Maar de essentie vam Mega is goed, maar leent zich uitstekend voor illegale zaken.
Enige wat wel fijn is, is dat ze Java hebben gebruikt. Java is zo lek als een mandje wat betreft beveiliging. Maar de essentie vam Mega is goed, maar leent zich uitstekend voor illegale zaken.
Denk je nu echt dat criminelen encryptie en het beheer van hun bestanden overlaten aan een derde als Mega ? Dat denk ik niet.
En als ze de files al zouden stallen bij een clouddienst als Mega dan zullen ze ongetwijfeld hun bestanden zelf encrypten met iets als TrueCrypt. En als ze het helemaal gek willen doen, zorgen ze dan ook voor een paar lagen encryptie. Maar dan kan je het net zo goed bij een cloud dienst als DropBox stallen.
Al met al zie ik geen reden voor je 'angst' dat deze dienst door dergelijke criminelen zoals jij omschrijft uitgebaat zal worden.
En als ze de files al zouden stallen bij een clouddienst als Mega dan zullen ze ongetwijfeld hun bestanden zelf encrypten met iets als TrueCrypt. En als ze het helemaal gek willen doen, zorgen ze dan ook voor een paar lagen encryptie. Maar dan kan je het net zo goed bij een cloud dienst als DropBox stallen.
Al met al zie ik geen reden voor je 'angst' dat deze dienst door dergelijke criminelen zoals jij omschrijft uitgebaat zal worden.
[Reactie gewijzigd door Perkouw op woensdag 23 januari 2013 15:38]
Maar de enige manier om dat tegen te gaan is het verbieden van encryptie door burgers. Ik denk niet dat er veel mensen zijn die daar positief tegen overstaan.
Maar de burger encrypt hier niet, dat doet MEGA. Net als je bank dat doet bij transacties.
Eer dat de overheid de scheidslijn precies heeft waar ze het hebben wil leven we in een politiestaat, en dan zijn de consequenties om het niet te gebruiken misschien wel groter dan die van het wel te gebruiken.
Eer dat de overheid de scheidslijn precies heeft waar ze het hebben wil leven we in een politiestaat, en dan zijn de consequenties om het niet te gebruiken misschien wel groter dan die van het wel te gebruiken.
Dat zeg je nou wel, maar ik meen juist gelezen te hebben dat de versleuteling in Javascript gebeurt. Aan de kant van de burger dus!
Om maar weer even een autologie in de groep te gooien; een auto ook.Maar de essentie vam Mega is goed, maar leent zich uitstekend voor illegale zaken.
(en natuurlijk een miljoen andere dingen).
Ik zie u punt. Maar men moet de producenten van die illegale content aanpakken (de ziekte), niet hun manier van opslaan (de symptomen).
Dat is zoals met bvb hamers. Hamers worden gemaakt om dingen mee te bouwen, maar er zijn er altijd die daar iets anders mee doen (iemand de kop inslaan). Draagt de hamerproducent enige verantwoordelijkheid? Natuurlijk niet.
Punt is: men moet de criminelen oppakken en opsluiten ipv achter services te zitten die zouden kunnen gebruikt worden om illegale shit op te slaan.
Dat is zoals met bvb hamers. Hamers worden gemaakt om dingen mee te bouwen, maar er zijn er altijd die daar iets anders mee doen (iemand de kop inslaan). Draagt de hamerproducent enige verantwoordelijkheid? Natuurlijk niet.
Punt is: men moet de criminelen oppakken en opsluiten ipv achter services te zitten die zouden kunnen gebruikt worden om illegale shit op te slaan.
Java?
WTF?
Javascript heeft, in tegenstelling tot wat de naam doet vermoeden, helemaal niets met Java te maken.
WTF?
Javascript heeft, in tegenstelling tot wat de naam doet vermoeden, helemaal niets met Java te maken.
Criminelen gebruiken al lang en breed software zoals SSL, TrueCrypt, GPG, enz.
De zwakste schakel is nog steeds de mens. Zwakke wachtwoorden en achterdeurtjes, bijvoorbeeld.
De zwakste schakel is nog steeds de mens. Zwakke wachtwoorden en achterdeurtjes, bijvoorbeeld.
[Reactie gewijzigd door Jerie op woensdag 23 januari 2013 16:36]
Ik vraag me altijd af hoe dit gebeurd, als ik de javascript code kan aanpassen kan ik toch ook de functie die javascript code controleert aanpassen?Verder claimt de cyberlockerdienst javascriptcode te verifiëren voordat deze binnen de browser wordt gedraaid.
[Reactie gewijzigd door kikker81 op woensdag 23 januari 2013 15:42]
Ja, maar niet de originele webpagina die op de server staat, tuurlijk je kan de .js file downloaden van de webserver (gewoon met ctrl+s) en bewerken dan, maar dan verander je uiteraard niks aan de code die op de webserver staat. Alleen aan het bestand dat op JOU computer staat.
Elke zichzelf respecterende webserver heeft een uitgebreid permissions managementsysteem, waardoor dit onmogelijk zou moeten zijn, ten minste dat is mijn ervaring van buiten af (ik ben geen webserverbeheerde o.i.d., maar ik heb wel eens geprobeerd om een html bestand van een site te editen puur uit nieuwsgierigheid en ik heb wat linux (meest gebruikte (web)server OS) ervaring)
Ik heb zelf geen uitgebreide kennis van UNIX permissionbeheer, maar ik weet wel wat rw(lees en schrijf rechten), r (bestand kan alleen gelezen worden en niet bewerkt of uitgevoerd etc.) en x (bestand mag uitgevoerd worden/executable) zijn.
Elke zichzelf respecterende webserver heeft een uitgebreid permissions managementsysteem, waardoor dit onmogelijk zou moeten zijn, ten minste dat is mijn ervaring van buiten af (ik ben geen webserverbeheerde o.i.d., maar ik heb wel eens geprobeerd om een html bestand van een site te editen puur uit nieuwsgierigheid en ik heb wat linux (meest gebruikte (web)server OS) ervaring)
Ik heb zelf geen uitgebreide kennis van UNIX permissionbeheer, maar ik weet wel wat rw(lees en schrijf rechten), r (bestand kan alleen gelezen worden en niet bewerkt of uitgevoerd etc.) en x (bestand mag uitgevoerd worden/executable) zijn.
[Reactie gewijzigd door Superpelican op woensdag 23 januari 2013 16:01]
Dat bedoelde ik, dus als je write access hebt tot het filesystem van de server houdt het hele verhaal qua beveiliging op, dan zou je zelf de javascript code kunnen aanpassen om alle bestanden en wachtwoorden niet encrypted naar jouw eigen server te sturen.
Edit, volgens het blog van Mega zit het zo, en dat klinkt best logisch:
Edit, volgens het blog van Mega zit het zo, en dat klinkt best logisch:
Fact #1: The JavaScript is not verifying itself. Fact #2: A piece of JavaScript coming from a trusted, 2048-bit HTTPS server is verifying additional pieces of JavaScript coming from untrusted, HTTP/1024-bit HTTPS servers.
[Reactie gewijzigd door kikker81 op woensdag 23 januari 2013 16:23]
Hoe registreert men toetsenbordbewegingen?
Ik vind het wel positief dat Mega ingaat op de kritiek van hun gebruikers. Veel bedrijven zouden met een smoesje komen of gewoon geen commentaar geven.
Ik vind het wel positief dat Mega ingaat op de kritiek van hun gebruikers. Veel bedrijven zouden met een smoesje komen of gewoon geen commentaar geven.
"MegaCracker" die dienst is amper online en er is nu al een speciale cracktool voor? 
Uit het artikel;
Zoals ik al zei, niet zo heel spannend dus.
Niet heel spannend dus. Ditzelfde kan je zonder al teveel moeite op een truecrypt volume doen. Zoals Kim al aangeeft, eenvoudig raadbare wachtwoorden worden afgeraden. Buiten dat moet je eerst nog het mailtje van je slachtoffer zien te bemachtigen met hierin de hashcode.Met deze tool wordt een brute force-aanval ingezet op de hashcode die Mega per mail naar gebruikers stuurt. De MegaCracker-tool gebruikt standaard-dictionary-aanvallen, volgens Mega een goede reden om geen eenvoudig raadbare wachtwoorden te gebruiken.
Zoals ik al zei, niet zo heel spannend dus.
Eindelijk wel slim gezien. Maar wil dat dan zeggen dat je met een fout wachtwoord de namen van de bestanden kan zien? Of zin die namen ook versleutelt ?
ik heb onderhand al een stuk of 100 keer geregisteerd, maar ik krijg geen registratie binnen...
Ik weet niet van welke mail provider je gebruik maakt ? Maar ik heb het hierboven al gezegd wanneer je bijvoorbeeld een @outlook adres gebruikt van Microsoft krijg je geen verificatie mail binnen. Wanneer je dit echter met een @hotmail adres gebruikt krijg je de mail wel binnen. @gmail werkt ook. Meer mail providers heb ik zelf niet uitgeprobeerd.
Ik krijg hem op @hotmail niet binnen hoor.
Heb meerdere hotmail en andere accounts geprobeerd, bij sommige wel activeringslinks binnen gekregen, maar alleen gmail werkt goed.
Dit gaat gewoon keihard in een rechtzaak eindigen. Is het hosten van illegale content in versleutelde vorm strafbaar? Hoe kan bewezen worden dat de content illegaal is, en wie is daarvoor verantwoordelijk. ?
Ik denk dat er al een legertje advocaten alles aan het uitpluizen zijn. Kim DotCom zal er ook wel zin in hebben: hij doet trouwens niets anders dan uitdagen. Ik denk dat ze hem het best pakken op iets strafbaars dat niets met Mega te maken heeft, waardoor zijn bedrijf mee de afgrond in duikt.
Ik denk dat er al een legertje advocaten alles aan het uitpluizen zijn. Kim DotCom zal er ook wel zin in hebben: hij doet trouwens niets anders dan uitdagen. Ik denk dat ze hem het best pakken op iets strafbaars dat niets met Mega te maken heeft, waardoor zijn bedrijf mee de afgrond in duikt.
Even afgezien van wat je allemaal in je tweede alinea zegt. Hoe zit dit volgens jou dan met bedrijven als DropBox? Spideroak? SugarSync? Google Drive? Skydrive? etc....
Volgens mij zijn die veel strikter en werken veel beter mee met Amerikaanse anti-piracy agentschappen. Ik zou daar totaal geen illegale content durven uploaden. Die sluiten direct je account, en sturen je ip door naar bevoegde instanties. Bij MegaUpload verwijderde ze enkel de link, en kon je doorgaan.
Bij Megaupload hadden de "gedupeerde" bedrijven ook gewoon toegang tot het systeem om illigale bestanden te verwijderen, dat zal nu wellicht weer het geval zijn, kijk dat interview met DotCom op youtube daar even op na
Wat dotcom beweert en wat waar is hoeft niet hetzelfde te zijn,
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Sony Games Microsoft Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
