Path: csiph.com!usenet.pasdenom.info!news.redatomik.org!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <558eded8$0$1642$c3e8da3$5496439d@news.astraweb.com>
References: <mmcagn$aa5$1@ger.gmane.org> <q67loadve6lsrh672u47omr04tvqttt6jd@4ax.com> <mailman.29.1435170987.3674.python-list@python.org> <558b7e85$0$1648$c3e8da3$5496439d@news.astraweb.com> <mailman.42.1435206516.3674.python-list@python.org> <558bc912$0$2899$c3e8da3$76491128@news.astraweb.com> <slrnmonkip.1nu.jon+usenet@frosty.unequivocal.co.uk> <558c1a7e$0$1668$c3e8da3$5496439d@news.astraweb.com> <slrnmoo7ev.1nu.jon+usenet@frosty.unequivocal.co.uk> <CAPTjJmqOzLTv9cFFKjV-BLtaFZhEZ4B870ALqNMmanCEN-VqXA@mail.gmail.com> <mailman.89.1435280528.3674.python-list@python.org> <558d86b0$0$1659$c3e8da3$5496439d@news.astraweb.com> <mailman.111.1435349412.3674.python-list@python.org> <558e1ac6$0$1675$c3e8da3$5496439d@news.astraweb.com> <mailman.121.1435384091.3674.python-list@python.org> <558e610f$0$1648$c3e8da3$5496439d@news.astraweb.com> <mailman.139.1435417817.3674.python-list@python.org> <558eded8$0$1642$c3e8da3$5496439d@news.astraweb.com>
From: Ian Kelly <ian.g.kelly@gmail.com>
Date: Sat, 27 Jun 2015 14:16:16 -0600
Subject: Re: Pure Python Data Mangling or Encrypting
To: Python <python-list@python.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.145.1435436224.3674.python-list@python.org>
Lines: 95
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:93261

On Sat, Jun 27, 2015 at 11:35 AM, Steven D'Aprano <steve@pearwood.info> wro=
te:
> On Sun, 28 Jun 2015 01:09 am, Ian Kelly wrote:
>
>> On Sat, Jun 27, 2015 at 2:38 AM, Steven D'Aprano <steve@pearwood.info>
>> wrote:
>>> Can you [generic you] believe that attackers can *reliably* attack remo=
te
>>> systems based on a 20=C2=B5s timing differences? If you say "No", then =
you
>>> fail Security 101 and should step away from the computer until a securi=
ty
>>> expert can be called in to review your code.
>>
>> Of course. I wouldn't bet the house on it, but with the proposed
>> substitution cipher system, I don't see why there would be any
>> measurable timing differences at all based on the choice of key.
>
> I wouldn't bet one wooden nickle on it. Not without a security audit of t=
he
> application. And then what happens when the implementation changes and th=
e
> audit is no longer valid?

I don't disagree about the security audit, although I think you'll
find that such things will require a greater investment of resources
than a wooden nickel.

> Despite his initial claim that he doesn't want to use AES because it's to=
o
> slow implemented as pure Python, Randall has said that the application wi=
ll
> offer AES encryption as an option.

Once again you're confusing what he said about the server with what he
said about the client. Just because he considers it too slow for data
mangling on the server doesn't make it too slow for any use.

>> The time to obfuscate a single byte is constant,
>
> Are you sure about that? Bet your house? How about your computer?
>
>
> # Python 3.3 on Linux, YMMV
>
> py> text =3D 'NOBODY expects the Spanish Inquisition!'*50000
> py> import string
> py> s =3D string.digits + string.ascii_letters
> py> t =3D (string.ascii_uppercase + string.digits[::-1] +
> ... string.ascii_lowercase)
> py> trans1 =3D str.maketrans('abcdef', 'fedcba')
> py> trans2 =3D str.maketrans(s, t)
> py> trans3 =3D str.maketrans('aZ', 'Za')
> py> with Stopwatch():
> ...     x =3D str.translate(text, trans1)
> ...
> time taken: 0.427513 seconds
> py> with Stopwatch():
> ...     x =3D str.translate(text, trans2)
> ...
> time taken: 0.228869 seconds
> py> with Stopwatch():
> ...     x =3D str.translate(text, trans3)
> ...
> time taken: 0.387105 seconds

Your examples are using partial keys of different sizes. It's hardly
surprising that the timing varies when you pass dicts of varying sizes
as the translation tables.

py> a =3D list(range(256))
py> b =3D random.sample(a, 256)
py> c =3D random.sample(a, 256)
py> d =3D random.sample(a, 256)
py> min(timeit.repeat("str.translate(text, a)", "from __main__ import
text, a", number=3D10, repeat=3D10))
0.9780099680647254
py> min(timeit.repeat("str.translate(text, b)", "from __main__ import
text, b", number=3D10, repeat=3D10))
0.9837233647704124
py> min(timeit.repeat("str.translate(text, c)", "from __main__ import
text, c", number=3D10, repeat=3D10))
0.9627216667868197
py> min(timeit.repeat("str.translate(text, d)", "from __main__ import
text, d", number=3D10, repeat=3D10))
0.9793561780825257
py> min(timeit.repeat("str.translate(text, c)", "from __main__ import
text, c", number=3D10, repeat=3D10))
0.9840573272667825

I ran it on c a second time to see if the 0.962 timing was systemic or
a fluke. The fact that c produced both the shortest and longest
timings out of only two runs lends me confidence (for the purpose of
this discussion) that the variation seen in these timings is random
and not correlated to the keys used.