If I understand it correctly...

If I understand it correctly, putting a file in an encrypted container basically scrambles it until its data is disordered anough that, for all intents and purposes, looks exaclty like noise.
Then, when the program decrypts the data, it follows a set of instructions (in the algorithm and the password) to locate all these pieces of random data and put them back in the order they should be, to recreate the original file.

Correct?

So theoretically, if I put a very secret file inside a TrueCrypt/VeraCrypt container (even with a single-character password), then put it into a .rar file that's split into 10MB pieces, and re-encrypted everything (but the first and the last piece) in a single .7z file, it would be phisically impossible for someone to access the file from that .7z archive, even if they they had scifi-tier technology to break all encryption (as long as they don't have the two pieces I left out).

That's because, even if they managed to open the first .7z archive, they would find themselves with an incomplete .rar archive, so even if they managed to extract everything contained in those .rar pieces, they still wouldn't have the complete TrueCrypt/VeraCrypt "noise blob", and therefore wouldn't be able to "reorder" it correctly even if they had the password (because it would be missing some of that noise that's contained in those two pieces I would leave out).

If that's correct, then by using this method, cloud storage doesn't have its security issues anymore, since even if anyone could access those files, it would still be impossible for them to open them and extract my secret documents.

Unless they could somehow extract part of my very secret file from what they have of the noise that they extracted from those incomplete .rar packets, but it's theoretically impossible to do that, right?

Bump

Sounds interesting. I'm not sure if true crypt would be able to read whatever corrupted file you'd get from forcing rar to extract the files without the first and the last part. But it actually is possible to get parts of your encrypted files, providing they're large enough, and just patch up the missing holes.

For example, you could make 2 dummy files to act as the first and last rar, but you'd still have to know the exact size of the last rar. This just means it would be a lot of brute forcing to just get a slightly distorted file, instead of an original. Even if you used all the computers in the world you'd still need years to do all that, especially if you use rar parts larger than 10MB.

You could test all this, but use very small passwords (2-3 characters), and a random 320x320 image as the "secret file" just to see what happens as you brute force it manually. I think larger images (for example) would be easier to "recover" though, at least if you want to see what the general idea of the image is (basically you have less percentage of the image filled with blank/dummy pixels, so it's easier to see what it's about).

Yeah, that's basically what I thought.

Every step in this process could potentially have a workaround to extract a "partial" corrupt file with the present data, so the real strength of this is in the innermost layer (TrueCrypt noise), where I'm wondering if it's possible to "un-scramble" the noise even if there are missing pieces.

I don't have the necessary skills to be able to test this properly though.

bump for interest.

I think the encrypted file can be split up into parts that can be unencrypted although the file inside might be corrupted

Yes, It would certainly be at least corrupted I think, but will it be possible to recover at least some data off of it, or will it be completely impossible due to some of the noise missing?

No, it doesn't physically reorder the file because there's no point. There's no difference from mathematical. Encrypt + encrypt again by physical rearrangement is the same as simply encrypting it with a different key, only it just takes much longer.
What you're thinking of doing would actually reduce security in most cases, since if you break the encryption you only have to guess the length of the missing data and now you have a representative sample across the entire length. Lo ing a bi chun is gen rally ha der to re ons ruct t an bit nd ieces.

Are you ok user?

>So theoretically, if I put a very secret file inside a TrueCrypt/VeraCrypt container (even with a single-character password), then put it into a .rar file that's split into 10MB pieces, and re-encrypted everything (but the first and the last piece) in a single .7z file, it would be phisically impossible for someone to access the file from that .7z archive, even if they they had scifi-tier technology to break all encryption (as long as they don't have the two pieces I left out).

Sounds like a hassle.

But I would still have those files somewhere, so I can use them to reconstruct the file if I wanted to.

The point is that if I upload the file on the cloud and someone tries to open it, it would be impossible without those two pieces.

I'm not encrypting the file two times to "harden" the encryption, but to split the file in multiple pieces so I can take a couple out before reuploading.

Instead, just encrypt the entire file and upload that to your favourite cloud service.

Also Google Shamir's secret sharing scheme for cryptographically secure information splitting.

It is, but (if it works) it's a useful tool for those occasional times where you want to upload some important stuff on the Internet and want to be sure nobody will ever be able to open it.

It's definitely not for everyday stuff.

>Instead, just encrypt the entire file and upload that to your favourite cloud service.
This is to protect my files from someone who's able to break the encryption (either by bruteforcing, or by a backdoor in the software, etc.)

>Also Google Shamir's secret sharing scheme for cryptographically secure information splitting.
Will check it out now thanks

encryption doesn't reorder the pieces, it modifies them in place. In your scenario, encrypting a file of all '1's would output a file of all '1's.

>Shamir's secret sharing scheme for cryptographically secure information splitting
Is this so I can split a file that's only decryptable if everyone who holds a piece got together and decrypted it?
Like those bank safes where you need two people with their own key to open it?

How would that be useful if there's nobody else involved?

Do I have to include my friends in this, just so I can encrypt a file, and then trust them to keep their parts safe?

Care to expand on that please?
If they're changed in place, then a TC container missing a piece would theoretically be decryptable and it would result in some corrupted data?
Would it theoretically be possible to extract the remaining data from this incomplete TC container?

I believe there's certain block cipher modes that work such that you need all blocks of ciphertext in the correct order to be able to decode any part
Of course, this makes it useless for a Truecrypt container where you need random access to different blocks, but would work for separate files

>it would be impossible without those two pieces.
It wouldn't. If you have the key you can reconstruct it. That's the point of a key.

Sounds like hell though. First of all what's the point of using the cloud storage if you both have to keep a local copy or at least pieces AND it's not able to be modified on the go for the purposes of syncing, since any changes would require the entire thing to be decrypted, rearchived and split etc.

>If you have the key you can reconstruct it
Even if it's a corrupted container?

If you corrupt it it's no good to anyone.

I was thinking about using this for long term backups.
Once every N days I would make an archive with all my important files and upload them on some cloud service.

I would then backup the remaining pieces (the two I would take out of each archive) in various safe places, so that it would be impossible to put them together.

I mean..why not just put the full backup in those safe places instead. I'm not seeing the point of the cloud at all. If your goal is separating the data then hide 2 usbs in different safe locations?

there's this thing called "keyfile", read up

Reread the OP.
It would be corrupt because it would have been extracted without the two pieces that I would leave out.

Since I still have the two pieces, I can extract it properly and not have it corrupt.

Yes, I would obviously also keep a local copy of it, but I want to use the cloud because it adds an additional layer of security, being in another country and everything.
The small files could even be kept in the flash drive that's always on me anyway, so from a practical point of view, I just have those files online that are ready to be opened anywhere I am.

Them being small, means I could also use steganography to hide them somewhere online without anybody knowing.
It would be slightly less safe, as a potential attacker might find them, but we're talking about a scenario that would require serious resources just to decrypt my stuff, which is highly unlikely.

See >This is to protect my files from someone who's able to break the encryption (either by bruteforcing, or by a backdoor in the software, etc.)

Couldn't those two pieces be pretty easily guessed?

>Them being small, means I could also use steganography to hide them somewhere online without anybody knowing.
You could rent a handful of tiny vps' full time and keep the first/last archives on those in an encrypted container (also in an encrypted os).

you can bruteforce a keyfile just as much as your two "secret" pieces.

You should look up how AES-256 works.
It is mathematically secure, forget technology, or space alien magic.

Truecrypt uses block encryption algorithms, and a virtual filesystem. In theory, as long as the section of the filesystem they recover has the file entirely within it, then they can recover the file. If yourplan involves hiding just a ssection of it, you're better off just hiding the entire truecrypt file. That said, no one can break truecrypts crypto as of right now.

Correct

It sounds like tinfoil tier paranoia

Everything that goes in and out your computer to a degree is known to at least one other party. If you upload your pieces somewhere, services that store those pieces have them. Your ISP knows which services did you use, your bank knows for which VPSes you've paid, etc. If some kind of magical illuminati is after you, it won't be hard to collect your pieces together

Just use strong enough encryption

No idea to be honest.
I would imagine it to be a quite difficult task, since they would contain parts of a TC container (which is basically noise).

How would someone bruteforce two ~10MB files containing noise?

The whole point of doing this is to protect my files from someone capable of breaking encryption.

The algorythm itslef might be safe (at least for now), but there are different ways it could be beaten. For example if its implementation has a hole (a mistake or a backdoor), or they could guess/bruteforce the password, or they could steal it from me somehow (a keylogger for example).

That might be the hole in my plan.
Can you please expand on that user?
How easy would it be to reconstruct an incomplete TC container in those conditions?
Also, doesn't a TrueCrypt container look like random noise from the outside? Or they would be able to find the beginning and end of it while encrypted/unmounted?

>The whole point of doing this is to protect my files from someone capable of breaking encryption.
Your shit would still be split up, just on various VPS' instead of in your cupboards.

>How would someone bruteforce two ~10MB files containing noise?
The same way you brute force a 1MB file. You don't, that's retarded.

>It sounds like tinfoil tier paranoia
It's because it is kek.
I'm not trying to hide from the government, or anything.
I just want to be sure that my files are safe even against technology that I may not know it exist, and most importantly against something that doesn't exist yet.
Who am I to tell if in 10 or 20 years there won't be a computer capable of bruteforcing every password in a small amount of time?

>Everything that goes in and out your computer to a degree is known to at least one other party(...)
Yeah, but with this system they would only have the big unencryptable (if my system works) files. My files would only be in my possession or hidden in some place that they don't know about (them being small makes it easy to put them somewhere without them looking like what they are).

So that part of my plan is safe then, no?
If I keep out thse two files from the big archive, it would be impossible for anyone who has the archive to reconstruct the two missing files, right?


I means that someone who can break my file's encryption might also be able to break the encryption of a VPS or an encrypted OS.

>I means that someone who can break my file's encryption might also be able to break the encryption of a VPS or an encrypted OS.
Well.. it's another 2 layers AND they have to actually find them, very unlikely. Like they'd have to know they actually exist and there's files missing.

>I just want to be sure that my files are safe even against technology that I may not know it exist, and most importantly against something that doesn't exist yet.
Sorry user, do you realize how stupid that sounds?

As the other guy said, they would be tied to me, unless I got them with fake IDs, but that starts to go into illegal territory, which I'm trying to stay out of.

To be honest, no.
Why is it stupid?

You realise some VPS can be bought with buttcoins right?

>For example if its implementation has a hole (a mistake or a backdoor), or they could guess/bruteforce the password, or they could steal it from me somehow (a keylogger for example).
This will be a problem in ANY solution you suggest. Infact, the more layers of complexity you add, the more points at which shit can go wrong appear.

It's best if you keep the implementation as simple as possible, relying on the mathematics rather than tricks and complexity.
For example, a password, passphrase, or keyfile.
The most complex you need to get is a password/keyfile combo (which veracrypt and truecrypt support)
Stop using truecrypt by the way, use veracrypt.

Doesn't buttcoin store all transactions forever, so it's only as anonymous as the source you've bought them from is reliable?

Or you laundered them with a bitcoin mixer.

>To be honest, no.
>Why is it stupid?
Because if you have no idea what you're doing, how can you be sure that you're doing it right?

I understand. In fact that's the entire point of doing this, and that's why the key point of my plan is not the multiple layers or the complexity, but the two missing pieces that would make it theoretically impossible for someone to reconstruct the file without the missing parts (that I would keep separated and safe). If this works.

Worrying about my bitcoins being untraceable, worrying about those services I would keep the files in, and actually paying for all these services would still be a bigger hassle than following a simple procedure of encrypting a file 3 times and uploading it somewhere.

>Because if you have no idea what you're doing, how can you be sure that you're doing it right?
That's why I'm asking.
Should I give up on using something just because I don't have a complete understanding of it?

Do you deeply understand 100% of what you use and you feel stupid if you have some holes in your knowledge?

Also, I don't see how me not being an expert and "not knowing what I'm doing" makes my worries about futureproofing stupid.
How do these two things relate?

Do you use Windows 10?
1) yes - it's too late
2) no
>do you use the latest (NSA) version of truecrypt?
2.1) yes - it's too late
2.2) no - you're good

And that's only up to 20MB of noise, that can be brute forced by just experimenting with different combination of bits on them. The thing is there are 2 things you need to brute force, first the size and the contents of the 2 missing archives and second the *crypt password/algorithm. It's still a pointless thing to do as it would take centuries probably, and your personal data isn't worth it. Alternatively, you could only insert blank noise in those two files and get what this says and reduce the decryption time by a trillion. Since it IS possible, then the worst possible scenario is the technology advances seriously in the next 30 years and supercomputers easily brute force everything a million times faster than today, your files are still there and can be accessed.

It isn't "theoretically impossible", it's possible, just not something a random person would want to waste time on since you and 100 generations of your family would've died of old age by the time it's all done.

>Do you use Windows 10?
I'm on 7 with the botnet updates disabled.

>do you use the latest (NSA) version of truecrypt?
7.1a (AKA the last one before the shitstorm).

So without bruteforcing the content of the two files it would be impossible to extract it, right?

Also, when they bruteforce the two files, how would they know that they got the right combination?
They would need to extract the files for each combination, and then try to work on the inner archive, right?

Yes that's the point and nobody would do that. They'd need to check more combinations than the total number of posts ever posted on Sup Forums, and that wouldn't even be 0.00001% of combinations, and you would still have to decrypt the result. You could do a lot to reduce the number of combinations required but it still wouldn't be enough.

So as long as nobody tries to reconstruct the two files, there is absolutely no way at all to get to the actual documents right?

If so, the plan is solid, except for what said.
Because if he's right, then they would still be able to extract the actual documents, just without the missing 20MB.

Stupid question but can you tell me where did you aquire this knowledge?

No, encryption of files is typically done with block ciphers which split the file up into 128, 256 or 512 bit blocks and encrypt those in isolation from everything else.

Yeah, that was a misconception I had, thank you.

Is there a way to scramble the data instead of changing it in its place then?

Doesn't file compression (like winrar) do that to some extent?

That's probably true, which is why I originally said the larger the file the more of your data can be decrypted. But it's still very unlikely someone will decrypt it, and depending on your files 20MB might be crucial (some files could be corrupted beyond repair), but you could always keep more with you on a 1GB flash drive for example, two 400MB files. You're still making it more difficult since you protected all your archives with passwords (as long as there are no backdoors on rar files)
Spotted the NSA agent. Why do you want to know where any of the anons learn this?

That just sounds like security by obscurity. I guess you add a lot of entropy by splitting the file into pieces though.

>Why do you want to know where any of the anons learn this?
Oh I dunno maybe because I too want to know it?

I don't know what you are trying to accomplish, but it's probably stupid and trivial to break.

Just don't do whatever it is you're doing.

Right, but 20MB is really pushing the limit on how large they can be before them being impractical to manage (especially considering the many iterations from every time I'd upload an archive).

Regarding the issue of someone being able to extract part of the TC container's contents, would putting a compressed file inside the truecrypt container make it impossible to recover the actual documents?

I imagine that if they extract the contents of the incomplete TC container, they would only find a corrupt .rar archive, that would be even harder to extract the files from, right?

Or is it also trivial to extract the files from a corrupt .rar archive when you have the password or a backdoor?

In a sense it's security through obscurity because you would need to obscure the pieces you keep out before uploading, but that's like calling AES the same thing because you need to hide a password/keyfile.

And besides, that's all ON TOP of regular encryption. It doesn't replace it.

Do you at least know why exactly? Serious question.

>In a sense it's security through obscurity because you would need to obscure the pieces you keep out before uploading, but that's like calling AES the same thing because you need to hide a password/keyfile.
Wouldn't you need to upload those pieces somewhere into the cloud anyway, if you're trying to share or back up the files?

No need for this paranoid bullshit.
If you have a strong enough tc password + have encrypted archives (. rar) you should be absolutely fine.
On a side note, back up your data - I had to recover from a damaged device that lost its encryption header, when I fixed that, the filesystem was corrupt, took me days to get my shit back.

Otherwise stop being a sick fuck, op.

You can just scramble data within each file you want to encrypt. It's not to difficult. Don't know if there are tools for this, but I made a project for fun which imports a file as text and then scrambles the characters depending on the password you enter. Try to find a similar program which can preferably do this to multiple files at the same time.
It's very trivial. Some data will be corrupt but that's still only 20MB out of probably over 10GB right? Don't know how much you want to encrypt, but as long as you're sending more than 1GB to the cloud 20MB is nothing.

I think he wants to keep the parts on himself somewhere.

It's for long term backups.
I would need those files offline, or at most, hidden somewhere online where it would be impossibly hard to find them and know what they are (I could re-encrypt them and use steganography to hide them inside some high-res pictures on my website, or inside some files in some random archive, etc).
There would still always be the chance of someone finding those files, but it would still be a very thick layer of security over just uploading the encrypted folder.

Then if I scrambled the TC container file before putting it into the split .rar archive (of which I would then take two pieces away), whatever they take out of the incomplete .rar archive would be useless because it would miss about 20MB of random parts of the archive, right?

>whatever they take out of the incomplete .rar archive would be useless
Not really, some of it would be corrupted but that's only 20MB of missing pieces. Since encryption is somewhat random, you don't really have full control over which parts of the encrypted files they get. They could even get whole files.

This is what I'd do in your place
1. Archive everything (password protected) and split it into 50 pieces
2. Take 2 of those, leaving 48
3. Use 7zip and make a single archive (another password)
4. TC the archive (encryption password) and scramble it somehow (another "password" or method)
5. Make an archive of the encrypted system, let's say 50 of them (another password)
6. Take 2 again, and zip the 48 into a single (password)

That would mean you used a total of 6 different passwords (overcomplicating, but effective). This is unlikely to ever be cracked, unless NSA really does have backdoors into rar/zip archives, which is why I'd recommend another archiving method. They'd still probably not care unless you're an actual enemy of the USA or (some of) their allies which I'll assume you're not. Even if you are, they still have to break TC and whatever method you used to scramble everything, I recommend making your own script for doing this. This way you can be sure nobody gets your actual files other than you.

OP here. I'll have to go in a few minutes, but will be back in a few hours.

If you have something to say (suggestions, questions, insults) please do, as I'll try to respond when I get back, or if the thread will be archived, I'll post a ghost reply on the archived thread on rbt.asia

>Not really, some of it would be corrupted but that's only 20MB of missing pieces.
But it would be 20MB of randomly taken bits from here and there in the file. Would they still be able to extract the stuff in the TC archive if it misses random bits at random points, or it won't be corrupt enough?

>This is what I'd do in your place (...)
Interesting.
This seems significantly more complicated than my original process, but I'll look into it and maybe integrate it (or part of it) into my "routine".

>They'd still probably not care unless you're an actual enemy of the USA or (some of) their allies which I'll assume you're not.
I'm not really worried about a targeted attack, but rather about an automated one against all the files they have (which would then go through a system that flags suspicious stuff for an in-depth check).
What the NSA is currently doing (as shown by the various leaks on the subject) was almost sci-fi a few years ago. I don't know if they'll stay at the current level or they'll develop a more advanced version of what they already have (which theoretically, if it worked properly, would hoard data automatically about everybody until the computer finds something noteworthy), meaning my encrypted files that are on the cloud could be decrypted in the future.

One last bump before going.

Thanks for the help guys.
I appreciate it

>Would they still be able to extract the stuff in the TC archive if it misses random bits at random points, or it won't be corrupt enough?
Really depends on how many file there are and what file types are they. In general, if you're archiving a lot of different files it's not going to be enough. Imagine image files with only 0.5-2% dead pixels, or text files with a few scrambled letters. That's how much you can expect to be unreadable, but you can see what's going on when you look at the bigger picture. But it's still unlikely for your files to get stolen either way. Everything can be decrypted, it just takes time. If you're really worried about NSA, don't store anything on cloud.

bump.

will test it soon