>"Our service may automatically delete a piece of data

>>42832990
>2014
>Trusting a third party to encrypt your files

top kek

encrypt the files with PGP and they can't violate your privacy even if they tried

>>42832990
it's still going to be encrypted you retard, it's just if there's a duplicate file with the same encrypted contents it'll delete the duplicate.

>>42833054
That would mean they use the same encryption key for everyone. Then what's the point of encrypting it at all? Mega would know the decryption key, which is as good as law enforcement knowing it.

>>42833054
That means they have to be able to decrypt it.
The same file encrypted with two different keys will not create the same hash.

>>42833054
What the fuck am I missing here? Don't the contents need to be decrypted first, in order to be recognized as duplicate?

>>42833084
NO. They don't know what it is, they only know it's the same.

Deduplication. It can be done with hashes of encrypted files. Its actually nothing to worry about.

The only worry you can have is that your encrypted files probably never get deleted.

>>42833101
that's only if they were encrypted with separate keys. if they were encrypted with the same key, however, it's self-explanatory how they could be compared to see if they're the same.

>>42833155
Mega claims to encrypt your data at the browser level using your own key that no one but you has access to. If this part of their ToS is true however that means they're lying about that.

>>42833155
So they provide the same encryption key to the uploader if the same file already exists? How does Mega know the encryption key of the original copy then?

Encrypt the master key with different header keys.

>>42833173
>>42833191
they could easily enough just have a hash of the file's contents before it's encrypted, and use that to check for duplicates.

not hard.

>>42833225
Which means their claim that they don't know what data you have is a lie, since they're hashing your data before you encrypt it.

>>42832990
>keeping sensitive data on the internet
>not encrypting it locally and the uploading shit
I keep backup of my flacs and games in encrypted 7zips. Can't give two shits what they do with it as long as they saturate my 100mbit connection.

>>42833236
so you're saying you can determine a file's contents from a hash alone?

6D9C0DB426AA723248B95E429F4275F1

what does that mean to you? can you tell what's in it? no.

>>42833236

they probably check by file size

If identical shit won't fly, just like on 4chan

I believe that MEGA should be used for storing your porn. But not child porn. That shit doen't belong on the internet. It belongs deep under encryption on a secure HDD only accessible through SFTP/SSH

Who gives a fuck? MEGA is a great service but you should trust NO third party cloud service with sensitive data. I use MEGA all the time but treat it as if all my data on it is compromised. Any 3rd party cloud host should be treated in this manner.

>>42833278
No, I'm saying the same data encrypted with two different keys will produce two different hashes.
The fact they are able to hash and detect duplicates where the data is claimed to be encrypted with per account private keys mean they are lying about something.

>>42833279
>they probably check by file size
There are plenty of things that have standardized filesizes right down to the bit. ROM dumps for example are usually padded with 0s. If they did that for deduplication then they'd run into problems VERY quickly.

>>42833236

They still don't know what it is though, so it's not exactly a lie

If the files are encrypted, the file is unique to every single file hosted on that website.

>>42833279
they actually probably check MD5s or something other than file size. I could have two split RARS, each exactly the same fucking byte-age. That doesn't mean they are the same.

>>42833323
If they are able to create hashes of the same data despite differing encryption keys then yes, they must be able to know what it is. They can pinkie promise and say they don't check anything but the hash, but the fact is that if they can hash it they can read it.

>>42833322
i know that separate data encrypted with the same key won't produce the same hash.

i'm saying that they could perhaps store a hash of its (unencrypted) data when you upload it, and this is used to check for duplicates.

just a guess.

>>42833355
Mega was created with the concept of encrypting you data at the browser level before you even begin uploading to their servers.

So either they use your browser to hash files, which also means they can analyze them, or they have some kind of universal key that they can use to decrypt any user's file.

>>42833347

And what if they hash it before it's uploaded? They still won't know the contents.

>>42833388
like i said before, a hash alone cannot determine a file's contents. it gives no information about what's in it. correct me if i'm wrong about that.

honestly, i don't know. you'd be wise to trust some of the posts in this thread which state that you should treat it like it's compromised

>>42833401
>>42833420
They need to be able to read the file to create the hash.
What don't you understand about this? Hashes aren't magical, they use the file's data as an input for an algorithm that creates the hash.

>>42833443
yes, we established that. like i said, your browser could be asked to generate a hash to use when the file's uploaded. and that's what i'm saying they -could- use to check for duplicats. what don't YOU understand about this?

>>42833443
You can do that in JavaScript without having to upload the file, Anon.

>>42833401
If they really hash it before uploading you could exchange the hash for another one and make their system think your file is unique, even if it's not...

>>42833388
Or maybe they just use deduplication on their storage machines just like pretty much any other company that stores a lot a potentially duplicate data? It's a standard thing that everybody uses, they're not decrypting your files, you're all freaking out over noting.

>>42833455
It means they are reading your files and sending info about the files back to their servers.
No, they don't have to analyze the data further than creating a hash, but there is absolutely no reason to assume otherwise.
It's like using Tor to go on the clear web. Yes, you probably won't get a malicious exit node, but you'd be naive to assume that you're not on one.

>>42833480
>Or maybe they just use deduplication on their storage machines just like pretty much any other company that stores a lot a potentially duplicate data?
That's impossible if all the data is encrypted with keys they claim they don't know. Again, the same exact data, bit for bit exact, will produce different hashes if they are encrypted with different keys.
101101 encrypted with the key "fag" will produce encrypted data that hashes differently than 101101 encrypted with the key "nigger".

>>42833478
See the first section.

>>42833480
if every user has their own encryption key, then data will never be deduplicated, because even duplicate data will look different

>>42833513
when did i say they were reading your files? if you read my post properly, i said that -your- browser could generate the hash. all you're sending to their servers is the computated hash. refer to >>42833478 Anon's post.

Hash the file and use that as the key of the file. Hash the encrypted file. Then use this hash as the name of the encrypted file. Then all duplicate files will be detected, but mega has no idea what it is.

Now if you encrypt the header another time with your own unique password, then only ypu can decrypt it and only who uploads the same file can create a password for the file.

>>42833513
What don't you get? All they care about is if the encrypted files are duplicate. Deduplication is widely used on large storages, it does not care whether the file is encrypted or what the key is.

>>42833532
Mega claims to not have the decryption key for any file. So even if they store the hash of the decrypted file and use it to compare it to any uploaded file, they wouldn't be able to provide the decryption key to the existing encrypted copy.

>>42833532
that wouldn't work either, because then if you deduplicated two pieces of data that were encrypted with different keys, someone is going to receive a copy of the data later that was made with a different key

There was a talk where the MEGA developers said that hashes are computed on the unencrypted files. They gave advice for the paranoid at the end of their talk saying that if you don't trust them you should pad, encrypt, and rename your sensitive files before uploading them to MEGA. Seems like reasonable advice to me.

>>42833532
You didn't, I did. To create a hash of a file you must put that file through a program that runs the data as an input for a hash creating algorithm.
Now, if we assume they're creating hashes on your computer, that still means they are reading your (or if you want to be technical, making your computer read your) file to create a hash which they then send to their servers.
In either case data about that file is being sent to their servers.
Like I said before, you can assume all they do is hash and nothing else, but it's just that, an assumption.
You can assume that no one will go into your house if you leave it unlocked in a "good" neighbourhood, but I think we can all agree that's just naive and reckless to do.

>>42833563
With all the NSA bullshit going on why would you assume all they care about is the hash?

>>42833563
if the same data is encryped with two different keys, the two resulting encrypted files are NOT DUPLICATES ANYMORE, they are comprised of different bits, and can only be read with the one corresponding key (not both/either)

If the encryption is really done client side, you can fucking read, or even debug, the JavaScript they use to hash it. Check for yourself.

MEGA stores both the encrypted files and the keys to those files. They're probably stored on different servers, but whenever I log in I get to see the keys for all of my files, which means that they have them.

So obviously what MEGA does is:
>before uploading file, first hash it
>compare database to determine whether there is a file already there with the same hash and filesize
>if there is, let the user upload it, decrypt the existing file, confirm match
>if they match, discard the uploaded file, add the existing file to the user's personal folder, along with the existing key

The additional step of encryption is just an argument against checking all of their files for illegal content. They can decrypt any file they want to, but it's infeasible to do to all of their files.

>>42833669
if they have access to all the keys

why even bother encrypting anything?

>>42833129
>They don't know what it is, they only know it's the same.
Fucking kek. How would they know if it's the same if they don't know what it is?

>>42833776
The checksum of the file that is transmitted, because of how the internet works, prior to the upload itself and before encryption.

>>42833806
It can even be done after encryption with an unique key, see >>42833555

>>42833806
>checksum
ok genius, how the FUCK are they supposed to delete some of the old data if it's encrypted then? The other person wouldn't be able to fucking decrypt it you hoodlum. Unless if that one key could decrypt both files, in which case your super secret special key isn't going to be good because other keys can decrypt it anyways.

>>42833844
>Checksum is transmitted
>File is encrypted
>Checksum remains attached to the file as an identifier for this exact purpose
Are you stupid or something?

It's called hashing it jackss.

It might do an md5 hash on something you uploaded, and then reject/delete something with the same md5 hash. Nothing wrong with that. Even if it's encrypted they can do that.

>>42833104
No, hurrr, they don't.

>>42833879
It's not something they're intentionally doing. The information they're using is an INTRINSIC PART OF A FILE UPLOAD HEADER EVERYWHERE ON THE INTERNET.

They're just deciding to put it to use.

If they terminated this feature, they would still receive the hash/checksum because you cannot send files without it.

File: autism-040.png (557KB, 772x1024px) Image search: [Google]

557KB, 772x1024px

>>42833879
>Even if it's encrypted they can do that.
I'm done.

>>42833857
>>Checksum is transmitted
>>File is encrypted
>now supposedly only your key can decrypt the encrypted file because that's how cryptography works
>oh fuck, someone tries to upload the same file
>points to your "useless" encrypted data because the checksums are the same
>can somehow decrypt it anyways
Encryption does now work how you seem to think it does.

>>42833905
There's no decryption. File A has a hash/checksum of S145, and this is universally unique. It is encrypted and never decrypted. Another file is uploaded with the checksum of S145. Without even decrypting the other file, you know they're the same file.

>>42833922
But how does the uploader of the duplicate file get access to that file on mega? It's encrypted, and mega does not have the password.

>>42833922
Why the fuck would deleting the new file with the same checksum be an option then? You'd only be able to delete the duplicates if both keys could, somehow, decrypt the same encrypted file.

>>42833905

Let me spell this out for you, because you're clearly a moron:

1. File is uploaded to MEGA, unencrypted. People do not upload already-encrypted files. This is a service MEGA provides.

2. In the file transfer header, among other data, a hash/checksum is offered. MEGA accepts it and names the file with this key.

3. File is encrypted.

4. Although the file is now encrypted, and never decrypted, it has a unique identifier as a filename that can be used to pair it with other files.

>>42833922
He's saying Mega claims your files on the server are encrypted with your own private key.
If that's true then it should be impossible for them to deduplicate data because even if they did hash before the data is encrypted only one person who uploaded that file should be able to decrypt it because the data should be encrypted with a key that even mega claims they don't know.

Goddammit, /g/, you're embarassing yourself again.
>hurr durr it's the same contents
>so I can delete duplicate that is encrypted with different key

>>42833945
Because the encrypted file's filename or meta data contains the hash, and MEGA searches for any files with a similar hash of a pending upload.

>>42833956
You can delete encrypted files without decrypting them.

>>42833960
Where Is this file header containing the checksum? It's not part of the http spec for file uploads.

>>42833960
https://blog.fortinet.com/Security%20Research/DotComs-Mega-Encryption-Scheme-Illustrated/

Mega claims your files are encrypted before they go to the servers.

>>42833981
>You can delete encrypted files without decrypting them.
Then one of the users won't be able to decrypt the encrypted file you fucking retard.

>>42833669
READ THIS YOU RETARDS.

>>42833997
Yes it is. No matter what website your on, this is a subset of the data that is transmitted prior to file uploads. It's fundamental to the Internet.

>>42833998
It's encrypted client-side AFTER upload. They HAVE to have already received the file for them to encrypt it in any way.

Please use your brain for a moment and think about this. How can they be encrypted before the hit the servers, without them having access to them, i.e., by them being uploaded?

You're not understanding what they're describing, namely, client-side encryption.

You idiots, I posted the solution to this already. It isn't encrypted just a single time. It's encrypted one time using a hash of a file as the key. So all uploaders create a duplicate encrypted file that looks the same. with a very unique key as the key is the fucking hash of the original file. This means every fucking file has it's own unique key, except duplicates.

Now you can use the hash of this encrypted file to recognize duplicates, while no one knows what it is except the uploaders.

Now encrypt that key another time with the personal key of the user. And every user that uploads the file, can access the file. And nobody else.

>>42833905
>now supposedly only your key can decrypt the encrypted file because that's how cryptography works
you aren't the one encrypting it
they are

The only way they know which files to delete are when links are publicly posted with their respective keys in the URL.

>>42834022
>It's encrypted client-side AFTER upload
So let me get this straight, you upload the information, THEN ENCRYPT IT AND UPLOAD IT AGAIN?

>>42834022
>Please use your brain for a moment and think about this. How can they be encrypted before the hit the servers, without them having access to them, i.e., by them being uploaded?
They claim to use client side javascript.

>>42834016
Except this service only applies to your files. They're not deleting other people's files because you uploaded a duplicate you absolute mongoloid. They're deleting YOUR duplicates to save space.

>>42834022
Tcp does Checksumming on packets. Http works on top of tcp, but the tcp checksum does not correspond at all with the file checksum. You need to be more clear about exactly where this checksum appears.

>>42834047
Yes. It passes through their MEGA client, is encrypted, is sent server-side, and is encrypted again. This is a multi-step process.

>>42834030
Using the file contents as the key could work, but that's not how mega claims it's done.

>>42834030
that doesn't count as encryption. there's no secret in the key. It's just obfuscated.
The content owners of pirated stuff for example could easily check for the presence of their stuff on the site and then force them to give out the uploader's info

>>42834050
>or give someone else access
Stop being a fucking retard and learn to read, it applies to other people's files as well.

>>42834105
[citation needed]

A lot of people are saying "They can hash it before encrypting and uploading which makes it okay", but that also does not work.

Since the keys are supposed to be per user, even if it knows I upload the same data as Bob, Bob's data must be encrypted with his key (which I do not know) so I can't download his data and use it.

Sure, that works and lets them only store one copy of data, but it also means only the original uploader can access it ever...

If I can download bob's data because my pre-encrypt hash matches his pre-encrypt hash that means Bob's encryption must have been compromised somehow, else I couldn't access it without his key.

This is fucked if they do it. There's absolutely no way to securely dedupe. Zero.

>>42834111
It's in the OP you fucking mouthbreather.
http://www.zdnet.com/review-what-to-expect-from-megas-free-50gbs-of-cloud-storage-7000010089/
http://www.networkworld.com/article/2223879/microsoft-subnet/testing-the-privacy-company-mega--50gb-free-storage--2048-bit-encrypted-protection.html
http://www.bestfilessharing.com/tos
http://www.shadygamer.com/threads/the-launch-of-mega.36807/
http://www.digitaltrends.com/web/terms-conditions-mega/
http://beta.slashdot.org/submission/2456725/mega---is-it-really-secure-

this is a good thing. this is how all file sharing and even video sharing sites should work. people shouldnt be allowed to post 20 of a file with different qualities and crap like that.

>>42834020
>>42833669

>whenever I log in I get to see the keys for all of my files, which means that they have them.

MEGA does not have your keys. They are stored locally on your machine.

>>42834132
Pick one link and quote the relevant portion, if you can.

Hint: You can't. MEGA doesn't delete person Y's movie just because you uploaded the same movie. That would prevent them from being able to access it themselves.

Ergo, it doesn't happen and you're wrong.

>>42834095
What you said does not work nor make any sense.

If it's encrypted with the user's key after the hash (not encryption), it's still not accessible to everyone. That doesn't work. Nice try.

If it does work, then it's even worse because it means the per-user keys are not strong encryption and are shared. gg.

>>42834137
I'll entertain you even though you don't understand the issue at all. If there are 20 different qualities of the same movie, who decides which file should be the right one that is kept?

>>42834151
>MEGA doesn't delete person Y's movie just because you uploaded the same movie
https://mega.co.nz/#terms
Right here retard, "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."
They'd have to know what you're uploading and what is already on their server.
It's in the fucking mega ToU so you can't fucking say they don't do it.

ITT: /g/ tries to figure out how MEGA works while pretending they know it works and everyone else doesn't

learning through being abrasive cunts

>>42834162
It's obvious the pre-user encrypted keys exist and are shared. It's the only way.

>>42834179
That clearly describes your own files.

>A piece of data you upload
>Or give someone else access to (from your own store of files)

Where does it mention other people's files?

>>42834137
>>42834170

Moot point, there is no programmatic way to determine image / movie duplicate when not completely identical (read, different quality).

For example, creating an image with 10 pixels different (e.g. take picture of president, make his eyes read to indicate evil) could have significantly different meaning. Alternately, 10 pixels different could be simple compression (eyes slightly blurred, thanks diff jpg compression algo)... You absolutely cannot differentiate minor human changes with compression / quality changes

It's unreasonable for a human to review all files nor can they due to encryption.

Quality must have a human component and this discussion concerns only exact duplicates and automated backend stuff. In other words, fuck off.

If you want your feature, you need users to tag files with what they are and their quality.

>>42834191
All the users just create duplicate master keys each time they upload a file. That's the magic trick.

>>42834143
Just remoted into another machine to confirm you're full of shit. It would also be a terrible idea if it were true.

>>42834179
Well strictly speaking they don't necessarily have to do it even though it's in their ToS. It's possible they only dedupe files encrypted with the same key (I.e same user)

>>42834222
You would be asked to provide your key.

This is called basic security.

They warn you that if you lose your key, your files are lost forever.

>>42834191
Mega said it didn't do that. Mega said it was zero-knowledge encryption (at first). Maybe it's fucked now.

If another user can get your key to decrypt, so can mega. They said they can't ever see your data there. Contradiction, aha, etc etc.

>>42834170
>you don't understand the issue at all

i'm not that dude, but you clearly don't understand anything about this thread? go back to /v/ or /b/ pls

>>42834239
You clearly don't understand what I posted here >>42834030

A hash of the original file is the master key. And mega does not have the original file.

>>42834196
>what is reading
>>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
>Our service may automatically delete a piece of data you upload
>where it determines that that data is an exact duplicate of original data already on our service
>already on our service
On the service, as in anywhere in the mega servers.
It would be fucking useless if all it did was keep duplicates off of your data.

>>42834238
If you want actual security, it makes more sense to encrypt the files yourself.

The way I see it, the encryption is probably implemented in such a way that it's unlikely that the government can get their hands on both the keys and the data. Intrusion of one system will trigger a dead man's switch on the other. I'm not sure, just speculating at this point.

>>42834170
bah.
>it determines that that data is an EXACT duplicate of original data

btw, if you this bothers you that it's provable that the file you uploaded is the same as the file someone else uploaded, you can just change a single byte (or if that's not feasible encrypt with almost any weak-ass encrpytion and a random key), and noone can ever know what you uploaded

>>42834241
What do you mean?

of course, this still means if you take a random wikileaks document and just upload it, if the government also gets access to the document they can find all the people who uploaded it

>>42834331
this
>>42834303

files of the same movie with different quality are NOT the exact same files, so they'll all be stored

>>42834351
Yeah. And Mega is not responsible because they are oblivious. It's zero knowledge for mega and that's all they care about.

>>42834381
"Zero knowledge" has a very specific meaning in crypto. Look it up. It's not "oblivious".

>>42834371
The guy was talking about deduping different qualities of the same file. I was explaining how that doesn't even remotely begin to work (I.e. Not understanding the issue at all), and thus entertaining him with even how unfeasible that is on a theoretical sense.

>>42834381
it most likely save them a ton of money, and most people don't need unique encryption. those who need are responsible to make the file unique themselves. i don't think it's wrong, it saves global storage which is better for everyone

>>42834406
my apologies

>>42834406
Was he really being that retarded? Or were there multiple idiots?

>>42834484
There are lots of idiots in this thread already

File: 1347900834389.jpg (335KB, 1200x838px) Image search: [Google]

335KB, 1200x838px

Wait, were people actually trusting that fatfuck "Dotcom" about anything encryption related?

Don't get me wrong, Mega is one of the better file hosts, but I would never put anything sensitive on there without having encrypted it myself.

>>42834022

dunning-kruger effect in full force here.

>>42834170
>If there are 20 different qualities of the same movie, who decides which file should be the right one that is kept?
this can easily be done with repository style management. for example, that new music device that was on kickstarter only hosts the best versions of hit songs. they determine this by doing a bit of research with the community to determine which is the lossless file right out of the studio. same can be done with video or anything else.

>>42833308
it doesnt belone anywhere you piece of shit
kill yourself

>>42836515
They will not ban you. MEGA is particularly awesome because you can essentially use infinite accounts to have infinite amounts of storage for free. Max out one account but put all your data in one folder and not right at the root and then create a new one. With your new account share that root folder you created with everything in it. You can keep doing this and build up accounts with your previous ones sharing with the current one. You can access all your previous data from other accounts and keep adding more. I have done this with an obscene amount of data for over a year and have not been banned.

>>42833236
No, probably what happens is YOUR BROWSER hashes the data and SENDS it to THEM before YOUR BROWSER encrypts and uploads it to THEM

>>42836555
Don't you think that, if enough users figured that out and started doing it, MEGA would put an end to it, just to prevent possible revenue loss?

anyone have tried mega sync? is it good?
i'm on linux and i can't try it out

>>42834049
I'm guessing that whatever software they use to encrypt in the client also sends the checksum to the server. The question is whether or not that is problematic, and I say no.

>>42836657
Not him, but I think that's unlikely. Their brand really revolves around their reputation, cracking down like that would damage them far more than a minority of individuals taking the piss with storage.

>>42836661
The official Windows client is quite good. It's very low on resources and does what it is asked to do. There is no official Linux client yet though they recently released the second version of their SDK so there's probably some sort of third party tool available. I've been wanting to write one lately as well so who knows.

>>42835189
the issue is that then it becomes a question of storage space vs. computing power, obviously not always worth it to ditch lower quality versions

>>42832990
>if you upload a exact duplicate of another upload, you will instead be given access to the original

I see nothing wrong with this, it saves space.

File: picture_2.jpg (1MB, 3244x1744px) Image search: [Google]

1MB, 3244x1744px

>>42832990

>still caring about Direct downloads

The encryption is hash-based, presumably. Each file is encrypted based upon the contents of the file before it was encrypted. Each copy of the file is encrypted the same way, and has the same resultant encrypted file.

If it detects that two encrypted files use the same hash, it will deduplicate them. The decryption key isn't knowable, but, will be the same for both versions of the file.

>>42838523
>If it detects that two encrypted files use the same hash, it will deduplicate them.
Was rather unwieldy, it should have been more like:
>Both encrypted copies of a duplicate file would have the exact same /encrypted/ hash, and could be deduplicated by simply linking the copies and deleting the extra.