Pure Python Data Mangling or Encrypting

[Jon Ribbens]

On 2015-06-26, Johannes Bauer <dfnsonfsduifb at gmx.de> wrote:
> On 26.06.2015 22:09, Randall Smith wrote:
>> You've gone on a rampage about nothing.  My original description said
>> the client was supposed to encrypt the data, but you want to assume the
>> opposite for some unknown reason.
>
> While you seem to think that Steven is rampaging about nothing, he does
> have a fair point: You consistently were vague about wheter you want to
> have encryption, authentication or obfuscation of data. This suggests
> that you may not be so sure yourself what it is you actually want.

He hasn't been vague, you and Steven just haven't been paying
attention.

> You always play around with the 256! which would be a ridiculously high
> security margin (1684 bits of security, woooo!). You totally ignore that
> the system can be broken in a linear fashion.

No, it can't, because the attacker does not have access to the
ciphertext.

> Nobody assumes you're a moron. But it's safe to assume that you're a
> crypto layman, because only laymen have no clue on how difficult it is
> to get cryptography even remotely right.

Amateur crypto is indeed a bad idea. But what you're still not getting
is that what he's doing here *isn't crypto*. He's just trying to avoid
letting third parties write completely arbitrary data to the disk. You
know what would be a perfectly good solution to his problem? Base 64
encoding. That would solve the issue pretty much completely, the only
reason it's not an ideal solution is that it of course increases the
size of the data.

> That people in 2015 actually defend inventing a substitution-cipher
> "crypto"system sends literally shivers down my spine.

Nobody is defending such a thing, you just haven't understood what
problem is being solved here.