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

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
> 

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/library/system.security.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
> > 
> 
> 
> 

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/library/system.security.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
>>> 

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/library/system.security.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
> >>> 
> 
> 
> 

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"  wrote in message 
news:68AF001B-50CB-462E-B325-0FD3B8FB4B83@microsoft.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/library/system.security.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
>> >>>
>>
>>
>> 

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"  wrote in message 
> news:68AF001B-50CB-462E-B325-0FD3B8FB4B83@microsoft.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/library/system.security.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
> >> >>>
> >>
> >>
> >> 
> 
> 
> 

reflector rocks ;)


-----
Dominick Baier (http://www.leastprivilege.com)

Developing More Secure Microsoft ASP.NET 2.0 Applications (http://www.microsoft.com/mspress/books/9989.asp)


> 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"  wrote in
>> message
>> news:68AF001B-50CB-462E-B325-0FD3B8FB4B83@microsoft.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/library/system.security.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
>>>>>>>