On 12/22/2014 12:25 PM, Chris Angelico wrote:
There's one exception. Writing your own crypto is a bad idea if that
means reimplementing AES... but if you want something that's effective
on completely different levels, sometimes it's best to write your own.
I had a project a while ago that needed some encryption work done, and
I implemented something that I described as "scarily effective". My
boss demanded that the debug code-execution feature be protected by a
password that would be strong even if someone could read the source
code, so I put together something that would hash the incoming
password, then check to see if the first two and last two bytes of the
hash were all the same byte value as the current hour-of-week (ranging
from 0 to 167). This is clearly more secure than simply embedding a
SHA256 hash in the source code, because you can't possibly
reverse-engineer it (since you don't even have the full hash). And
yes, this was 100% effective in convincing my boss that the code
executor was safely guarded. Since that was the goal, having several
lines of complex and opaque code was far better than a single line
that says "if
hash(password)=='5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8':
do stuff", which is way too easy for someone to decode.
And it was, indeed, scarily effective. That lasted for a long time,
and any time there was a question about security, I could just point
to that and say "See? Safe."...
I figure I must be misunderstanding something in your explanation, since
a brute-force password guesser would seem to only need four billion
tries to (probably) crack that.
1) Are you assuming that the cracker can read the source code, but
cannot modify the version of the code that is running?
2) Are you really doing something equivalent to:
test = time_calc() - get a one-byte byte-string according to hour of the
week
encoded_pw = hash(password)
if encoded_pw.startswith(test*2) and encoded_pw.endswith(test*2):
---passed---
I can understand that being sufficiently obscure for the pointy haired
boss, but I figure I've got to be missing something. A quick test with
3.2 shows that around a million hashes can be generated per second, so
checking four billion is only an hour or so. Since some of them will
collide, that gives us something better than 50% likelihood of having
found a useful pw in an hour. But a few more hours and we'll most
likely have it.
For that matter, you must have already written such a pw finder.
I'm back to figuring I'm misunderstanding what you're saying.
--
DaveA
--
https://mail.python.org/mailman/listinfo/python-list
