To respond:
1. ' encryption approximates at 200% less performance'
At the top of the script I point out that CPU load is greatly increased and suggest that using single or double at most is more than suffficient, perhaps you skimmed it. I took it to a potential three layers since tbat seemed the likely practical maximum. For a laugh I also tested it with 8 layers of encryption, and a 1.87GHz Centrino actually coped, even (barely) playing an avi file off the encrypted partition. Some posters on his list talk about double encryption, presumably they can take the performance hit.
2. 'the keys where used wrongly'
The embedded keys are all gpg encrypted as usual before being written to the loop devices. Unsure what you mean by 'exposed' or 'wrongly used'. You have to remember a seperate passphrase for each layer. There is not one passphrase for all three layers.
3. 'after breaking the
first layer, you still have something for which you can say if it is a
valid gpg file"
Can't be helped with embedded keys unless some type of steganographic scheme is used to hide gpg-encrypted keys within encrypted loop devices. The purpose of the embedded gpg-encrypted keys is convenient key management (you only have one external key) and has been posted on this list before, but not with a script AFAIK. Since the first layer uses an external key, the partition does not have a gpg key sticking out to announce that it is probably encrypted.
Or use the script's detatched keys setting and just keep your keys physically somewhere else as usual (no embedded keys) if you really think the first layer is crackable. But if the first loop-aes layer is crackable, attackers still have to crack the second. And if they can decrypt the first layer then there's likely to be a fundamental flaw in the user's setup/security, like a key logger.
Matthias Schniedermeyer <ms@xxxxxxx> wrote:
Phil H wrote:
> Seems my little script has been met with about as much interest as yet another offer to "enlarge your penis".
>
> Is there a reason for that? Is it naive? Does it contain or repesent an encryption faux pas?
First: Similar to IANAL i have to say that i'm no encryption expert.
So at least part of my argumentation is pure guessing!
For me personally:
- Performance: triple encryption approximates at 200% less performance.
(With which i could live for tiny amounts of data, but not the 11,5TB of
space for which i need best(tm) performance, given the constraints)
- IIRC the keys where used wrongly, breaking the first layer exposes the
keys to the second and that exposes the keys to the third layer.
But even if that's true. Then it's only an implementation fault, not a
fault in the schema itself.
Encrypting all 3 keys would solve that "problem", with the new "problem"
that you have to remember 3 passphrases instead of one.
Also storing the 2 "inside" keys somewhere outside "solves" the problem
that you can(!) verify that you broke the first layer.
With 3 layers, of exactly the same size on top of each other, you have
to break all 3 layers to get to verifiable data/known plaintext.
Although you don't have exactly "know plaintext", after breaking the
first layer, you still have something for which you can say if it is a
valid gpg file or not.
- I need automation (as much as possible). Besides entering the
passphrase for a key-containers i want no interaction at all.
- Therefore: I had my own scripts done before you posted yours, and i
think mine are too specific for myself.
I don't think my udev/autofs integration/configuration is general usable.
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
Don't pick lemons.
See all the new 2007 cars at Yahoo! Autos.
