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.
--
https://mail.python.org/mailman/listinfo/python-list
