Help porting HMAC-SHA256 code

About Monkey 2 Forums Monkey 2 Programming Help Help porting HMAC-SHA256 code

This topic contains 8 replies, has 3 voices, and was last updated by  Danilo 2 days, 3 hours ago.

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #15894

    jondecker76

    Participant

    I’m trying to port some fairly simple code to make my own HMAC-SHA256 function, but I’m not getting expected results (I’m sure it’s a string vs byte issue).  Here is information on the algorithm:

    https://datatracker.ietf.org/doc/html/rfc2104

    https://en.wikipedia.org/wiki/HMAC

     

    Here is where my tests are so far…

     

    Any pointers?

     

    Thanks

    #15898

    jondecker76

    Participant

    Still working on this.  I’m much happier with the state of the code, but it still isn’t returning expected results :/

     

    #15900

    jondecker76

    Participant

    Here is a full project to show the issue.  Everything looks right, but I can’t figure out why it’s not returning expected results

    #15903


    abakobo

    Participant

    I ported part of a library to get this done. Code is from https://create.stephan-brumme.com/hash-library/ . Please check for the license(MIT I think).

    I had to remove the call to endian.h because it’s a mess with OSX. This result in this port working on “Little Endian” OS/Hardware ONLY (which is all common now but I preffer to tell). (Networks seems to be “Big Endian” though!)
    Sorry not to review your code but for me it’s easyer to Import C++ code..

    I’m using a libc.char_t array to get my CString to avoid memory leaks.
    Hope it works well for you.

    Code in attached zip.

    PS: I’ve seen on StackOverflow that the most common problem with hashes is a confusion with chars and bytes.
    PS2: you could check the code in std.digest to see how the types are managed in there if you want to continue your mx2 education..

    Attachments:
    1. hmac256_64.zip
    #15923


    jondecker76

    Participant

    Thank you very much, this is very helpful.

    I’ll definitely still work on figuring out what is causing it to fail  in pure Mx2, but at least it won’t hold me up on my project!

    #15930


    jondecker76

    Participant

    Ouch, this keeps getting stranger.

    It’s easy to see the first obvious problem with this test..  MX2 text can’t represent characters $80-$FF?  Strange!  The strangest thing is that $FF isn’t even possible, and equates to $00?  Run the test below and look at the last entry.  Yes, I see that the first byte is $FF for >$80…  But that stops at $FFFE.  Where is $FFFF?   Is this expected behavior or a bug?

     

    #15931


    Danilo

    Participant

    0 To 255 requires a DataBuffer of 256 bytes.

    #15939

    Danilo

    Participant

    Strings in Monkey2 are 16-bit Unicode Strings.

     

    Please try the following code to catch ASCII strings from DataBuffer and convert it to Unicode-Monkey2-Strings.

    #15941


    Danilo

    Participant

    @jondecker76: Could it be that your expected results comes from routines that use SHA256() on ASCII strings? All std.digest functions in Monkey2 use 16-bit Unicode strings.

    The SHA(), MD5(), SHA256() with Unicode string buffers are probably much different from using the same functions with ASCII buffers.

Viewing 9 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic.