Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Crypto: Archive with three different crypto programs - how safe?
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Crypto: Archive with three different crypto programs - how safe?

myhkenmyhken Member
edited September 2016 in General

Have a archive that I want/need to store offsite, on dedicated servers/and or VPS.

My plan is: Using containers in three different programs

VeraCrypt - AES - Password length 16

BestCrypt - Serpent - Password length 22

TrueCrypt - Serpent - AES - Password length 32

Three containers, but only one file at the end.

Can of course be that I change the crypto for each container, but this is the layout.
Is it safe to be stored on places I don't have totally control?

I'm thinking about encrypt a whole partition on a drive also, to store the encrypted file in.

«1

Comments

  • GCatGCat Member
    edited September 2016

    It's almost as good as my Wheel 2.9, patient pending! A proud product of the (re) Inventors

  • Just use one. VeraCrypt, for example, very effectively mitigates up to state level attacks. If you're worried about state level attacks I would recommend either getting the help of a lawyer or the drug cartel.

  • Silvenga said: drug cartel

    Mafia is the best option. We had someone here too.

    Jokes aside, you can use one. I've used TrueCrypt and if my memory is correct, VeraCrypt is based on TrueCrypt. Haven't heard about the BestCrypt though.

    Thanked by 1myhken
  • hzrhzr Member
    edited September 2016

    If you are this paranoid, it doesn't matter at all if you are running it in a VM because you can just dump the container memory from the host (or potentially another VM on vulnerable hypervisors), extract the key from that, or if you already have the crypted volume mounted, just snapshot there or something.

    If you just have a giant archive you want to dump somewhere, it really isn't going to be cracked anytime soon with just one thing..

    Thanked by 2yomero myhken
  • It's only a archive that never will be mounted on the dedicated server/VPS.

    @sdglhm BestCrypt comes from Finland and Jetico.com. Using military grade encryption with no backdoors to NSA or US. It is not free, so maybe the reason why not many have heard about it. But I have used the for 12-14 years now.

  • joepie91joepie91 Member, Patron Provider

    myhken said: Using military grade encryption

    There's no such thing. Any vendor that claims this, is one you should avoid, because they're more interested in selling you crap than actually securing your information.

    myhken said: with no backdoors to NSA or US

    It's proprietary, so there's no way to verify this whatsoever. Avoid at all costs.

  • I would look at something based on libsodium like PCP1 to encrypt your image with Curve22519.

    Stacking one encryption on top of another may not give you more security, but could make it worse. For instance, file headers introduced in the inner encrypted file can make it easier to crack the outer layer. And the order of applying would also matter.

    Thanked by 3joepie91 Chronic myhken
  • joepie91 said: There's no such thing. Any vendor that claims this, is one you should avoid

    Can agree on this. (Cannot say specified reasons, but I know this is pure bull-crap)

    myhken said: BestCrypt comes from Finland and Jetico.com

    Thank you. Will check it out.

    Thanked by 1myhken
  • joepie91joepie91 Member, Patron Provider
    edited September 2016

    @rincewind said:
    I would look at something based on libsodium like PCP1 to encrypt your image with Curve22519.

    Stacking one encryption on top of another may not give you more security, but could make it worse. For instance, file headers introduced in the inner encrypted file can make it easier to crack the outer layer. And the order of applying would also matter.

    There is (was?) an interesting case of that in vBulletin, actually. It tries to be clever by doing md($salt . md5($password)) for password hashing.

    However, because the keyspace for an MD5 hash of $password is considerably smaller than that of $password itself, it's actually theoretically weaker than md5($salt . $password) would have been, despite hashing twice instead of once.

    Of course, you just shouldn't be using MD5/SHA1/etc. for passwords at all, and should be looking at scrypt or bcrypt instead... but just to illustrate how adding more crypto can make things less secure, if you are not extremely careful about how you implement it.

  • @joepie91 my plan was to solve this with stronger and stronger password for each layer, and using different crypto for each layer, and different software for each layer.

  • @joepie91 said:

    myhken said: Using military grade encryption

    There's no such thing. Any vendor that claims this, is one you should avoid, because they're more interested in selling you crap than actually securing your information.

    myhken said: with no backdoors to NSA or US

    It's proprietary, so there's no way to verify this whatsoever. Avoid at all costs.

    I think BestCrypt is pretty safe to use, I hae used it for so long, and there has never been any story about their encryption has been broken.
    It's a costly software when you need it for more then one computer, for BestCrypt, BCWipe and BestCrypt Volum Encryption we talk around $200 per computer.

  • xyzxyz Member
    edited September 2016

    joepie91 said: There's no such thing.

    AES is approved by the NSA to protect up to TOP SECRET rated data, so if you're using AES (which most people are these days), you're using "military grade encryption".

    joepie91 said: However, because the keyspace for an MD5 hash of $password is considerably smaller than that of $password itself

    MD5 hash has 128-bits of entropy. I bet the majority of passwords don't have that much, though you could come up with a password with more. It doesn't matter much though, yes it can be weaker, but 128-bits is plenty and no-one's going to be able to search all of that.
    As a side note, in that particular example, MD5 is somewhat weak, but considering the age of vBulletin and needing to be compatible with really old versions PHP back in the day (before even the sha1() function was added), the strategy makes some sense. Definitely could've been better though.

    Actually, running multiple rounds of hashing is a fairly standard technique to increase the strength of a hashed password.

    Thanked by 1myhken
  • joepie91 said: There is (was?) an interesting case of that in vBulletin, actually. It tries to be clever by doing md($salt . md5($password)) for password hashing.

    Yup. I remember a similar conversation about encrypting a file before compressing it. If you compress first you lose entropy and weaken encryption.

    myhken said: with stronger and stronger password for each layer, and using different crypto for each layer, and different software for each layer

    If you are going to layer them, it is better to put the strongest layer inside and weaker layers outside. Fingers crossed.

    Thanked by 1myhken
  • The simplest tool for the job: https://www.tarsnap.com/scrypt.html

    Even if you choose another, don't decrypt any file on hosts you don't physically control, to prevent Memory-dump attacks.

    Thanked by 2Chronic ehab
  • Already mention this. This is just for storage, will not be opened ever on any host, just at home.

    Thanked by 1vimalware
  • @joepie91 said:

    myhken said: Using military grade encryption

    There's no such thing. Any vendor that claims this, is one you should avoid, because they're more interested in selling you crap than actually securing your information.

    myhken said: with no backdoors to NSA or US

    It's proprietary, so there's no way to verify this whatsoever. Avoid at all costs.

    My definition of "military grade encryption" = a piece of paper inside of a safe hidden in a TOP SECRET location. (or use a safety deposit box, whatever floats your boat)

    Thanked by 3ManofServer tux myhken
  • joepie91joepie91 Member, Patron Provider

    @myhken said:
    @joepie91 my plan was to solve this with stronger and stronger password for each layer, and using different crypto for each layer, and different software for each layer.

    You're unlikely to add any security beyond the first layer, because good crypto tools are designed to work and be sufficiently secure on a stand-alone basis - if anything, you increase the chance that you mess up and accidentally break the security in some way. I wouldn't recommend it.

    myhken said: I think BestCrypt is pretty safe to use, I hae used it for so long, and there has never been any story about their encryption has been broken.

    This is completely irrelevant, and not at all how security works. You're wrongly assuming that if it's broken,

    1. The victim will find out
    2. The victim is still alive
    3. The victim will be able to speak out about it towards anybody at all
    4. The victim wants to speak out about it towards anybody at all
    5. You are at the right place in the 'grapevine' to hear about it
    6. The compromise didn't happen in a different piece of software that uses the same internals

    That's a hell of a lot of assumptions to make, and they are not valid assumptions when assessing security. This is precisely why the only safe assumption in security is "if I can't see how it works, it's broken". Kerchkoff's Principle is relevant here as well.

    xyz said: AES is approved by the NSA to protect up to TOP SECRET rated data, so if you're using AES (which most people are these days), you're using "military grade encryption".

    "Approved", yes. As many other things are, and many other things have been, including now-weakened or -broken things. Not to mention that the public perception of "military-grade" is "used by the military because it's better than the other options", even if you can pedantically argue that "well technically it's been approved".

    And all that ignores that if everybody is using "technically military-grade" encryption, it's misleading at best to be advertising it as such, and suggests that the advertising party cannot be trusted.

    xyz said: MD5 hash has 128-bits of entropy. I bet the majority of passwords don't have that much, though you could come up with a password with more. It doesn't matter much though, yes it can be weaker, but 128-bits is plenty and no-one's going to be able to search all of that.

    Emphasis on "theoretically". There's a reason I said that explicitly.

    xyz said: As a side note, in that particular example, MD5 is somewhat weak, but considering the age of vBulletin and needing to be compatible with really old versions PHP back in the day (before even the sha1() function was added), the strategy makes some sense.

    No, it does not. This really is complete nonsense - there is no reason to support old PHP versions anymore, and it's perfectly possible to implement hash algo migration.

    The vBulletin developers are fully responsible for the decision they've made.

    xyz said: Actually, running multiple rounds of hashing is a fairly standard technique to increase the strength of a hashed password.

    This is completely missing the point. The issue isn't in "running multiple rounds of hashing". The issue is in the fact that it is extremely easy to fuck up, just like every other kind of crypto, and that people's perception that "oh, adding multiple hashes is better than nothing" is wrong.

    The fuck-up in vBulletin's case wasn't the double md5, it was the fact that they hashed the $password and $salt in different steps. Had they done md5(md5($password . $salt)), it would not have been prone to the theoretical attack I described.

    TL;DR: Don't try to "stack crypto" yourself, because you will probably fuck up.

    Thanked by 2myhken apidevlab
  • @joepie91

    You're unlikely to add any security beyond the first layer, because good crypto tools >are designed to work and be sufficiently secure on a stand-alone basis - if anything, >you increase the chance that you mess up and accidentally break the security in some >way. I wouldn't recommend it.

    You understand that I talk about creating a container with program x with crypto x so then I have one container.
    Then I create a new container with software y with crypto y, and a stronger password.
    Then I create a new container with software z with crypto z, and a stronger password.

    Then I put the last container inside the second container that I put in the first container.

    We are not talking about Linux here, but Windows.

    Then I have three independent containers, with different crypto and stronger and stronger password. So if they brake into container A, they still have to brake into container B and C.

  • joepie91joepie91 Member, Patron Provider
    edited September 2016

    @myhken said:
    @joepie91

    You're unlikely to add any security beyond the first layer, because good crypto tools >are designed to work and be sufficiently secure on a stand-alone basis - if anything, >you increase the chance that you mess up and accidentally break the security in some >way. I wouldn't recommend it.

    You understand that I talk about creating a container with program x with crypto x so then I have one container.
    Then I create a new container with software y with crypto y, and a stronger password.
    Then I create a new container with software z with crypto z, and a stronger password.

    Then I put the last container inside the second container that I put in the first container.

    We are not talking about Linux here, but Windows.

    Then I have three independent containers, with different crypto and stronger and stronger password. So if they brake into container A, they still have to brake into container B and C.

    Yes, I understand what you are suggesting. All that I described applies to it. You are very unlikely to make it more secure in practice, but very likely to mess something up that makes it less secure.

    Just use one well-audited, well-understood, transparent system with a strong passphrase.

    Thanked by 1myhken
  • xyzxyz Member
    edited September 2016

    joepie91 said: And all that ignores that if everybody is using "technically military-grade" encryption, it's misleading at best to be advertising it as such, and suggests that the advertising party cannot be trusted.

    WTF? That's the most roundabout way of accusing someone of being misleading I've heard of. What - I can't claim that I'm using strong encryption because everyone else is? (not everyone is, but let's assume your premise for now) Or any product whose marketing department adds a little spin to something (who honestly doesn't?) is automatically misleading and shouldn't be trusted at all?

    AES is considered a strong and secure cipher, and it is indeed a vert good cipher on its own merits, which is why it won the NIST competition after all. I don't know why you're emphasising 'technically' here, but it's unlikely the military would be using weak ciphers.

    joepie91 said: Emphasis on "theoretically". There's a reason I said that explicitly.

    I'd argue against that even, considering the overall hash only has 128-bits of entropy, and hence no more than the inner hash, but I'll give you this one.

    joepie91 said: This really is complete nonsense - there is no reason to support old PHP versions anymore, and it's perfectly possible to implement hash algo migration.

    They certainly needed to support old versions in the past - though not now (I doubt vBulletin would run on PHP3).
    I was merely pointing out the origins of the issue, and that, considering circumstances, it's understandable. Migration is indeed possible, but somewhat ugly to do, which may be why no-one bothered. But maybe they should've considered it...

    joepie91 said: Had they done md5(md5($password . $salt)), it would not have been prone to the theoretical attack I described.

    Which is vulnerable to a different kind of attack - precomputed MD5+MD5 tables. The salt needs to be included in every round of hashing for it to be effective as a key strengthening technique.

    X(salt + X(password)) where X denotes a strong hash function, is perfectly fine for what it is. This is because your "theoretical" weakness isn't practical in any way here, if X is a strong hash.

    joepie91 said: The issue is in the fact that it is extremely easy to fuck up, just like every other kind of crypto, and that people's perception that "oh, adding multiple hashes is better than nothing" is wrong.

    Whether or not it improves security is questionable, but it certainly doesn't make it worse than the weakest link in the chain (maybe with some rare exceptions).

    The general principle of nesting goes like this. If you had a scheme, A(B(C( X ))) where X is your data, and you could quantify the strength of the crypto algorithms, say A's strength is 5, B=3, C=4, then the resulting overall security of the nest would be at least 3. It would not somehow be 2 or less.

    In the OP's case, I agree that nesting is unnecessary, but it doesn't magically weaken the setup more than the weakest individual part.

    Yes, security is hard, and easy to mess up, but many other things are as well. Saying that people shouldn't bother with it just for those reasons, I think is counter-productive.

    Thanked by 3MikePT myhken apidevlab
  • joepie91joepie91 Member, Patron Provider
    edited September 2016

    xyz said: Or any product whose marketing department adds a little spin to something (who honestly doesn't?) is automatically misleading and shouldn't be trusted at all?

    For security-related tools? Yes, absolutely. If the tool is secure enough, such marketing is not needed. If it isn't, then you don't want to use it.

    (who honestly doesn't?)

    People who honestly provide security software that does exactly what it says on the tin.

    AES is considered a strong and secure cipher, and it is indeed a vert good cipher on its own merits, which is why it won the NIST competition after all. I don't know why you're emphasising 'technically' here, but it's unlikely the military would be using weak ciphers.

    I'm not disputing that AES is considered a strong and secure cipher. I'm disputing that it's legitimate to advertise it as "military-grade".

    xyz said: I'd argue against that even, considering the overall hash only has 128-bits of entropy, and hence no more than the inner hash, but I'll give you this one.

    This is an interesting one (that I haven't heard before), but it does assume that each input under 128 bits of entropy results in precisely one unique output, without collisions in that space. I don't think that's necessarily a valid assumption. Going to think over that one a bit more, though.

    xyz said: They certainly needed to support old versions in the past - though not now (I doubt vBulletin would run on PHP3).

    I was merely pointing out the origins of the issue, and that, considering circumstances, it's understandable.

    Sure, but the issue I'm describing is relatively recent, and the origins of the issue are not really relevant when looking at a more recent state of the code. The issue I'm referring to has existed in vBulletin somewhere during the past several years, and bcrypt has been around for a long time now.

    xyz said: Migration is indeed possible, but somewhat ugly to do, which may be why no-one bothered. But maybe they should've considered it...

    It's fairly simple, in practice. All you have to do is add an indicator for the 'version' of a password hash, and re-hash upon login. Another useful recommendation is to hash the existing hashes as well (so instead of md5(value) you now have two versions: 1) bcrypt(md5(value)) and 2) the rehashed bcrypt(value)), though that does introduce some potential 'crypto-stacking' concerns.

    xyz said: Which is vulnerable to a different kind of attack - precomputed MD5+MD5 tables. The salt needs to be included in every round of hashing for it to be effective as a key strengthening technique.

    X(salt + X(password)) where X denotes a strong hash function, is perfectly fine for what it is. This is because your "theoretical" weakness isn't practical in any way here, if X is a strong hash.

    The 'correct' solution here would probably be md5(md5($password . $salt) . $salt), which should be vulnerable to neither.

    xyz said: The general principle [... snipped because of CloudFlare WAF ...] It would not somehow be 2 or less.

    It can be. Here is one example.

    Yes, security is hard, and easy to mess up, but many other things are as well. Saying that people shouldn't bother with it just for those reasons, I think is counter-productive.

    But that's not what I'm saying at all. I'm saying that they should stick with a known-good arrangement of cryptographic features that provides a certain (practically sufficient) set of guarantees, rather than trying to tack on their own stuff and risk breaking it with no practical benefits.

    EDIT: Fucking hell, CloudFlare's WAF is idiotic. Excuse any sloppy comments, it's pretty hard to write a sensible reply when CF is constantly throwing captcha pages into your screen while editing.

    Thanked by 1myhken
  • Truecrypt has since stopped being supported ("The development of TrueCrypt was ended in 5/2014 after Microsoft terminated support of Windows XP.")

    Veracrypt is a forked version that is being maintained now. Veracrypt is also in the middle of a security audit to verify the security of the project

    Thanked by 1myhken
  • myhken said: Three containers, but only one file at the end.

    This is way overkill and you are liable to lose data because you forgot one or more passwords. Just encrypt it once using openssl or gpg. That's it.

  • +1 for @joepie91 from here.

    @mykhen go with the one strongest tool you find or decide to be it and use a strong cipher/password for sure. adding weaker layers around it doesn't make sense at all.

    only if I had two tools of comparable strenght but different protection technologies I would consider combining them to protect against different attacking vectors.

    so out of your comparison I'd probably pick veracrypt with a encryption like serpent aes and a strong pw, as it's actively maintained and opensource.

    Thanked by 1myhken
  • This discussion has been wide-ranging. I would like to start at the beginning. Is this the requirement?

    @myhken (paraphrased by @emg): I have an archive and I want to encrypt it so that only I can read it. I want to store the encrypted archive overseas, in a place where attackers will have access to the encrypted archive. I want to feel confident that my encrypted archive will remain secure no matter what, even if the attackers have virtually unlimited time and resources.

    >

    Kenneth (@myhken) then proposes a solution that uses three different encryption tools in succession. He names the three tools, along with the respective encryption algorithms and password sizes that he intends to use.

    Is that right? Here are my responses:

    • Archive Format - Kenneth mentioned both "archive" and "containers", but I do not understand what he means in this context. Is this a static archive that does not change, or is he thinking of a dynamic, encrypted virtual drive? His choice of tools implies the latter, but his original statement implies the former. Until he clarifies his requirements, I will assume that he has an unchanging (static) archive that he wants to encrypt.

    • Tools - Find a single, high quality tool that is being actively maintained, written by people who are passionate about security. Use the internet to find a good one. Trust it - you have no choice. You are not equipped to analyze it yourself.

    • More about Tools - TrueCrypt and VeraCrypt can do what you want, but most users think of them for volume-level encryption, where you can create an encrypted virtual drive or add whole disk encryption (the entire bootable drive is encrypted, like BitLocker). Support for TrueCrypt was suddenly and mysteriously stopped when the unknown authors posted a warning message that it was not secure. At the same time, the TrueCrypt source code underwent a paid security review by well-respected security experts who found only minor issues and pronounced it secure. The original authors removed encryption from the final release, so be sure you get "latest version - 1". VeraCrypt started from the TrueCrypt source code, and is one of several tools that wants to be the successor to TrueCrypt. It is NOT fully compatible with TrueCrypt, however. I know nothing about "BestCrypt" and won't bother to look.

    • Algorithms - There has been way too much focus on algorithms lately. In your case, either AES or Serpent is sufficiently strong for your needs. As of this writing, both algorithms are considered too strong for any adversary to break (even a well-funded government). Much more important is choosing a strong password.

    • Password Length - Passwords are not keys. A 16-character password is not the equivalent of a 16-byte (128 bit) random key, especially if you limit yourself to lowercase characters only. Whatever encryption tool you choose, you must use it with a very strong password. Try for 128 bits of randomness (entropy) = 10^39. A good, RANDOM 20+ character password should be sufficient. Here is a tool that may help you analyze your passwords:

    https://www.grc.com/haystack.htm

    Other considerations:

    • Data Integrity - is important. You must have a way to know whether your encrypted archive has been modified. Some tools incorporate data integrity checking as a part of their function.

    • Availability - is important. Even if your archive is securely encrypted, it won't do much good if you can't get it when you need it.

    My recommendation:

    I like @Abdussamad's recommendation: Zip the archive and then use openssl or gpg with AES. GPG will let you "encrypt and sign" the file, which provides built-in integrity protection, but it is more complicated for its initial setup. For your level of paranoia, I recommend a public key size of 3072 bits or more (but not more than 4096 for compatibility reasons).

    Thanked by 2myhken ehab
  • emg said: Zip the archive and then use openssl or gpg with AES

    Noooo. Encrypt and then compress! Both have diametrically opposite goals. Compression decreases the entropy of a stream to approach the entropy of the source (perfect/Hamming codes), while encryption increases it to make it appear more random. Compressed files have predictable regions, like file headers, and can be used to break the crypto.

    I suspect OP is trying to hide his tentacle porn. So 3072 bit key-size may not be enough :P

    Thanked by 1myhken
  • raindog308raindog308 Administrator, Veteran

    myhken said: Then I have three independent containers, with different crypto and stronger and stronger password. So if they brake into container A, they still have to brake into container B and C.

    You need to read more, because people who know more than you about encryption are telling you that you are wrong.

    joepie91 said: The issue is in the fact that it is extremely easy to fuck up,

    Take this as a summary of everything related to crypot. STOP TRYING TO DO YOUR OWN CRYPTO. You will screw it up. And you won't know it's screwed up if you do.

    Sure, "I encrypt with A, then B, and then C" sounds like it will increase security. But what you don't know is how those mathematical operations will interact. It's entirely possible - as in, go read some Schneier and find examples - that your resultant bitstream will be weaker.

    xyz said: Whether or not it improves security is questionable, but it certainly doesn't make it worse than the weakest link in the chain (maybe with some rare exceptions).

    The general principle of nesting goes like this. If you had a scheme, A(B(C( X ))) where X is your data, and you could quantify the strength of the crypto algorithms, say A's strength is 5, B=3, C=4, then the resulting overall security of the nest would be at least 3. It would not somehow be 2 or less.

    You don't know that, and unless you have a PhD in mathematics, you're unlikely to understand the math below. I certainly don't. But I do know it's not always true.

    It is not a safe assumption that multiple layers of encryption provide additive security.

    Sure, they sometimes do - e.g., https://en.wikipedia.org/wiki/Multiple_encryption - but encryption is something you leave to pros.

    Encryption is a field where the key knowledge is knowing what you don't know. You then either decide you want to know and spend 12-15 years getting a PhD in mathematics and reading the field, or you decide to leave it to pros.

    rincewind said: Noooo. Encrypt and then compress!

    If you can compress after encryption, your encryption isn't very good. By definition.

    rincewind said: Compressed files have predictable regions, like file headers, and can be used to break the crypto.

    OTOH so do most file formats, so...

    emg said: however. I know nothing about "BestCrypt" and won't bother to look.

    I know about BestCrypt and the last time I used it was about 1995 because it's been irrelevant since then. Who needs closed-source crypto in 2016?

    hzr said: If you are this paranoid, it doesn't matter at all if you are running it in a VM because you can just dump the container memory from the host (or potentially another VM on vulnerable hypervisors), extract the key from that, or if you already have the crypted volume mounted, just snapshot there or something.

    Yeah, that's the giggle here. The vulnerability isn't the encryption algorithm...it's the key management, the VM management, the network between you and the VPS (which passes through a kernel you don't control and devices you don't control, etc.)

    Thanked by 2myhken MikePT
  • I'm following the discussion and see that my plan maybe not was the best.
    I'm was sure of that three different containers, that had nothing to do with each other, then put together with copy/past in Windows would increase the security.

    I can't understand how container B can have any effect on container A, when container B is created with a different software, outside of container A, with a different crypto and a different password. When I then open(mount) container A and copy container B inside, how can that do anything with the safety of container A? Container B is just a normal file inside container A.
    And when I add container C inside container B, it also is a normal file. How can that be less secure? I really don't understand?

    The files in the last container is just normal files, will not be changed, will not be opened on any remote server.

    But most of you tell me that adding a container inside another container make the first container weak. So if I add normal files inside the first container, they will also make the container weak?
    What is the difference between a .jpg file and a .tc (trycrypt) file inside a container?

  • @rincewind said:
    Noooo. Encrypt and then compress!

    if the use of compressing here is just randomness than maybe with with cost of increased file size and time!

    i didn't read all through this but what is wrong with encfs!

    Thanked by 1myhken
  • It will not be any compressing, the files stay as they are, within their container.

Sign In or Register to comment.