'Dropbox misleidde gebruikers met claims over veiligheid'
Een beveiligingsdeskundige beschuldigt de populaire cloudopslagdienst Dropbox ervan dat het gebruikers heeft misleid met zijn claims dat versleutelde bestanden zelfs niet toegankelijk zijn voor medewerkers van het bedrijf.
Beveiligingsdeskundige Christopher Soghoian wil dat de FTC Dropbox gaat dwingen om duidelijkheid over zijn beveiligings- en privacybeleid te geven. In een document gericht aan de FTC somt Soghoian zijn klachten op. Hij publiceerde in april een artikel over het feit dat Dropbox weliswaar encryptie op basis van het aes-256-algoritme gebruikt, maar dat medewerkers van het bedrijf over de sleutels beschikken.
Dropbox vergelijkt namelijk bestanden van gebruikers, zodat die geen bestanden dubbel hoeven op te slaan. Hiermee zouden de gebruikers bandbreedte en opslagcapaciteit besparen. Bij goed gebruik van aes-256-encryptie zou Dropbox niet kunnen detecteren dat er bij het uploaden sprake is van duplicatie van een bestaand bestand van een gebruiker. Concurrerende diensten als Spideroak en Tarsnap zouden wel versleutelen met een key die alleen bij de gebruiker bekend is.
Na publicatie wijzigde Dropbox zijn voorwaarden. De dienst verwijderde claims dat de bestanden op zijn servers ontoegankelijk waren voor medewerkers. In plaats daarvan staat er nu dat het verboden is voor medewerkers om de inhoud van bestanden te bekijken. Ook is een alinea toegevoegd dat een kleine groep medewerkers de data kan inzien als dit nodig is op basis van het privacybeleid.
Soghoian klaagt nu dat Dropbox zijn gebruikers op het verkeerde been zette. De dienst zou zijn beleid moeten verduidelijken op zijn site en al zijn gebruikers erop moeten wijzen dat de data is in te zien. Ook zouden betalende gebruikers een teruggaaf aangeboden moeten krijgen en zou de FTC Dropbox moeten verbieden om in de toekomst opnieuw misleidende claims te maken.
Dropbox verwerpt de beschuldigingen en zegt dat het met een blogbericht van 21 april al aan alle bezwaren is tegemoetgekomen.
Reacties (92)
Aan de ene kant begrijp ik dat medewerkers de encryptiesleutels moeten hebben om klanten te ondersteunen... Aan de andere kant is het niet echt klantvriendelijk om je klanten voor te liegen.
Het ging niet over om de klanten te ondersteunen, maar om zelf minder disk space nodig te hebben door te gaan dedupliceren (over de klanten heen als ik het goed lees).
Doordat ze minder disk space nodig hadden, kan Dropbox goedkoper werken dan concurrenten die wel alles encrypten (en dus niet kunnen dedupliceren).
Doordat ze minder disk space nodig hadden, kan Dropbox goedkoper werken dan concurrenten die wel alles encrypten (en dus niet kunnen dedupliceren).
Dan vraag ik me af; over hoeveel data en duplicaties hebben we het hier nu precies? Ik geloof namelijk, in deze tijd van enorme bakken storage 'in de cloud', dat het veel zou schelen (ook niet aangezien ze een extra verwerkingsstap moeten doorlopen om te kijken of het bestand al bestaat, dat kost CPU tijd).Doordat ze minder disk space nodig hadden, kan Dropbox goedkoper werken dan concurrenten die wel alles encrypten (en dus niet kunnen dedupliceren).
Daar zou je van kunnen verschieten wat dedup voor een bedrijf, en dan zeker Dropbox, zou kunnen beteken...
Ik neem nu even mijn Dropbox (ook al is het maar tijdelijk), wat ik er ooit in had staan:
Een vSphere client installer (IDEAAL om te dedup'en
een ISO van Ubuntu (IDEAAL om te dedup'en)
een paar publiek beschikbare presentaties omtrent VMware en Citrix
handleidingen enz...
Die dingen (met uitzondering van een paar presentaties) waren bij wijze van spreken op 2 seconden geupload, thanks to dedup, jawel...
En dan heb ik het alleen nog maar over file-dedup, kan je je voorstellen wat er gebeurt bij block dedup? Stel nu dat ik een presentatie heb van 50 slides van VMware en ik pas er één slide van aan... Dan is dat in een theoretisch ideale wereld 49/50 die potentieel hetzelfde kan zijn voor iemand anders...
En ja, als dat GEDEELTIJK (!) ten koste gaat van mijn versleuteling aan de storage-kant, ok, mijn files komen veilig daar en verder vertrouw ik op de kennis van Dropbox om alles veilig te houden. En ja, ik weet het, recente voorvallen met PSN hebben ons anders geleerd...
maar hoe wil je anders in hemelsnaam dedup gaan toepassen als iedereen een andere key heeft maar wel dezelfde data?
Gaan we dan even publiek de vraag stellen: hoeveel van jullie hebben effectief betaald voor Dropbox ipv "geprofiteerd" van het referentie principe en de gratis storage?
Ik ga niet zeggen dat gratis daarom gelijk is aan "security-wise brakke implementatie van een cloud-service". Maar iedereen wil nu eenmaal voor een centje op de eerste rij zitten... In hun voorwaarden staat (nu dan wel pas) dat de keys beschikbaar zijn voor een selecte groep en dat het verboden is om gegevens te ontsleutelen... Als je dat niet wilt, dan moet je het niet gebruiken...
Host dan zelf op een VPS je WebDAV server en encrypteer het met een 2048-bits sleutel of whatever floats your boat...
Ik wil maar zeggen: cloud, het is allemaal heel mooi, maar het is niet de holy grail (net zoals andere producten ook niet altijd the holy grail zijn...). Er zijn, zoals bij iedere oplossing kanttekeningen die iedereen voor zichzelf moet uitmaken of deze van belang zijn voor hem of haar...
Ik neem nu even mijn Dropbox (ook al is het maar tijdelijk), wat ik er ooit in had staan:
Een vSphere client installer (IDEAAL om te dedup'en
een ISO van Ubuntu (IDEAAL om te dedup'en)
een paar publiek beschikbare presentaties omtrent VMware en Citrix
handleidingen enz...
Die dingen (met uitzondering van een paar presentaties) waren bij wijze van spreken op 2 seconden geupload, thanks to dedup, jawel...
En dan heb ik het alleen nog maar over file-dedup, kan je je voorstellen wat er gebeurt bij block dedup? Stel nu dat ik een presentatie heb van 50 slides van VMware en ik pas er één slide van aan... Dan is dat in een theoretisch ideale wereld 49/50 die potentieel hetzelfde kan zijn voor iemand anders...
En ja, als dat GEDEELTIJK (!) ten koste gaat van mijn versleuteling aan de storage-kant, ok, mijn files komen veilig daar en verder vertrouw ik op de kennis van Dropbox om alles veilig te houden. En ja, ik weet het, recente voorvallen met PSN hebben ons anders geleerd...
maar hoe wil je anders in hemelsnaam dedup gaan toepassen als iedereen een andere key heeft maar wel dezelfde data?
Gaan we dan even publiek de vraag stellen: hoeveel van jullie hebben effectief betaald voor Dropbox ipv "geprofiteerd" van het referentie principe en de gratis storage?
Ik ga niet zeggen dat gratis daarom gelijk is aan "security-wise brakke implementatie van een cloud-service". Maar iedereen wil nu eenmaal voor een centje op de eerste rij zitten... In hun voorwaarden staat (nu dan wel pas) dat de keys beschikbaar zijn voor een selecte groep en dat het verboden is om gegevens te ontsleutelen... Als je dat niet wilt, dan moet je het niet gebruiken...
Host dan zelf op een VPS je WebDAV server en encrypteer het met een 2048-bits sleutel of whatever floats your boat...
Ik wil maar zeggen: cloud, het is allemaal heel mooi, maar het is niet de holy grail (net zoals andere producten ook niet altijd the holy grail zijn...). Er zijn, zoals bij iedere oplossing kanttekeningen die iedereen voor zichzelf moet uitmaken of deze van belang zijn voor hem of haar...
[Reactie gewijzigd door HyperBart op maandag 16 mei 2011 17:11]
Laat niet onverlet dat Dropbox dit dan ook kenbaar had moeten maken naar de gebruikers. Dan hadden die zelf kunnen kiezen of ze Dropbox ondanks de verminderde veiligheid toch wilden gebruiken. Nu is men gewoon voorgelogen en heeft een dergelijke keuze niet kunnen maken.
Aan de gratis dienst van Dropbox heb je theoretisch gezien helemaal niets. Je hebt nl. helemaal nergens recht op.
Nu kun je dat ook zeggen over de betaalde dienst, aangezien het bedrijf in theorie failliet kan gaan (ik ken hun cijfers niet en ze zijn ook geen publiekelijk verhandelbaar bedrijf).
Ik vind Dropbox overigens een slecht product (onafhankelijk van het feit dat de concurrerende cloud diensten die ik ken dit ook zijn) waarmee ik bekend ben dit ook is).
De enige cloudservice die echt iets toevoegt is een zoekmachine wat mij betreft.
Nu kun je dat ook zeggen over de betaalde dienst, aangezien het bedrijf in theorie failliet kan gaan (ik ken hun cijfers niet en ze zijn ook geen publiekelijk verhandelbaar bedrijf).
Ik vind Dropbox overigens een slecht product (onafhankelijk van het feit dat de concurrerende cloud diensten die ik ken dit ook zijn) waarmee ik bekend ben dit ook is).
De enige cloudservice die echt iets toevoegt is een zoekmachine wat mij betreft.
Omdat het gratis is heb ik nergens recht op?
Ik heb recht op wat (in dit geval) Dropbox mij aanbiedt, of ze er nou geld voor willen hebben of niet. Zij doen een belofte, dan moeten ze die waarmaken. Dat gold al heel lang, geld of geen geld.
Ik heb recht op wat (in dit geval) Dropbox mij aanbiedt, of ze er nou geld voor willen hebben of niet. Zij doen een belofte, dan moeten ze die waarmaken. Dat gold al heel lang, geld of geen geld.
die word een humancentipad...
bij betaling moet je krijgen waar je een contract voor hebt afgesloten...of de voorwaarden die daarbij horen...bij gratis kunnen ze de voorwaarden wijzigen zonder dat ze je iets verplicht zijn...
bij betaling moet je krijgen waar je een contract voor hebt afgesloten...of de voorwaarden die daarbij horen...bij gratis kunnen ze de voorwaarden wijzigen zonder dat ze je iets verplicht zijn...
Je hebt altijd rechten, en al helemaal op privacy...Aan de gratis dienst van Dropbox heb je theoretisch gezien helemaal niets. Je hebt nl. helemaal nergens recht op.
Nu kun je dat ook zeggen over de betaalde dienst, aangezien het bedrijf in theorie failliet kan gaan (ik ken hun cijfers niet en ze zijn ook geen publiekelijk verhandelbaar bedrijf).
Ik vind Dropbox overigens een slecht product (onafhankelijk van het feit dat de concurrerende cloud diensten die ik ken dit ook zijn) waarmee ik bekend ben dit ook is).
De enige cloudservice die echt iets toevoegt is een zoekmachine wat mij betreft.
kijk naar facebook , google, etc... om een paar voorbeelden te noemen ze lappen allemaal de privacy aan hun laars, en hebben er schijt aan
Hoe lapt google privacy aan hun laars?
Gratis ontslaat Dropbox niet van iedere verantwoordelijkheid. Zeggen 'encrypted' maar straks wel mijn creditcard nummer gejat laten worden is gewoon onrechtmatig als je het mij vraagt. Ook bij een gratis dienst heb je gewoon verantwoordelijkheden naar je klanten. 'Free is just another price'
Stel nu dat ik een presentatie heb van 50 slides
Dropbox zal misschien presentaties vergelijken, maar toch geen slides binnen die presentaties.
Dropbox zal misschien presentaties vergelijken, maar toch geen slides binnen die presentaties.
Dat ligt eraan of ze file-level dedup of block-level dedup doen. Ze kijken uiteraard niet naar slides van een presentatie, maar ze kijken (bij block-level dedup) wel naar blokken data zoals die op disk staan en daar kan heel veel hetzelfde in blijken te zijn (in theorie zelfs tussen totaal verschillende bestanden)
Voor blokken willekeurige data maakt het niet uit of die wel of niet encrypted is. Personeel heeft daar dan ook geen sleutel voor nodig.
Alleen is de-dupen (is dat een woord? 
) van blocken encrypted data een compleet zinloze exercitie. Als het bestand goed versleuteld is dan is het niet te onderscheiden van random data en als jij en ik hetzelfde bestand versleutelen dan krijg je twee keer een ander bestand. De kans dat er identieke blocks voorkomen wordt op die manier heel, heel erg veel kleiner dan wanneer je op block niveau deduped bij niet versleutelde bestanden.
Maar echt heel erg slecht dit. Is ook meteen de reden dat ik geen gebruik maak van diensten als Dropbox. De service die ze aanbieden is echt helemaal top, super handig en heel eenvoudig in het gebruik maar veiligheidstechnisch ben je overgeleverd aan de blauwe ogen van de beheerders daar. Het is echt niet zo dat ik hier staatsgeheimen heb maar m'n data is me toch net wat meer waard dan dat
) van blocken encrypted data een compleet zinloze exercitie. Als het bestand goed versleuteld is dan is het niet te onderscheiden van random data en als jij en ik hetzelfde bestand versleutelen dan krijg je twee keer een ander bestand. De kans dat er identieke blocks voorkomen wordt op die manier heel, heel erg veel kleiner dan wanneer je op block niveau deduped bij niet versleutelde bestanden.Maar echt heel erg slecht dit. Is ook meteen de reden dat ik geen gebruik maak van diensten als Dropbox. De service die ze aanbieden is echt helemaal top, super handig en heel eenvoudig in het gebruik maar veiligheidstechnisch ben je overgeleverd aan de blauwe ogen van de beheerders daar. Het is echt niet zo dat ik hier staatsgeheimen heb maar m'n data is me toch net wat meer waard dan dat
Wie betaalt er voor Dropbox. Wel, klanten, zoals ik.
edit: zie nu pas dat cybero hierbeneden al deels hetzelfde geschreven had.
[Reactie gewijzigd door GORby op dinsdag 17 mei 2011 16:24]
Ik gebruik zelf ook Dropbox en kan je vertellen dat dit inderdaad zo werkt.
Als je bijvoorbeeld een groot download bestand toevoegt dan is deze in een fractie van een seconde gupload. Zo snel als mijn lijn nooit zou kunnen halen. Ik vermoed dat ze met hashes van bestanden werken en deze eerst sturen. (jouw computer doet dus het cpu werk) Als het bestand door iemand al is geupload dan word deze aan mijn dropbox toegevoegd. Slim natuurlijk dat het je wel de ruimte kost, net als met foto's delen, het telt bij dropbox bij iedereen bij zijn limiet.
Ik moet zeggen het werkt zeer snel en makkelijk (houd ook versies bij)
Dit verhaal doet me inderdaad weer anders over dropbox denken. Voordat ik met dropbox ging werken ben ik ook op zoek gegaan en ben ik blijkbaar de oude voorwaarden tegengekomen. Kwam me in bovenstaande namelijk bekend voor.
Was gelukkig terughoudend met het erop zetten van data die niet direct de wereld in moet, maar toch.
Als je bijvoorbeeld een groot download bestand toevoegt dan is deze in een fractie van een seconde gupload. Zo snel als mijn lijn nooit zou kunnen halen. Ik vermoed dat ze met hashes van bestanden werken en deze eerst sturen. (jouw computer doet dus het cpu werk) Als het bestand door iemand al is geupload dan word deze aan mijn dropbox toegevoegd. Slim natuurlijk dat het je wel de ruimte kost, net als met foto's delen, het telt bij dropbox bij iedereen bij zijn limiet.
Ik moet zeggen het werkt zeer snel en makkelijk (houd ook versies bij)
Dit verhaal doet me inderdaad weer anders over dropbox denken. Voordat ik met dropbox ging werken ben ik ook op zoek gegaan en ben ik blijkbaar de oude voorwaarden tegengekomen. Kwam me in bovenstaande namelijk bekend voor.
Was gelukkig terughoudend met het erop zetten van data die niet direct de wereld in moet, maar toch.
Waarschijnlijk is het gevoeliger voor fouten, en is het daarnaast waarschijnlijk te zwaar voor sommige clients (zeker bij een grote hoeveelheid data) en daarmee minder gebruiksvriendelijk, maar een client-side hashing functie zou toch zeker een oplossing kunnen zijn om het dedupliceren mogelijk te maken?
Of worden er per gebruiker encryptiesleutels gebruikt en kan na het vinden van een dubbel bestand het niet eens aan de ander worden aangeboden?
Of worden er per gebruiker encryptiesleutels gebruikt en kan na het vinden van een dubbel bestand het niet eens aan de ander worden aangeboden?
Het lijkt me dat er per gebruiker sleutels worden gebruikt. Het gaat om een 2-way encryptie (anders kon je je bestanden niet terug krijgen), en als de sleutels overal gelijk zouden zijn, zou je ook gewoon kunnen de-duppen.
Daarnaast zou het nut van het encrypten dan enorm afnemen, 1 keer sleuteltje kwijt of uitlekken en alle bestanden zijn te decrypten.
Daarnaast zou het nut van het encrypten dan enorm afnemen, 1 keer sleuteltje kwijt of uitlekken en alle bestanden zijn te decrypten.
Volgens mij gaat het hier niet over deduplicatie op de servers van Dropbox, maar om enkel de gewijzigde delen van een bestand over te sturen, zodat het up- en downloaden voor de gebruiker zo snel mogelijk gaat en er het minste beslag wordt gelegd op bandbreedte van de gebruikers.
Inderdaad. Deduplicatie op de servers lijkt mij niet aan de orde. Dat zou betekenen dat de gebruikers-sleutel namelijk helemaal niet gebruikt wordt. Iedere gebruiker heeft immers een andere sleutel.
Voor zover ik begreep doet Dropbox op het volgende niveau dedup:
Voor het uploaden, er wordt gehashed op een file, die wordt vergeleken met hashes in een database bij Dropbox, is de hash hetzelfde, wordt er aan de server kant een set pointers geplaatst die verwijzen naar dezelfde file... Naar de client wordt het bericht gestuurd dat de file geupload is...
Dedup op block niveau lijkt me sterk omdat je dan aan beide kanten hetzelfde filesystem moet gebruiken... Nu, je kan het altijd testen, gooi er een ISO in, open die, gooi er een bestandje uit en meet hoe lang het duurt...
Voor het uploaden, er wordt gehashed op een file, die wordt vergeleken met hashes in een database bij Dropbox, is de hash hetzelfde, wordt er aan de server kant een set pointers geplaatst die verwijzen naar dezelfde file... Naar de client wordt het bericht gestuurd dat de file geupload is...
Dedup op block niveau lijkt me sterk omdat je dan aan beide kanten hetzelfde filesystem moet gebruiken... Nu, je kan het altijd testen, gooi er een ISO in, open die, gooi er een bestandje uit en meet hoe lang het duurt...
Daar lijkt op dit moment geen sprake van. Ik heb even de Ubuntu 11.04 ISO in mijn dropbox folder gezet en hij begon hem doodleuk te uploaden met mijn 1 megabit uploadlijntje.Voor zover ik begreep doet Dropbox op het volgende niveau dedup:
Voor het uploaden, er wordt gehashed op een file, die wordt vergeleken met hashes in een database bij Dropbox, is de hash hetzelfde, wordt er aan de server kant een set pointers geplaatst die verwijzen naar dezelfde file... Naar de client wordt het bericht gestuurd dat de file geupload is...
[Reactie gewijzigd door W3ird_N3rd op maandag 16 mei 2011 21:56]
http://forums.dropbox.com/topic.php?id=37320
Dus een hash geven van win7_ultimate.iso en versturen en je hebt in 1 seconde de iso in je dropbox. Maakt file sharing wel heel snel.
Stuk dus. Lijkt erop dat je een hash kon geven, en als deze hash dan in de database voorkomt dan zet hij hem erbij in je eigen account.hi guys,
sorry it took me so long to get back to the forums. de-duplication of uploads across all accounts is currently off (it remains active within accounts/across shared folders). the feature is off now because the protocol has started getting abused (i.e. dropbox is being tricked to "upload" files that were never on the uploader's computer). we'll be modifying the client to provide better proof that it actually has a given file (along with some other optimizations around batching downloads/uploads of small files). unfortunately I don't have any timelines/promises on when it could be back, but we'll try our best!
Dus een hash geven van win7_ultimate.iso en versturen en je hebt in 1 seconde de iso in je dropbox
. Maakt file sharing wel heel snel.[Reactie gewijzigd door thegve op maandag 16 mei 2011 21:24]
Neemt niet weg dat je die alsnog moet downloaden, wat over het algemeen iets langer duurt dan 1 seconde. 
[Reactie gewijzigd door Sypher op maandag 16 mei 2011 22:59]
Maar wel sneller dan uploaden..Neemt niet weg dat je die alsnog moet downloaden, wat over het algemeen iets langer duurt dan 1 seconde.
dedup als de hash gelijk is? En dan een hash over miljoenen gebruikers? Dat klinkt als vragen om problemen. 't Is geen lossy compressie.
Een dedup hash wordt uitsluitend gebruikt om te bepalen welke blokken eventueel gelijk zouden kunnen zijn. Vervolgens worden deze bit-voor-bit vergeleken.
Een dedup hash wordt uitsluitend gebruikt om te bepalen welke blokken eventueel gelijk zouden kunnen zijn. Vervolgens worden deze bit-voor-bit vergeleken.
Als deze bit-voor-bit vergeleken zou worden zou hij dus ook bit voor bit over het lijntje gestuurd moeten worden.
Allerlei mensen hebben aangegeven ( voordat ze het uitzetten ) dat ze in 1 seconde gigabytes uploaden.
Hoe verklaar je dat dan? Ze moeten wel een hash gebruiken, kan niet anders.
Allerlei mensen hebben aangegeven ( voordat ze het uitzetten ) dat ze in 1 seconde gigabytes uploaden.
Hoe verklaar je dat dan? Ze moeten wel een hash gebruiken, kan niet anders.
Nee, de check is een proof-of-concept dat Dropbox (schijnbaar) wel de bestanden kan decoderen. Dat beweerde het bedrijf niet te kunnen en dat is nu gerectificeerd.
Dat ze proberen minder disk space te gebruiken is niet het probleem, de toegang is het probleem.
Dat ze proberen minder disk space te gebruiken is niet het probleem, de toegang is het probleem.
Het is beter om de gebruiker een ticket aan te laten maken, en daarin toestemming geeft aan deze medewerker om zijn of haar bestanden in te mogen zien. Nu kan (bijna) elke medewerker iemands bestanden inzien. Als je slim bent, pas je zelf ook nog encryptie toe.
Mijn bestanden mogen ze zien. Gevoelige info houdt ik van het www af. Maar als je echt veilig wilt zijn, pas dan inderdaad encryptie toe.
Ik vind het ook erg jammer dat Dropbox mijn vertrouwen beschaamd heeft. Beloftes doen en niet nakomen, slechtere reclame bestaat niet!
offtopic:
Ik zeg: compensatie! Iedereen een paar GB extra ofzo.
Ik vind het ook erg jammer dat Dropbox mijn vertrouwen beschaamd heeft. Beloftes doen en niet nakomen, slechtere reclame bestaat niet!
offtopic:
Ik zeg: compensatie! Iedereen een paar GB extra ofzo.
Ik vind het wel een beetje hypocriet, iedereen roept "security", "privacy", "smerig", "misbruikt vertrouwen", maar met een paar GB extra kopen we het wel af...
Just saying...
Just saying...
nee dat zie je verkeerd compensatie onder de vorm van enkele gratis GB en een sluitende encryptie natuurlijk.
Je kunt er natuurlijk nooit vanuit gaan dat de software die ze je aanbieden het ook echt versleutelt. Het is een beetje hetzelfde idee als hardware hard-disk encryptie. Er is geen enkele reden om aan te nemen dat je key niet ergens in de firmware blijft hangen.
Iedereen die dus geeft om encryptie zal dus tenminste zelf de code die hij/zij daarvoor gebruikt moeten controleren. Er zijn nog wel een aantal extra stappen nodig wil je bijv. voorkomen dat je processor detecteert dat je iets aan het versleutelen bent, etc. (of je moet natuurlijk je eigen computer vanaf 0 opbouwen met goede electromagnetische shielding met een ruisgenerator.
Iedereen die dus geeft om encryptie zal dus tenminste zelf de code die hij/zij daarvoor gebruikt moeten controleren. Er zijn nog wel een aantal extra stappen nodig wil je bijv. voorkomen dat je processor detecteert dat je iets aan het versleutelen bent, etc. (of je moet natuurlijk je eigen computer vanaf 0 opbouwen met goede electromagnetische shielding met een ruisgenerator.
Op zich is dat een mooi idee maar dat is slechts een beperking in hun interface natuurlijk: Dropbox heeft technisch de mogelijkheid om bij de files te komen, zo'n vinkje kan men dus prima plaatsen zonder hier wat mee te doen of wat dan ook.Het is beter om de gebruiker een ticket aan te laten maken, en daarin toestemming geeft aan deze medewerker om zijn of haar bestanden in te mogen zien.
Ik bedenk het maar ter plekke, en ik ken de dropbox dienst ook niet erg goed, net even gekeken.
Als je je data hashed met een secret (key file of gewoon een wachtwoordje) dat de gebruiker alleen heeft. Op het moment dat je de medewerker toestemming wil geven, plaats je het dan in een (liefst een beetje veilige....) support applicatie, met het liefst een restrictie in deze applicatie zodat deze alleen in de context van dit support ticket gebruikt kan worden, oftewel, alleen door de medewerkers aan wie dit ticket gekoppeld is, waardoor je altijd kunt auditen.
Enig vertrouwen zul je toch altijd moeten houden bij een cloud dienst, anders moet je het zelf hosten.
Als je je data hashed met een secret (key file of gewoon een wachtwoordje) dat de gebruiker alleen heeft. Op het moment dat je de medewerker toestemming wil geven, plaats je het dan in een (liefst een beetje veilige....) support applicatie, met het liefst een restrictie in deze applicatie zodat deze alleen in de context van dit support ticket gebruikt kan worden, oftewel, alleen door de medewerkers aan wie dit ticket gekoppeld is, waardoor je altijd kunt auditen.
Enig vertrouwen zul je toch altijd moeten houden bij een cloud dienst, anders moet je het zelf hosten.
Als je begrip hebt voor het idee dat je toegang nodig hebt tot de encryptie sleutel om je klanten te kunnen helpen heb je fundamenteel geen goed begrip van security.
Een dropbox like dienst is alleen veilig als alle content van gebruikers wordt versleuteld met een key of passphrase voordat de data op de servers van die dienst terecht komen.
Deduplicatie is dan onmogelijk. Maar wat boeit eindgebruikers dat? De keuze om voor dienst x of y te kiezen zou bij mij gebaseerd zijn op de technische mogelijkheid voor x of y om bij mijn data te kunnen.
Dropbox kan ook bij je data om aan de wet (opsporing) te voldoen. Dat kan alleen als er een 'backdoor' is en daarmee is dropbox fundamenteel onveilig.
Dropbox gebruikers kunnen dit issue zelf oplossen door alle data in een truecrypt container te stoppen. Maar dat is niet zo gebruiksvriendelijk als dropbox.
Ik heb de materie een beetje gevolgd en de feiten zijn dat dropbox oorspronkelijk zijn gebruikers heeft misleid door de indruk te wekken dat het fundamenteel technisch niet mogelijk is voor dropbox om bij de inhoud van bestanden te komen, terwijl dit wel kon.
Daarmee heb je bij mij alle fundamentele vertrouwen verloren en zou ik zo'n service nimmer meer gebruiken zonder een truecrypt laagje er overheen.
Als zij beveiliging goed hadden toegepast, zouden ze zelfs niet in staat zijn om met de overheid mee te werken en data onversleuteld aan te leveren. Zoals het hoort. Anders is er gewoon geen sprake van security.
Hoe weet ik als end-user nu hoe dropbox met zijn 'backdoor' master key omgaat? Slingert die ergens op een floppy rond ofzo?
Maar zelfs andere services vergelijkbaar met dropbox die claimen dat ze wel 'veilig' zijn en niet dezelfde fout maken als dropbox: dat kun je alleen weten als je de client applicatie hebt gecode-reviewed, anders weet je nog niets. En dan resteert alleen nog de optie om dan ook daar maar truecrypt toe te passen, als zeker-voor-het-onzekere.
Niemand boeit mijn data. Maar ik zou het niet leuk vinden dat als dropbox gehacked zou worden ze via die master sleutels al mijn private info zouden kunnen uploaden naar the pirate bay.
En daarmee wordt het fundamentele probleem van zo'n 'backdoor' oplossing geillustreerd. Als dropbox ooit gehacked wordt moet je al je data als gecompromitteerd beschouwen. Bij een 'secure' oplossing zou zelfs bij een hack van dropbox weinig aan de hand zijn.
Een dropbox like dienst is alleen veilig als alle content van gebruikers wordt versleuteld met een key of passphrase voordat de data op de servers van die dienst terecht komen.
Deduplicatie is dan onmogelijk. Maar wat boeit eindgebruikers dat? De keuze om voor dienst x of y te kiezen zou bij mij gebaseerd zijn op de technische mogelijkheid voor x of y om bij mijn data te kunnen.
Dropbox kan ook bij je data om aan de wet (opsporing) te voldoen. Dat kan alleen als er een 'backdoor' is en daarmee is dropbox fundamenteel onveilig.
Dropbox gebruikers kunnen dit issue zelf oplossen door alle data in een truecrypt container te stoppen. Maar dat is niet zo gebruiksvriendelijk als dropbox.
Ik heb de materie een beetje gevolgd en de feiten zijn dat dropbox oorspronkelijk zijn gebruikers heeft misleid door de indruk te wekken dat het fundamenteel technisch niet mogelijk is voor dropbox om bij de inhoud van bestanden te komen, terwijl dit wel kon.
Daarmee heb je bij mij alle fundamentele vertrouwen verloren en zou ik zo'n service nimmer meer gebruiken zonder een truecrypt laagje er overheen.
Als zij beveiliging goed hadden toegepast, zouden ze zelfs niet in staat zijn om met de overheid mee te werken en data onversleuteld aan te leveren. Zoals het hoort. Anders is er gewoon geen sprake van security.
Hoe weet ik als end-user nu hoe dropbox met zijn 'backdoor' master key omgaat? Slingert die ergens op een floppy rond ofzo?
Maar zelfs andere services vergelijkbaar met dropbox die claimen dat ze wel 'veilig' zijn en niet dezelfde fout maken als dropbox: dat kun je alleen weten als je de client applicatie hebt gecode-reviewed, anders weet je nog niets. En dan resteert alleen nog de optie om dan ook daar maar truecrypt toe te passen, als zeker-voor-het-onzekere.
Niemand boeit mijn data. Maar ik zou het niet leuk vinden dat als dropbox gehacked zou worden ze via die master sleutels al mijn private info zouden kunnen uploaden naar the pirate bay.
En daarmee wordt het fundamentele probleem van zo'n 'backdoor' oplossing geillustreerd. Als dropbox ooit gehacked wordt moet je al je data als gecompromitteerd beschouwen. Bij een 'secure' oplossing zou zelfs bij een hack van dropbox weinig aan de hand zijn.
quote]
Aan de ene kant begrijp ik dat medewerkers de encryptiesleutels moeten hebben om klanten te ondersteunen... Aan de andere kant is het niet echt klantvriendelijk om je klanten voor te liegen.
[/quote]
Beter lezen BLue Entharion,
Daar gaat het hier helemaal niet om.[
Aan de ene kant begrijp ik dat medewerkers de encryptiesleutels moeten hebben om klanten te ondersteunen... Aan de andere kant is het niet echt klantvriendelijk om je klanten voor te liegen.
[/quote]
Beter lezen BLue Entharion,
Daar gaat het hier helemaal niet om.[
Ach, als je een dienst afneemt waarbij zowel de bestanden als de encryptiesleutels worden verstuurd, dan kun je er wel vanuit gaan dat ze ook bij de hostende partij bekend zijn, ja. Het staat en stond nota bene zo in hun voorwaarden. Ze stellen enkel dat de bestanden versleuteld verzonden worden, en dat ze versleuteld worden opgeslagen. Maar niet dat de account-houder de enige is die de sleutels kent. Die 'security' expert had blijkbaar wat media aandacht nodig. Slimme jongen hoor, 't is 'm gelukt
Dat geldt toch ook voor bedrijven die nog geen 'fouten' hebben gemaakt, of mag je eerst fouten maken?zou de FTC Dropbox moeten verbieden om in de toekomst opnieuw misleidende claims te maken.
[Reactie gewijzigd door watercoolertje op maandag 16 mei 2011 16:42]
Dropbox werkt goed, maar je moet er geen gevoelige data mee opslaan. Dat vertrouw ik tenmiste niet!
Je kunt natuurlijk eerst je bestand middels truecrupt versleutelen en daarna uploaden dan is er niks aan de hand
Alleen moet je bij wijziging van een password.kdb van enkele kilobytes ipv die kilobyters wel je hele truecryptcontainer van een gigabyte of meer gaan uploaden.
kdb is zelf al versleuteld. Nou weet ik niet hoe sterk die is, maar ik neem aan redelijk veilig, dus dat in een truecrypt container plaatsen is wat dubbelop.
Waarom doe je alsof TrueCrypt de heillige graal is van versleuteling? Heb je de broncode wel eens gezien?
nee dat is nou juist ook de bedoeling van dit soort software denk ik zo? Security through obscurity.
als je de broncode kent weet je ook de manier waarop truecrypt de boel versleuteld en kan zo alles "reverse engineren" om het originele ongecodeerde bestand weer te krijgen.
als je de broncode kent weet je ook de manier waarop truecrypt de boel versleuteld en kan zo alles "reverse engineren" om het originele ongecodeerde bestand weer te krijgen.
Dat is niet hoe de huidige encryptie werkt. Hoe Truecrypt werkt kun je gewoon lezen op wikipedia (bovendien kun je de broncode gewoon downloaden van hun site)
Mijn sarcasme detector is kapot. Meen je dit serieus of is dit sarcastisch bedoeld?
Je kan natuurlijk ook zelf je documenten encrypten met een 3rd party tool in je Dropbox map.
Hoezo is het onmogelijk om voor het encrypten van het bestand een cheksum te berekenen, en die ergens in een database te zetten zodat je volgende bestanden kan vergelijken? Tenzij een bestand geencrypted wordt aangeleverd aan de software/servers.Bij goed gebruik van aes-256-encryptie zou Dropbox niet kunnen detecteren dat er bij het uploaden sprake is van duplicatie van een bestaand bestand van een gebruiker.
En hoezo is het vreemd dat medewerkers de bestanden kunnen inzien als de keys bij dropbox in gebruik zijn om te encrypten? Dat ze het niet mogen lijkt mij veel waarschijnlijker, want een beetje sysadmin zou het wel voor elkaar moeten kunnen krijgen om de bestanden in te lezen (dat het niet mag van de baas is niet zetzelfde als niet kunnen).
Die checksum kan dan meteen gebruikt worden voor een brute force attack op de encryptie. Dat lijkt me niet wat je wilt.
Als je een groot bestand upload dat Dropbox al heeft dan duurt het uploaden luttele seconden. Wat je daaruit kunt afleiden is het volgende:
Dropbox heeft jouw data aan de server kant nooit in handen gehad. De data is dus de hele tijd op de client gebleven want anders kan het nooit zo snel. Dat betekend dat op de client een hashcode of md5sum of zoiets gemaakt moet zijn die op de server is vergeleken met al bestaande data. Kan niet anders, niet met deze snelheid.
Dropbox bewaard dus het originele bestand, versleuteld, de sleutel (onafhankelijk van gebruiker want anders kun je de data niet delen) en een hashcode of md5sum.
Ik denk echter niet dat je veel hebt aan een md5sum bij een brute force attack, hooguit om achteraf te controleren of je het origineel terug hebt gekregen, maar dat kun je ook wel op een andere manier controleren. Een md5sum of hashcode gebruikt zelf ook cryptografische technieken, het is vrijwel onmogelijk om daar iets uit te halen dat informatie prijs zou geven over de inhoud van het bestand.
Dropbox heeft jouw data aan de server kant nooit in handen gehad. De data is dus de hele tijd op de client gebleven want anders kan het nooit zo snel. Dat betekend dat op de client een hashcode of md5sum of zoiets gemaakt moet zijn die op de server is vergeleken met al bestaande data. Kan niet anders, niet met deze snelheid.
Dropbox bewaard dus het originele bestand, versleuteld, de sleutel (onafhankelijk van gebruiker want anders kun je de data niet delen) en een hashcode of md5sum.
Ik denk echter niet dat je veel hebt aan een md5sum bij een brute force attack, hooguit om achteraf te controleren of je het origineel terug hebt gekregen, maar dat kun je ook wel op een andere manier controleren. Een md5sum of hashcode gebruikt zelf ook cryptografische technieken, het is vrijwel onmogelijk om daar iets uit te halen dat informatie prijs zou geven over de inhoud van het bestand.
Of gewoon je bestanden versleutelen voor je ze in dropbox zet.
Dat zou Dropbox moeten doen volgens de algemene voorwaarden waar ik toendertijd mee akkoord ben gegaan. Als ze achteraf de policy veranderen zonder de gebruiker opnieuw deze te laten accepteren vind ik schandalig.
true, dat is de essentie, dat ze zelf beweerden veilig te zijn....
ohwja alsof jij die ook echt gelezen hebt. denk ff na man. Dit soort dingen zijn never nooit 100% veilig. voor thuis gebruik met wat fotos en muziek werkt dit. voor School werkt dit ook prima, maar voor gevoelige informatie mag en kan je alleen vertrouwen op CD's, DVD's en USB sticks die al dan niet versleuteld zijn.
Ik gebruik zelf SpiderOak. Mijn kwuze hiervoor was gevallen omdat zij (beloven dat ze) je bestanden nooit in kunnen zien. Ze hebben danook geeb privacy policy, maar een password policy; als je je wachtwoord kwijt ben ben je gewoon alles kwijt. Wanneer je het programma gedownload hebt spiked je cpu eerst even omdat hij een sleutel genereerd.
Als Spideroak wel doet wat ze beloofd, dan moet online backuppen in de cloud dus prima veilig kunnen zijn..
Als Spideroak wel doet wat ze beloofd, dan moet online backuppen in de cloud dus prima veilig kunnen zijn..
Kan Dropbox dan niet net zo goed vragen aan gebruikers of ze de MD5's willen meeleveren? Scheelt dat niet een hoop werk.. (Heb je wel last van mensen die geen MD5's kunnen maken...)
Dat werkt zo slecht vanuit de windows verkenner. Dropbox wordt onder Windows nl. geintegreerd in de verkenner.
Lijkt me overbodig, aangezien de Dropbox client dit zelf ook kan berekenen voordat het een bestand gaat uploaden naar de servers.
Oh, fijn... Dus voor ieder van de +- 1000 bestanden die ik heb geupload had ik dan eerst een MD5 moeten genereren? Ik zie liever dat de Dropbox-tool dit doet, die uploadt, er een check wordt gedaan of deze overeen komt met een ander bestand, en zo niet er geencrypt wordt geupload.
Dan moet nog steeds de key van dat bestand bekend zijn, anders kan je dat bestand niet delen tussen gebruikers.
Belangrijke / gevoelige bestanden sla ik gewoon zelf op. gewoon backup maken op externe harde schijf die je in je kluis legt, en voila: brand en waterbestendige backup.
Dropbox is niet alleen een backupsysteem maar ook een sharing-systeem. Ik zou het bijvoorbeeld voor gevoelige bestanden die ik met 1 persoon wil delen kunnen gebruiken. Het argument: "Maar dan doe ik het zelf!" vind ik zwak, en ik vind dat dropbox hier een goede beveiliging voor in zou moeten kunnen bouwen.
In dat geval zou ik het encrypten met PGP (met de public key van de ontvanger). Dat kan niemand het lezen behalve de ontvanger. Zelfs de afzender kan het net meer teruglezen. Het met PGP versleutelde bestand kun je gerust op Dropbox zetten.
Dat ben ik met je eens. Ze zouden het inderdaad beter moeten beveiligen. maar ik doe het al jaren zo, en het heeft tot nu toe altijd al gewerkt... maar je hebt gelijk, het delen wordt dan wat lastiger. Bestanden die ik deel in mijn netwerk, die gevoelige informatie bevatten, versleutel ik gewoon 256 bit AES met winzip pro. Als ik iets zou uploaden, zou ik het in ieder geval zelf eerst versleutelen, voordat ik het upload. Ik vertrouw dit soort systemen namelijk niet echt. maar ieder zijn voorkeur natuurlijk, ik begrijp je punt absoluut. Bestanden die ik over me netwerk wil delen staan gewoon op me allround pc, (storage, messenger, gamen) en ik maak 1x per week een backup op me externe HDD (zoveel download wijzig ik niet)
[Reactie gewijzigd door _-SaVaGe-_ op dinsdag 17 mei 2011 08:00]
Tsja, ik snap in het geheel niet waarom jij 1 gevoelig bestand via dropbox wil delen met 1 persoon 
Dan kun je dit beter doen via e-mail of via een direkte verbinding met die persoon met een private server, zoals HFS, even een mailtje naar die persoon dat je servertje bij staat, downloaden en de server weer uitzetten, werkt veel beter dan de boel even op dropbox te zetten.
Dan kun je dit beter doen via e-mail of via een direkte verbinding met die persoon met een private server, zoals HFS, even een mailtje naar die persoon dat je servertje bij staat, downloaden en de server weer uitzetten, werkt veel beter dan de boel even op dropbox te zetten.
en toen smolt je hd/floppy/tape door de enorme temperatuur tijdens de brand, maar de kluis doet 't nog!
Daar heb je dus brandwerende kluizen voor http://www.safe2lock.nl/a...NHutanN7qgCFQhO3god8R0yxA
http://www.safe2lock.nl/a...NHutanN7qgCFQhO3god8R0yxA
Die werken ook maar tijdelijk. Dan moet 't vuur kortstondig zijn.
Trouwens... 30 minuten voor papier... Intussen hebben je HD's in zo'n safe waarschijnlijk al lang eerder 't loodje gelegd.
Trouwens... 30 minuten voor papier... Intussen hebben je HD's in zo'n safe waarschijnlijk al lang eerder 't loodje gelegd.
[Reactie gewijzigd door kimborntobewild op dinsdag 17 mei 2011 18:45]
Toen viel er een oude Russische MIG op je backup center en weg was de boel, zo ken ik er nog wel 1000
Ja ze hebben altijd geclaimd dat ze echt niet bij je bestanden konden terwijl dat natuurlijk onmogelijk is. Om je data te versleutelen heb je hoe dan ook een key nodig. Als eindgebruiker heb je nooit een key hoeven genereren of opgeven. Dus dan kun je wel raden wie die sleutel dan heeft: yep, Dropbox zelf. Dus dat ze nu in eindelijk toegeven dat ze wel bij de bestanden kunnen, komt niet echt als een verrassing.
Dat is natuurlijk ook niet waar. Openssh genereert ook keys, maar Theo de Raadt heeft niet jouw sleutels.
Wat je zegt klopt niet, gang-ster. Goed lezen wat sys64738 schrijft...
Als je gebruik maakt van OpenSSH, wat op je eigen computer draait, dan gebruik je het zelf om keys te genereren, en die keys heb jij zelf in beheer, ze staan op je eigen computer. Daar heeft de auteur van OpenSSH verder niets mee te maken.
Bij Dropbox versleutelen zij alle data voor je die je in je Dropbox-folder zet, zonder dat jij daar zelf iets voor hoeft te doen. Dropbox beheert de sleutel. Vrij logisch dat er bij Dropbox dus medewerkers zijn die in principe toegang hebben tot je bestanden.
Dus het is niet "niet waar" omdat OpenSSH ook keys genereert.
Als je gebruik maakt van OpenSSH, wat op je eigen computer draait, dan gebruik je het zelf om keys te genereren, en die keys heb jij zelf in beheer, ze staan op je eigen computer. Daar heeft de auteur van OpenSSH verder niets mee te maken.
Bij Dropbox versleutelen zij alle data voor je die je in je Dropbox-folder zet, zonder dat jij daar zelf iets voor hoeft te doen. Dropbox beheert de sleutel. Vrij logisch dat er bij Dropbox dus medewerkers zijn die in principe toegang hebben tot je bestanden.
Dus het is niet "niet waar" omdat OpenSSH ook keys genereert.
[Reactie gewijzigd door jj71 op dinsdag 17 mei 2011 07:32]
Ik vind de TOS eigenlijk alleen maar duidelijker geworden op deze manier.
Los daarvan heb ik niet kunnen vinden waar Dropbox nou eigenlijk claimt dat medewerkers niet bij de bestanden kunnen. De claim van geen toegang stond op de help-pagina, wat mij meer ongelukkig lijkt gezien er niet zoiets in de TOS staat. De wijziging van de TOS voegt alleen maar toe dat medewerkers bij de bestanden kunnen. Er stond daarvoor niet dat medewerkers dat niet kunnen.
Daarnaast staat in het artikel dat Dropbox bestandsnamen vergelijkt. Dit lijkt me echt heel erg stug, want bestanden met dezelfde naam hebben niet perse dezelfde inhoud. Logischer lijkt me dat Dropbox een hash van de bestanden vergelijkt om te kijken of ze hetzelfde zijn. Stel dat je de bestandnaam gebruik en je voegt een README.txt toe? Dan moet worden gekeken welke van de 100000 README.txt bestanden hetzelfde is. Lijkt mij niet efficiënt. Daarnaast hernoemen mensen bestanden. Puur op bestandsnaam afgaan betekend dat als ik ubuntu-11.04-desktop-i386.iso nernoem naar ubuntu-natty-desktop-i386.iso er niet zou worden gekeken of het bestand al bestaat. Lijkt me echt niet handig.
Ik denk dat er tabellen zijn met hashes (en bestandsnamen/locaties) en dat van nieuwe bestanden wordt gekeken of ze al bestaan en zo ja, dat dat bestand niet opnieuw toegevoegd wordt.
Los daarvan heb ik niet kunnen vinden waar Dropbox nou eigenlijk claimt dat medewerkers niet bij de bestanden kunnen. De claim van geen toegang stond op de help-pagina, wat mij meer ongelukkig lijkt gezien er niet zoiets in de TOS staat. De wijziging van de TOS voegt alleen maar toe dat medewerkers bij de bestanden kunnen. Er stond daarvoor niet dat medewerkers dat niet kunnen.
Daarnaast staat in het artikel dat Dropbox bestandsnamen vergelijkt. Dit lijkt me echt heel erg stug, want bestanden met dezelfde naam hebben niet perse dezelfde inhoud. Logischer lijkt me dat Dropbox een hash van de bestanden vergelijkt om te kijken of ze hetzelfde zijn. Stel dat je de bestandnaam gebruik en je voegt een README.txt toe? Dan moet worden gekeken welke van de 100000 README.txt bestanden hetzelfde is. Lijkt mij niet efficiënt. Daarnaast hernoemen mensen bestanden. Puur op bestandsnaam afgaan betekend dat als ik ubuntu-11.04-desktop-i386.iso nernoem naar ubuntu-natty-desktop-i386.iso er niet zou worden gekeken of het bestand al bestaat. Lijkt me echt niet handig.
Ik denk dat er tabellen zijn met hashes (en bestandsnamen/locaties) en dat van nieuwe bestanden wordt gekeken of ze al bestaan en zo ja, dat dat bestand niet opnieuw toegevoegd wordt.
[Reactie gewijzigd door mpkossen op maandag 16 mei 2011 17:16]
maar ze doen het wel. probeer maar eens. een 40 GB groot bestand met de naam henk.jpg zal gewoon worden vervangen door een 2 KB bestand dat ook henk.jpg heet als jij daar geen halt voor zet.Daarnaast staat in het artikel dat Dropbox bestandsnamen vergelijkt. Dit lijkt me echt heel erg stug, want bestanden met dezelfde naam hebben niet perse dezelfde inhoud.
Natuurlijk niet. Men controleert doormiddel van hashes. De kans dat twee verschillende bestanden dezelfde hash opleveren is verwaarloosbaar. Zeker als men ook de bestandsgrote vergelijkt.
Eh:Bij goed gebruik van aes-256-encryptie zou Dropbox niet kunnen detecteren dat er bij het uploaden sprake is van duplicatie van een bestaand bestand van een gebruiker.
Stap 1. Upload bestand
Stap 2. bereken Hash (MD5/SHA1)
Stap 3. Sla hash op.
Stap 4 encrypt het bestand en sla het op.
Volgende keer wordt er bij stap 2 bekeken of een ander bestand dezelfde hash heeft, zoja dan bestaat het bestand al, zo nee dan door naar stap 3 en 4.
Dus hoe kan hier geen AES gebruikt worden op een goede manier?
Ok, dan vind je dus een duplicate hash bij een andere gebruiker en dan?
Dan is jouw bestand snel geüpload maar nergens bruikbaar zonder een eeuwigdurende decryptie zonder dat je de sleutel hebt...
Dan is jouw bestand snel geüpload maar nergens bruikbaar zonder een eeuwigdurende decryptie zonder dat je de sleutel hebt...
Het probleem zit 'm in stap 4: deduplicatie werkt alleen als de key bekend is bij Dropbox. Encryptie is namelijk een 2-richtingsproces waarbij al tijdens de encryptie de sleutel bekend moet zijn.
M.a.w. als het bestand al aanwezig is in Dropbox (kun je idd voor encryptie met hash bepalen) dan zou Dropbox aan jou de sleutel moeten geven zodat jij op de juiste manier kan decrypten als je later weer downloadt. De sleutel moet dan dus bij Dropbox bekend en opgeslagen zijn.
Als dat niet zo is kun je inderdaad wel dedup opslaan, maar kan alleen de gebruiker die het eerst heeft geupload bij jouw (zijn eigen) file komen omdat hij de enige is met een werkende sleutel
M.a.w. als het bestand al aanwezig is in Dropbox (kun je idd voor encryptie met hash bepalen) dan zou Dropbox aan jou de sleutel moeten geven zodat jij op de juiste manier kan decrypten als je later weer downloadt. De sleutel moet dan dus bij Dropbox bekend en opgeslagen zijn.
Als dat niet zo is kun je inderdaad wel dedup opslaan, maar kan alleen de gebruiker die het eerst heeft geupload bij jouw (zijn eigen) file komen omdat hij de enige is met een werkende sleutel
Op dit item kan niet meer gereageerd worden.
Populair: Asus Samsung Mobiele telefoons Laptops Apple 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
