I'm wondering if inserting a container within a container based approach like a recursive TrueCrypt or VeraCrypt container would provide a more secure protection against brute force attacks, I/O efficacy be damned, my primary concern is protection against brute force attacks.

Would including the keys of the image(s) it was nested inside along with its own key be secure? considering the nested image would have different keys not placed outside its own metaphorical bubble.

Is there a benefit or flaw in mixing NIST/Non-NIST algorithms and is it even realistic in coding such a tool?

  • That is a solution in wait of a problem. – Stephane Nov 10 '15 at 7:52
  • Law of diminishing returns, rapidly approaches WoT. – Fiasco Labs Nov 10 '15 at 8:00
  • WoT relies on code audit, which means people have to understand both complex cryptography and *insert language or crypto library* – drwdal Nov 27 '15 at 11:48

There really is no value in double or triple encrypting data in the manner you describe. First, as a non-cryptographer, you cannot know the level to which you may compromise the crypto process. You absolutely can do that when combining algorithms. A good example of this is 3DES, which is really 3 cipher rounds of DES with the 144 bit key being three 48 bit keys, is more secure doing ENC->DEC->ENC than doing ENC->ENC->ENC. How do I know this? Some crypto guy told me. How did he know? He understood the cryptanalysis.

Information protection does not layer up the same way physical protection does (fences, cameras, locked doors, armed guards, key swipes and passcode, etc.). Some solutions might work like physical protection, but us normal humans can't really tell.

Also, if it did work really well, why aren't cryptographers advocating for the types of layered crypto you describe? I suspect the answer is that the value add (if there is value) is not worth the effort or complexity.

Also, packing keys along with the cryptext (if I understood your proposal) sounds like one need only break the exterior cipher in order to peel back every layer of the onion and get the inside text.

You've inadvertently hit upon the most significant problem with encrypting data at rest (stored data crypto): what to do with the encryption key? A large crypto key makes the data safe. You can't memorize it and you certainly can't memorize a 2048 RSA private key sequence. Where do you put it? How do you protect? You could encrypt it, but then that becomes a recursive problem - what to do with the new key? Ultimately, some human needs to open a wallet or a key store of some type, which means that human has to memorize a long sequence of characters containing enough entropy (true randomness) to be worthy of the data and/or keys it's protecting. That's why people are enamored with USB fobs. Of course, that's a physical object, which is a PITA to carry around and, if lost, often results in loss of all keys and plaintext. In the end, the human may write down the passwords and put them behind a locked door or drawer. So, back to physical security...

| improve this answer | |
  • 1
    Packing the keys would work like this, Layer 0 contains no keys, opens into an image containing the layer 0 key and the Hashed value of layer 1 for integrity check and the layer one container file then when layer one is opened it contains the layer 1 key and the integrity hash for layer 2, such is that the only keys exposed are the keys of the layer you are currently inside – drwdal Nov 10 '15 at 22:56
  • Right, so when you open layer 1 you have the layer 0 key right there available to open the layer 0. That means you only need to break the outside layer to open every layer. – Andrew Philips Nov 11 '15 at 5:23
  • layer 0 is the highest level layer, not the lowest, that explanation was confusing. I might end up making a chart and how would having the layer 0 key make a difference, if the next container wasn't encrypted with the same key? – drwdal Nov 27 '15 at 11:44
  • Got it. What is the value of appending the key to the plaintext prior to encryption with that key? You don't have the key when you need it (prior to encryption) and you don't need the key once you have it (after decrypting). More importantly, I'm concerned about a cryptanalysis attack that relies upon the key being encrypted by itself. Us common folk should refrain from making up cryptographic algorithms; it rarely ends well. – Andrew Philips Nov 27 '15 at 16:11
  • As far as what I've asked my CS professor and Discrete Mathematics professor they've asserted that a cryptanalysis attack would not really be an issue as long as key reuse and length/entropy were sustained, as far as I/O efficacy is concerned encrypting multiple rounds of an algorithm, even using different algorithms, would be acceptable as long as they didn't share a key but the required bit length was the same – drwdal Nov 28 '15 at 7:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.