SHA512 produces a 512-bit result, which is 128 hex digits (each digit represents 4 bits) so a 128-character string. I think the Python result would also be a 128-character string here.
I don’t really know what the Python output would be, but the fact is that the POST is not accepted because of an error in this header, which could only be a result of my attempt to duplicate hexdigest().
Interesting to note, in order for the hexdigest string to fit in ascii, the hexdigest method produces a string twice the size of the hash in bytes, so in this case the hexdigest string is 32 bytes wide, not 16, the actual size of the hash in bytes. Each character is represented as an individual byte in ascii, just like any normal python string.
To compare:
len(hashlib.md5(‘test’).digest())
16
len(hashlib.md5(‘test’).hexdigest())
32
In summary hexdigest simply produces an ascii safe way to view the bytes produced from the hash algorithm.
As I understand, I should be ending up with a 256 char string?
The binary result of SHA-512, the digest(), is 512 bits or 64 bytes. The hexdigest() is twice that size, or 128 bytes.
Unfortunately, if it’s not working, you must either be hashing the wrong information or using the wrong secret. Even more unfortunately, the service won’t be all that helpful in telling you exactly what the problem was, as that could lead to security holes.
You’ve almost got it - but the loop in your BlobToHex function will occasionally return strings longer than 2 characters (padded with FF at the start)… here’s some code that should work for you:
`function BlobToHexString(data) {
local str = “”;
foreach (b in data) {
local c = format("%02x", b);
str += c.slice(c.len()-2);
}
return str;
}
function test() {
local secret = “secret”;
local data = “data”;
local hash = http.hash.hmacsha512(data, secret);
// from the python script..
local expected = "6274071d33dec2728a2a1c903697fc1210b3252221c3d137e12d9f1ae5c8ed53e05e692b05a9eefff289667e2387c0fc0bd8a3d9bd7000782730c856a77a77d5";
local actual = BlobToHexString(hash.tostring());
server.log(expected.tolower());
server.log(actual.tolower());
if (expected == actual) {
server.log("Test Passed");
} else {
server.log("Test Failed");
}
the loop in your BlobToHex function will occasionally return strings longer than 2 characters (padded with FF at the start)
If you can catch it doing that, it’s a bug and we’ll fix it… characters in Squirrel blobs and strings are meant to be unsigned (at least in Imp Squirrel – in upstream Squirrel they are signed on some platforms).
I ended up with the following alternative for hexdigest() based on your input:
function BlobToHexString(data) { local str = ""; foreach (b in data) { local c = format("%02x", b); str += c.slice(c.len()-2); } return str.tolower().tostring(); }
Sadly, I’m still not getting an OK from the service
I’ll continue debugging and let you know once I get to the bottom of it.
Finally got the request to go through - turns out that we were sending the correct data with the function above! Thanks for all of your help!
I did, however, hit kind of a strange issue, which I had to work around - I’m able to successfully decode the JSON the service is passing back, but they’re passing a nested table with a key called “return”.
And, naturally, I get an error in the IDE when I try to address it as
data.return
I just copied the pointer into another variable and addressed it from there, but I was wondering whether there was a more elegant way of addressing a nested table called “return” in Squirrel without this workaround.
Thanks for the quick reply!