dicono che fanno deduplicazione.
i casi sono due: o n copie dello stesso file cifrato sono tutte diverse, e allora la eduplicazione non funziona, o sono tutte uguali e allora è immediato vedere chi ha cosa.
insomma, qualche sopracciglio sulla privacy, il piu' grande selling point, IMHO va sollevato.
d'altro canto, non mi pare che kim.com sia esattamente un paladino delle libertà digitali, non più di quanto gli basta per i suoi affari. (ricordo le pistole fumanti di megaupload)
Megabad: A quick look at the state of Mega’s encryption | Ars Technica.
i casi sono due: o n copie dello stesso file cifrato sono tutte diverse, e allora la eduplicazione non funziona, o sono tutte uguali e allora è immediato vedere chi ha cosa.
insomma, qualche sopracciglio sulla privacy, il piu' grande selling point, IMHO va sollevato.
d'altro canto, non mi pare che kim.com sia esattamente un paladino delle libertà digitali, non più di quanto gli basta per i suoi affari. (ricordo le pistole fumanti di megaupload)
Megabad: A quick look at the state of Mega’s encryption | Ars Technica.
The fact that encrypted data is not a total mystery to Mega is the most troubling issue. On one hand, the reason behind implementing a block-based data deduplication scheme is obvious: storage is cheap, but it's not that cheap, and the distributed infrastructure providers supplying storage to Mega don't have to waste space storing non-unique data—instead of 10,000 copies of The Hobbit, the service would only store a single copy, freeing up terabytes of space (though the scale and scope of the deduplication isn't known yet, so this may be optimistic). On the other hand, even if the service doesn't know those blocks of data happen to be The Hobbit, the service does know which users own those deduplicated blocks, and if one user is implicated, there's proof against all the others, too.
Mah.. su moli di dati così grandi: dividi in chunck di n MB più meno fissi, ne fai l'hash e vedi se qualcun altro ha un chunck con lo stesso lo stesso hash; se sì ne tieni una copia sola. Algoritmo da complicare a piacere per evitare collisioni, distribuzioni su N server e gestire il fatto che i chunk sono dati cifrati (sulla carta) e i comuni hash non funzionino molto bene.
Mi pare che in quel modo non ci sia bisogno di sapere cosa ci sia effettivamente nel chunk.
Scritto da: Anonimo codardo | 27/01/2013 a 22:31
se lo dovessi fare io terrei criptato solo il modo con cui i chunck si devono ricomporre ed a chi debbano essere assegnati, detto in altri termini il gestore sa solo che quei chunck sono di qualcuno ma non sa dire di chi sono e non sa con quali altri chunck si debbano ricomporre per formare un file
Scritto da: Dino Bortolotto | 28/01/2013 a 17:05
«MEGA indeed uses deduplication, but it does so based on the entire file post-encryption rather than on blocks pre-encryption. If the same file is uploaded twice, encrypted with the same random 128-bit key, only one copy is stored on the server. Or, if (and this is much more likely!) a file is copied between folders or user accounts through the file manager or the API, all copies point to the same physical file.»
Se non ho capito male (non sono un tecnico), solo se il file è stato caricato dallo stesso account, e dunque crittografato con la stessa chiave, allora non viene duplicato.
Scritto da: Marco M. | 29/01/2013 a 18:28