Unbeatable Encryption

Picking up from the thread I made a few days ago ().

If I had to protect my files on the cloud against someone with the ability to break encryption (by somehow finding the password, with a backdoor or 0day in my programs, etc,), would this method work?

>Take secret documents and put them inside a TrueCrypt/VeraCrypt container.
>Use a file scrambler to scramble the data of the unmounted container.
>Put the result inside an encrypted .rar archive that's split into many small parts (let's say 50 files of 10MB each).
>Take the first and last part out and keep them safe somewhere offline
>Take the remaining 48 parts and put them inside an encrypted .7z file (for the practicality of not having to handle 48 different files, but also for the added layer of encryption).
>Scramble that into a new file (not really needed but it makes it look like a random uninteresting file to a potential automated check, so that it doesn't look like an archive that needs to be decrypted).
>Upload that wherever you want.

Even if they had all the passwords/keyfiles I'd have used, to retrieve my secret documents, the attackers would first need to unscramble and decrypt the .7z file, where they would find an encrypted .rar archive with the two main parts missing, so they would need to somehow extract the present data from the incomplete archive (after decrypting it), and they would have a corrupt file with some missing data.
At this point they would need to unscramble it and then try to open the TrueCrypt container that would come out of it (which has missing data at random points in it).
I they manage to successfully get to this point, they would have a corrupt version of my documents (because of the missing data).

My question is: Would they be able to get to the final point and extract the files with the missing data, or they would be stopped at some point by the file being too corrupt to be opened (without the two missing parts)?

(Cont.)

Other urls found in this thread:

security.stackexchange.com/questions/6141/amount-of-simple-operations-that-is-safely-out-of-reach-for-all-humanity/6149#6149
d-scholarship.pitt.edu/7358/
en.wikipedia.org/wiki/One-time_pad)
skrilnetz.net/bullet-proof-data-encryption-with-luks-and-a-detached-header/
reddit.com/r/explainlikeimfive/comments/3x66aa/eli5_how_will_the_new_cisa_bill_affect_the/cy25z4k
wayback.archive.org/web/20160101100053/https://www.reddit.com/r/explainlikeimfive/comments/3x66aa/eli5_how_will_the_new_cisa_bill_affect_the/
reddit.com/r/explainlikeimfive/comments/3x66aa/eli5_how_will_the_new_cisa_bill_affect_the/cy2323o
reddit.com/r/changemyview/comments/1fv4r6/i_believe_the_government_should_be_allowed_to/cd89cqr
en.wikipedia.org/wiki/One-time_pad
twitter.com/SFWRedditGifs

(Continued from )

If the files aren't corrupt enough, then is there something I can add/change to the procedure that can make it completely corrupted and mathematically unrecoverable, but also allows me to "un-corrupt" it?
Would keeping more parts of the split .rar archive (maybe the middle, the quarter, and the three quarters pieces) achieve this result?

PS: Sorry for the tripcode. I'm just using it to continue from the other thread.

literally fucking useless

Kek I pasted the wrong tripcode.

if the encryption is provably solid, any further obfuscation like this is just a retarded hassle for you and completely unnecessary
if they can acquire your keys, they can surely get anything else you have

It's to protect your files against someone who might be able to bypass your passwords, either by bruteforcing (with dictionary attacks or whatever), by backdooring the software, etc.

It's also for futureproofing. Even if you encrypt your files, if you use the cloud you can't be sure that they aren't getting stored somewhere until they find a way to open them. This makes it so that even if they find a way to open them, they won't be able to, without the two missing pieces (which are much harder for them to get, especially if they are always kept locally and never uploaded anywhere).

Also, this is obviously not against present targeted attacks, but rather against blanket searches by bots that might find all the archives in their database and try to open them.
Or even against future targeted attacks, where it would be too late to find the missing pieces, and it will be impossible to open the archives.

I don't know how these things like TrueCrype work, but you're going about this all wrong.
It's interesting, but dumb.
Just use GPG and call it a day.
If they can brute force your keys, they can brute force anything else they need/want.

The point is that even if they manage to bruteforce my keys, the files would be so corrupt that they won't get to open my files, since some key data would be missing.

Use dm-crypt+luks, store the headers offline.

Interesting...
Would that make the files "corrupt" enough that whey will be impossible to open?

Then the data is useless to you as well.
And any way you make where it's not becomes accessible to these people.

No, because I wouldn't delete those files, but keep them safe offline (on some microsd or whatever), so the archive would be corrupt for them (as long as they don't have the two missing pieces), but perfectly fine for me.

well if they know that you are using dm-crypt+like they could try to brute force the header
if they have the password this will depend on the header format
if the headers contain a large salt or random key they would definitely need that. a 256 bit random salt would be impossible to crack
the thing about dm-crypt and luks is that they are very tweakable so go study how they work, I'm sure they have something like an adjustable salt

>a 256 bit random salt would be impossible to crack
Would it be impossible for the prohibitive amount of time needed, or because it's mathematically impossible, even in an infinite number of years of bruteforcing?

(same person)

if you want a secret offline key that would be extremely hard to guess and stored offline why don't you use a keyfile?

it has the same use case as the thing you explained in your post but easier to apply
a few 1MB random file would be good


as of now we don't have any means to produce the energy required to iterate over 256bit
security.stackexchange.com/questions/6141/amount-of-simple-operations-that-is-safely-out-of-reach-for-all-humanity/6149#6149

If they can brute force your keys, they can brute force any missing pieces.
If they can gain access to and steal your keys, they can also take the missing pieces.
Any potential benefits of your idea are only valid so long as the machine which sees these keys and missing pieces is never networked.
In which case it's still overly convoluted - All you need to do is encrypt it, burst it into a bunch of archives, and not upload one.

You may be interested in reading this:

d-scholarship.pitt.edu/7358/

For how he splits up the files. Ignore the DHT part which could be replaced by servers or just your own drive alone.

shit, sorry for the bad formulation and grammar mistakes, I'm on the phone and in a hurry

>if you want a secret offline key that would be extremely hard to guess and stored offline why don't you use a keyfile?
Are you sure a keyfile is as hard to crack as two 10MB files?

>as of now we don't have any means to produce the energy required to iterate over 256bit
I know, but what if they find a new way to beat encryption that doesn't require all these years of bruteforcing? Maybe something with quantum computing or even something else.

>If they can brute force your keys, they can brute force any missing pieces.
Not exactly, because even if they could bruteforce the data in my 20MB missing files, they would need to try and decrypt the result, for them to know if the combination of data they have is the right one. It would make even sci-fi quantum computers take billions of years, because it's impossible to know right away if you got the right result.

>If they can gain access to and steal your keys, they can also take the missing pieces.
Yes, but it's significantly harder to get my missing pieces, especially if created on an airgapped machine and immediately stored in a drive that's phisically in my possession.
They would have to send agents in my home to get the data, and I'm not trying to protect myself against that, as there would need to be a significant interest in my files, which I doubt it will ever be the case.

>All you need to do is encrypt it, burst it into a bunch of archives, and not upload one.
Just like the best form of birth control is abstinence, right?

Last three of those replies are for My bad.

I don't get your very last statement or whatever you think it's supposed to mean.
What I said is literally just a less retarded way of doing exactly what you outlined.

you can create a 1GB keyfile with random data
you can take your favorite movie in a digital format and use it as as a keyfile if you please

a keyfile is just an extension of the password, although not meant for memorising

Theres no reason to use any password over 256 bits unless its extremely low entropy.

Thank you, I will read it carefully later.

From what I understood from the abstract, it's basically torrent-like encryption, right?

It seems much more convoluted than my procedure (which is just a long series of easy steps), and I don't think I'm confident enough to pull this off without losing sleep about something going wrong and losing my files.

I'll see if the benefits make up for these problems.

All I'm asking is "is this a good way to protect my files on the cloud", and you basically said "the best way is to not use the cloud".
That's pleonastic, but we're not talking about the best way to protect our encrypted files in general. We're talking about a scenario in which the attacker can already access the files and we're thinking about a way of making sure they can't open them.

To crack a keyfile, would they need to crack the entire file, of just its hash or something like that?
Also there's still the issue of them having backdoors or other methods of bypassing the keys altogether.

>and you basically said "the best way is to not use the cloud"
But no, that's not what I said at all.
I said >All you need to do is encrypt it, burst it into a bunch of archives, and not upload one.
What do you think the word `upload' means?
This is your exact idea, minus all the weird stuff that's only there because you don't understand what you're talking about.

>To crack a keyfile, would they need to crack the entire file, of just its hash or something like that?
the entire file, that's why keyfile are so powerful and fragile too. if someone obtains your drive and knows the password they can try files from your drive until they find the one that decrypts it.
also if you loose it you are doomed

>Also there's still the issue of them having backdoors or other methods of bypassing the keys altogether.
definetly, but there is no workaround this

Or you put all your files on a USB, break it into multiple pieces and hide the pieces around the world.

Ah sorry, when you said "not upload one" I thought you meant to not upload a single one.

My bad, english is my third language. Sorry.

Anyway, that's the main point of my procedure... To leave out some piece of data so that even if they crack the encryption, they would get a file with missing parts inside.
If I put my secret documents directly inside the split archive and upload that, I'm not sure that they won't find a way to extract what's there anyway, and they would end up having a corrupt version of my files.
The encrypting and scrambling done before splitting the archive are to ensure that even if they extract the remaining data from the split archives, all they would have is a file too corrupt to extract anything usable from.

Well im not sure how torrents are fragmented but essentially its using an old technique commonly found in networking to add redundancy to packets, however, when hising the key it can also actually be used to add some security since the order you recombine them matters.

The main thing is the IDA (information dispersal algorithm). Its actually really simply to implement and is a simple matrix manipulation combined with a key to name and send certain files to certain servers which allows you to remember the order via the key for recombination later.

...

what you ideally want is a method of encrypting data such that every bit in the encrypted file depends on all the bits in the original file and the key (pass + keyfile or whatever)

>the entire file, that's why keyfile are so powerful and fragile too. if someone obtains your drive and knows the password they can try files from your drive until they find the one that decrypts it.
Ah ok, I'll read up on that, thank you.

>definetly, but there is no workaround this
The entire point of my procedure is to make a workaround to this by corrupting the files so much that even if they could magically open them ignoring my keys, they wouldn't be able to find anything useful.

that was your second mistake, the first one was using a tripcode

That's interesting. I'll look it up later and research it better, thank you.

Yeah, but if I don't "ruin" the file someway (while still be able to "unruin" it), my archive are still susceptible to other weaknesses in the system in case they can find a way to still open the files.

what you don't seem to get is that if they are capable of `magically opening them ignoring your keys' they are necessarily magically capable [computationally] of doing literally anything else
good encryption is good enough on it"s own
you are the weakest link
complicating the chain only opens up more venues for things to go wrong

See >PS: Sorry for the tripcode. I'm just using it to continue from the other thread.

I'm just using it for this thread so it's easier to keep track of who's OP (since this thread is basically me asking questions).
It's not like I'm tripfagging for attention in the entire board.
I'm just using it as intended.

But in real life they won't be using magic anytime soon, and there are limitations even with those sci-fi quantum computers they're predicting will exist in the future.
For example, see this >even if they could bruteforce the data in my 20MB missing files, they would need to try and decrypt the result, for them to know if the combination of data they have is the right one. It would make even sci-fi quantum computers take billions of years, because it's impossible to know right away if you got the right result.

Truecrypt is arguably better than GpG or PgP because the creator refused to install a back doors like the NSA demanded. That's why they shut the development down. Just use an older version and a really big key file.

Rar files are meant to be repairable and a missing piece is not a guarantee of security.

The only unbreakable encryption in the coming days of quantum computers (10years) is a one time pad.

the most powerful method of encryption is a one-time pad (read more here en.wikipedia.org/wiki/One-time_pad)
it is so basic that there is no security hole in the method by itself
as long as the system that stores the secret key and performs the decryption is secure the whole file is secure

this is the property that you described in your original post: without the missing pieces that are stored on a safe offline system the encrypted file is uncrackable
with a one-time pad the "missing" pieces is actually just one huge piece

One time pads are also largely impractical for anything large. If you use them on a large scale you also have to ensure your random key pad is actually random and not biased or repeats too quickly. Also no authentication.

Lots of problems with one time pads.

Sort of like a Vigenere cypher with the key as long as the hidden text (so a Vernam cypher) that people used for text, just applied to digital data?

So, if I uploaded a 50GB file on MEGA, I would need a key that's 50GB, and keep that safe offline?

That's surely useful for a lot of things, but in my case it would have a few issues, since my idea was to use this as a long term online backup solution. If I had to keep a file of the same size safe offline, I might as well keep the original file, right?

Two small files can be kept on the flash drive I keep on me 24/7, so it's not really a problem, but worrying about keeping safe a file that's exactly as large as my archive, would be exactly like keeping my files offline (since if I lose the OTP file, it's like I lost my online file).

there is always a compromise between security, ease of use and performance

it all depends on your needs and paranoia

I consider a good password and keyfile with a detached header to be secure enough for a human's lifetime
more to read: skrilnetz.net/bullet-proof-data-encryption-with-luks-and-a-detached-header/

No, it's a shit idea the last time you asked and it's still a shit idea now

If they can break your encryption, you're fucked. Just don't use breakable encryption

The thing about a one-time pad is that it's essentially useless for data storage, because you have to store just as much for the key as you would have needed to just store the data directly

The only legitimate use for a one-time-pad is in advance-rendezvous scenarios, e.g. say you can arrange a safe meeting with somebody beforehand but then need to communicate over an unsafe channel later.

Is all good until NSA devulges their secret exploit/backdoor/quantum jew.

It'll be DES 2.0

My problem with a OTP is that it makes the whole thing pointless for online backups.
It may be good for other things (such as communication for example), but for this purpose it's definitely not the right choice.

I'll look into the detatchable header though, that might be interesting.

If the file is too corrupt to be used once they extract it after breaking the encryption, then the files will be unaccessible, making them safe. Unlike regular encryption where if they break it it's game over.

Exactly.

OR, somebody might steal it from them and it will be only a matter of time before it's available to everyone.

>If the file is too corrupt to be used once they extract it after breaking the encryption, then the files will be unaccessible, making them safe. Unlike regular encryption where if they break it it's game over.
Here's a small thought experiment you can try doing:

If you assume they can break the encryption, then the logical consequence is that it would make no difference whether you encrypted the data or not.

So try imagining this: If you uploaded your data, under your chosen scheme, as plaintext (instead of ciphertext) - would it still be “secure”?

Heres a thought experiment:

If you are a law abiding citizen why do you need emcryption to hide details?

As long as the scrambling and splitting work, yes, because when they open the archive, they will see a file with missing parts, so that its content will be corrupt and useless.

Other than being an additional layer of security, using encryption will make it so the data is even more corrupt (since they would need to extract it from an encrypted container that lacks some key data for the decryption), and therefore significantly lowering their chances of extracting the remaining part of my documents.

Are you honestly so naive as to truly believe that the FBI wouldn't be able to
read a partially corrupt JPEG of you fucking a kid?

>Retard alert

Of course they would be able to do that. That's precisely why I'm doing this. If I thought they couldn't do it, I would just split the file and keep a part of it offline.
All the other steps are so that even if they manage to extract the corrupt data from the split archive (that's missing two important parts), they won't be able to open it because it would be too corrupt to extract the actual data from.

Also, why does anyone think if you care about your privacy it means you're a criminal?
You and , wait a few minutes... I'll dig up an email I received with a couple of links you might find interesting.

I don't get why you're going to all of this misguided effort. Why not just
pick a secure cipher to begin with and not worry about your convoluted
splitting schemes?

Either they can break your crypto or they can't - and layering on your own
homegrown garbage rearrangement cipher won't change that. Why can't you just
use AES, serpent, twofish or whatever like a normal person and pick a key size
that exceeds the entropy limits of the universe? (like 256 bits)

>Nothing to hide argument

Read these posts please:
reddit.com/r/explainlikeimfive/comments/3x66aa/eli5_how_will_the_new_cisa_bill_affect_the/cy25z4k
The post has been deleted, but is still readable here: wayback.archive.org/web/20160101100053/https://www.reddit.com/r/explainlikeimfive/comments/3x66aa/eli5_how_will_the_new_cisa_bill_affect_the/
Just look for the "blueredscreen" username and you'll find it.

reddit.com/r/explainlikeimfive/comments/3x66aa/eli5_how_will_the_new_cisa_bill_affect_the/cy2323o

reddit.com/r/changemyview/comments/1fv4r6/i_believe_the_government_should_be_allowed_to/cd89cqr

I know they are long, but it's important in understanding how much privacy is important, especially against someone/something who could destroy your life at any time for something you did/said/wrote a long time before when it was allowed.

>inb4 reddit.
I know, but these posts are valid and I suggest you to ignore the rest of the site and just read them.

Why did you quote me faggot?

Because in the future (or perhaps even now) they might be able to break this encryption and my files would be easily readable.

If I "ruin" the file (while still be able to "unruin" it), my archives are protected even if they manage to open them.

I assume you're It's because you assumed I'm paranoid about encryption because I want to hide CP, which is not the case and I linked you a few pages about why you would want to be serious about encryption even if you're not a criminal.

Your approach is essentially indistinguishable from simply using two different
encryption algorithms:

1. Based on our current understanding of crypto (e.g. AES)
2. Based on your own homegrown/hacky rearrangement cipher

If you're worried about #1 being broken, then #2 would only add negligible
extra security. It would be a better (NOTE: better, not good) idea to simply
use two different ciphers instead, for example:

1. AES
2. Serpent

That way, if the first cipher is broken, your data would still be as secure as
serpent if used alone. But note that it's important that you must use ciphers
which are both considered secure, and you should also try to use the “more
secure” cipher first (which in this case would be serpent) because a bad first
cipher might make cryptanalysis on the second cipher easier due to potentially
known patterns.

>It's because you assumed I'm paranoid about encryption because I want to hide
>CP, which is not the case and I linked you a few pages about why you would
>want to be serious about encryption even if you're not a criminal.

You're preaching to the choir here m8. I'm just using a worst case threat
model to demonstrate a point. All strong cryptography should be based around
the idea that the information getting leaked, even metadata, will lead to
death, serious bodily harm or life imprisonment.

I already talked many times about this in the thread.

It's not about reinforcing encryption. It's about a hypothetical case in which encryption is thrown out of the window and an attacker is able to open the files.

My procedure would make the files too currupt to be opened.

Just using multiple different algorithms would not be enough against someone with the technology to beat it, a backdoor in my software, or even just my passwords.

I know Sup Forums is usually pro-privacy, but there are still many users who are not, and frankly it's hard sometimes to separate the trolls from the actually stupid and/or uninformed.
I just assumed these posts were made by the latter group.

Saying it over and over again does not change the matter of fact. If somebody
knows enough about your end point to be able to defeat any and all
cryptography you throw at it, they would also be able to defeat your
rearrangement scheme.

And your rearrangement scheme is still a cipher almost by definition, because
it's a reversible means of obfuscation. (Which is exactly what ciphers are)

Also, if somebody has the technology to beat any and all cryptography you
throw at it, then it means they control your end point either way and
therefore would be able to read your files in plaintext one way or the other.

Sounds like you think the "scrambling" of the file would "corrupt" the file enough to not be readable.

Except...That's what crypto is. Taking data and scrambling so that other users can't read it.

Essentially you:
1) Do not trust crypto schemes
2) Want to store data online
3) Would be willing to store some data offline (in your post, ~4% of the data)
4) Are proposing homegrown crypto to fix 1)

1 & 4 are contradictory. Your homegrown scheme would only benefit from being black-box to an adversary.

Also, I really don't see how you plan to achieve 1 & 2 simultaneously. You want your data to be secure in other people's hands while believing data cannot be kept secure in other's hands.


If you're willing to store data offline, why send it to the cloud? Just keep it offline. Your other option is a one-time pad, but it will take effort each time. en.wikipedia.org/wiki/One-time_pad

are you fucking retarded? put everything in a veracrypt container, use 24 character password, all done.

>Your other option is a one-time pad, but it will take effort each time.
And still require securely storing the data offline.

The best thing to do is to use a fully random 256-bit key for the crypto, NOT
a passphrase (this is essentially what was proposing).

There is absolutely no way that a 256-bit key will be cracked within your
lifetime on an unknown-plaintext. If cryptography gets broken it's usually:

- A chosen-plaintext attack that lets you reconstruct the key by repeatedly
feeding an encryption black box and observing its response.

- A known-plaintext attack that lets you reconstruct a key by knowing some
plain text and the corresponding encrypted text.

- A known bias in the output that lets you identify a few bytes of the
plaintext but nothing else.

It's extremely rare, and has practically never happened (except where due to
advance in computer power), for a block cipher being broken in a way that lets
you reconstruct the plaintext to an arbitrary ciphertext with unknown key.

The only way they're realistically going to assault your encrypted files is by
knowing the encryption key. So to avoid this, just pick a completely random
256-bit key and store it securely on your local machine. (Ideally also
protected by a passphrase)

>And still require securely storing the data offline.
Yup. But for some reason, OP really wants their data in the clouds.

>Saying it over and over again does not change the matter of fact.
Sorry I thought you didn't read the thread and just posted that, so I repeated it for you.

>if somebody has the technology to beat any and all cryptography you
>throw at it, then it means they control your end point either way and
>therefore would be able to read your files in plaintext one way or the other.
Even with the two missing parts?
Wouldn't the file be too corrupt for that?

>Sounds like you think the "scrambling" of the file would "corrupt" the file enough to not be readable.
Nope.
My idea is if you corrupt a normal file, you can still read part of it and get the information inside.
If you corrupt an encrypted file, there's a smaller chance of it being recoverable, so in the end they could gain access to at least part of your file.
If you corrupt an encrypted file that's scrambled, by taking out some main parts (therefore heavily corrupting it), then it would be extremely hart to gain access to the original files because they would be corrupted in such a way that without the two missing parts the corruption would be all over the file, making it hard to do any recovery procedures.

Since you misunderstood this part of my post, the rest of what you wrote would be correct based on your wrong understanding of what I meant, but since I meant something else, your post doesn't really make sense in relation to what I mean.

Also It's not homegrown encryption because I would only use respected and secure software.
Just using many of them in a specific order doesn't mean it's homegrown.

>Also, I really don't see how you plan to achieve 1 & 2 simultaneously. You want your data to be secure in other people's hands while believing data cannot be kept secure in other's hands.
I only believe it can't be secure in other people if the current methods are used, not that it's always insicure no matter what.
That's why I'm trying to make a more secure method.

That is only valid if the technology doesn't significantly progress, allowing us to decrypt much faster than now, and also if there are no weaknesses in the encryption programs (such as backdoors or bugs).

The entire point of my method of corrupting the file is to make my archives immune to this sort of scenarios.

This is also useful for local files.
If someone gets your hard drives, they won't be able to open your sensitive data without the two small files that you can keep hidden somewhere in a MicroSD, or even inside another file with steganography, or something like that.

That is, if my method works obviously.

You are retarded op.
Trying to solve a problem that was fixed ages ago by all the tools you mention in your post.

Problem is not having unbreakable encryption. problem is that any faggot can beat you up until you cough up the password if they are determined enough.

>If you corrupt an encrypted file, there's a smaller chance of it being recoverable, so in the end they could gain access to at least part of your file.
Look up how block ciphers work

At worst they have to guess the block offset, which is one out of 256 or so (i.e. trivial), and they would still be able to read the majority of it

You just don't give up, do you? People have spent way more time than is reasonable on explaining to you why your ideas are silly, won't work as you think; and you dismiss any and all advice and suggestions.

If you're so hell-bent on doing things your way, just do it. I don't get if you get busted.

>Trying to solve a problem that was fixed ages ago by all the tools you mention in your post.
But that's not true. Thera are still many risks. Read the thread.

>Problem is not having unbreakable encryption. problem is that any faggot can beat you up until you cough up the password if they are determined enough.
Of course, but that's a retarded way of thinking.
Just because you can't have 100% security against everything it doesn't mean you shouldn't think about protecting yourself with what you can.
That's like saying that wearing a seatbelt is stupid because any faggot can obliterate your car with a Marauder (pic related) if they're drunk enough.

You wear your seatbelts because the sceario you need to protect yourself from is likely to be a regular accident with another car, not a deliberate attack with a tank.
Just like I'm trying to protect myself against an automatic check or at most, the regular police. Not a CIA agent beating me up in a Guantanamo.

Also, as I already said, this is not about being a high-profile criminal or anything like that. It's mainly against blanket controls on their servers, or other "small" things like that.

That's precisely why I added the crambling step (it wasn't there in the beginning of my first thread).

What are you talking about?
I responded to literally everything in this thread (even the borderline retarded arguments and the posts of people who clearly didn't read the thread) argumenting all my points, and never dismissing anything as silly (I just dismissed the OTP because in my use-case it would be pointless).
Every time I argued against their points, they just stopped responding or repeated the points I argued against just before, without addressing my new points.

I'm very open to any possibility of being wrong (if you read the first thread, I was proven wrong multiple times and changed my procedure accordingly), and I really want someone to point out serious flaws in my method, so I can improve it and be completely sure it works.

>Read the thread.
your posts are so uninformed and stupid it hurts to read.
You clearly dont know how this stuff works. so why don't you just leave it up to experts?

Your god given right to privacy and your responsibility to protect it?

Unless you are a member of the non free third world hordes?

But even then do you not want to aspire to something greater.

>Also, why does anyone think if you care about your privacy it means you're a criminal?

You are a few steps passed caring about your privacy. I care about privacy and like my tin foil but I assume this was trolling. If it is you are a boring troll.

I know I'm not an expert, and that's why I'm asking here.

The whole point of the thread is to ask someone who might know more than me to pint any flaws in my idea.
I'm not defending it as an alternative to what experts use (especially since it's just a different implementation of it).

>your posts are so uninformed and stupid it hurts to read
Care to tell me what I'm ignoring please?
I'd really like to know.

What?

...

Thanks for bumping my thread user!

Or
>create your own proprietary file format
>never release software required to read said format
Probably less hassle in the long run, compared to what you're considering. Could even encrypt further if you're mega paranoid.

I don't think you understand encryption

If you're use TC/VC, your files are already decrypted by the 3LAs

I bet you use Windows and think you're safe.

How secure is a password like:

Juliachildscookswith10%ugly

Yeah, that's an option too I guess, but I don't have the time or resources to pull it off, and even if I did, I wouldn't trust my skills with something like this.

That's the entire point of the thread. Re-read the OP more carefully.

What am I doing wrong?
Please tell me user (not sarcastic. I'm actually interested).

Realistically secure enough, but if you want to easily increase its security, you could always type it two times (with maybe a variation in the second time).

For example:
Juliachildscookswith10%uglyJuliachildscookswith20%pretty

Only marginally harder to remember as the old one, but significantly stronger.

YOU JUST KNOW the NSA or DARPA have the ability to decrypt anything

How long would it take the fbi or nsa whoever has high computing power to Crack that password?

Might as well use a key that is as long as the file, at that point.

.0000376 seconds

Using current technology and techniques, probably more than our solar system will last.

The problem is, we don't know if they secretly have ways to break encryption, or if they will find them in the future.

What's a better type of password?

If I have to keep a key file that's as big as the original file, I might as well just keep the original file with me.
We already talked about OTPs in the thread. The're completely pointless in this case.

joe346642$%&##%%3momma246*$#2575%#

Looks too complex to remember

>unlocking takes 2 weeks
>once the keyfile is assembled attacker steals is despite your autistic attempt to protect it

write it on a piece of paper put into a tiny glass vial keep in mouth at all times swallow it if you get captured

It'd be significantly harder to steal my local files than it'd be to just crack the encryption.

Also why would it take two weeks?

just have it on an offline usb