Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!feeder.news-service.com!xlned.com!feeder5.xlned.com!newsfeed.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=MD9eGhKbdkyWSEpjknxvVuYwTsdhMaDS5xevpolzhCb4AVUH1xtkppfinN0XtsmHIw gF7ZyKeBK8tGUt/Oxh6su+xiVwmLBExIESPy7c8k36pfu4GsMgdZ1negzzZKqb8a7llO EUEhc7x79m8SNX0/nJGW5xAlTTXCKV+T4eed8=
MIME-Version: 1.0
In-Reply-To: <4vlea8-55t.ln1@svn.schaathun.net>
References: <4DD08620.4030507@tysdomain.com> <mailman.1611.1305512463.9059.python-list@python.org> <op.vvlipenoa8ncjz@gnudebst> <5h9ca8-ekq.ln1@svn.schaathun.net> <mailman.1757.1305737674.9059.python-list@python.org> <rgcda8-tor.ln1@svn.schaathun.net> <mailman.1769.1305745672.9059.python-list@python.org> <1skda8-3as.ln1@svn.schaathun.net> <mailman.1773.1305754489.9059.python-list@python.org> <4vlea8-55t.ln1@svn.schaathun.net>
Date: Thu, 19 May 2011 10:23:47 -0700
Subject: Re: obviscating python code for distribution
From: geremy condra <debatem1@gmail.com>
To: Hans Georg Schaathun <hg@schaathun.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: python-list@python.org
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.1795.1305825830.9059.python-list@python.org>
Lines: 74
NNTP-Posting-Host: 82.94.164.166
Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:5779

On Wed, May 18, 2011 at 10:21 PM, Hans Georg Schaathun <hg@schaathun.net> w=
rote:
> On Wed, 18 May 2011 14:34:46 -0700, geremy condra
> =A0<debatem1@gmail.com> wrote:
> : =A0Systems can be designed that are absolutely secure under reasonable
> : =A0assumptions. The fact that it has assumptions does not make your
> : =A0statement true.
> : (...)
> : =A0I can't tell if you're trying to play word games with the distinctio=
n
> : =A0between "system" and "module" or if you're just saying that you aren=
't
> : =A0sure what FIPS actually certifies. Could you please clarify?
>
> The distinction between system and module is rather significant.
> If you only consider modules, you have bounded your problem and
> drastically limited the complexity.

Ah, the 'word games' option. I'm not going to spend a lot of time
arguing this one: HSMs are clearly the domain of systems research, are
referred to in both technical and nontechnical documents as 'keystone
systems', and the FIPS standard under which they are certified
specifically calls them systems more times than I care to count. They
are, to the people who make and use them, systems, and your attempt at
redefinition won't change that.

> : =A0Are you talking about the Mayfair classical cipher here?
>
> I am talking about the system used in public transport cards like
> Oyster and Octopus. =A0I am not sure how classical it is, or whether
> mayfair/mayfare referred to the system or just a cipher. =A0Any way,
> it was broken, and it took years.

Ah, MIFARE. That's a different story, and no, I don't believe they
would have been broken sooner if the specs were released. The
importance (and difficulty) of securing devices like smartcards wasn't
really recognized until much later, and certainly people with a foot
in both worlds were very rare for a long time. Also remember that DES
(with its 56-bit keys) was recertified just a few months before MIFARE
(with its 48-bit keys) was first released- it was a different world.

> : =A0The entire field of formal modeling and verification has grown aroun=
d
> : =A0solving this problem. My new favorite in the field is "formal models
> : =A0and techniques for analyzing security protocols", but there are othe=
r
> : =A0works discussing OS kernel verification (which has gotten a lot of
> : =A0attention lately) and tons of academic literature. Google (scholar) =
is
> : =A0the place to go.
>
> Sure, but now you are considering modules, rather than systems again.
> It is when these reliable components are put together to form systems
> that people fail (empirically).

Let me get this straight: your argument is that operating *systems*
aren't systems?

> : =A0If you can't say with confidence that something meets minimum securi=
ty
> : =A0standards, the answer is not to try to say it meets high security
> : =A0standards.
>
> So what? =A0The levels of assurance have nothing to do with standards.
> The levels of assurance refer to the /confidence/ you can have that
> the standards are met.

The increasing levels of assurance don't just signify that you've
checked for problems- it certifies that you don't have them, at least
insofar as that level of testing is able to find. Insisting that this
doesn't, or shouldn't, translate into tighter security doesn't make
much sense.

Geremy Condra