Pure Python Data Mangling or Encrypting

[Randall Smith]

On 06/26/2015 05:42 PM, Johannes Bauer wrote:
> On 26.06.2015 23:29, Jon Ribbens wrote:
>
>>> 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.
>
> Bullshit. Even the topic indicates that he doesn't know what he wants:
> "data mangling" or "encryption", which one is it?

I knew exactly what I wanted and spelled it out.

"protect the recipient against exposure to nefarious data ... before it 
is written to disk"

You shouldn't need to make assumptions about other parts of the system. 
  Just prevent potential malware from hitting the disk as such.

Before this thread, I knew that encryption would definitely work and 
data mangling might.  Now I know that data mangling is a really nice 
solution for the given requirements.


>
>>> 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.
>
> Or so you claim.

No the attacker does not have access to the ciphertext.  What would lead 
you to think they did?

This statement is central to the problem:

"I'd like to protect the recipient against exposure to nefarious data by 
mangling or encrypting the data before it is written to disk"

This makes it clear I'm not trying to encrypt data to protect the data. 
  I'm trying to protect the recipient (storage server) from an attack. 
This specific attack being malware.  Yes, AES encryption would have 
worked here, but encryption is not the objective.

>
> I could go into detail about how the assumtion that the ciphertext is
> secret is not a smart one in the context of cryptography. And how side
> channels and other leakage may affect overall system security. But I'm
> going to save my time on that. I do get paid to review cryptographic
> systems and part of the job is dealing with belligerent people who have
> read Schneier's blog and think they can outsmart anyone else. Since I
> don't get paid to convice you, it's absolutely fine that you think your
> substitution scheme is the grand prize.


All of which has nothing to do with this thread.  Actual encryption is 
handled using AES and TLS.  This is not about encryption.

>
>>> 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*.
>
> So the topic says "Encrypting". If you look really closely at the word,
> the part "crypt" might give away to you that cryptography is involved.
>


This isn't about encrypting data to protect the data.  All the 
encryption I do uses standard AES and TLS.  Yes, I do understand that 
crypto is best left to experts.  The topic says "Encrypting" because I 
knew that encrypting the data would properly obfuscate it.


>> He's just trying to avoid
>> letting third parties write completely arbitrary data to the disk.
>
> There's your requirement. Then there's obviously some kind of
> implication when a third party *can* write arbitrary data to disk. And
> your other solution to that problem...

It's a network protocol.  Just like when writing a web app, you have to 
deal with bad actors.  That's what I'm doing here.  The entire service 
is about handling arbitrary data.  Just like Amazon S3 handles people's 
"arbitrary data".  Not sure what you mean by "third party".  It would be 
a registered peer.  But registration doesn't prevent the scenario in 
discussion.