[CryptoAPI] Question regarding ComputeHash function for SHA-256 hash

Forge Component
Published on 3 Mar by Ricardo Silva
23 votes
Published on 3 Mar by Ricardo Silva
I am using the ComputeHash function as part of the CryptoAPI component and having a slight issue.

I am calling this function two times as part of an authentication logic. The issue I am running into is when the "Data" parameter being passed to the function contains new lines. Part of the requirement per the web service I am authenticating with (Amazon AWS) is that the "canonical request" contain information separated by new lines. (Not the new line character "\n" but lines created by the return key)

The output of the function does not match what I get when I use an online SHA-256 hash generator like this:

The sample data I am using for my test is the following:


That text, when passed to ComputeHash with the "Algorithm" parameter left blank (for SHA-256) does not match the online generators.

Am I doing anything wrong here?

I've also tried passing the text with the new lines escaped as "\n" and this also does not match.


Hi Brian,

Sorry I haven't been able to look into this.

I suspect that the issue is that when you create new-lines in your .net code you're getting a \r\n instead of \n and that's what's causing the hashes to be different.

I'll prolly look further into this later, but for this use-case I really suggest that you do all the low level operations in an extension action.

Hi Ricardo,

I created a copy of your extension for that one method (ComputeHash) and did exactly what you are saying...

The output is now as expected!

All I added to the .NET code was the following:

ssData = ssData.Replace("\r\n", "\n");

Following the rest of the function exactly the same, my outputted SHA256 hash now matches what I expect.

Do you think this can be added to the function? (If it makes sense for all use cases) Or parameter based?

Thanks very much for the help!

I don't think this transformation makes sense to be added to the Compute Hash function.

Normalization of the input is something that should be done before passing it to the hash computation.

I agree with that. Only thing I'm not sure of is if the normalization on the Outsystems end, I have not tested that out yet but I will give it a go and let you know if I have any issues. Otherwise I would need a simple extension to handle that for me, before passing off to the CryptoAPI.

Thanks Ricardo!

Ricardo, thanks in advance for any pointers.

I am having a similar mismatch on hashes: 

Outsystems HASH = HEX: D4AB222EBA33E27C5F6C4AA8D1CA0CEBCBD0AEE6D8C405CA8A153A72D6CC0792

3rd party HASH = 

HEX: 98EC3A03729E8B945E72949A09F61A91185A6E151F130C9877E719C689A9EAB1

My Logic below, input is coming from File upload widget:

Hello Allen,

Unfortunately I don't think I have any magic solution for you. My implementation of ComputeHash takes a string, converts it to bytes using UTF-8 encoding, and returns the hash of those bytes.

What's likely happening here is that the "convert-to-bytes" part on the 3rd party is different.

Another thing that could be happening is that the BinaryToText is not using the right encoding and is mucking up the text.

A third option is also that your 3rd party is not using sha256.

In order to properly help you with this, is it possible for you to share any documentation you have on how the 3rd party is doing the hashing?

Best regards,

Ricardo Silva

I think I found the way around this issue with the newline:  use  

SyntaxEditor Code Snippet


functiion instead of newline()