Comments on: Mesh design pattern: hash-and-decrypt http://rdist.root.org/2007/04/09/mesh-design-pattern-hash-and-decrypt/ Embedded security, crypto, software protection Mon, 06 Feb 2012 20:16:28 +0000 hourly 1 http://wordpress.com/ By: Nate Lawson http://rdist.root.org/2007/04/09/mesh-design-pattern-hash-and-decrypt/comment-page-1/#comment-2658 Thu, 23 Aug 2007 19:11:49 +0000 http://rdist.root.org/2007/04/09/mesh-design-pattern-hash-and-decrypt/#comment-2658 Thanks for the reference, ivan. There’s a huge hole in defining the various properties of this primitive, and it’s nice to see your paper covers more ground than I did here.

I have to write another post on this explaining how to obfuscate the process of gathering information for the hash. There are some really tricky things you can do to tie the hashing process to the functioning of the program such that it is hard to isolate which inputs actually have an effect on the output and which are no-ops.

]]> By: ivan http://rdist.root.org/2007/04/09/mesh-design-pattern-hash-and-decrypt/comment-page-1/#comment-2653 Wed, 22 Aug 2007 05:32:55 +0000 http://rdist.root.org/2007/04/09/mesh-design-pattern-hash-and-decrypt/#comment-2653 ahhh nice… similar ideas are presented, in a somewhat more “theoretical” manner here. A particularly interesting case is when the encrypted stages i..n+i are “triggered” (decrypted and executed) upon hiting the “right” hash on some external, enviromental input that is somewhere into the “future”, which makes and dynamic analysis quite painful (static analysis already is) because it does not suffice to artificially move the clock forward, you need to mvoe the entire programs state into the future

]]> By: Nate Lawson http://rdist.root.org/2007/04/09/mesh-design-pattern-hash-and-decrypt/comment-page-1/#comment-520 Thu, 12 Apr 2007 23:26:09 +0000 http://rdist.root.org/2007/04/09/mesh-design-pattern-hash-and-decrypt/#comment-520 I don’t understand how the fact that block ciphers have some of the same criteria as a hash function has any bearing on this. SHA-1 is being used to gather state at various points during operation, from various components. You could construct a hash function using AES as a primitive to get the same function as just using SHA, but why do that?

Your second point seems to be that you just brute force the input bits of state. If the protection gathers more than 128 bits of data, the naive brute force attack will not produce the necessary key in our lifetime. If you try to identify all the places where it gathers data, you’re back to needing to understand the protection code. If you try to find the key in memory just before it is used to decrypt the next stage, same thing.

Hash-and-decrypt is a primitive and needs to be used in conjunction with other primitives to prevent simple attacks like the above. The whole point of a mesh design is to have multiple checks which are interdependent and not easy to isolate for attack. I’ll be adding more articles on complementary mechanisms in the future.

]]> By: pepe http://rdist.root.org/2007/04/09/mesh-design-pattern-hash-and-decrypt/comment-page-1/#comment-519 Thu, 12 Apr 2007 23:03:45 +0000 http://rdist.root.org/2007/04/09/mesh-design-pattern-hash-and-decrypt/#comment-519 > Since a cryptographic hash (e.g., SHA-1) is sensitive to a change of even a single bit of input,
> this pattern provides a strong way to insure the next stage (code, data, more checks) is not
> accessible unless all the input bits are correct.

This should be covered by the avalanche-criterium for ciphers. Hashing gains no security, I simply prepend the hash-op myself when bruteforcing the needed game-state. No?

]]>