spaniakos
commented
8 years ago I will check the results when i have success to my computer. On Dec 14, 2015 4:52 PM, "Bud Nail" notifications@github.com wrote:
HMAC SHA256 example, Test:RFC4231 4.6.
Expected:"a3b6167473100ee06e0c796c2955552b-------------------------------" according to the example code in Cryptosuite and RFC4231 4.6. A truncated result.
Actual Result:"3b6167473100ee06e0c796c2955552bfa6f7c0a6a8aef8b93f860aab0cd20c5", not truncated.
The actual result appears to behave more like PRF-HMAC-SHA-256 of RFC 4868, which is better for my purposes. I tried a couple of random online HMAC-SHA-256 implementations, and they also seem to match my actual result. So maybe most implementations are using the same algorithm and/or there is some understanding that this is an acceptable implementation. If that is the case, it is fine by me.
A couple of ideas: (1) simply note that although RFC4231 calls for truncation, this implementation fails in that aspect and follows PRF-HMAC-SHA-256 of RFC 4868 instead. (2) Add code to truncate the result.
Note: I have only tested this using my slightly modified version for the Photon, but I didn't alter anything that should have affected the results of this test. It would be nice if someone could confirm they get the same result.
— Reply to this email directly or view it on GitHub https://github.com/spaniakos/Cryptosuite/issues/5.
axelbusch
HMAC SHA256 example, Test:RFC4231 4.6.
Expected:"a3b6167473100ee06e0c796c2955552b-------------------------------" according to the example code in Cryptosuite and RFC4231 4.6. A truncated result.
Actual Result:"a3b6167473100ee06e0c796c2955552bfa6f7c0a6a8aef8b93f860aab0cd20c5", not truncated.(corrected a copy and paste error where I cut off the leading "a". 12-29-2015)
The actual result appears to behave more like PRF-HMAC-SHA-256 of RFC 4868, which is better for my purposes. I tried a couple of random online HMAC-SHA-256 implementations, and they also seem to match my actual result. So maybe most implementations are using the same algorithm and/or there is some understanding that this is an acceptable implementation. If that is the case, it is fine by me.
A couple of ideas: (1) simply note that although RFC4231 calls for truncation, this implementation fails in that aspect and follows PRF-HMAC-SHA-256 of RFC 4868 instead. (2) Add code to truncate the result.
Note: I have only tested this using my slightly modified version for the Photon, but I didn't alter anything that should have affected the results of this test. It would be nice if someone could confirm they get the same result.