Path: csiph.com!usenet.pasdenom.info!news.albasani.net!feeder.erje.net!1.eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: Mark Lawrence <breamoreboy@yahoo.co.uk>
Subject: Re: Pure Python Data Mangling or Encrypting
Date: Fri, 26 Jun 2015 02:17:03 +0100
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>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
In-Reply-To: <CAPTjJmqOzLTv9cFFKjV-BLtaFZhEZ4B870ALqNMmanCEN-VqXA@mail.gmail.com>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.91.1435281438.3674.python-list@python.org>
Lines: 44
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:93175

On 26/06/2015 01:33, Chris Angelico wrote:
> On Fri, Jun 26, 2015 at 1:26 AM, Jon Ribbens
> <jon+usenet@unequivocal.co.uk> wrote:
>>> There are only 256 possible values for n, one of which doesn't transform the
>>> data at all (ROT-0). If you're thinking of attacking this by pencil and
>>> paper, 255 transformations sounds like a lot. For a computer, that's barely
>>> harder than a single transformation.
>>
>> Well, it means you need to send 256 times as much data, which is a
>> start. If you're instead using a 256-byte translation table then
>> an attack becomes utterly impractical.
>>
>
> Utterly impractical? Maybe, if you attempt a pure brute-force approach
> - there are 256! possible translation tables, which is roughly e500
> attempts [1], and at roughly four a microsecond [2] that'd still take
> a ridiculously long time. But there are two gigantic optimizations you
> could do. Firstly, there are frequency-based attacks, and byte value
> duplicates will tell you a lot - classic cryptographic work. And
> secondly, you can simply take the first few bytes of a file - let's
> say 16, although a lot of files can be recognized in less than that.
> Even if there are no duplicate bytes, that'd be a maximum of 16!
> translation tables that truly matter, or just 2e13. At the same speed,
> that makes about a million seconds of computing time required. Divide
> that across a bunch of separate computers (the job is embarrassingly
> parallel after all), and you could get that result pretty easily. Cut
> the prefix to just 8 bytes and you have a mere 40K encryption keys to
> try - so quick that you wouldn't even see it happen. Nope, a simple
> substitution cipher is still not secure. Even the famous Enigma
> machine was a lot more than just letter-for-letter substitution - a
> double letter in the cleartext wouldn't be represented by a double
> letter in the result - and once the machine's secrets were figured
> out, the day's key could be reassembled fairly readily.
>

The day's key for a given network, with the Luftwaffe easily being the 
worst offenders.  Some networks remained unbroken at the end of WWII.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence