-1

newbie playing around with hashes here and not getting the result I am looking for. Trying to get a hash from a txt file from the web, then comparing that hash to a local hash.

For testing purposes I'm using SHA256.new(“10”).hexdigest() which is: 4a44dc15364204a80fe80e9039455cc1608281820fe2b24f1e5233ade6af1dd5

CODE:

import urllib2
from Crypto.Hash import SHA256

source = urllib2.urlopen("<xxURLxx>")
line1 = source.readline()  # get first line of the txt file in source which is the hash

localHash = SHA256.new("10").hexdigest()

if localHash == line1: #  I know, shouldnt use == to compare hashes but it is my first try.
   print("it works!")
else:
   print("it does not work...")

Printing the hashes I get from the web file and the local hash they return the same characters. But if I hash each hash one more time I get different results.

Any ideas?

Had a look around S.O. and found: Compare result from hexdigest() to a string but the issue there was the lack of .digest() which I have.

Thank you in advance for any help.

Community
  • 1
  • 1
user2808964
  • 1
  • 2
  • 2
  • I'm guessing `line1` has a newline at the end, but without the actual value of `line1`, it's impossible to say for sure. – Blender Sep 23 '13 at 22:42
  • 1
    What is "hash each hash one more time"? If you SHA256 a SHA256, you shouldn't expect it to return itself… If you mean something different… then what do you mean? If you show us the code, input, expected output, and actual output that demonstrates the problem, you don't need to describe the problem as rigorously. – abarnert Sep 23 '13 at 22:49
  • 2
    Also, who told you that you shouldn't use `==` to compare hashes? They're hexdigest strings; how else would you compare them? – abarnert Sep 23 '13 at 22:49
  • Turns out I was reading some _old_ python comments without realizing. Was a block of text about == not being secure... all a bit over my head at the moment. – user2808964 Sep 24 '13 at 18:57
  • @abarnert: timing attacks – Hubert Kario Feb 18 '15 at 15:22
  • @HubertKario: In this context? An attacker (say, someone who wants to substitute dangerous misinformation for your intended download) has no control over the code, couldn't run a timing attack even if he had, and would get no useful information even if he could. Knowing what's relevant to a relevant attack is the most important thing in evaluating any security system. – abarnert Feb 19 '15 at 16:37
  • @abarnert: Here I don't know, there's too little context. But unless you're positively sure it's not needed, it's *safer* to use a constant time compare than a regular compare. You won't introduce bugs by using constant time compare while you can introduce by using regular one. – Hubert Kario Feb 20 '15 at 13:24
  • @HubertKario: He's downloaded a text file from the web, and he wants to hash it and compare the result to a known hash. How much more context do you need? Making your code slower and more complex for no reason doesn't increase security. – abarnert Feb 22 '15 at 05:45

1 Answers1

0

If I had to guess, I'd say that changing 

line1 = source.readline()

to 

line1 = source.readline().strip()

will fix the problem. strip() removes leading and trailing whitespace, including the newline ('\n') character that will almost certainly be at the end of the first line read by readline.

You can see whether there are "invisible" characters like that by using repr, which renders them explicitly using escape characters:

>>> print repr('\t')
'\t'
senderle
  • 145,869
  • 36
  • 209
  • 233