obviscating python code for distribution

Hans Georg Schaathun hg at schaathun.net
Wed May 18 15:56:17 EDT 2011


On Wed, 18 May 2011 12:07:49 -0700, geremy condra
  <debatem1 at gmail.com> wrote:
:  I was playing around with an HSM the other day that had originally
:  targeted FIPS 140-3 level 5, complete with formal verification models
:  and active side-channel countermeasures. I'm quite confident that it
:  was secure in nearly any practical sense.

And you ostensibly use the word /nearly/ rather than «absolutely».
It seems that we agree.

BTW, according to the sources I can find quickly, FIPS 140-3
targets /modules/ and not systems.

:  Ah, my mistake- when you said 'some level of security' I read that as
:  'some meaningful level of security'. If you were arguing that it
:  provided roughly as much protection to your code as the curtain of air
:  surrounding you does to your body, then yes- you're correct.

Well, I didn't.  Whether it is meaningful is relative and dependent
on the context, but it sure isn't meaningful if any values at stake are.

:  Empirically this doesn't appear to be a successful gambit, and from an
:  attacker's point of view it's pretty easy to see why. When a system
:  I'm trying to break turns out to have done something stupid like this,
:  it really just ticks me off, and I know a lot of actual attackers who
:  think the same way.

That is very true.  It is a very crude measure with a marginal
effect on risk.  Going out of one's way to try to obfuscate the
code as machine code, as was the starting point of the discussion,
is surely not a good strategy, as one is then spending significant 
time to achieve a rather insignificant.

My main concern is that the use of absolutes, «you need this», and
«that is silly», is drawing attention from the main point.  Rather,
get to know your risks and focus on the greater ones.  Consider
possible controls, and choose cheap and effective ones.  Even a
marginally effective control may be worth-while if the cost is even
less.  We all seem to agree on the main point; many have argued the
same way.

As an aside, OTOH, don't you think MAYFARE would have been broken 
earlier if the source code were open?  It was around for ages before 
it was.

: > In theory, you can of course talk about absolute security.  For
: > instance, one can design something like AES¹, which is secure in
: > a very limited, theoretical model.  However, to be of any practical
: > use, AES must be built into a system, interacting with other systems,
: > and the theory and skills to prove that such a system be secure simply
: > has not been developed.
: 
:  This is flatly incorrect.

Which part of it?  If you claim that the theory and skills to prove it
exist, could you give a reference please?

Of course, if you are only thinking of «nearly any practical sense»
again, then we agree and always did.

: > Why do you think Common Criteria have not yet specified frameworks
: > for the top levels of assurance?
: 
:  Perhaps because the lower levels of 'assurance' don't seem to provide very much.

If the lower levels do not, would that not be an argument to implement
more levels?  Too many governments have put too much resources into 
this to just throw it away if the methodology to achieve higher assurance
could be codified.

Or maybe it is right to say that the theory and skills do exist, but the
money to gather it all in one project to demonstrate the security of
a single system does not :-)

-- 
:-- Hans Georg



More information about the Python-list mailing list