On 2015-06-26, Johannes Bauer <dfnsonfsdu...@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. -- https://mail.python.org/mailman/listinfo/python-list
