Path: csiph.com!usenet.pasdenom.info!news.redatomik.org!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: Randall Smith <randall@tnr.cc>
Subject: Re: Pure Python Data Mangling or Encrypting
Date: Tue, 30 Jun 2015 12:39:30 -0500
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> <mmkbij$dpm$1@ger.gmane.org> <CAPTjJmon4abegr01-+mo5aLML+gA3wnR_+_kTTU7gGuCn=xrDA@mail.gmail.com> <mailman.141.1435424948.3674.python-list@python.org> <558ef059$0$1673$c3e8da3$5496439d@news.astraweb.com> <mailman.171.1435611181.3674.python-list@python.org> <5592065e$0$1675$c3e8da3$5496439d@news.astraweb.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
In-Reply-To: <5592065e$0$1675$c3e8da3$5496439d@news.astraweb.com>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.198.1435685990.3674.python-list@python.org>
Lines: 61
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:93343

On 06/29/2015 10:00 PM, Steven D'Aprano wrote:
> On Tue, 30 Jun 2015 06:52 am, Randall Smith wrote:
>
>> Not sure why you posted the link.  The crc32 checksum is just to check
>> for possible filesystem corruption.  The system does periodic data
>> corruption checks.  BTRFS uses crc32 checksums also.  Please explain.
>
> The file system can trust that anything writing to a file is allowed to
> write to it, in doesn't have to defend against malicious writes. As I
> understand it, your application does.
>
> Here is the attack scenario I have in mind:
>
> - you write a file to my computer, and neglect to encrypt it;
> - and record the checksum for later;
> - I insert malware into your file;
> - you retrieve the file from me;
> - if the checksum matches what you have on record, you accept the file;
> - since you are using CRC, it is quite easy for me to ensure the
>    checksums match after inserting malware;
> - and I have now successfully injected malware into your computer.
>
> I'm making an assumption here -- I assume that the sender records a checksum
> for uploaded files so that when they get something back again they can tell
> whether or not it is the same content they uploaded.

Yes.  The client software computes sha256 checksums.

>
> * * *
>
> By the way, regarding the use of a substitution cipher, I spoke to the
> crypto guy at work, and "preimage attack" is not quite the right
> terminology, since that's normally used in the context of hash functions.
> It's almost a "known ciphertext attack", but not quite, since that
> terminology refers to guessing the key from the ciphertext.
>
> I was wrong: cryptographically strong ciphers are generally NOT resistant to
> what I described as a preimage attack. If the key leaks, using AES won't
> save you: an attacker with access to the key can produce a ciphertext that
> decrypts to the malware of his choice, regardless of whether you use
> AES-256 or rot-13. There may be other encryption methods which don't suffer
> from that, but he doesn't know of them off the top of his head.
>
> His comment was, "don't leak the key".

I'm pretty sure all encryption hinges on guarding the key.

>
> The other threat I mentioned is that the receiver will read the content of
> the file. For that, a strong cipher is much to be preferred over a weak
> one, and it needs to be encrypted by the sending end, not the receiving
> end. (If the receiving end does it, it has to keep the key so it can
> decrypt before sending back, which means the computer's owner can just grab
> the key and read the files.)
>


And again, that's why the client (data owner) uses AES.