 | |
Exact implementation of PasswordDerivedBytes
Dotnet Security microsoft.public.dotnet.security
 |
| | Thread Tools | Search this Thread | Display Modes |
#11
 
| |||
| |||
|
Re: Exact implementation of PasswordDerivedBytes -
07-30-2007
, 03:36 PM
|
Hi Dominick, I'm sorry. I lived under the false impression that these questions were always answered by MS employees. Apparently you are some other reader that wanted to help me along quickly. I hope reflector will help me along, but my expectations are low. Any clue on how I can get an MS employee to take a look at this? Kind regards, rvangeldrop "Dominick Baier" wrote: well - since i am not working for microsoft a) i can't give you the source code b) i don't set any expectations c) i don't care about your partner status but a quick google for reflector (http://www.google.de/search?q=reflector) would reveal a very useful tool with which you can look at the implementation yourself. HTH. ----- Dominick Baier (http://www.leastprivilege.com) Developing More Secure Microsoft ASP.NET 2.0 Applications (http://www.microsoft.com/mspress/books/9989.asp) Hi Dominick, This is obviously not the kind of answer I am expecting. 1. Can you explain me in more detail what 'reflector' is and how I can use it? 2. Maybe it is easier to give me the code inside PasswordDeriveBytes, since with other similar situations I'm used to being helped that way. We are a Gold Certified Partner so I was guessing I'm entitled to a more service-oriented answer. This answer is also very disappointing since the documentation Microsoft is already providing on this subject is incorrect: "This class uses an extension of the PBKDF1 algorithm defined in the PKCS#5 v2.0 standard to derive bytes suitable for use as key material from a password. The standard is documented in IETF RRC 2898." see also: http://msdn2.microsoft.com/en-us/lib...y.cryptography. passwordderivebytes.aspx I expect you to help me explain why this incorrect and what the actual implementation is. If this document would be correct my results would have been different. Regards, rvangeldrop "Dominick Baier" wrote: Use reflector. ----- Dominick Baier (http://www.leastprivilege.com) Developing More Secure Microsoft ASP.NET 2.0 Applications (http://www.microsoft.com/mspress/books/9989.asp) Hello, We are currently running a project in which we wish to reengineer parts of the System.Security.Cryptography namespace on a unix machine. We discovered that the implementation of the PasswordDerivedBytes shows some unexpected results in case the input is a 32 bytes length MD5 hash which is iterated twice. It seems that the existing documentation on this function is incorrect. It would be nice if we would know what exact algorithm is used to calculate the 32 bytes version, since in theory an MD5 hash can never result in a 32 byte length. This is our C# code: PasswordDeriveBytes pdb = new PasswordDeriveBytes("secretkey", Encoding.ASCII.getBytes("*&JHj_JHG"), "MD5", 2); byte[] hash16bytes = pdb.getBytes(16); byte[] hash32bytes = pdb.getBytes(32); and results are: For 16 bytes: 59 192 53 176 173 34 125 34 236 243 119 17 31 99 147 180 For 32 bytes: 115 229 92 88 209 121 109 87 144 35 48 70 22 39 222 198 159 230 239 240 3 64 182 168 91 39 214 244 54 200 89 222 So how is the 32 bytes result calculated? Thanks, rvangeldrop |
#12
| |||
| |||
|
|
Typically, MS support only answers questions that are posted with registered newsgroup aliases (a discussions.microsoft.com email address). Joe K. -- Joe Kaplan-MS MVP Directory Services Programming Co-author of "The .NET Developer's Guide to Directory Services Programming" http://www.directoryprogramming.net -- "rvangeldrop" <rvangeldrop (AT) discussions (DOT) microsoft.com> wrote in message news:68AF001B-50CB-462E-B325-0FD3B8FB4B83 (AT) microsoft (DOT) com... Hi Dominick, I'm sorry. I lived under the false impression that these questions were always answered by MS employees. Apparently you are some other reader that wanted to help me along quickly. I hope reflector will help me along, but my expectations are low. Any clue on how I can get an MS employee to take a look at this? Kind regards, rvangeldrop "Dominick Baier" wrote: well - since i am not working for microsoft a) i can't give you the source code b) i don't set any expectations c) i don't care about your partner status but a quick google for reflector (http://www.google.de/search?q=reflector) would reveal a very useful tool with which you can look at the implementation yourself. HTH. ----- Dominick Baier (http://www.leastprivilege.com) Developing More Secure Microsoft ASP.NET 2.0 Applications (http://www.microsoft.com/mspress/books/9989.asp) Hi Dominick, This is obviously not the kind of answer I am expecting. 1. Can you explain me in more detail what 'reflector' is and how I can use it? 2. Maybe it is easier to give me the code inside PasswordDeriveBytes, since with other similar situations I'm used to being helped that way. We are a Gold Certified Partner so I was guessing I'm entitled to a more service-oriented answer. This answer is also very disappointing since the documentation Microsoft is already providing on this subject is incorrect: "This class uses an extension of the PBKDF1 algorithm defined in the PKCS#5 v2.0 standard to derive bytes suitable for use as key material from a password. The standard is documented in IETF RRC 2898." see also: http://msdn2.microsoft.com/en-us/lib...y.cryptography. passwordderivebytes.aspx I expect you to help me explain why this incorrect and what the actual implementation is. If this document would be correct my results would have been different. Regards, rvangeldrop "Dominick Baier" wrote: Use reflector. ----- Dominick Baier (http://www.leastprivilege.com) Developing More Secure Microsoft ASP.NET 2.0 Applications (http://www.microsoft.com/mspress/books/9989.asp) Hello, We are currently running a project in which we wish to reengineer parts of the System.Security.Cryptography namespace on a unix machine. We discovered that the implementation of the PasswordDerivedBytes shows some unexpected results in case the input is a 32 bytes length MD5 hash which is iterated twice. It seems that the existing documentation on this function is incorrect. It would be nice if we would know what exact algorithm is used to calculate the 32 bytes version, since in theory an MD5 hash can never result in a 32 byte length. This is our C# code: PasswordDeriveBytes pdb = new PasswordDeriveBytes("secretkey", Encoding.ASCII.getBytes("*&JHj_JHG"), "MD5", 2); byte[] hash16bytes = pdb.getBytes(16); byte[] hash32bytes = pdb.getBytes(32); and results are: For 16 bytes: 59 192 53 176 173 34 125 34 236 243 119 17 31 99 147 180 For 32 bytes: 115 229 92 88 209 121 109 87 144 35 48 70 22 39 222 198 159 230 239 240 3 64 182 168 91 39 214 244 54 200 89 222 So how is the 32 bytes result calculated? Thanks, rvangeldrop |
#13
| |||
| |||
|
|
Typically, MS support only answers questions that are posted with registered newsgroup aliases (a discussions.microsoft.com email address). Joe K. -- Joe Kaplan-MS MVP Directory Services Programming Co-author of "The .NET Developer's Guide to Directory Services Programming" http://www.directoryprogramming.net -- "rvangeldrop" <rvangeldrop (AT) discussions (DOT) microsoft.com> wrote in message news:68AF001B-50CB-462E-B325-0FD3B8FB4B83 (AT) microsoft (DOT) com... Hi Dominick, I'm sorry. I lived under the false impression that these questions were always answered by MS employees. Apparently you are some other reader that wanted to help me along quickly. I hope reflector will help me along, but my expectations are low. Any clue on how I can get an MS employee to take a look at this? Kind regards, rvangeldrop "Dominick Baier" wrote: well - since i am not working for microsoft a) i can't give you the source code b) i don't set any expectations c) i don't care about your partner status but a quick google for reflector (http://www.google.de/search?q=reflector) would reveal a very useful tool with which you can look at the implementation yourself. HTH. ----- Dominick Baier (http://www.leastprivilege.com) Developing More Secure Microsoft ASP.NET 2.0 Applications (http://www.microsoft.com/mspress/books/9989.asp) Hi Dominick, This is obviously not the kind of answer I am expecting. 1. Can you explain me in more detail what 'reflector' is and how I can use it? 2. Maybe it is easier to give me the code inside PasswordDeriveBytes, since with other similar situations I'm used to being helped that way. We are a Gold Certified Partner so I was guessing I'm entitled to a more service-oriented answer. This answer is also very disappointing since the documentation Microsoft is already providing on this subject is incorrect: "This class uses an extension of the PBKDF1 algorithm defined in the PKCS#5 v2.0 standard to derive bytes suitable for use as key material from a password. The standard is documented in IETF RRC 2898." see also: http://msdn2.microsoft.com/en-us/lib...y.cryptography. passwordderivebytes.aspx I expect you to help me explain why this incorrect and what the actual implementation is. If this document would be correct my results would have been different. Regards, rvangeldrop "Dominick Baier" wrote: Use reflector. ----- Dominick Baier (http://www.leastprivilege.com) Developing More Secure Microsoft ASP.NET 2.0 Applications (http://www.microsoft.com/mspress/books/9989.asp) Hello, We are currently running a project in which we wish to reengineer parts of the System.Security.Cryptography namespace on a unix machine. We discovered that the implementation of the PasswordDerivedBytes shows some unexpected results in case the input is a 32 bytes length MD5 hash which is iterated twice. It seems that the existing documentation on this function is incorrect. It would be nice if we would know what exact algorithm is used to calculate the 32 bytes version, since in theory an MD5 hash can never result in a 32 byte length. This is our C# code: PasswordDeriveBytes pdb = new PasswordDeriveBytes("secretkey", Encoding.ASCII.getBytes("*&JHj_JHG"), "MD5", 2); byte[] hash16bytes = pdb.getBytes(16); byte[] hash32bytes = pdb.getBytes(32); and results are: For 16 bytes: 59 192 53 176 173 34 125 34 236 243 119 17 31 99 147 180 For 32 bytes: 115 229 92 88 209 121 109 87 144 35 48 70 22 39 222 198 159 230 239 240 3 64 182 168 91 39 214 244 54 200 89 222 So how is the 32 bytes result calculated? Thanks, rvangeldrop |
#14
| |||
| |||
|
|
Hello all, The reflector tool proved to be very powerful in this case. I expected it not to work at first, because I expected that the cryptography namespace would be unaccessible by itself too. Thanks, rvangeldrop "Joe Kaplan" wrote: Typically, MS support only answers questions that are posted with registered newsgroup aliases (a discussions.microsoft.com email address). Joe K. -- Joe Kaplan-MS MVP Directory Services Programming Co-author of "The .NET Developer's Guide to Directory Services Programming" http://www.directoryprogramming.net -- "rvangeldrop" <rvangeldrop (AT) discussions (DOT) microsoft.com> wrote in message news:68AF001B-50CB-462E-B325-0FD3B8FB4B83 (AT) microsoft (DOT) com... Hi Dominick, I'm sorry. I lived under the false impression that these questions were always answered by MS employees. Apparently you are some other reader that wanted to help me along quickly. I hope reflector will help me along, but my expectations are low. Any clue on how I can get an MS employee to take a look at this? Kind regards, rvangeldrop "Dominick Baier" wrote: well - since i am not working for microsoft a) i can't give you the source code b) i don't set any expectations c) i don't care about your partner status but a quick google for reflector (http://www.google.de/search?q=reflector) would reveal a very useful tool with which you can look at the implementation yourself. HTH. ----- Dominick Baier (http://www.leastprivilege.com) Developing More Secure Microsoft ASP.NET 2.0 Applications (http://www.microsoft.com/mspress/books/9989.asp) Hi Dominick, This is obviously not the kind of answer I am expecting. 1. Can you explain me in more detail what 'reflector' is and how I can use it? 2. Maybe it is easier to give me the code inside PasswordDeriveBytes, since with other similar situations I'm used to being helped that way. We are a Gold Certified Partner so I was guessing I'm entitled to a more service-oriented answer. This answer is also very disappointing since the documentation Microsoft is already providing on this subject is incorrect: "This class uses an extension of the PBKDF1 algorithm defined in the PKCS#5 v2.0 standard to derive bytes suitable for use as key material from a password. The standard is documented in IETF RRC 2898." see also: http://msdn2.microsoft.com/en-us/lib...rity.cryptogra phy. passwordderivebytes.aspx I expect you to help me explain why this incorrect and what the actual implementation is. If this document would be correct my results would have been different. Regards, rvangeldrop "Dominick Baier" wrote: Use reflector. ----- Dominick Baier (http://www.leastprivilege.com) Developing More Secure Microsoft ASP.NET 2.0 Applications (http://www.microsoft.com/mspress/books/9989.asp) Hello, We are currently running a project in which we wish to reengineer parts of the System.Security.Cryptography namespace on a unix machine. We discovered that the implementation of the PasswordDerivedBytes shows some unexpected results in case the input is a 32 bytes length MD5 hash which is iterated twice. It seems that the existing documentation on this function is incorrect. It would be nice if we would know what exact algorithm is used to calculate the 32 bytes version, since in theory an MD5 hash can never result in a 32 byte length. This is our C# code: PasswordDeriveBytes pdb = new PasswordDeriveBytes("secretkey", Encoding.ASCII.getBytes("*&JHj_JHG"), "MD5", 2); byte[] hash16bytes = pdb.getBytes(16); byte[] hash32bytes = pdb.getBytes(32); and results are: For 16 bytes: 59 192 53 176 173 34 125 34 236 243 119 17 31 99 147 180 For 32 bytes: 115 229 92 88 209 121 109 87 144 35 48 70 22 39 222 198 159 230 239 240 3 64 182 168 91 39 214 244 54 200 89 222 So how is the 32 bytes result calculated? Thanks, rvangeldrop |
#15
| |||
| |||
|
|
Hello all, The reflector tool proved to be very powerful in this case. I expected it not to work at first, because I expected that the cryptography namespace would be unaccessible by itself too. Thanks, rvangeldrop "Joe Kaplan" wrote: Typically, MS support only answers questions that are posted with registered newsgroup aliases (a discussions.microsoft.com email address). Joe K. -- Joe Kaplan-MS MVP Directory Services Programming Co-author of "The .NET Developer's Guide to Directory Services Programming" http://www.directoryprogramming.net -- "rvangeldrop" <rvangeldrop (AT) discussions (DOT) microsoft.com> wrote in message news:68AF001B-50CB-462E-B325-0FD3B8FB4B83 (AT) microsoft (DOT) com... Hi Dominick, I'm sorry. I lived under the false impression that these questions were always answered by MS employees. Apparently you are some other reader that wanted to help me along quickly. I hope reflector will help me along, but my expectations are low. Any clue on how I can get an MS employee to take a look at this? Kind regards, rvangeldrop "Dominick Baier" wrote: well - since i am not working for microsoft a) i can't give you the source code b) i don't set any expectations c) i don't care about your partner status but a quick google for reflector (http://www.google.de/search?q=reflector) would reveal a very useful tool with which you can look at the implementation yourself. HTH. ----- Dominick Baier (http://www.leastprivilege.com) Developing More Secure Microsoft ASP.NET 2.0 Applications (http://www.microsoft.com/mspress/books/9989.asp) Hi Dominick, This is obviously not the kind of answer I am expecting. 1. Can you explain me in more detail what 'reflector' is and how I can use it? 2. Maybe it is easier to give me the code inside PasswordDeriveBytes, since with other similar situations I'm used to being helped that way. We are a Gold Certified Partner so I was guessing I'm entitled to a more service-oriented answer. This answer is also very disappointing since the documentation Microsoft is already providing on this subject is incorrect: "This class uses an extension of the PBKDF1 algorithm defined in the PKCS#5 v2.0 standard to derive bytes suitable for use as key material from a password. The standard is documented in IETF RRC 2898." see also: http://msdn2.microsoft.com/en-us/lib...rity.cryptogra phy. passwordderivebytes.aspx I expect you to help me explain why this incorrect and what the actual implementation is. If this document would be correct my results would have been different. Regards, rvangeldrop "Dominick Baier" wrote: Use reflector. ----- Dominick Baier (http://www.leastprivilege.com) Developing More Secure Microsoft ASP.NET 2.0 Applications (http://www.microsoft.com/mspress/books/9989.asp) Hello, We are currently running a project in which we wish to reengineer parts of the System.Security.Cryptography namespace on a unix machine. We discovered that the implementation of the PasswordDerivedBytes shows some unexpected results in case the input is a 32 bytes length MD5 hash which is iterated twice. It seems that the existing documentation on this function is incorrect. It would be nice if we would know what exact algorithm is used to calculate the 32 bytes version, since in theory an MD5 hash can never result in a 32 byte length. This is our C# code: PasswordDeriveBytes pdb = new PasswordDeriveBytes("secretkey", Encoding.ASCII.getBytes("*&JHj_JHG"), "MD5", 2); byte[] hash16bytes = pdb.getBytes(16); byte[] hash32bytes = pdb.getBytes(32); and results are: For 16 bytes: 59 192 53 176 173 34 125 34 236 243 119 17 31 99 147 180 For 32 bytes: 115 229 92 88 209 121 109 87 144 35 48 70 22 39 222 198 159 230 239 240 3 64 182 168 91 39 214 244 54 200 89 222 So how is the 32 bytes result calculated? Thanks, rvangeldrop |
|
« Previous Thread
|
Next Thread »
| Thread Tools | Search this Thread |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.4
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.