John asked me to review his entry prior to submission, and we had some ongoing discussion as he worked through his revisions. He initially pointed me to a "minimally obfuscated" version to analyze. I'd say it took me a good hour or so to feel like I had a pretty good understanding of its workings, and even then I still wasn't clear on some details of the I/O model and a couple other things.
Most of the evolution from that point was finding ways to reduce the code size, then finally reformatting into a lambda. I credit John for not succumbing to gratuitous obfuscation, nor gratuitous use of macros to shave bytes. I suggested to him at one point to consider reducing the entire program to a single loop. He didn't think it would be shorter and pointed out that he had made a similar transformation in an earlier IOCCC entry of his, his infamous maze program, so I believed him and didn't go through the effort to verify for myself.
When you are talking about mid to high level security, you assume that your adversary is not an average programmer, but rather a train security analasyst. A major part of that field is looking finding vulnurabilities in machine code. Based on the statement "Obfuscation is due entirely to conciseness" in the author's hint, it sound like he did not use any techniques that would have a significant effect on the generated machine code.
Source: http://www.ioccc.org/2012/tromp/tromp.c
Spoiler: http://www.ioccc.org/2012/tromp/hint.html
It's based on a minimal implementation of Binary Lambda Calculus: http://en.wikipedia.org/wiki/Binary_lambda_calculus