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.
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?
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.
Comments
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.
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.
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..
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.
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.
It's proprietary, so there's no way to verify this whatsoever. Avoid at all costs.
I would look at something based on
libsodiumlike 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.
Can agree on this. (Cannot say specified reasons, but I know this is pure bull-crap)
Thank you. Will check it out.
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
scryptorbcryptinstead... 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.
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.
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".
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.
Yup. I remember a similar conversation about encrypting a file before compressing it. If you compress first you lose entropy and weaken encryption.
If you are going to layer them, it is better to put the strongest layer inside and weaker layers outside. Fingers crossed.
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.
Already mention this. This is just for storage, will not be opened ever on any host, just at home.
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)
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.
This is completely irrelevant, and not at all how security works. You're wrongly assuming that if it's broken,
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.
"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.
Emphasis on "theoretically". There's a reason I said that explicitly.
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.
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$passwordand$saltin different steps. Had they donemd5(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.
@joepie91
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.
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.
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.
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...
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.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.
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.
People who honestly provide security software that does exactly what it says on the tin.
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".
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.
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.
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 rehashedbcrypt(value)), though that does introduce some potential 'crypto-stacking' concerns.The 'correct' solution here would probably be
md5(md5($password . $salt) . $salt), which should be vulnerable to neither.It can be. Here is one example.
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.
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
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.
This discussion has been wide-ranging. I would like to start at the beginning. Is this the requirement?
>
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).
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
You need to read more, because people who know more than you about encryption are telling you that you are wrong.
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.
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.
If you can compress after encryption, your encryption isn't very good. By definition.
OTOH so do most file formats, so...
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?
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.)
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?
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!
It will not be any compressing, the files stay as they are, within their container.