|
|
You're in the
dotnet security
group:Exact implementation of PasswordDerivedBytes
dotnet security:
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,
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 [quoted text, click to view] "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 [quoted text, click to view] "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 > >>> > >
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) [quoted text, click to view] > 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 -- [quoted text, click to view] "rvangeldrop" <rvangeldrop@discussions.microsoft.com> 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 >> >>> >> >> >>
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) [quoted text, click to view] > 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 [quoted text, click to view] "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@discussions.microsoft.com> 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) [quoted text, click to view] > 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@discussions.microsoft.com> 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 >>>>>>>
Don't see what you're looking for? Try a search.
|
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
| home · blog · groups | Questions? Comments? Contact the dn |