3 ms·
(1) You're saying use standardized fully-vetted methods. (2) Parent is asking for something just slightly different enough that it escapes dragnets and automat
by cantrevealname 11y ago
(1) You're saying use standardized fully-vetted methods.
(2) Parent is asking for something just slightly different enough that it escapes dragnets and automated attacks.
There is no question that (1) is much better than (2).
But in special circumstances, one could do both (1) and (2) in cascade operation (i.e., do one first, then the other). If the code for (1) and (2) run as separate processes with independently chosen keys, seeds, parameters, etc., then it doesn't matter how awful (2) is. It might help, it might not help, but it won't make the security worse than using (1) alone.
The obvious downsides are slowness, code complexity, non-standard API/interface, code maintenance headaches, and false sense of extra security (but not worse security).
- adrianN 11y agoYou have to be careful which algorithm you run first though. If you use your crappy implementation first, it might compromise the security of the second round of encryption. ftp://ftp.inf.ethz.ch/pub/crypto/publications/MauMas93a.pdf
- drblast 11y agoThis was a great reverse engineering trick. A lot of "hackers" would make their tools super-secure by packing the binary and then protecting it with VMProtect. Because, that's way better than just using VMProtect by itself, right? Except that you could run the VMProtected binary until just after the unpacking routine ended giving you the original binary in memory. Didn't have to understand VMProtect at all. Thanks hackers! The same thing isn't necessarily true with crypto, but the lesson is that thinking you're adding security by layering without knowing what you're doing might backfire.