Attempting to implement Keyed MD-5 Hash
-
Code project C# guru’s :confused:, I am attempting to implement RFC 2095 ( http://www.ietf.org/rfc/rfc2095.txt ) I’ve found what I believe is an error in the crypto library for C#. Now be kind I’ve been coding C# for exactly 1 week :omg:, and it has been about 7 years since I coded in production :eek:. The last time I coded was in VI on Unix. This is just one of the methods I’m attempting to implement in this project. The rest of the project includes an SMTP server, and verification schema. I’m implementing the procedures in a C# program found in RFC 2095, and using the CRAM algorithm found in http://www.ietf.org/rfc/rfc2104.txt . The test data strings found in RFC 2095 include a share key string “tanstaaftanstaaf” and the challenge “1896.697170952@postoffice.reston.mci.net” these test values should produce according to the test in the RFC the hashed hex output “b9 13 a6 02 c7 ed a7 a4 95 b4 e6 e7 33 4d 38 90” . In the following program from the MSDN code library (ms-help://MS.VSCC.2003/MS.MSDNQTR.2003FEB.1033/cpguide/html/cpconextendingkeyedhashalgorithmclass.htm) I get the following output from the output string B9 13 A6 2 C7 ED A7 A4 95 B4 E6 E7 33 4D 38 90 on the test case. And, of course the fourth hex pair has dropped the leading zero :doh:. That would be wrong according to the Keyed MD-5 hash algorithm :mad:. The leading zero should be left in place. From my feeble attempts at debugging it looks like it is either the output of the HEX according to Microsoft or internal to the crypto library. Either way how do I make sure that it does not drop that leading zero X| ? Thanks in advance, Sam From the MSDN Code Library with RFC 2095 Edits //////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// using System; using System.Security.Cryptography; public class TestHMACMD5 { static private void PrintByteArray(Byte[] arr) { int i; Console.WriteLine("Length: " + arr.Length); for (i=0; i
-
Code project C# guru’s :confused:, I am attempting to implement RFC 2095 ( http://www.ietf.org/rfc/rfc2095.txt ) I’ve found what I believe is an error in the crypto library for C#. Now be kind I’ve been coding C# for exactly 1 week :omg:, and it has been about 7 years since I coded in production :eek:. The last time I coded was in VI on Unix. This is just one of the methods I’m attempting to implement in this project. The rest of the project includes an SMTP server, and verification schema. I’m implementing the procedures in a C# program found in RFC 2095, and using the CRAM algorithm found in http://www.ietf.org/rfc/rfc2104.txt . The test data strings found in RFC 2095 include a share key string “tanstaaftanstaaf” and the challenge “1896.697170952@postoffice.reston.mci.net” these test values should produce according to the test in the RFC the hashed hex output “b9 13 a6 02 c7 ed a7 a4 95 b4 e6 e7 33 4d 38 90” . In the following program from the MSDN code library (ms-help://MS.VSCC.2003/MS.MSDNQTR.2003FEB.1033/cpguide/html/cpconextendingkeyedhashalgorithmclass.htm) I get the following output from the output string B9 13 A6 2 C7 ED A7 A4 95 B4 E6 E7 33 4D 38 90 on the test case. And, of course the fourth hex pair has dropped the leading zero :doh:. That would be wrong according to the Keyed MD-5 hash algorithm :mad:. The leading zero should be left in place. From my feeble attempts at debugging it looks like it is either the output of the HEX according to Microsoft or internal to the crypto library. Either way how do I make sure that it does not drop that leading zero X| ? Thanks in advance, Sam From the MSDN Code Library with RFC 2095 Edits //////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// using System; using System.Security.Cryptography; public class TestHMACMD5 { static private void PrintByteArray(Byte[] arr) { int i; Console.WriteLine("Length: " + arr.Length); for (i=0; i
The bug is in your code. If MD5 didn't work once, it wouldn't work for any plain text. Use
Console.Write("{0:X2}", arr[i])instead of just using "{0:X}" for the format specifier. This makes sure that 2 chars are used per bit. Also, it's faster to usearr[i].ToString("X2")in this case, and this is typically true when you need to format only one value. Why? Because usingConsole.Write(or any of the formatting methods) instantiates aStringBuilderand does some having parsing to eventually callByte.ToString(string, IFormatProvider), which you could just do directly here (though you don't need to pass anIFormatProviderin this case). It's best you don't claim bugs, especially when you've only been programming C# for 1 week. Check out the documentation, search the 'net for similar findings, and ask someone to verify (like on this forum), then declare you've found a bug and report it to the proper channels.Microsoft MVP, Visual C# My Articles
-
Code project C# guru’s :confused:, I am attempting to implement RFC 2095 ( http://www.ietf.org/rfc/rfc2095.txt ) I’ve found what I believe is an error in the crypto library for C#. Now be kind I’ve been coding C# for exactly 1 week :omg:, and it has been about 7 years since I coded in production :eek:. The last time I coded was in VI on Unix. This is just one of the methods I’m attempting to implement in this project. The rest of the project includes an SMTP server, and verification schema. I’m implementing the procedures in a C# program found in RFC 2095, and using the CRAM algorithm found in http://www.ietf.org/rfc/rfc2104.txt . The test data strings found in RFC 2095 include a share key string “tanstaaftanstaaf” and the challenge “1896.697170952@postoffice.reston.mci.net” these test values should produce according to the test in the RFC the hashed hex output “b9 13 a6 02 c7 ed a7 a4 95 b4 e6 e7 33 4d 38 90” . In the following program from the MSDN code library (ms-help://MS.VSCC.2003/MS.MSDNQTR.2003FEB.1033/cpguide/html/cpconextendingkeyedhashalgorithmclass.htm) I get the following output from the output string B9 13 A6 2 C7 ED A7 A4 95 B4 E6 E7 33 4D 38 90 on the test case. And, of course the fourth hex pair has dropped the leading zero :doh:. That would be wrong according to the Keyed MD-5 hash algorithm :mad:. The leading zero should be left in place. From my feeble attempts at debugging it looks like it is either the output of the HEX according to Microsoft or internal to the crypto library. Either way how do I make sure that it does not drop that leading zero X| ? Thanks in advance, Sam From the MSDN Code Library with RFC 2095 Edits //////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// using System; using System.Security.Cryptography; public class TestHMACMD5 { static private void PrintByteArray(Byte[] arr) { int i; Console.WriteLine("Length: " + arr.Length); for (i=0; i
selil wrote: static private void PrintByteArray(Byte[] arr) { int i; Console.WriteLine("Length: " + arr.Length); for (i=0; i { Console.Write("{0:X}", arr[i]); Console.Write(" "); if ( (i+9)%8 == 0 ) Console.WriteLine(); } if (i%8 != 0) Console.WriteLine(); } This is happening because the format specifier in {0:X} is dropping the leading zero. The value is represented with the leading zero (obviously, since the value is 2), but the leading zero is just not printed. RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
-
The bug is in your code. If MD5 didn't work once, it wouldn't work for any plain text. Use
Console.Write("{0:X2}", arr[i])instead of just using "{0:X}" for the format specifier. This makes sure that 2 chars are used per bit. Also, it's faster to usearr[i].ToString("X2")in this case, and this is typically true when you need to format only one value. Why? Because usingConsole.Write(or any of the formatting methods) instantiates aStringBuilderand does some having parsing to eventually callByte.ToString(string, IFormatProvider), which you could just do directly here (though you don't need to pass anIFormatProviderin this case). It's best you don't claim bugs, especially when you've only been programming C# for 1 week. Check out the documentation, search the 'net for similar findings, and ask someone to verify (like on this forum), then declare you've found a bug and report it to the proper channels.Microsoft MVP, Visual C# My Articles
Heath Stewart wrote: It's best you don't claim bugs, especially when you've only been programming C# for 1 week. Check out the documentation, search the 'net for similar findings, and ask someone to verify (like on this forum), then declare you've found a bug and report it to the proper ch First. Thank you very much. Second. I was using the example code from Microsoft on their implemenatation of the correct code (which is still obviously wrong according to the RFC). I did check the net for this very topic (very thin and obscure task). I did ask somebody to verify but they were looking at the entire code and easily missed the problem. Third. It was an obvious small error on my part that I should have caught. I just never figured that Microsoft would provide a sample of an RFC that wasn't compliant. That is exactly why I thought to ask the kind folks here at Code Project for help. Fourth I wasn't claiming a bug and was looking for the exact validation you provided in that the Microsoft code as supplied was wrong and not something deeper. They should change that one item to make it RFC compliant. Fifth. Thanks again. Sorry if you thought I was calling your baby ugly. Haven't you ever beat your head on the keyboard looking at the obvious to somebody else while completely missing the EASY! answer? Again thank you very much for the help.... Now to finish the project. And, I think C# is pretty darn nifty......Thanks again, and again.... Really... -------------------- Sam
-
selil wrote: static private void PrintByteArray(Byte[] arr) { int i; Console.WriteLine("Length: " + arr.Length); for (i=0; i { Console.Write("{0:X}", arr[i]); Console.Write(" "); if ( (i+9)%8 == 0 ) Console.WriteLine(); } if (i%8 != 0) Console.WriteLine(); } This is happening because the format specifier in {0:X} is dropping the leading zero. The value is represented with the leading zero (obviously, since the value is 2), but the leading zero is just not printed. RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
THANK YOU! Too! I'm working on a coding project for a class (500 level course) to implement a secure email (schema) login procedure. I was looking to learn C# since I had heard about how easy it is to utilize for fast development. The hardest thing to learn has been where certain libraries are located. Doing the windows programming was a breeze, but I beat my head trying to figure out where this particular issue was (I implicitly trusted the MS code). I used to do a lot of programming in VC++, and Java and everybody seems to think C# is the wave of the future (RFC 2095 and RFC 2104) so to increase the level of difficulty I switched. So I'm writing an IMAP server and IMAP mail client for my first C# project. I have three days to complete the assignment in a new language, against sketchy RFC's, and it must be fully functional by tomorrow morning... Yee haw. Thanks again! -------------------- Sam
-
Heath Stewart wrote: It's best you don't claim bugs, especially when you've only been programming C# for 1 week. Check out the documentation, search the 'net for similar findings, and ask someone to verify (like on this forum), then declare you've found a bug and report it to the proper ch First. Thank you very much. Second. I was using the example code from Microsoft on their implemenatation of the correct code (which is still obviously wrong according to the RFC). I did check the net for this very topic (very thin and obscure task). I did ask somebody to verify but they were looking at the entire code and easily missed the problem. Third. It was an obvious small error on my part that I should have caught. I just never figured that Microsoft would provide a sample of an RFC that wasn't compliant. That is exactly why I thought to ask the kind folks here at Code Project for help. Fourth I wasn't claiming a bug and was looking for the exact validation you provided in that the Microsoft code as supplied was wrong and not something deeper. They should change that one item to make it RFC compliant. Fifth. Thanks again. Sorry if you thought I was calling your baby ugly. Haven't you ever beat your head on the keyboard looking at the obvious to somebody else while completely missing the EASY! answer? Again thank you very much for the help.... Now to finish the project. And, I think C# is pretty darn nifty......Thanks again, and again.... Really... -------------------- Sam
The samples in the documentation is riddled with bugs. Look at it - hopefully it helps you to understand if the class documentation doesn't - but never copy it.
Microsoft MVP, Visual C# My Articles