Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #93096 > unrolled thread

Re: Pure Python Data Mangling or Encrypting

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Pure Python Data Mangling or Encrypting Randall Smith <randall@tnr.cc> - 2015-06-24 13:36 -0500
    Re: Pure Python Data Mangling or Encrypting Steven D'Aprano <steve@pearwood.info> - 2015-06-25 14:07 +1000
      Re: Pure Python Data Mangling or Encrypting Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-06-24 21:27 -0700
        Re: Pure Python Data Mangling or Encrypting Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-06-25 19:25 +1000
          Re: Pure Python Data Mangling or Encrypting Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-06-25 02:41 -0700
          Re: Pure Python Data Mangling or Encrypting Chris Angelico <rosuav@gmail.com> - 2015-06-25 19:57 +1000
          Re: Pure Python Data Mangling or Encrypting Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-06-25 10:03 +0000
            Re: Pure Python Data Mangling or Encrypting Steven D'Aprano <steve@pearwood.info> - 2015-06-26 01:13 +1000
              Re: Pure Python Data Mangling or Encrypting Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-06-25 15:26 +0000
                Re: Pure Python Data Mangling or Encrypting Randall Smith <randall@tnr.cc> - 2015-06-25 13:58 -0500
                Re: Pure Python Data Mangling or Encrypting Chris Angelico <rosuav@gmail.com> - 2015-06-26 10:33 +1000
                  Re: Pure Python Data Mangling or Encrypting Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-06-26 10:49 +0000
                Re: Pure Python Data Mangling or Encrypting Ian Kelly <ian.g.kelly@gmail.com> - 2015-06-25 19:01 -0600
                  Re: Pure Python Data Mangling or Encrypting Steven D'Aprano <steve@pearwood.info> - 2015-06-27 03:06 +1000
                    Re: Pure Python Data Mangling or Encrypting Randall Smith <randall@tnr.cc> - 2015-06-26 15:09 -0500
                      Re: Pure Python Data Mangling or Encrypting Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-06-26 23:07 +0200
                        Re: Pure Python Data Mangling or Encrypting Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-06-26 21:29 +0000
                          Re: Pure Python Data Mangling or Encrypting Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-06-26 22:55 +0100
                          Re: Pure Python Data Mangling or Encrypting Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-06-27 00:42 +0200
                            Re: Pure Python Data Mangling or Encrypting Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-06-26 16:26 -0700
                            Re: Pure Python Data Mangling or Encrypting Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-06-27 00:21 +0000
                            Re: Pure Python Data Mangling or Encrypting Randall Smith <randall@tnr.cc> - 2015-06-26 19:55 -0500
                              Re: Pure Python Data Mangling or Encrypting Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-06-27 07:24 +0200
                          Re: Pure Python Data Mangling or Encrypting Randall Smith <randall@tnr.cc> - 2015-06-26 19:12 -0500
                        Re: Pure Python Data Mangling or Encrypting Ian Kelly <ian.g.kelly@gmail.com> - 2015-06-26 15:58 -0600
                        Re: Pure Python Data Mangling or Encrypting Randall Smith <randall@tnr.cc> - 2015-06-26 19:23 -0500
                      Re: Pure Python Data Mangling or Encrypting Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-06-26 23:11 +0200
                        Re: Pure Python Data Mangling or Encrypting Michael Torrie <torriem@gmail.com> - 2015-06-27 11:02 -0600
                          Re: Pure Python Data Mangling or Encrypting Paul Rubin <no.email@nospam.invalid> - 2015-06-27 10:45 -0700
                      Re: Pure Python Data Mangling or Encrypting Steven D'Aprano <steve@pearwood.info> - 2015-06-27 13:38 +1000
                        Re: Pure Python Data Mangling or Encrypting Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-06-26 21:05 -0700
                          Re: Pure Python Data Mangling or Encrypting Steven D'Aprano <steve@pearwood.info> - 2015-06-27 16:16 +1000
                            Re: Pure Python Data Mangling or Encrypting Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-06-27 13:30 -0700
                              Re: Pure Python Data Mangling or Encrypting Steven D'Aprano <steve@pearwood.info> - 2015-06-28 11:18 +1000
                                Re: Pure Python Data Mangling or Encrypting Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-06-27 19:11 -0700
                        Re: Pure Python Data Mangling or Encrypting Ian Kelly <ian.g.kelly@gmail.com> - 2015-06-26 23:47 -0600
                          Re: Pure Python Data Mangling or Encrypting Steven D'Aprano <steve@pearwood.info> - 2015-06-27 18:38 +1000
                            Re: Pure Python Data Mangling or Encrypting Chris Angelico <rosuav@gmail.com> - 2015-06-27 18:53 +1000
                              Re: Pure Python Data Mangling or Encrypting Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-06-27 11:07 +0200
                                Re: Pure Python Data Mangling or Encrypting Chris Angelico <rosuav@gmail.com> - 2015-06-27 19:17 +1000
                                  Re: Pure Python Data Mangling or Encrypting Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-06-27 09:27 +0000
                                    Re: Pure Python Data Mangling or Encrypting Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-06-27 12:05 +0200
                                      Re: Pure Python Data Mangling or Encrypting Chris Angelico <rosuav@gmail.com> - 2015-06-27 20:16 +1000
                                        Re: Pure Python Data Mangling or Encrypting Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-06-27 12:55 +0200
                                      Re: Pure Python Data Mangling or Encrypting Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-06-27 10:26 +0000
                                    Re: Pure Python Data Mangling or Encrypting Laura Creighton <lac@openend.se> - 2015-06-27 14:27 +0200
                                  Re: Pure Python Data Mangling or Encrypting Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-06-27 12:18 +0200
                                    Re: Pure Python Data Mangling or Encrypting Chris Angelico <rosuav@gmail.com> - 2015-06-27 21:33 +1000
                                    Re: Pure Python Data Mangling or Encrypting Ian Kelly <ian.g.kelly@gmail.com> - 2015-06-27 08:59 -0600
                                  Re: Pure Python Data Mangling or Encrypting Laura Creighton <lac@openend.se> - 2015-06-27 13:25 +0200
                                    Re: Pure Python Data Mangling or Encrypting Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2015-06-27 15:23 +0300
                                    Re: Pure Python Data Mangling or Encrypting Laura Creighton <lac@openend.se> - 2015-06-27 14:48 +0200
                            Re: Pure Python Data Mangling or Encrypting Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-06-27 11:12 +0200
                            Re: Pure Python Data Mangling or Encrypting Ian Kelly <ian.g.kelly@gmail.com> - 2015-06-27 09:09 -0600
                              Re: Pure Python Data Mangling or Encrypting Steven D'Aprano <steve@pearwood.info> - 2015-06-28 03:35 +1000
                                Re: Pure Python Data Mangling or Encrypting Steven D'Aprano <steve@pearwood.info> - 2015-06-28 03:58 +1000
                                Re: Pure Python Data Mangling or Encrypting Ian Kelly <ian.g.kelly@gmail.com> - 2015-06-27 14:16 -0600
                                Re: Pure Python Data Mangling or Encrypting Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-06-28 13:41 +0000
                        Re: Pure Python Data Mangling or Encrypting Robert Kern <robert.kern@gmail.com> - 2015-06-27 08:58 +0100
                        Re: Pure Python Data Mangling or Encrypting Robert Kern <robert.kern@gmail.com> - 2015-06-27 09:07 +0100
                        Re: Pure Python Data Mangling or Encrypting Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-06-27 10:39 -0400
                      Re: Pure Python Data Mangling or Encrypting Grant Edwards <invalid@invalid.invalid> - 2015-06-27 12:38 +0000
                        Re: Pure Python Data Mangling or Encrypting Randall Smith <randall@tnr.cc> - 2015-06-27 13:22 -0500
                          Re: Pure Python Data Mangling or Encrypting Steven D'Aprano <steve@pearwood.info> - 2015-06-28 04:51 +1000
                            Re: Pure Python Data Mangling or Encrypting Chris Angelico <rosuav@gmail.com> - 2015-06-28 09:05 +1000
                    Re: Pure Python Data Mangling or Encrypting Chris Angelico <rosuav@gmail.com> - 2015-06-27 11:21 +1000
                    Re: Pure Python Data Mangling or Encrypting Ian Kelly <ian.g.kelly@gmail.com> - 2015-06-26 23:59 -0600
                      Re: Pure Python Data Mangling or Encrypting Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-06-27 09:26 +0000
                    Re: Pure Python Data Mangling or Encrypting Chris Angelico <rosuav@gmail.com> - 2015-06-27 16:52 +1000
                    Re: Pure Python Data Mangling or Encrypting Randall Smith <randall@tnr.cc> - 2015-06-27 12:08 -0500
                      Re: Pure Python Data Mangling or Encrypting Steven D'Aprano <steve@pearwood.info> - 2015-06-28 04:50 +1000
                        Re: Pure Python Data Mangling or Encrypting Randall Smith <randall@tnr.cc> - 2015-06-29 15:52 -0500
                          Re: Pure Python Data Mangling or Encrypting Steven D'Aprano <steve@pearwood.info> - 2015-06-30 13:00 +1000
                            Re: Pure Python Data Mangling or Encrypting Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-06-30 12:19 +0000
                              Re: Pure Python Data Mangling or Encrypting Steven D'Aprano <steve@pearwood.info> - 2015-07-01 04:17 +1000
                                Re: Pure Python Data Mangling or Encrypting Chris Angelico <rosuav@gmail.com> - 2015-07-01 04:33 +1000
                                Re: Pure Python Data Mangling or Encrypting Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-06-30 18:37 +0000
                                Re: Pure Python Data Mangling or Encrypting Randall Smith <randall@tnr.cc> - 2015-07-01 09:38 -0500
                            Re: Pure Python Data Mangling or Encrypting Randall Smith <randall@tnr.cc> - 2015-06-30 12:39 -0500
                              Re: Pure Python Data Mangling or Encrypting Steven D'Aprano <steve@pearwood.info> - 2015-07-01 04:59 +1000
                                Re: Pure Python Data Mangling or Encrypting Chris Angelico <rosuav@gmail.com> - 2015-07-01 05:20 +1000
                                Re: Pure Python Data Mangling or Encrypting Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-06-30 23:25 +0000
                                  Re: Pure Python Data Mangling or Encrypting alister <alister.nospam.ware@ntlworld.com> - 2015-07-01 08:06 +0000
                      Re: Pure Python Data Mangling or Encrypting Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-06-28 14:21 +0000
                        Re: Pure Python Data Mangling or Encrypting Randall Smith <randall@tnr.cc> - 2015-06-29 15:46 -0500
                          Re: Pure Python Data Mangling or Encrypting Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-06-29 20:49 +0000
                            Re: Pure Python Data Mangling or Encrypting Randall Smith <randall@tnr.cc> - 2015-06-30 12:43 -0500
                      Re: Pure Python Data Mangling or Encrypting Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-07-02 10:31 +1200
                Re: Pure Python Data Mangling or Encrypting Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-06-26 02:17 +0100
                Re: Pure Python Data Mangling or Encrypting Chris Angelico <rosuav@gmail.com> - 2015-06-26 12:06 +1000
                Re: Pure Python Data Mangling or Encrypting Chris Angelico <rosuav@gmail.com> - 2015-06-26 12:05 +1000
                Re: Pure Python Data Mangling or Encrypting Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-06-26 03:24 +0100
                Re: Pure Python Data Mangling or Encrypting Chris Angelico <rosuav@gmail.com> - 2015-06-26 12:29 +1000
          Re: Pure Python Data Mangling or Encrypting Joonas Liik <liik.joonas@gmail.com> - 2015-06-25 13:00 +0300
          Re: Pure Python Data Mangling or Encrypting Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-06-25 03:18 -0700
      Re: Pure Python Data Mangling or Encrypting Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-06-25 17:05 +1000
      Re: Pure Python Data Mangling or Encrypting Randall Smith <randall@tnr.cc> - 2015-06-25 14:09 -0500

Page 5 of 5 — ← Prev page 1 2 3 4 [5]

#93349

On Wed, Jul 1, 2015 at 4:59 AM, Steven D'Aprano <steve@pearwood.info> wrote:
> Today, if the key is compromised, all is lost. Is it possible that there are
> ciphers that are resistant to discovery of the key? Obviously if you know
> the key you can read encrypted messages, that's what the key is for, but
> there are scenarios where you would want security to degrade gracefully
> instead of in a brittle all-or-nothing manner:
>
> - even if the attacker can read my messages, he cannot tamper with
>   them or write new ones as me.
>
> (I'm pretty sure that, for example, the military would consider it horrible
> if the enemy could listen in on their communications, but *even worse* if
> the enemy could send false orders that appear to be legitimate.)

That would be accomplished by a two-fold enveloping of signing and
encrypting. If I sign something using my private key, then encrypt it
using your public key, someone who's compromised your private key
could snoop and read the message, but couldn't forge a message from
me. Of course, that just means there are lots more secrets to worry
about getting compromised.

ChrisA

[toc] | [prev] | [next] | [standalone]

#93354

On 2015-06-30, Steven D'Aprano <steve@pearwood.info> wrote:
> I don't think there has been much research into keeping at least *some*
> security even when keys have been compromised, apart from as it relates to
> two-factor authentication.

That's because "the key" is all the secret part. If an attacker knows
the algorithm, and the key, and the ciphertext, then *by definition*
all is lost. If you mean keeping the algorithm secret too then that's
just considered bad crypto.

> In the past, and still today among people who don't understand Kerckhoffs'
> principle, people have tried to keep the cipher secret and not have a key
> at all. E.g. atbash, or caesar cipher, which once upon a time were cutting
> edge ciphers, as laughably insecure as they are today. If the method was
> compromised, all was lost. 

Caesar cipher has a key. It's just very small, so is easy to guess.

> Today, if the key is compromised, all is lost. Is it possible that there are
> ciphers that are resistant to discovery of the key? Obviously if you know
> the key you can read encrypted messages, that's what the key is for, but
> there are scenarios where you would want security to degrade gracefully
> instead of in a brittle all-or-nothing manner:
>
> - even if the attacker can read my messages, he cannot tamper with 
>   them or write new ones as me.

I suppose that could be achieved by having separate encryption and
signing keys, but you could do the same but better by encrypting
with multiple algorithms. It's not an unstudied area:
https://en.wikipedia.org/wiki/Multiple_encryption

[toc] | [prev] | [next] | [standalone]

#93360

On Tue, 30 Jun 2015 23:25:01 +0000, Jon Ribbens wrote:

> On 2015-06-30, Steven D'Aprano <steve@pearwood.info> wrote:
>> I don't think there has been much research into keeping at least *some*
>> security even when keys have been compromised, apart from as it relates
>> to two-factor authentication.
> 
> That's because "the key" is all the secret part. If an attacker knows
> the algorithm, and the key, and the ciphertext, then *by definition* all
> is lost. If you mean keeping the algorithm secret too then that's just
> considered bad crypto.
> 
>> In the past, and still today among people who don't understand
>> Kerckhoffs' principle, people have tried to keep the cipher secret and
>> not have a key at all. E.g. atbash, or caesar cipher, which once upon a
>> time were cutting edge ciphers, as laughably insecure as they are
>> today. If the method was compromised, all was lost.
> 
> Caesar cipher has a key. It's just very small, so is easy to guess.
> 
>> Today, if the key is compromised, all is lost. Is it possible that
>> there are ciphers that are resistant to discovery of the key? Obviously
>> if you know the key you can read encrypted messages, that's what the
>> key is for, but there are scenarios where you would want security to
>> degrade gracefully instead of in a brittle all-or-nothing manner:
>>
>> - even if the attacker can read my messages, he cannot tamper with
>>   them or write new ones as me.
> 
> I suppose that could be achieved by having separate encryption and
> signing keys, but you could do the same but better by encrypting with
> multiple algorithms. It's not an unstudied area:
> https://en.wikipedia.org/wiki/Multiple_encryption

"The kipper flies at Midnight"

(from almost every WWII spy movie ever)
even if this message is decoded it is meaningless unless the attacker 
also has the meanings of the Code phrases
(which would mean your agent had been captured anyway)



-- 
That's the funniest thing I've ever heard and I will _not_ condone it.
        -- DyerMaker, 17 March 2000 MegaPhone radio show

[toc] | [prev] | [next] | [standalone]

#93272

On 2015-06-27, Randall Smith <randall@tnr.cc> wrote:
> Thankyou.  Nice points. I do think given the risks (there are always 
> risks) discussed, a successful attack of this nature is not very likely. 
>   Worse case, something that looks like this would land on the disk.
>
> crc32 checksum + translation table + malware
>
> with a generated base64 name and no extension.

I'm not sure why you're bothering with the checksum, it doesn't seem
to me that it buys you anything. Personally I'd do something like
this (pseudocode):

  def obfuscate(data):
      encode_key = list(range(256))
      random.shuffle(encode_key)
      encode_key = bytes(encode_key)
      decode_key = bytes(encode_key.index(i) for i in range(256))
      return decode_key + data.translate(encode_key) + decode_key

  def deobfuscate(data):
      return data[256:-256].translate(data[:256])

The reason for appending the key as well as prepending it is that some
anti-virus or malware scanners may well look at the last part of the
file first, so putting something entirely locally-generated there may
add a bit of safety. You could also simply pad with nulls or something
of course, but again I can imagine some tools skipping backwards past
nulls.

[toc] | [prev] | [next] | [standalone]

#93293

On 06/28/2015 09:21 AM, Jon Ribbens wrote:
> On 2015-06-27, Randall Smith <randall@tnr.cc> wrote:
>> Thankyou.  Nice points. I do think given the risks (there are always
>> risks) discussed, a successful attack of this nature is not very likely.
>>    Worse case, something that looks like this would land on the disk.
>>
>> crc32 checksum + translation table + malware
>>
>> with a generated base64 name and no extension.
>
> I'm not sure why you're bothering with the checksum, it doesn't seem
> to me that it buys you anything. Personally I'd do something like
> this (pseudocode):


Same reason newer filesystems like BTRFS use checkusms (BTRFS uses 
CRC32).  The storage machine runs periodic file integrity checks.  It 
has no control over the underlying filesystem.


>
>    def obfuscate(data):
>        encode_key = list(range(256))
>        random.shuffle(encode_key)
>        encode_key = bytes(encode_key)
>        decode_key = bytes(encode_key.index(i) for i in range(256))
>        return decode_key + data.translate(encode_key) + decode_key
>
>    def deobfuscate(data):
>        return data[256:-256].translate(data[:256])
>
> The reason for appending the key as well as prepending it is that some
> anti-virus or malware scanners may well look at the last part of the
> file first, so putting something entirely locally-generated there may
> add a bit of safety. You could also simply pad with nulls or something
> of course, but again I can imagine some tools skipping backwards past
> nulls.
>

[toc] | [prev] | [next] | [standalone]

#93294

On 2015-06-29, Randall Smith <randall@tnr.cc> wrote:
> Same reason newer filesystems like BTRFS use checkusms (BTRFS uses 
> CRC32).  The storage machine runs periodic file integrity checks.  It 
> has no control over the underlying filesystem.

True, but presumably neither does it have anything it can do to
rectify the situation if it finds a problem, and the client will
have to keep its own secure hash of its file anyway. (Unless I suppose
the server actually can request a new copy from the client or another
server if it finds a corrupt file?)

[toc] | [prev] | [next] | [standalone]

#93344

On 06/29/2015 03:49 PM, Jon Ribbens wrote:
> On 2015-06-29, Randall Smith <randall@tnr.cc> wrote:
>> Same reason newer filesystems like BTRFS use checkusms (BTRFS uses
>> CRC32).  The storage machine runs periodic file integrity checks.  It
>> has no control over the underlying filesystem.
>
> True, but presumably neither does it have anything it can do to
> rectify the situation if it finds a problem, and the client will
> have to keep its own secure hash of its file anyway. (Unless I suppose
> the server actually can request a new copy from the client or another
> server if it finds a corrupt file?)
>

Yes.  The storage servers are monitored for integrity.  They can request 
a new copy, though frequent corruption results in the server being 
marked as unreliable.

-Randall

[toc] | [prev] | [next] | [standalone]

#93392

Randall Smith wrote:

>  Worse case, something that looks like this would land on the disk.
> 
> crc32 checksum + translation table + malware

It would be safer to add something to both the
beginning *and* end of the file. Some file formats,
e.g. zip, pdf, are designed to be read starting
from the end.

So I would suggest something like

   crc32 checksum + payload + translation table

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#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

[toc] | [prev] | [next] | [standalone]

#93179

On Fri, Jun 26, 2015 at 11:17 AM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
>> 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.

I was massively oversimplifying, here. But there's a reason that
modern crypto doesn't use str.translate() level ciphers.

ChrisA

[toc] | [prev] | [next] | [standalone]

#93180

On Fri, Jun 26, 2015 at 11:01 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Thu, Jun 25, 2015 at 6:33 PM, Chris Angelico <rosuav@gmail.com> wrote:
>> On Fri, Jun 26, 2015 at 1:26 AM, Jon Ribbens
>> <jon+usenet@unequivocal.co.uk> wrote:
>>> 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? <chomp analysis>
>
> You're making the same mistake that Steven did in misunderstanding the
> threat model.

To be honest, I wasn't actually answering anything about the original
threat model, but only responding to the statement that a 256-byte
"anything-to-anything" cipher is somehow incredibly secure. It isn't,
but that might not be a problem for the original purpose.

ChrisA

[toc] | [prev] | [next] | [standalone]

#93181

On 26/06/2015 03:06, Chris Angelico wrote:
> On Fri, Jun 26, 2015 at 11:17 AM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
>>> 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.
>
> I was massively oversimplifying, here. But there's a reason that
> modern crypto doesn't use str.translate() level ciphers.
>
> ChrisA
>

I should know.  Ever heard of DISCON?  Like to hazard a guess as to who 
worked on it all those years ago?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#93182

On Fri, Jun 26, 2015 at 12:24 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> On 26/06/2015 03:06, Chris Angelico wrote:
>>
>> On Fri, Jun 26, 2015 at 11:17 AM, Mark Lawrence <breamoreboy@yahoo.co.uk>
>> wrote:
>>>>
>>>> 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.
>>
>>
>> I was massively oversimplifying, here. But there's a reason that
>> modern crypto doesn't use str.translate() level ciphers.
>>
>> ChrisA
>>
>
> I should know.  Ever heard of DISCON?  Like to hazard a guess as to who
> worked on it all those years ago?

No, not familiar with it. But I'm guessing you have the crypto
background to know all this stuff, which means you aren't the sort of
person I need to explain things to. Great! :)

ChrisA

[toc] | [prev] | [next] | [standalone]

#93130

Personally, i have had AVG give at least 2 false positives (fyi one of
them was like python2.6)

as long as antivirus software can give so many false positives i would
thing preventing your AV from nuking someone elses data is a
reasonable thing.

[toc] | [prev] | [next] | [standalone]

#93131

On Thu, Jun 25, 2015 at 2:57 AM, Chris Angelico <rosuav@gmail.com> wrote:
> On Thu, Jun 25, 2015 at 7:41 PM, Devin Jeanpierre
> <jeanpierreda@gmail.com> wrote:
>>> I know that the OP doesn't propose using ROT-13, but a classical
>>> substitution cipher isn't that much stronger.
>>
>> Yes, it is. It requires the attacker being able to see something about
>> the ciphertext, unlike ROT13. But it is reasonable to suppose that
>> maybe the attacker can trigger the file getting executed, at which
>> point maybe you can deduce from the behavior what the starting bytes
>> are...?
>>
>
> If a symmetric cipher is being used and the key is known, anyone can
> simply perform a decryption operation on the desired bytes, get back a
> pile of meaningless encrypted junk, and submit that. When it's
> encrypted with the same key, voila! The cleartext will reappear.
>
> Asymmetric ciphers are a bit different, though. AIUI you can't perform
> a decryption without the private key, whereas you can encrypt with
> only the public key. So you ought to be safe on that one; the only way
> someone could deliberately craft input that, when encrypted with your
> public key, produces a specific set of bytes, would be to brute-force
> it. (But I might be wrong on that. I'm no crypto expert.)

Yes, so it should be random.

-- Devin

[toc] | [prev] | [next] | [standalone]

#93117

On Thursday 25 June 2015 14:07, Steven D'Aprano wrote:

>> You got it.  I didn't want to explain any more than necessary.  But yes,
>> the recipient just stores the data for the end-user.
> 
> Trust me. That's not all they are doing.

Hmm, sorry, that's a glib answer.

What I meant to say is, you can't *trust* that this is all they are doing, 
not unless all your users are within a single organisation where everyone 
trusts everyone else.

Obviously some people are more trustworthy, or less inquisitive, than 
others. But you don't know which ones are which.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#93161

On 06/24/2015 11:27 PM, Devin Jeanpierre wrote:
> On Wed, Jun 24, 2015 at 9:07 PM, Steven D'Aprano <steve@pearwood.info> wrote:
>> But just sticking to the three above, the first one is partially mitigated
>> by allowing virus scanners to scan the data, but that implies that the
>> owner of the storage machine can spy on the files. So you have a conflict
>> here.
>
> If it's encrypted malware, and you can't decrypt it, there's no threat.
>
>> Honestly, the *only* real defence against the spying issue is to encrypt the
>> files. Not obfuscate them with a lousy random substitution cipher. The
>> storage machine can keep the files as long as they like, just by making a
>> copy, and spend hours bruteforcing them. They *will* crack the substitution
>> cipher. In pure Python, that may take a few days or weeks; in C, hours or
>> days. If they have the resources to throw at it, minutes. Substitution
>> ciphers have not been effective encryption since, oh, the 1950s, unless you
>> use a one-time pad. Which you won't be.
>
> The original post said that the sender will usually send files they
> encrypted, unless they are malicious. So if the sender wants them to
> be encrypted, they already are.
>
> "While the data senders are supposed to encrypt data, that's not
> guaranteed, and I'd like to protect the recipient against exposure to
> nefarious data by mangling or encrypting the data before it is written
> to disk."
>
> The cipher is just to keep the sender from being able to control what
> is on disk.
>
> I am usually very oppositional when it comes to rolling your own
> crypto, but am I alone here in thinking the OP very clearly laid out
> their case?
>
> -- Devin
>

Thanks Devin.  You understand the issue perfectly despite my limited 
description of the system.  I've fully implemented and performance 
tested your suggested solution and am quite happy with it.

Though the issue is solved, I would be glad to listen to any remaining 
criticisms, suggestions or questions.

--Randall

[toc] | [prev] | [standalone]

Page 5 of 5 — ← Prev page 1 2 3 4 [5]

Back to top | Article view | comp.lang.python

csiph-web