Howdy, Stranger!

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

Subscribe to our newsletter

Advertise on LowEndTalk.com

Latest LowEndBox Offers

    Crypto: Archive with three different crypto programs - how safe?
    New on LowEndTalk? Please read our 'Community Rules' by clicking on it in the right menu!

    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.

    Kenneth Myhre
    WindowsTemplate.com - free Windows templates for OVH/Hetzner/Kimsufi/Online.net

    Powered by Hetzner.com, backed up by OVH, Kimsufi and VULTR.com

    «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

      My comments are mine and mine alone, and do not reflect the opinion of my business

    • 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

      time wasters please dont comment as we are a serious buyer
      Programmer trying to do Logo Designs

    • hzrhzr Member, Moderator
      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.

      Thanked by 1sdglhm

      Kenneth Myhre
      WindowsTemplate.com - free Windows templates for OVH/Hetzner/Kimsufi/Online.net

      Powered by Hetzner.com, backed up by OVH, Kimsufi and VULTR.com

    • joepie91joepie91 Member, 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

      time wasters please dont comment as we are a serious buyer
      Programmer trying to do Logo Designs

    • joepie91joepie91 Member, 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.

      Kenneth Myhre
      WindowsTemplate.com - free Windows templates for OVH/Hetzner/Kimsufi/Online.net

      Powered by Hetzner.com, backed up by OVH, Kimsufi and VULTR.com

    • @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.

      Kenneth Myhre
      WindowsTemplate.com - free Windows templates for OVH/Hetzner/Kimsufi/Online.net

      Powered by Hetzner.com, backed up by OVH, Kimsufi and VULTR.com

    • 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

      Trusted Provider ultravps[.]eu in AMS/LON/DAL/LAX/Moldova/Düsseldorf :
      2GB KVM(SSD 60GB) starts €33.6/yr (Limited Stock) <-- bonus discount (~7.5% off in 1st year for new clients.)

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

      Thanked by 1vimalware

      Kenneth Myhre
      WindowsTemplate.com - free Windows templates for OVH/Hetzner/Kimsufi/Online.net

      Powered by Hetzner.com, backed up by OVH, Kimsufi and VULTR.com

    • @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, 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.

      Kenneth Myhre
      WindowsTemplate.com - free Windows templates for OVH/Hetzner/Kimsufi/Online.net

      Powered by Hetzner.com, backed up by OVH, Kimsufi and VULTR.com

    • joepie91joepie91 Member, 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, 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

      jimpop: nuclear accidents DO happen
      jimpop: don't let them bring your website down

    • 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

      most recommended Provider: First-Root KVM Power-Edition /w SSD
      UltraVPS.eu KVM in US/UK/NL/DE: 15% off first 6 month | Netcup VPS/rootDS - 5€ off: 36nc15279180197 (ref)

    • 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
    • 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

      For LET support, please visit the interim support desk.

    • 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?

      Kenneth Myhre
      WindowsTemplate.com - free Windows templates for OVH/Hetzner/Kimsufi/Online.net

      Powered by Hetzner.com, backed up by OVH, Kimsufi and VULTR.com

    • @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
      • do not prepay > 1 year and check for reviews/support
      • only use monthly from a provider operating < 1 year 🍆
    • It will not be any compressing, the files stay as they are, within their container.

      Kenneth Myhre
      WindowsTemplate.com - free Windows templates for OVH/Hetzner/Kimsufi/Online.net

      Powered by Hetzner.com, backed up by OVH, Kimsufi and VULTR.com

    • This is/was/maybe my plan:

      All three container files is created independently with their respectably software as one and one file = total 3 files. They have nothing to do with each other, beside I will copy C into B and B into A. To open C (there the files is) you have to mount A, then mount B, then mount C. If A is cracked, they still have to crack B, then C, meaning they have to crack three different crypto software, three different crypto and three different passwords.

      Kenneth Myhre
      WindowsTemplate.com - free Windows templates for OVH/Hetzner/Kimsufi/Online.net

      Powered by Hetzner.com, backed up by OVH, Kimsufi and VULTR.com

    • emgemg Member
      edited September 2016

      Follow-up:

      YOU CAN'T COMPRESS ENCRYPTED DATA:

      As others have pointed out, if your data is encrypted, then you can't compress it. If you find that you can compress your encrypted data, then your encryption algorithm is not secure. One of the first lessons that budding cryptographers learn is: "Compress, then encrypt".

      I suggested "zip then encrypt" as much to bundle the files together into one package for convenience as to save on storage, but I wrote it mostly to demonstrate the correct order as I explained in the paragraph above. @myhken (Kenneth) can bundle up his archive however he wants. The tar command might be more appropriate. I should have been more clear about that. Sorry.

      HOW MULTIPLE LAYERS OF ENCRYPTION CAN DECREASE SECURITY

      Kenneth asks how multiple layers of encryption could weaken his security. In most reasonable cases it won't, other than wasting CPU cycles. I will try to explain how it can make a difference and reduce security, and it isn't just the encryption part.

      Consider ROT13.

      ROT13 might be good enough to keep your kid sister's diary safe from your kid brother. If your kid sister double-encrypts the diary with ROT13, then even your kid brother will be able to read it. (That's because the second "encryption" actually decrypts the text back to its original form.)

      To cite an example that is more relevant to Kenneth's proposal, look at Triple DES.

      (Single) DES is a 64-bit block cipher (encryption algorithm) with a 56-bit key size. It was a US government standard, now deprecated because it is not secure. There are several reasons why DES is not secure, but that doesn't matter. To strengthen DES for high security use, the government approved Triple DES. Triple DES is where you perform the DES "encryption" operation three times, each with a different, independent key. Thus, the Triple DES key size is 168 bits, which is considered very strong, even by today's standards.

      A brute force attack is one where you try every possible key until you find the right one. You might get lucky on the first try, or you might be unlucky and try all possible keys, but on average, you would try about half the keys before you find the right one. To brute force an ideal encryption algorithm with a 128-bit key, you would try 2^127 keys on average. (2^127 is half of 2^128.)

      Based on what I wrote above, you would think that the average "work factor" to break Triple DES with the 168-bit key would be 2^167. In fact, it is only 2^112 plus a hair more. (That is still very strong, but not as strong as you would expect.)

      I have left out many important details, including memory requirements, but the essential point is that even though you are performing three separate encryptions using three independent keys, the resulting security is roughly as strong as two encryptions, not three. (Extra credit: Search for "Triple DES meet in the middle attack.")

      APPLYING THE LESSON TO KENNETH's PROPOSAL

      Let us assume that the only way to attack Kenneth's proposed solution is a brute force attack on each product, and that the products are roughly equivalent. Basically: Try every possible password until you get it right. I will assume that the passwords are completely random combinations of uppercase, lowercase, numbers, and special characters.

      Per the GRC website (https://www.grc.com/haystack.htm):

      • First Password is 16 characters = 10^31 = 105 bits
      • Second Password is 22 characters = 10^43 = 145 bits
      • Third Password is 32 characters = 10^63 = 210 bits

      You would think that the strength of Kenneth's three program scheme is 16 + 22 + 32 = 70 characters = 10^138 = 459 bits. That is not true. The actual strength of Kenneth's scheme is "only" 16 + 22 = 38 characters = 10^67 = 224 bits.

      Kenneth would have stronger security if he used one encryption, but added seven more characters to his longest password (32 + 7 = 39 characters). In that case, 39 characters = 10^69 = 229 bits.

      In other words, a single encryption with a 39 character password is 32 times stronger than Kenneth's three-pass encryption with the 70 character combined password (16 + 22 + 32 characters).

      NOT THE ONLY EXAMPLE

      I can cite many other examples where multiple encryptions are weaker than a single pass. To be honest, many of them rely on poor software implementations by programmers with less than ideal security programming experience, or weak algorithms. Typical examples involve (re)using related keys and/or IVs, certain block cipher mode issues, stream ciphers, etc.

      WHY KENNETH'S PROPOSAL WEAKENS SECURITY

      I will concede that as long as the passwords (keys) are strong, independent, and not reused, using multiple products to perform encryptions is very unlikely to weaken the security related to encryption below the strength of the longest password that he uses (32 characters). As we have seen above, it doesn't really help, either.

      That's not the only aspect of security that should be important to Kenneth. People often think about the "CIA" triad - confidentiality (encryption), integrity, and availability.

      Complexity is the enemy of security, and Kenneth's proposed solution is a poor one, because of its operational complexity. If Kenneth makes any mistakes, then his data is lost - not available when he needs it. The more processing operations that are performed, the more likely that a bit will flip and put the integrity of his data at risk, too. Some products may detect integrity issues and fail ungracefully, losing all of the data, not just a small amount. The probability of a bit error in the processing is far higher than the key strength of one of his three encryption products put together, let alone all three in sequence.

      RECOMMENDATION

      I still believe that Kenneth should find one good solid product that meets his needs, and rely on it. Choose a long, strong password, and it does not have to be 39 characters, that's for sure. That's what I would do. KISS.

      Okay, I wrote waaay more than I wanted (or expected), but I hope I got my points across.

      Thanked by 4myhken MikePT sdglhm xyz
    • emgemg Member
      edited September 2016

      P.S. I hope everybody realizes that once key sizes reach a certain point, adding bits to a key length does not improve security in a practical sense.

      If it takes longer than the lifetime of the universe to brute force a key, then what does lengthening the key by another bit mean? (Doubling the time to brute force the key.)

      Thanked by 1myhken
    • raindog308 said: If you can compress after encryption, your encryption isn't very good. By definition.

      You would be right for perfect encryption, and compressing an encrypted file is fucked up - but worse than encrypting a highly compressed file.

      But no encryption method is perfect, it's all about the trade-offs you make. I don't recommend mixing encryption and compression, or layering/stacking encryption one on top of another, but if you want to do it there are ways to minimize the damage. For instance, if you want to compress a file-system image you could do run-length encoding to skip all the zeroes and reduce file-size, and then do encryption on that.

      myhken said: All three container files is created independently with their respectably software as one and one file = total 3 files.

      Individual encryption methods work by squeezing in entropy in different ways, and understanding how they interact is very complex - just because one is AES and another is Serpent doesn't mean they are independent/orthogonal. Encryption strength also depends on your input file, where a method can encrypt some byte sequences better than others. Any security guarantees are probabilistic, over many files.

      Adding many passwords just makes you feel safer, it doesn't change the fundamental strength of any of these methods.

      I would recommend using a single strong encryption method - along the lines of PGP/GPG. PCP1 is a variation of PGP that uses elliptic curves instead of AES.

      Thanked by 1myhken
    • When nobody support my theory it's time to do what the expert says. Use one of my crypto software, choose a crypto and then use a long(er) password.

      Kenneth Myhre
      WindowsTemplate.com - free Windows templates for OVH/Hetzner/Kimsufi/Online.net

      Powered by Hetzner.com, backed up by OVH, Kimsufi and VULTR.com

    • rincewindrincewind Member
      edited September 2016

      emg said: budding cryptographers learn is: "Compress, then encrypt".

      Here is a counter example: Let's say a file has only combinations of "true" or "false". Eg - "true false true"

      Case1: Compress then Encrypt

      A perfect compression would whittle down each word to a single bit : either 0 or 1. So "true false true" = "101" - 3 bits. Then you encrypt that 3-bit sequence. Doesn't look good to me.

      Case2: Encrypt then Compress

      Encrypt your text file of 16 characters. Since the input has higher entropy than 3 bits, you would get better encrypted strings, but maybe negligible compression.

      Thanked by 1myhken
    • rincewind said: You would be right for perfect encryption, and compressing an encrypted file is fucked up - but worse than encrypting a highly compressed file.

      But no encryption method is perfect, it's all about the trade-offs you make. I don't recommend mixing encryption and compression, or layering/stacking encryption one on top of another,

      You may not, but pros in the field do:

      "10.6 Compression, Encoding, and Encryption

      Using a data compression algorithm together with an encryption algorithm makes sense for two reasons:

      • Cryptanalysis relies on exploiting redundancies in the plaintext; compressing a file before encryption reduces these redundancies.

      • Encryption is time-consuming; compressing a file before encryption speeds up the entire process.

      The important thing to remember is to compress before encryption. If the encryption algorithm is any good, the ciphertext will not be compressible; it will look like random data. (This makes a reasonable test of an encryption algorithm; if the ciphertext can be compressed, then the algorithm probably isn’t very good.)"

      -- Bruce Schneier, Applied Cryptography, 2nd Edition

      "Cryptanalysts use the natural redundancy of language to reduce the number of possible plaintexts. The more redundant the language, the easier it is to cryptanalyze. This is the reason that many real-world cryptographic implementations use a compression program to reduce the size of the text before encrypting it. Compression reduces the redundancy of a message as well as the work required to encrypt and decrypt."

      Same book, page 333

      Thanked by 3myhken yomero emg

      For LET support, please visit the interim support desk.

    • yomeroyomero Member
      edited September 2016

      Afer reading all this discussion, the only point that I want to add is, what a waste of resources and time to do this. If that can be an extra negative point to do this.

    • rincewindrincewind Member
      edited September 2016

      raindog308 said: Bruce Schneier, Applied Cryptography, 2nd Edition

      Hard to argue against Bruce Schneier without the context, but things have changed from 1996.

      Side-channel attacks based on the compressor can be used to break encryption as discussed here.

      The “folk wisdom” in the cryptographic community is that adding compression
      to a system that does encryption adds to the security of the system, e.g.,
      makes it less likely that an attacker might learn anything about the data being
      encrypted. This belief is generally based on concerns about unicity distance,
      keysearch difficulty, or ability of known- or chosen-plaintext attacks. We believe
      that this folk wisdom, though often repeated in a variety of sources, is not generally
      true; adding compression to a competently designed encryption system has
      little real impact on its security. 
      

      Cases in point, the CRIME and BREACH attacks that use information leakage in HTTP compression to break SSL and TLS.

      The point is that both encryption and compression have different goals when it comes to transforming entropy. You need to balance your priorities.

      EDIT: Added quote from paper

    • My thanks to @raindog308 and @rincewind for their time and helpful contributions.

      In my opinion, @rincewind's comments about potential security issues with compression are valid in some contexts (e.g., HTTPS), but do not apply in the context of @myhken's specific problem.

    • joepie91 said: I'm disputing that it's legitimate to advertise it as "military-grade".

      I think it's perfectly legitimate and in no way misleading to do so, but each to their own.

      joepie91 said: 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.

      Salt adds entropy.

      joepie91 said: the origins of the issue are not really relevant when looking at a more recent state of the code

      But I believe it is, which is why I mentioned it.

      joepie91 said: It can be. Here is one example.

      I really can't be bothered reading through a massive page to find something that's relevant to the topic at hand, so I'll apologise that I won't be getting back to you on that one.

      rincewind said: 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

      Excuse me for saying this, but are you honestly just throwing out buzzwords hoping that it somehow makes sense? You're so far off the mark that it's not even worth responding to.

      But since I was stupid enough to enter the conversation anyway, here I go:

      • compression increases entropy
      • encryption also increases entropy. In a number of ways, compression and encryption have similar goals
      • Hamming codes are a form of parity/FEC scheme, and have little relevance to compression or encryption
      • as pointed out, you can't compress encrypted data if your encryption scheme is any good
      • compression and predictability are 'diametrically opposite goals'. If something can be predicted, then compression should remove it.
      • as pointed out, compression can improve the effectiveness of encryption by increasing the source's entropy as well as reducing the amount of 'vulnerable data'. In practice, the difference probably isn't really noteworthy though. Note that if the attacker can influence the source data (i.e. a chosen plaintext attack), attacks such as 'CRIME' are problematic as it can cause leaks due to length changes, but this isn't an issue if the attacker cannot do this

      raindog308 said: You don't know that

      I do know that. What of it?

    • If you believe that encryption and compression have similar goals then it makes a conversation difficult.

      Compression removes the redundancy in the input to represent the input in the fewest number of bytes. Eg - "true false" to "10"

      Encryption uses the redundancy to make the input less predictable. Eg - "true false" to "T%#DJ#F4s2" - i.e. same number of bytes but the memory capacity of the 10-byte string is filled up with more entropy extracted from /dev/urandom, salts and passwords.

      I understand your skepticism on the relevance of Hamming codes, but compression can be viewed as a packing problem. I'll just refer to the Wikipedia entry on Coding Theory under the section on Perfect codes and leave it at that.

      On the question of compression improving effectiveness of encryption, I have already addressed it in my previous post.

    • If I recall, the requirements were:

      (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) proposed 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.

      The discussions about entropy, compression, etc. are academically interesting, but are not very useful to Kenneth unless you show him how your conclusions apply to his problem.

      Here is my summary:

      • We have demonstrated why using multiple tools weakens security. (I failed to mention that if you use three encryption products, you triple the risk that one of your chosen tools might lose support, backwards compatibility, etc., so I will mention it now.)

      • We gave Kenneth a way to measure the strength of a random password.

      • I hope we made it clear to Kenneth that once the strength of his encryption reaches a certain point, increasing the key size or adding another encryption layer will not improve security. At best, it will be just as secure, and at worst, it will weaken it. In my opinion, a well-written encryption tool that uses a full 128-bit key is sufficient.

      • We have explained that if you are going to compress the archive, you must do it before encryption. Some encryption tools include a compression capability.

      • I believe that we have shown Kenneth that compressing his archive does not weaken security for his use case. There are other situations where compression should not be used, but they do not apply to Kenneth's archive question.

      I recommend that Kenneth find a single encryption product that he trusts. Kenneth should use it to encrypt his archive. He should choose a strong password that is the equivalent of a 128-bit key (that's a very long password!). He can safely compress his archive (for bundling or size-reduction purposes) before encryption, without degrading security for this use case.

      Does anyone disagree with that?

      Thanked by 1myhken
    • @emg said:

      Why do you keep calling him Kenneth?

    • xyz said: I do know that. What of it?

      You may, but my point was that 99.999% of people on the planet (hell, it might be 99.999999%) don't have the math background to understand encryption. Yet many people try to roll their own encryption.

      I don't argue with my dentist about the right way to fill a cavity. I don't argue with professional cryptographers about encryption theory. Some things just require a specialist and it's folly to ignore their advice.

      For LET support, please visit the interim support desk.

    • rincewindrincewind Member
      edited September 2016

      As an alternate to dd + gzip, you could do e2image -Qap to generate a QCOW2 image, before encrypting it.

    • emgemg Member
      edited September 2016

      @ManofServer said:

      Why do you keep calling him Kenneth?

      Umm ... because that's his name?

      Did you read his signature on the top post of this thread ... and every one of his posts after that? Don't respond; it is a rhetorical question. We already know the answer.

    • @ManofServer said:

      @emg said:

      Why do you keep calling him Kenneth?

      Hello, my name is Kenneth. Whats yours?

      Kenneth Myhre
      WindowsTemplate.com - free Windows templates for OVH/Hetzner/Kimsufi/Online.net

      Powered by Hetzner.com, backed up by OVH, Kimsufi and VULTR.com

    • @myhken said:
      Hello, my name is Kenneth.

      What's the frequency, btw?

      Thanked by 3emg Microlinux myhken

      For LET support, please visit the interim support desk.

    • @emg said:

      @ManofServer said:

      Why do you keep calling him Kenneth?

      Umm ... because that's his name?

      Did you read his signature on the top post of this thread ... and every one of his posts after that? Don't respond; it is a rhetorical question. We already know the answer.

      It still is weird to cite his username and first name several times in the same post, no one else does it? I didn't understand the fundamental purpose behind it.

    Sign In or Register to comment.