On Sun, 28 Jun 2015 01:09 am, Ian Kelly wrote:
> On Sat, Jun 27, 2015 at 2:38 AM, Steven D'Aprano <st...@pearwood.info>
> wrote:
>> Can you [generic you] believe that attackers can *reliably* attack remote
>> systems based on a 20µs timing differences? If you say "No", then you
>> fail Security 101 and should step away from the computer until a security
>> expert can be called in to review your code.
>
> Of course. I wouldn't bet the house on it, but with the proposed
> substitution cipher system, I don't see why there would be any
> measurable timing differences at all based on the choice of key.
I wouldn't bet one wooden nickle on it. Not without a security audit of the
application. And then what happens when the implementation changes and the
audit is no longer valid?
Despite his initial claim that he doesn't want to use AES because it's too
slow implemented as pure Python, Randall has said that the application will
offer AES encryption as an option. (He says it is enabled by default,
except that the user can turn it off.) So the code is already there, all he
has to do is call it.
It might not be a timing attack. Maybe there's a vulnerability in the
application that if you upload a sufficiently large file, a buffer will
overflow and you can force the key of your choosing. Who knows? Bugs
happen. The nature of how the hypothetical key leakage happens is less
important than the consequences if there is one.
Randall can:
(1) bet the security of his application and his users on the key never
leaking;
"Why have you situated a naked flame right next to the gas tank?"
"It's okay, I'm confident that the tank will never leak."
or
(2) use something which, *even if the key leaks*, is still resistant to
preimage attacks.
The choice ought to be a no-brainer. The fact that folks are seriously
considering using something barely one step up from a medieval substitution
cipher in 2015 for something with real security consequences if it is
broken goes to show what a lousy job the IT industry does for security.
> The time to obfuscate a single byte is constant,
Are you sure about that? Bet your house? How about your computer?
# Python 3.3 on Linux, YMMV
py> text = 'NOBODY expects the Spanish Inquisition!'*50000
py> import string
py> s = string.digits + string.ascii_letters
py> t = (string.ascii_uppercase + string.digits[::-1] +
... string.ascii_lowercase)
py> trans1 = str.maketrans('abcdef', 'fedcba')
py> trans2 = str.maketrans(s, t)
py> trans3 = str.maketrans('aZ', 'Za')
py> with Stopwatch():
... x = str.translate(text, trans1)
...
time taken: 0.427513 seconds
py> with Stopwatch():
... x = str.translate(text, trans2)
...
time taken: 0.228869 seconds
py> with Stopwatch():
... x = str.translate(text, trans3)
...
time taken: 0.387105 seconds
> so the total time to
> obfuscate the payload should just be a function of the length of the
> data.
Good thing you didn't bet your house.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
