|
security
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Encrypt with RijndaelManaged and decrypt with OpenSSLI'm trying to encrypt with RijndaelManaged and decrypt with OpenSSL.
Specifically, Linksys manufactures and sells SIP devices whose firmware is written by Sipura. Sipura tells me that I can encrypt configuration files with OpenSSL, provide the key to the devices, and the devices can decrypt the files. They specified that I should use 256-bit AES in CBC mode. Thus far I've had no luck. In my research it has become apparent to me that different implementations of Rijndael are in fact...different. I can only hope that these differences can be overcome by setting appropriate values of the various properties of the class...BlockSize, IV, etc...and that the differences don't extend to the actual algorithm. Forgive me if that's an absurd worry. Crypto ain't my thing. Has anyone successfully done this? Not specifically with Linksys devices, but at least with .NET and OpenSSL? I've been beating at this for a couple of days now to no avail.
Show quote
Hide quote
"chlock" <tay***@innovaworks.net> wrote in message I have done some experiments with exchanging AES-encrypted data between Java news:1114058601.403157.279060@f14g2000cwb.googlegroups.com... > I'm trying to encrypt with RijndaelManaged and decrypt with OpenSSL. > Specifically, Linksys manufactures and sells SIP devices whose firmware > is written by Sipura. Sipura tells me that I can encrypt configuration > files with OpenSSL, provide the key to the devices, and the devices can > decrypt the files. They specified that I should use 256-bit AES in CBC > mode. Thus far I've had no luck. > In my research it has become apparent to me that different > implementations of Rijndael are in fact...different. I can only hope > that these differences can be overcome by setting appropriate values of > the various properties of the class...BlockSize, IV, etc...and that the > differences don't extend to the actual algorithm. Forgive me if that's > an absurd worry. Crypto ain't my thing. > Has anyone successfully done this? Not specifically with Linksys > devices, but at least with .NET and OpenSSL? I've been beating at this > for a couple of days now to no avail. > and .Net. Generally this works, but you have to choose the same block chaining mode (for example CBC) and use the same IV (Initialization Vector) for the encryption and decryption. However, I haven't tried with open ssl. Please check the abovementioned AES parameters in your code and in open ssl. Regards Rafal Gwizdala Rafal-
This is a point that I'm a bit stuck on...because the devices have to decrypt the file, and I can only give them the key. There is no way for me to provide them witht the IV. Sipura provides a command line tool that allows me to encrypt the files. It is obviously a wrapper for the OpenSSL.exe. It has some other functionality, but essentially it's use is equivelent to: OpenSSL> enc -aes-256-cbc -in MyInputFile -out MyOutputFile So. My question is this...or maybe my questions are these: 1. If I add the -p switch, I can see that OpenSSL is generating an IV. Is there some way to pass the IV to the recipient in the encrypted data? I've seen some references that seem to indicate the the IV may be prepended to the output...??? 2. Perhaps there is some behavior that allows each party to derive the IV from the Key? Hello,
Well, it is possible that openssl prepends (or appends) the iv to encrypted output. I just don't know openssl enough to give you an answer. But please post an answer here if you check the openss behavior, I'm also interested. It is not important how do you obtain the IV. It simply must be the same in encryption and in decryption. Some aes-encryption utilities use a text password that is used to generate IV (IV = some value based on SHA-1 or md5 of password). You could also obtain it from the encryption key (using the same technique), I don't think this will lower the security anyhow in your case. But on a second thought: As I see it, you must pass the IV the same way as openssl passes it, otherwise Sipura device won't be able to get it - so don't think how to get the IV but how to pass it with the encrypted file. If Sipura says that it is enough to use the commandline and to send only the encrypted file to the device, then the IV must be somewhere in the encrypted file - so it is either prepended or appended. The second option is that the IV is fixed and not passed with the file (stored in device), but the commandline does not specify any IV, so this is probably not true. Best regards, Rafal Gwizdala Show quoteHide quote "chlock" <tay***@innovaworks.net> wrote in message news:1114106658.666175.97640@z14g2000cwz.googlegroups.com... > Rafal- > > This is a point that I'm a bit stuck on...because the devices have > to decrypt the file, and I can only give them the key. There is no way > for me to provide them witht the IV. Sipura provides a command line > tool that allows me to encrypt the files. It is obviously a wrapper for > the OpenSSL.exe. It has some other functionality, but essentially it's > use is equivelent to: > > OpenSSL> enc -aes-256-cbc -in MyInputFile -out MyOutputFile > > So. My question is this...or maybe my questions are these: > > 1. If I add the -p switch, I can see that OpenSSL is generating an IV. > Is there some way to pass the IV to the recipient in the encrypted > data? I've seen some references that seem to indicate the the IV may be > prepended to the output...??? > 2. Perhaps there is some behavior that allows each party to derive the > IV from the Key? > Now let me discuss a bit with myself
I checked your commandline and encrypted a short text file Typed the exact command as you gave, and 1. It asked me for encryption password - so the password was used to generate the IV 2. The input file was 11 bytes, the result is 32, so I think that the file contains the IV (16 bytes) + 11 bytes of data + some padding to full block size. 3. The encrypted file contains: Salted__ß?ÝwNÔ\6àÄySw}?Ì!' ýÁkQ? I can speculate that the prefix 'Salted....' is the initialization vector (in some publications IV is called a 'salt' value) Can you verify that? Best regards RG Show quoteHide quote "Rafal Gwizdala" <gwra***@poczta.onet.pl> wrote in message news:eLbOcKrRFHA.3120@TK2MSFTNGP10.phx.gbl... > Hello, > > Well, it is possible that openssl prepends (or appends) the iv to > encrypted output. I just don't know openssl enough to give you an answer. > But please post an answer here if you check the openss behavior, I'm also > interested. > > It is not important how do you obtain the IV. It simply must be the same > in encryption and in decryption. > Some aes-encryption utilities use a text password that is used to generate > IV (IV = some value based on SHA-1 or md5 of password). You could also > obtain it from the encryption key (using the same technique), I don't > think this will lower the security anyhow in your case. > But on a second thought: > As I see it, you must pass the IV the same way as openssl passes it, > otherwise Sipura device won't be able to get it - so don't think how to > get the IV but how to pass it with the encrypted file. If Sipura says that > it is enough to use the commandline and to send only the encrypted file to > the device, then the IV must be somewhere in the encrypted file - so it is > either prepended or appended. The second option is that the IV is fixed > and not passed with the file (stored in device), but the commandline does > not specify any IV, so this is probably not true. > > Best regards, > Rafal Gwizdala > > "chlock" <tay***@innovaworks.net> wrote in message > news:1114106658.666175.97640@z14g2000cwz.googlegroups.com... >> Rafal- >> >> This is a point that I'm a bit stuck on...because the devices have >> to decrypt the file, and I can only give them the key. There is no way >> for me to provide them witht the IV. Sipura provides a command line >> tool that allows me to encrypt the files. It is obviously a wrapper for >> the OpenSSL.exe. It has some other functionality, but essentially it's >> use is equivelent to: >> >> OpenSSL> enc -aes-256-cbc -in MyInputFile -out MyOutputFile >> >> So. My question is this...or maybe my questions are these: >> >> 1. If I add the -p switch, I can see that OpenSSL is generating an IV. >> Is there some way to pass the IV to the recipient in the encrypted >> data? I've seen some references that seem to indicate the the IV may be >> prepended to the output...??? >> 2. Perhaps there is some behavior that allows each party to derive the >> IV from the Key? >> > > According to Openssl docs for this:
"When a password is being specified using one of the other options, the IV is generated from this password." - Mitch Show quoteHide quote "Rafal Gwizdala" <gwra***@poczta.onet.pl> wrote in message news:%23Uv46QrRFHA.3704@TK2MSFTNGP12.phx.gbl... > Now let me discuss a bit with myself > > I checked your commandline and encrypted a short text file > Typed the exact command as you gave, and > 1. It asked me for encryption password - so the password was used to > generate the IV > 2. The input file was 11 bytes, the result is 32, so I think that the file > contains the IV (16 bytes) + 11 bytes of data + some padding to full block > size. > 3. The encrypted file contains: > Salted__ß?ÝwNÔ\6àÄySw} Ì!' ýÁkQ? > I can speculate that the prefix 'Salted....' is the initialization vector > (in some publications IV is called a 'salt' value) > > Can you verify that? > > Best regards > RG > > "Rafal Gwizdala" <gwra***@poczta.onet.pl> wrote in message > news:eLbOcKrRFHA.3120@TK2MSFTNGP10.phx.gbl... > > Hello, > > > > Well, it is possible that openssl prepends (or appends) the iv to > > encrypted output. I just don't know openssl enough to give you an answer. > > But please post an answer here if you check the openss behavior, I'm also > > interested. > > > > It is not important how do you obtain the IV. It simply must be the same > > in encryption and in decryption. > > Some aes-encryption utilities use a text password that is used to generate > > IV (IV = some value based on SHA-1 or md5 of password). You could also > > obtain it from the encryption key (using the same technique), I don't > > think this will lower the security anyhow in your case. > > But on a second thought: > > As I see it, you must pass the IV the same way as openssl passes it, > > otherwise Sipura device won't be able to get it - so don't think how to > > get the IV but how to pass it with the encrypted file. If Sipura says that > > it is enough to use the commandline and to send only the encrypted file to > > the device, then the IV must be somewhere in the encrypted file - so it is > > either prepended or appended. The second option is that the IV is fixed > > and not passed with the file (stored in device), but the commandline does > > not specify any IV, so this is probably not true. > > > > Best regards, > > Rafal Gwizdala > > > > "chlock" <tay***@innovaworks.net> wrote in message > > news:1114106658.666175.97640@z14g2000cwz.googlegroups.com... > >> Rafal- > >> > >> This is a point that I'm a bit stuck on...because the devices have > >> to decrypt the file, and I can only give them the key. There is no way > >> for me to provide them witht the IV. Sipura provides a command line > >> tool that allows me to encrypt the files. It is obviously a wrapper for > >> the OpenSSL.exe. It has some other functionality, but essentially it's > >> use is equivelent to: > >> > >> OpenSSL> enc -aes-256-cbc -in MyInputFile -out MyOutputFile > >> > >> So. My question is this...or maybe my questions are these: > >> > >> 1. If I add the -p switch, I can see that OpenSSL is generating an IV. > >> Is there some way to pass the IV to the recipient in the encrypted > >> data? I've seen some references that seem to indicate the the IV may be > >> prepended to the output...??? > >> 2. Perhaps there is some behavior that allows each party to derive the > >> IV from the Key? > >> > > > > > > I think that the first 8 bytes Salted__ is followed by the randomly
generated 8 byte salt value. Then, the supplied password is combined with that 8 byte random salt value to derive both the key and IV using EVP_BYTESToKey: http://www.openssl.org/docs/crypto/EVP_BytesToKey.html So the IV is not stored with the openssl enc generated blob. It is recovered. - Mitch Gallant MVP Security Show quoteHide quote "Rafal Gwizdala" <gwra***@poczta.onet.pl> wrote in message news:%23Uv46QrRFHA.3704@TK2MSFTNGP12.phx.gbl... > Now let me discuss a bit with myself > > I checked your commandline and encrypted a short text file > Typed the exact command as you gave, and > 1. It asked me for encryption password - so the password was used to > generate the IV > 2. The input file was 11 bytes, the result is 32, so I think that the file > contains the IV (16 bytes) + 11 bytes of data + some padding to full block > size. > 3. The encrypted file contains: > Salted__ß?ÝwNÔ\6àÄySw} Ì!' ýÁkQ? > I can speculate that the prefix 'Salted....' is the initialization vector > (in some publications IV is called a 'salt' value) > > Can you verify that? > > Best regards > RG > > "Rafal Gwizdala" <gwra***@poczta.onet.pl> wrote in message > news:eLbOcKrRFHA.3120@TK2MSFTNGP10.phx.gbl... > > Hello, > > > > Well, it is possible that openssl prepends (or appends) the iv to > > encrypted output. I just don't know openssl enough to give you an answer. > > But please post an answer here if you check the openss behavior, I'm also > > interested. > > > > It is not important how do you obtain the IV. It simply must be the same > > in encryption and in decryption. > > Some aes-encryption utilities use a text password that is used to generate > > IV (IV = some value based on SHA-1 or md5 of password). You could also > > obtain it from the encryption key (using the same technique), I don't > > think this will lower the security anyhow in your case. > > But on a second thought: > > As I see it, you must pass the IV the same way as openssl passes it, > > otherwise Sipura device won't be able to get it - so don't think how to > > get the IV but how to pass it with the encrypted file. If Sipura says that > > it is enough to use the commandline and to send only the encrypted file to > > the device, then the IV must be somewhere in the encrypted file - so it is > > either prepended or appended. The second option is that the IV is fixed > > and not passed with the file (stored in device), but the commandline does > > not specify any IV, so this is probably not true. > > > > Best regards, > > Rafal Gwizdala > > > > "chlock" <tay***@innovaworks.net> wrote in message > > news:1114106658.666175.97640@z14g2000cwz.googlegroups.com... > >> Rafal- > >> > >> This is a point that I'm a bit stuck on...because the devices have > >> to decrypt the file, and I can only give them the key. There is no way > >> for me to provide them witht the IV. Sipura provides a command line > >> tool that allows me to encrypt the files. It is obviously a wrapper for > >> the OpenSSL.exe. It has some other functionality, but essentially it's > >> use is equivelent to: > >> > >> OpenSSL> enc -aes-256-cbc -in MyInputFile -out MyOutputFile > >> > >> So. My question is this...or maybe my questions are these: > >> > >> 1. If I add the -p switch, I can see that OpenSSL is generating an IV. > >> Is there some way to pass the IV to the recipient in the encrypted > >> data? I've seen some references that seem to indicate the the IV may be > >> prepended to the output...??? > >> 2. Perhaps there is some behavior that allows each party to derive the > >> IV from the Key? > >> > > > > > > OK-
Here is what I've learned...by a lot of trial and error. Mitch is correct...Salted__ is followed by the salt value. So I can now take the salt, key, and iv that the command line OpenSSL returns to me for say the password "p"...and I can generate an identical file using those values and the RijndaelManaged class. Now...in theory I should be able to use the salt that OpenSSL gave me (they randomly generate it, I'm sure) and the same password "p" and generate the same key and iv using .NET code. And now we're really up against it. Although OpenSSL documentation states that the key and iv are generated based on the password, http://www.openssl.org/docs/crypto/EVP_BytesToKey.html (I just realized that Mark had posted this link already..oh well) I can't make it happed so far from C#. I've been poring over the code (and I ain't no C guru) all day trying to trace back and discover what algorithm they use to generate the key and how many iterations they use. There must be defaults somewhere, but I haven't found them yet. So. If I use the OpenSSL exe like this: OpenSSL> enc aes-256-cbc -salt -p -in myInFile.cfg -out myOutFile.cfg ...and I specify a password when asked...How does OpenSSL derive the salt (random probably), Key, and IV. The latter two come from a recursive hash of the password using a certain algorithm a certain number of times... 1. What is the algorithm? 2. What is the number iterations? These are the $64000 questions. -chlock Please explain once more what do you want to achieve in .Net.
If you want to encrypt the config file please just do so. You have only to: 1. Generate the key and IV 2. Write the IV to output file 3. Write the encrypted data You don't have to derive the IV from any password, openssl doesn't put any requirements on the IV structure. So it will use any IV .Net generates. Why did you introduce the salt and IV? Isn't it the same thing? IV = Salted_ + some random 8 bytes - which gives 16 bytes. There is no separate 'salt' part in .Net and you don't have to dig deeper into it. Best Regards Rafal Gwizdala ----- Original Message ----- From: "chlock" <tay***@innovaworks.net> Newsgroups: microsoft.public.dotnet.securitySent: Friday, April 22, 2005 4:21 AM Subject: Re: Encrypt with RijndaelManaged and decrypt with OpenSSL Show quoteHide quote > OK- > > Here is what I've learned...by a lot of trial and error. Mitch is > correct...Salted__ is followed by the salt value. So I can now take the > salt, key, and iv that the command line OpenSSL returns to me for say > the password "p"...and I can generate an identical file using those > values and the RijndaelManaged class. > > Now...in theory I should be able to use the salt that OpenSSL gave me > (they randomly generate it, I'm sure) and the same password "p" and > generate the same key and iv using .NET code. > > And now we're really up against it. Although OpenSSL documentation > states that the key and iv are generated based on the password, > > http://www.openssl.org/docs/crypto/EVP_BytesToKey.html (I just realized > that Mark had posted this link already..oh well) > > I can't make it happed so far from C#. I've been poring over the code > (and I ain't no C guru) all day trying to trace back and discover what > algorithm they use to generate the key and how many iterations they > use. There must be defaults somewhere, but I haven't found them yet. > > So. If I use the OpenSSL exe like this: > > OpenSSL> enc aes-256-cbc -salt -p -in myInFile.cfg -out myOutFile.cfg > > ..and I specify a password when asked...How does OpenSSL derive the > salt (random probably), Key, and IV. The latter two come from a > recursive hash of the password using a certain algorithm a certain > number of times... > > 1. What is the algorithm? > 2. What is the number iterations? > > These are the $64000 questions. > > -chlock > Have a look at listing 30.12 in ".NET Framework Security"
LaMacchia et. al. It is an excellent example and discussion of PBE in .NET which uses both a crypto-random salt value and a randomly generated IV. ONLY the AES KEY is derived from the password. See the discussion therein for why it's important to both have a randome SALT and IV. - Mitch Gallant MVP Security Show quoteHide quote "Rafal Gwizdala" <gwra***@poczta.onet.pl> wrote in message news:%23VgAADwRFHA.3156@TK2MSFTNGP15.phx.gbl... > Please explain once more what do you want to achieve in .Net. > If you want to encrypt the config file please just do so. You have only to: > 1. Generate the key and IV > 2. Write the IV to output file > 3. Write the encrypted data > You don't have to derive the IV from any password, openssl doesn't put any > requirements on the IV structure. > So it will use any IV .Net generates. > > Why did you introduce the salt and IV? Isn't it the same thing? IV = Salted_ > + some random 8 bytes - which gives 16 bytes. There is no separate 'salt' > part in .Net and you don't have to dig deeper into it. > > Best Regards > Rafal Gwizdala > > ----- Original Message ----- > From: "chlock" <tay***@innovaworks.net> > Newsgroups: microsoft.public.dotnet.security > Sent: Friday, April 22, 2005 4:21 AM > Subject: Re: Encrypt with RijndaelManaged and decrypt with OpenSSL > > > > OK- > > > > Here is what I've learned...by a lot of trial and error. Mitch is > > correct...Salted__ is followed by the salt value. So I can now take the > > salt, key, and iv that the command line OpenSSL returns to me for say > > the password "p"...and I can generate an identical file using those > > values and the RijndaelManaged class. > > > > Now...in theory I should be able to use the salt that OpenSSL gave me > > (they randomly generate it, I'm sure) and the same password "p" and > > generate the same key and iv using .NET code. > > > > And now we're really up against it. Although OpenSSL documentation > > states that the key and iv are generated based on the password, > > > > http://www.openssl.org/docs/crypto/EVP_BytesToKey.html (I just realized > > that Mark had posted this link already..oh well) > > > > I can't make it happed so far from C#. I've been poring over the code > > (and I ain't no C guru) all day trying to trace back and discover what > > algorithm they use to generate the key and how many iterations they > > use. There must be defaults somewhere, but I haven't found them yet. > > > > So. If I use the OpenSSL exe like this: > > > > OpenSSL> enc aes-256-cbc -salt -p -in myInFile.cfg -out myOutFile.cfg > > > > ..and I specify a password when asked...How does OpenSSL derive the > > salt (random probably), Key, and IV. The latter two come from a > > recursive hash of the password using a certain algorithm a certain > > number of times... > > > > 1. What is the algorithm? > > 2. What is the number iterations? > > > > These are the $64000 questions. > > > > -chlock > > > > Hi,
Originally salt was a very different thing than IV. It was added somewhere in the middle of 70th as countermeasure against fast hardware based cryptography. Salt supposes to be altering cryptographic algorithm, not to add data to the input or internal state. DES salt is 12 bits value that changes key schedule. Key schedule is a function that calculates round keys from given key. DES uses 56 bit key, and round function calculates 16 48bit keys from it. Salt application is following: round key is divided in two halves, each half divided into 12 bit pairs, each bit of salt defines which bitpairs should switch bits. That way, any standard hardware DES implementation that uses standard keyschedule is unusable with modified salted key schedule. IV is just a part of input. Adding IV does nothing for preventing use of standard hardware based cryptography components. Another example of correct salt is Bruce Schneier's block chiphers (ex. blowfish) that uses salt for altering context of s-boxes (4k of altering s-box data depending on both key and salt that effectively prevents any pipelining for purposes of brute force attacks). Salt was introduced during development of UNIX crypt password encryption scheme somewhere in the middle of 70th for purpose of protecting UNIX passwords against governmental agencies that has sufficient fundings for buying a lot of fast hardware based DES chips and able running them in concerted password breaking attack. Limitation of crypt (max 8 characters) lead to development of other password encryption schemes, one of them was based on use of hash function (like MD4 hash that was designed by Ronald Rivest in 1982). Since new hash based password protection scheme supposed to replace older DES based crypt, it was convenient to designate something to be salt in that scheme. It was decided to use some extra data (IV) that shall be feed to the hash function and alters internal state of the function before it starts processing the password. And that was called salt as well just for convenience of network administrators, even so it meant entirely different thing. I think it was quite unfortunate. -Valery. http://www.harper.no/valery Show quoteHide quote "Rafal Gwizdala" <gwra***@poczta.onet.pl> wrote in message news:%23VgAADwRFHA.3156@TK2MSFTNGP15.phx.gbl... > Please explain once more what do you want to achieve in .Net. > If you want to encrypt the config file please just do so. You have only > to: > 1. Generate the key and IV > 2. Write the IV to output file > 3. Write the encrypted data > You don't have to derive the IV from any password, openssl doesn't put any > requirements on the IV structure. > So it will use any IV .Net generates. > > Why did you introduce the salt and IV? Isn't it the same thing? IV = > Salted_ > + some random 8 bytes - which gives 16 bytes. There is no separate 'salt' > part in .Net and you don't have to dig deeper into it. > > Best Regards > Rafal Gwizdala > > ----- Original Message ----- > From: "chlock" <tay***@innovaworks.net> > Newsgroups: microsoft.public.dotnet.security > Sent: Friday, April 22, 2005 4:21 AM > Subject: Re: Encrypt with RijndaelManaged and decrypt with OpenSSL > > >> OK- >> >> Here is what I've learned...by a lot of trial and error. Mitch is >> correct...Salted__ is followed by the salt value. So I can now take the >> salt, key, and iv that the command line OpenSSL returns to me for say >> the password "p"...and I can generate an identical file using those >> values and the RijndaelManaged class. >> >> Now...in theory I should be able to use the salt that OpenSSL gave me >> (they randomly generate it, I'm sure) and the same password "p" and >> generate the same key and iv using .NET code. >> >> And now we're really up against it. Although OpenSSL documentation >> states that the key and iv are generated based on the password, >> >> http://www.openssl.org/docs/crypto/EVP_BytesToKey.html (I just realized >> that Mark had posted this link already..oh well) >> >> I can't make it happed so far from C#. I've been poring over the code >> (and I ain't no C guru) all day trying to trace back and discover what >> algorithm they use to generate the key and how many iterations they >> use. There must be defaults somewhere, but I haven't found them yet. >> >> So. If I use the OpenSSL exe like this: >> >> OpenSSL> enc aes-256-cbc -salt -p -in myInFile.cfg -out myOutFile.cfg >> >> ..and I specify a password when asked...How does OpenSSL derive the >> salt (random probably), Key, and IV. The latter two come from a >> recursive hash of the password using a certain algorithm a certain >> number of times... >> >> 1. What is the algorithm? >> 2. What is the number iterations? >> >> These are the $64000 questions. >> >> -chlock >> > > Hi,
So thanks to chlock's quite innocent problem we have now a lecture on cryptoghaphy history. I like it very much, thank you Valery. Hope no one solves this problem too soon, I have learned some things here and want more... Best regards RG Show quoteHide quote "Valery Pryamikov" <val***@harper.no> wrote in message news:uy0I4d9RFHA.2748@TK2MSFTNGP09.phx.gbl... > Hi, > Originally salt was a very different thing than IV. It was added somewhere > in the middle of 70th as countermeasure against fast hardware based > cryptography. Salt supposes to be altering cryptographic algorithm, not to > add data to the input or internal state. DES salt is 12 bits value that > changes key schedule. Key schedule is a function that calculates round > keys from given key. DES uses 56 bit key, and round function calculates 16 > 48bit keys from it. Salt application is following: round key is divided in > two halves, each half divided into 12 bit pairs, each bit of salt defines > which bitpairs should switch bits. That way, any standard hardware DES > implementation that uses standard keyschedule is unusable with modified > salted key schedule. IV is just a part of input. Adding IV does nothing > for preventing use of standard hardware based cryptography components. > Another example of correct salt is Bruce Schneier's block chiphers (ex. > blowfish) that uses salt for altering context of s-boxes (4k of altering > s-box data depending on both key and salt that effectively prevents any > pipelining for purposes of brute force attacks). > Salt was introduced during development of UNIX crypt password encryption > scheme somewhere in the middle of 70th for purpose of protecting UNIX > passwords against governmental agencies that has sufficient fundings for > buying a lot of fast hardware based DES chips and able running them in > concerted password breaking attack. Limitation of crypt (max 8 characters) > lead to development of other password encryption schemes, one of them was > based on use of hash function (like MD4 hash that was designed by Ronald > Rivest in 1982). Since new hash based password protection scheme supposed > to replace older DES based crypt, it was convenient to designate something > to be salt in that scheme. It was decided to use some extra data (IV) that > shall be feed to the hash function and alters internal state of the > function before it starts processing the password. And that was called > salt as well just for convenience of network administrators, even so it > meant entirely different thing. I think it was quite unfortunate. > > -Valery. > http://www.harper.no/valery > > "Rafal Gwizdala" <gwra***@poczta.onet.pl> wrote in message > news:%23VgAADwRFHA.3156@TK2MSFTNGP15.phx.gbl... >> Please explain once more what do you want to achieve in .Net. >> If you want to encrypt the config file please just do so. You have only >> to: >> 1. Generate the key and IV >> 2. Write the IV to output file >> 3. Write the encrypted data >> You don't have to derive the IV from any password, openssl doesn't put >> any >> requirements on the IV structure. >> So it will use any IV .Net generates. >> >> Why did you introduce the salt and IV? Isn't it the same thing? IV = >> Salted_ >> + some random 8 bytes - which gives 16 bytes. There is no separate 'salt' >> part in .Net and you don't have to dig deeper into it. >> >> Best Regards >> Rafal Gwizdala >> >> ----- Original Message ----- >> From: "chlock" <tay***@innovaworks.net> >> Newsgroups: microsoft.public.dotnet.security >> Sent: Friday, April 22, 2005 4:21 AM >> Subject: Re: Encrypt with RijndaelManaged and decrypt with OpenSSL >> >> >>> OK- >>> >>> Here is what I've learned...by a lot of trial and error. Mitch is >>> correct...Salted__ is followed by the salt value. So I can now take the >>> salt, key, and iv that the command line OpenSSL returns to me for say >>> the password "p"...and I can generate an identical file using those >>> values and the RijndaelManaged class. >>> >>> Now...in theory I should be able to use the salt that OpenSSL gave me >>> (they randomly generate it, I'm sure) and the same password "p" and >>> generate the same key and iv using .NET code. >>> >>> And now we're really up against it. Although OpenSSL documentation >>> states that the key and iv are generated based on the password, >>> >>> http://www.openssl.org/docs/crypto/EVP_BytesToKey.html (I just realized >>> that Mark had posted this link already..oh well) >>> >>> I can't make it happed so far from C#. I've been poring over the code >>> (and I ain't no C guru) all day trying to trace back and discover what >>> algorithm they use to generate the key and how many iterations they >>> use. There must be defaults somewhere, but I haven't found them yet. >>> >>> So. If I use the OpenSSL exe like this: >>> >>> OpenSSL> enc aes-256-cbc -salt -p -in myInFile.cfg -out myOutFile.cfg >>> >>> ..and I specify a password when asked...How does OpenSSL derive the >>> salt (random probably), Key, and IV. The latter two come from a >>> recursive hash of the password using a certain algorithm a certain >>> number of times... >>> >>> 1. What is the algorithm? >>> 2. What is the number iterations? >>> >>> These are the $64000 questions. >>> >>> -chlock >>> >> >> > Hi Rafal,
it was nice to hear that you liked my answer :-). btw. i did a stupid mistake about the year of md4 invention (wrote it all from the top of my head but was wrong regarding that particular date). Rivest invented md4 in 1990. The rest looks to be correct (if we don't count for spelling mistakes :-). -Valery. http://www.harper.no/valery Show quoteHide quote "Rafal Gwizdala" <gwra***@poczta.onet.pl> wrote in message news:e1nO4dASFHA.688@TK2MSFTNGP10.phx.gbl... > Hi, > > So thanks to chlock's quite innocent problem we have now a lecture on > cryptoghaphy history. > I like it very much, thank you Valery. Hope no one solves this problem too > soon, I have learned some things here and want more... > > Best regards > RG > > "Valery Pryamikov" <val***@harper.no> wrote in message > news:uy0I4d9RFHA.2748@TK2MSFTNGP09.phx.gbl... >> Hi, >> Originally salt was a very different thing than IV. It was added >> somewhere in the middle of 70th as countermeasure against fast hardware >> based cryptography. Salt supposes to be altering cryptographic algorithm, >> not to add data to the input or internal state. DES salt is 12 bits value >> that changes key schedule. Key schedule is a function that calculates >> round keys from given key. DES uses 56 bit key, and round function >> calculates 16 48bit keys from it. Salt application is following: round >> key is divided in two halves, each half divided into 12 bit pairs, each >> bit of salt defines which bitpairs should switch bits. That way, any >> standard hardware DES implementation that uses standard keyschedule is >> unusable with modified salted key schedule. IV is just a part of input. >> Adding IV does nothing for preventing use of standard hardware based >> cryptography components. >> Another example of correct salt is Bruce Schneier's block chiphers (ex. >> blowfish) that uses salt for altering context of s-boxes (4k of altering >> s-box data depending on both key and salt that effectively prevents any >> pipelining for purposes of brute force attacks). >> Salt was introduced during development of UNIX crypt password encryption >> scheme somewhere in the middle of 70th for purpose of protecting UNIX >> passwords against governmental agencies that has sufficient fundings for >> buying a lot of fast hardware based DES chips and able running them in >> concerted password breaking attack. Limitation of crypt (max 8 >> characters) lead to development of other password encryption schemes, one >> of them was based on use of hash function (like MD4 hash that was >> designed by Ronald Rivest in 1982). Since new hash based password >> protection scheme supposed to replace older DES based crypt, it was >> convenient to designate something to be salt in that scheme. It was >> decided to use some extra data (IV) that shall be feed to the hash >> function and alters internal state of the function before it starts >> processing the password. And that was called salt as well just for >> convenience of network administrators, even so it meant entirely >> different thing. I think it was quite unfortunate. >> >> -Valery. >> http://www.harper.no/valery >> >> "Rafal Gwizdala" <gwra***@poczta.onet.pl> wrote in message >> news:%23VgAADwRFHA.3156@TK2MSFTNGP15.phx.gbl... >>> Please explain once more what do you want to achieve in .Net. >>> If you want to encrypt the config file please just do so. You have only >>> to: >>> 1. Generate the key and IV >>> 2. Write the IV to output file >>> 3. Write the encrypted data >>> You don't have to derive the IV from any password, openssl doesn't put >>> any >>> requirements on the IV structure. >>> So it will use any IV .Net generates. >>> >>> Why did you introduce the salt and IV? Isn't it the same thing? IV = >>> Salted_ >>> + some random 8 bytes - which gives 16 bytes. There is no separate >>> 'salt' >>> part in .Net and you don't have to dig deeper into it. >>> >>> Best Regards >>> Rafal Gwizdala >>> >>> ----- Original Message ----- >>> From: "chlock" <tay***@innovaworks.net> >>> Newsgroups: microsoft.public.dotnet.security >>> Sent: Friday, April 22, 2005 4:21 AM >>> Subject: Re: Encrypt with RijndaelManaged and decrypt with OpenSSL >>> >>> >>>> OK- >>>> >>>> Here is what I've learned...by a lot of trial and error. Mitch is >>>> correct...Salted__ is followed by the salt value. So I can now take the >>>> salt, key, and iv that the command line OpenSSL returns to me for say >>>> the password "p"...and I can generate an identical file using those >>>> values and the RijndaelManaged class. >>>> >>>> Now...in theory I should be able to use the salt that OpenSSL gave me >>>> (they randomly generate it, I'm sure) and the same password "p" and >>>> generate the same key and iv using .NET code. >>>> >>>> And now we're really up against it. Although OpenSSL documentation >>>> states that the key and iv are generated based on the password, >>>> >>>> http://www.openssl.org/docs/crypto/EVP_BytesToKey.html (I just realized >>>> that Mark had posted this link already..oh well) >>>> >>>> I can't make it happed so far from C#. I've been poring over the code >>>> (and I ain't no C guru) all day trying to trace back and discover what >>>> algorithm they use to generate the key and how many iterations they >>>> use. There must be defaults somewhere, but I haven't found them yet. >>>> >>>> So. If I use the OpenSSL exe like this: >>>> >>>> OpenSSL> enc aes-256-cbc -salt -p -in myInFile.cfg -out myOutFile.cfg >>>> >>>> ..and I specify a password when asked...How does OpenSSL derive the >>>> salt (random probably), Key, and IV. The latter two come from a >>>> recursive hash of the password using a certain algorithm a certain >>>> number of times... >>>> >>>> 1. What is the algorithm? >>>> 2. What is the number iterations? >>>> >>>> These are the $64000 questions. >>>> >>>> -chlock >>>> >>> >>> >> > > I was looking at this last night :-) .. got me hooked on this.
And comparing Java PBE with .NET .. I noticed that in standard Java 2 JCE, it is impossible to hook out the internally generated symmetric key? You can retrieve the internally PBE-generated IV but NOT the key! The classes hide that internally. In .NET, PasswordDerivedBytes directly returns the keymaterial based on PKCS #5 v2.0 Is that your understanding? I was quickly trying to see if .NET PasswordDeriveBytes returns the same byte keymaterial (for same password, salt and it count) as that generated in Java by: ----------- Java 2 JCE implementation of PBE SecretKey generation ----- String MYPBEALG = "PBEWithSHA1AndDESede" ; PBEParameterSpec pbeParamSpec = new PBEParameterSpec(salt, count); String password = "ssshh! a difficult secret" ; PBEKeySpec pbeKeySpec = new PBEKeySpec(password.toCharArray()); keyFac = SecretKeyFactory.getInstance(MYPBEALG); SecretKey pbeKey = keyFac.generateSecret(pbeKeySpec); Cipher pbeCipher = Cipher.getInstance(MYPBEALG); pbeCipher.init(Cipher.ENCRYPT_MODE, pbeKey, pbeParamSpec); byte[] IV = pbeCipher.getIV() ; //actual internally generated IV byte[] key = pbeKey.getEncoded(); //this just returns the password as a byte[] ----------------------- I haven't actually tried comparing the ciphertext generated tho. - Mitch Gallant MVP Security Show quoteHide quote "chlock" <tay***@innovaworks.net> wrote in message news:1114136507.550811.297350@f14g2000cwb.googlegroups.com... > OK- > > Here is what I've learned...by a lot of trial and error. Mitch is > correct...Salted__ is followed by the salt value. So I can now take the > salt, key, and iv that the command line OpenSSL returns to me for say > the password "p"...and I can generate an identical file using those > values and the RijndaelManaged class. > > Now...in theory I should be able to use the salt that OpenSSL gave me > (they randomly generate it, I'm sure) and the same password "p" and > generate the same key and iv using .NET code. > > And now we're really up against it. Although OpenSSL documentation > states that the key and iv are generated based on the password, > > http://www.openssl.org/docs/crypto/EVP_BytesToKey.html (I just realized > that Mark had posted this link already..oh well) > > I can't make it happed so far from C#. I've been poring over the code > (and I ain't no C guru) all day trying to trace back and discover what > algorithm they use to generate the key and how many iterations they > use. There must be defaults somewhere, but I haven't found them yet. > > So. If I use the OpenSSL exe like this: > > OpenSSL> enc aes-256-cbc -salt -p -in myInFile.cfg -out myOutFile.cfg > > ..and I specify a password when asked...How does OpenSSL derive the > salt (random probably), Key, and IV. The latter two come from a > recursive hash of the password using a certain algorithm a certain > number of times... > > 1. What is the algorithm? > 2. What is the number iterations? > > These are the $64000 questions. > > -chlock > Well, I got confused here, that's why my post wasn't accurate. I don't know
exactly what problem we are solving - this is a question to [chlock]. If both the encrypted file and symmetric key are passed to the device, there is no need to derive the key from a password. And in the first post chlock said: 'Sipura tells me that I can encrypt configuration files with OpenSSL, provide the key to the devices, and the devices can decrypt the files.' So if the device has a key, the only problem is to generate an IV and prepend it to the file. Ain't I right? Best Regards, Rafal Gwizdala Show quoteHide quote "Michel Gallant" <neut***@istar.ca> wrote in message news:e%23r38A0RFHA.2356@TK2MSFTNGP14.phx.gbl... >I was looking at this last night :-) .. got me hooked on this. > And comparing Java PBE with .NET .. > I noticed that in standard Java 2 JCE, it is impossible to > hook out the internally generated symmetric key? You > can retrieve the internally PBE-generated IV but NOT the > key! The classes hide that internally. > In .NET, PasswordDerivedBytes directly returns the keymaterial > based on PKCS #5 v2.0 > > Is that your understanding? I was quickly trying to see if .NET > PasswordDeriveBytes returns the same byte keymaterial (for same > password, salt and it count) as that generated in Java by: > > ----------- Java 2 JCE implementation of PBE SecretKey generation ----- > String MYPBEALG = "PBEWithSHA1AndDESede" ; > PBEParameterSpec pbeParamSpec = new PBEParameterSpec(salt, count); > String password = "ssshh! a difficult secret" ; > PBEKeySpec pbeKeySpec = new PBEKeySpec(password.toCharArray()); > keyFac = SecretKeyFactory.getInstance(MYPBEALG); > SecretKey pbeKey = keyFac.generateSecret(pbeKeySpec); > Cipher pbeCipher = Cipher.getInstance(MYPBEALG); > pbeCipher.init(Cipher.ENCRYPT_MODE, pbeKey, pbeParamSpec); > > byte[] IV = pbeCipher.getIV() ; //actual internally generated IV > > byte[] key = pbeKey.getEncoded(); //this just returns the password as > a byte[] > ----------------------- > > I haven't actually tried comparing the ciphertext generated tho. > > - Mitch Gallant > MVP Security > > > "chlock" <tay***@innovaworks.net> wrote in message > news:1114136507.550811.297350@f14g2000cwb.googlegroups.com... >> OK- >> >> Here is what I've learned...by a lot of trial and error. Mitch is >> correct...Salted__ is followed by the salt value. So I can now take the >> salt, key, and iv that the command line OpenSSL returns to me for say >> the password "p"...and I can generate an identical file using those >> values and the RijndaelManaged class. >> >> Now...in theory I should be able to use the salt that OpenSSL gave me >> (they randomly generate it, I'm sure) and the same password "p" and >> generate the same key and iv using .NET code. >> >> And now we're really up against it. Although OpenSSL documentation >> states that the key and iv are generated based on the password, >> >> http://www.openssl.org/docs/crypto/EVP_BytesToKey.html (I just realized >> that Mark had posted this link already..oh well) >> >> I can't make it happed so far from C#. I've been poring over the code >> (and I ain't no C guru) all day trying to trace back and discover what >> algorithm they use to generate the key and how many iterations they >> use. There must be defaults somewhere, but I haven't found them yet. >> >> So. If I use the OpenSSL exe like this: >> >> OpenSSL> enc aes-256-cbc -salt -p -in myInFile.cfg -out myOutFile.cfg >> >> ..and I specify a password when asked...How does OpenSSL derive the >> salt (random probably), Key, and IV. The latter two come from a >> recursive hash of the password using a certain algorithm a certain >> number of times... >> >> 1. What is the algorithm? >> 2. What is the number iterations? >> >> These are the $64000 questions. >> >> -chlock >> > >
Show quote
Hide quote
"chlock" <tay***@innovaworks.net> wrote in message news:1114136507.550811.297350@f14g2000cwb.googlegroups.com... KEY DERIVATION ALGORITHM> OK- > > Here is what I've learned...by a lot of trial and error. Mitch is > correct...Salted__ is followed by the salt value. So I can now take the > salt, key, and iv that the command line OpenSSL returns to me for say > the password "p"...and I can generate an identical file using those > values and the RijndaelManaged class. > > Now...in theory I should be able to use the salt that OpenSSL gave me > (they randomly generate it, I'm sure) and the same password "p" and > generate the same key and iv using .NET code. > > And now we're really up against it. Although OpenSSL documentation > states that the key and iv are generated based on the password, > > http://www.openssl.org/docs/crypto/EVP_BytesToKey.html (I just realized > that Mark had posted this link already..oh well) > > I can't make it happed so far from C#. I've been poring over the code > (and I ain't no C guru) all day trying to trace back and discover what > algorithm they use to generate the key and how many iterations they > use. There must be defaults somewhere, but I haven't found them yet. > > So. If I use the OpenSSL exe like this: > > OpenSSL> enc aes-256-cbc -salt -p -in myInFile.cfg -out myOutFile.cfg > > ..and I specify a password when asked...How does OpenSSL derive the > salt (random probably), Key, and IV. The latter two come from a > recursive hash of the password using a certain algorithm a certain > number of times... > > 1. What is the algorithm? > 2. What is the number iterations? > The key and IV is derived by concatenating D_1, D_2, etc until enough data is available for the key and IV. D_i is defined as: D_i = HASH^count(D_(i-1) || data || salt) where || denotes concatentaion, D_0 is empty, HASH is the digest algorithm in use, HASH^1(data) is simply HASH(data), HASH^2(data) is HASH(HASH(data)) and so on. The initial bytes are used for the key and the subsequent bytes for the IV. Not sure exactly what iteration count is passed in by default from openssl enc tho. - Mitch
Show quote
Hide quote
"Michel Gallant" <neut***@istar.ca> wrote in message news:OyBjk41RFHA.2528@TK2MSFTNGP10.phx.gbl... Well evp.h has:> "chlock" <tay***@innovaworks.net> wrote in message news:1114136507.550811.297350@f14g2000cwb.googlegroups.com... > > OK- > > > > Here is what I've learned...by a lot of trial and error. Mitch is > > correct...Salted__ is followed by the salt value. So I can now take the > > salt, key, and iv that the command line OpenSSL returns to me for say > > the password "p"...and I can generate an identical file using those > > values and the RijndaelManaged class. > > > > Now...in theory I should be able to use the salt that OpenSSL gave me > > (they randomly generate it, I'm sure) and the same password "p" and > > generate the same key and iv using .NET code. > > > > And now we're really up against it. Although OpenSSL documentation > > states that the key and iv are generated based on the password, > > > > http://www.openssl.org/docs/crypto/EVP_BytesToKey.html (I just realized > > that Mark had posted this link already..oh well) > > > > I can't make it happed so far from C#. I've been poring over the code > > (and I ain't no C guru) all day trying to trace back and discover what > > algorithm they use to generate the key and how many iterations they > > use. There must be defaults somewhere, but I haven't found them yet. > > > > So. If I use the OpenSSL exe like this: > > > > OpenSSL> enc aes-256-cbc -salt -p -in myInFile.cfg -out myOutFile.cfg > > > > ..and I specify a password when asked...How does OpenSSL derive the > > salt (random probably), Key, and IV. The latter two come from a > > recursive hash of the password using a certain algorithm a certain > > number of times... > > > > 1. What is the algorithm? > > 2. What is the number iterations? > > > > KEY DERIVATION ALGORITHM > The key and IV is derived by concatenating D_1, D_2, etc until enough data is available for the key and IV. D_i is defined as: > > D_i = HASH^count(D_(i-1) || data || salt) > where || denotes concatentaion, D_0 is empty, HASH is the digest algorithm in use, HASH^1(data) is simply HASH(data), HASH^2(data) > is HASH(HASH(data)) and so on. > > The initial bytes are used for the key and the subsequent bytes for the IV. > > > > Not sure exactly what iteration count is passed in by default from openssl enc tho. > #define PKCS5_DEFAULT_ITER 2048 Not sure if that is what openssl enc .. uses. - Mitch Well...damn....I just typed this big old response, and lost it
somehow...must've killed the browser... To answer Rafal's question...I have to pass the password, not the key...sorry for the confusion...I wasn't so clear myself at the time of my first post. My options are: 1. Duplicate OpenSSL's key derviation function. 2. Find out if I can simply pass the 256 bit key to the device. The examples in Sipura's docs look like I can, which is what caused my confusion. They seem to be showing a 256 bit, hex encoded key in their example. Then yesterday, they emailed me and told me to give the device the pass phrase. I'd prefer to make the KDF work. Which is a bit of a misnomer, cuz the OpenSSL docs clearly state that the Key AND the IV are generated at the same time. Thanks to Mitch for pointing out the PKCS5_DEFAULT_ITER. Maybe I can find a similar value for the default hash. Well I guess to the un-initiated (like myself :-) the whole
area of PBKD and PBE is a bit confusing: There are a lot of different versions like: PKCS #5 v1.5 (supported by OpenSSL in enc and also in pkcs#8, and also in Java 2 JCE) PKCS #5 v2.0 (supported in .NET via PasswordDeriveBytes() which is PBDKF1 and ... but RFC 2898 recommends the next better version PBDKF2 !) PKCS #12 v1.2 (like Java 2 PBEWithSHA1AndDESede for protecting RSA private keys .. i guess used inside pfx encapsulations. and for EVP_BytesToKey(), it states: "If the total key and IV length is less than the digest length and MD5 is used then the derivation algorithm is compatible with PKCS#5 v1.5 otherwise a non standard extension is used to derive the extra data. " - Mitch Show quoteHide quote "chlock" <tay***@innovaworks.net> wrote in message news:1114192921.262929.303790@f14g2000cwb.googlegroups.com... > Well...damn....I just typed this big old response, and lost it > somehow...must've killed the browser... > > To answer Rafal's question...I have to pass the password, not the > key...sorry for the confusion...I wasn't so clear myself at the time of > my first post. > > My options are: > > 1. Duplicate OpenSSL's key derviation function. > 2. Find out if I can simply pass the 256 bit key to the device. The > examples in Sipura's docs look like I can, which is what caused my > confusion. They seem to be showing a 256 bit, hex encoded key in their > example. Then yesterday, they emailed me and told me to give the device > the pass phrase. > > I'd prefer to make the KDF work. Which is a bit of a misnomer, cuz the > OpenSSL docs clearly state that the Key AND the IV are generated at the > same time. > > Thanks to Mitch for pointing out the PKCS5_DEFAULT_ITER. Maybe I can > find a similar value for the default hash. > Yeah....I doubt you're as confused as I am.
The answer from Sipura is that I can not pass the key to the device. I have to pass the password, and of course the salt must be prepended to the file. So. Anybody seen a port of the PKCS5_PBE_keyivgen() function done in C#? I found it in p5_crpt.c. So far I can't nail down what hash they use. And here's another question(s): A hash always returns the same number of bits. So why would iterating generate any extra bits for the IV? If I use SHA256 and hash 1000 times, I'm still going to have 256 bits. Where do they come up with the extra bytes for the IV? And if they use MD5, how do they ever get 256 bits out of it? Man, I have a lot to learn, I'm afraid. Have a look at the Bouncy Castle C# port (in beta 2 now):
http://www.bouncycastle.org/csharp They seem to have a good complement of PBE algs. implemented, including the PKCS #5 v2.0 set. - Mitch Show quoteHide quote "chlock" <tay***@innovaworks.net> wrote in message news:1114208337.806518.29820@z14g2000cwz.googlegroups.com... > So. Anybody seen a port of the PKCS5_PBE_keyivgen() function done in > C#? I found it in p5_crpt.c. > "chlock" <tay***@innovaworks.net> wrote in message news:1114208337.806518.29820@z14g2000cwz.googlegroups.com... The key and IV is derived by concatenating D_1, D_2, etc until enough data is available for the key and IV. D_i is defined as:> Yeah....I doubt you're as confused as I am. > > > A hash always returns the same number of bits. So why would iterating > generate any extra bits for the IV? If I use SHA256 and hash 1000 > times, I'm still going to have 256 bits. Where do they come up with the > extra bytes for the IV? And if they use MD5, how do they ever get 256 > bits out of it? > D_i = HASH^count(D_(i-1) || data || salt) where || denotes concatentaion, D_0 is empty, HASH is the digest algorithm in use, HASH^1(data) is simply HASH(data), HASH^2(data) is HASH(HASH(data)) and so on. The initial bytes are used for the key and the subsequent bytes for the IV. OK I think I have figured out the problem! (or my lack of understanding).
I implemented the documented keygen algorithm described here in C#: http://www.openssl.org/docs/crypto/EVP_BytesToKey.html D_i = HASH^count(D_(i-1) || data || salt) And, for a given salt, this produces (for MD5) exactly the same key as that generated in Java by PBEWithMD5AndDES, using a test count of say 2048 (which I *thought* was the default count for PBKD hashing). The Java implemention only exposes the IV value, but that is sufficient to show the agreement. Java follows the PKCS #5 v1.5 spec. which is exatly what the multi-hashing algorithm is! However, try as I might, using: OpenSSL enc -des -p -in cleartxt.txt -out decenc.txt I could NOT get the correct key and iv for the same salt. (Since MD5 is 16 bytes and DES key and iv are both 8 bytes, no "non standard extension" is required in this case. However, looking at the openssl enc.c source code and the call to EVP_BytesToKey(), the count parameter is 1 !! Applying that to my C# implemention produces exactly the same IV and Key values as output by openssl enc ..... So, that is strange .. that openssl enc does not provide an option to change the iteration count for PBKD keys! Or did i miss something? Anyway so that is how one reproduces the openssl enc .. key and iv values for the (randomly generated) salt. Pick a single iteration count for standard PKCS #5 v1.5 PDKD. If anyone wishes to see the C# implementation, i'll post it. - Mitch Gallant MVP Security Show quoteHide quote "chlock" <tay***@innovaworks.net> wrote in message news:1114208337.806518.29820@z14g2000cwz.googlegroups.com... > Yeah....I doubt you're as confused as I am. > > The answer from Sipura is that I can not pass the key to the device. I > have to pass the password, and of course the salt must be prepended to > the file. > > So. Anybody seen a port of the PKCS5_PBE_keyivgen() function done in > C#? I found it in p5_crpt.c. > > So far I can't nail down what hash they use. And here's another > question(s): > > A hash always returns the same number of bits. So why would iterating > generate any extra bits for the IV? If I use SHA256 and hash 1000 > times, I'm still going to have 256 bits. Where do they come up with the > extra bytes for the IV? And if they use MD5, how do they ever get 256 > bits out of it? > > Man, I have a lot to learn, I'm afraid. > Also, I forgot to add that yes this also produces the exact aes key (32 bytes)
and IV (16 bytes) for your initial sample command: OpenSSL> enc -aes-256-cbc -in MyInputFile -out MyOutputFile In that case, you need to invoke the algorithm iteration 3 times to build up 48 bytes total. Here is sample output from the C# application (for hash iteration count of 1, and 3 algorithm passes: C:\.....\DeriveKeyM>DeriveKeyM test 3065AD204B46DD02 1 3 Contatenated pswd || salt 746573743065AD204B46DD02 Computing hash 1 times over 3 algorithm iterations D_1 5DC4CC9BCEFC482B7208C7A077519EB1 D_2 EE5C334761228D9F712387F331F73B9F D_3 EDE37C9B8333573CFE4ABCAEBE6F05F2 Contatenated key data: 5DC4CC9BCEFC482B7208C7A077519EB1EE5C334761228D9F712387F331F73B9FEDE37C9B8333573C FE4ABCAEBE6F05F2 AES Key is: 5DC4CC9BCEFC482B7208C7A077519EB1EE5C334761228D9F712387F331F73B9F AES IV is: EDE37C9B8333573CFE4ABCAEBE6F05F2 - Mitch Show quoteHide quote "Michel Gallant" <neut***@istar.ca> wrote in message news:%23nJ%232RHSFHA.3336@TK2MSFTNGP10.phx.gbl... > OK I think I have figured out the problem! (or my lack of understanding). > I implemented the documented keygen algorithm described here in C#: > > http://www.openssl.org/docs/crypto/EVP_BytesToKey.html > > D_i = HASH^count(D_(i-1) || data || salt) > > And, for a given salt, this produces (for MD5) exactly the same key > as that generated in Java by PBEWithMD5AndDES, using a test count > of say 2048 (which I *thought* was the default count for PBKD hashing). > > The Java implemention only exposes the IV value, but that > is sufficient to show the agreement. Java follows the PKCS #5 v1.5 > spec. which is exatly what the multi-hashing algorithm is! > > However, try as I might, using: > OpenSSL enc -des -p -in cleartxt.txt -out decenc.txt > I could NOT get the correct key and iv for the same salt. (Since MD5 > is 16 bytes and DES key and iv are both 8 bytes, no "non standard extension" > is required in this case. > > However, looking at the openssl enc.c source code and the call to EVP_BytesToKey(), > the count parameter is 1 !! > > Applying that to my C# implemention produces exactly the same > IV and Key values as output by openssl enc ..... > > So, that is strange .. that openssl enc does not provide an option to > change the iteration count for PBKD keys! Or did i miss something? > > Anyway so that is how one reproduces the openssl enc .. key and iv > values for the (randomly generated) salt. Pick a single iteration count > for standard PKCS #5 v1.5 PDKD. > > If anyone wishes to see the C# implementation, i'll post it. > > - Mitch Gallant > MVP Security > > > "chlock" <tay***@innovaworks.net> wrote in message news:1114208337.806518.29820@z14g2000cwz.googlegroups.com... > > Yeah....I doubt you're as confused as I am. > > > > The answer from Sipura is that I can not pass the key to the device. I > > have to pass the password, and of course the salt must be prepended to > > the file. > > > > So. Anybody seen a port of the PKCS5_PBE_keyivgen() function done in > > C#? I found it in p5_crpt.c. > > > > So far I can't nail down what hash they use. And here's another > > question(s): > > > > A hash always returns the same number of bits. So why would iterating > > generate any extra bits for the IV? If I use SHA256 and hash 1000 > > times, I'm still going to have 256 bits. Where do they come up with the > > extra bytes for the IV? And if they use MD5, how do they ever get 256 > > bits out of it? > > > > Man, I have a lot to learn, I'm afraid. > > > > Here is the C# sample code and description:
http://www.jensign.com/JavaScience/dotnet/DeriveKeyM - Mitch Show quoteHide quote "Michel Gallant" <neut***@istar.ca> wrote in message news:uYXl1VOSFHA.2788@TK2MSFTNGP09.phx.gbl... > Also, I forgot to add that yes this also produces the exact aes key (32 bytes) > and IV (16 bytes) for your initial sample command: > OpenSSL> enc -aes-256-cbc -in MyInputFile -out MyOutputFile > > In that case, you need to invoke the algorithm iteration 3 times to build > up 48 bytes total. Here is sample output from the C# application (for > hash iteration count of 1, and 3 algorithm passes: > > C:\.....\DeriveKeyM>DeriveKeyM test 3065AD204B46DD02 1 3 > > Contatenated pswd || salt > 746573743065AD204B46DD02 > > Computing hash 1 times over 3 algorithm iterations > > D_1 > 5DC4CC9BCEFC482B7208C7A077519EB1 > > D_2 > EE5C334761228D9F712387F331F73B9F > > D_3 > EDE37C9B8333573CFE4ABCAEBE6F05F2 > > Contatenated key data: > 5DC4CC9BCEFC482B7208C7A077519EB1EE5C334761228D9F712387F331F73B9FEDE37C9B8333573C > FE4ABCAEBE6F05F2 > > AES Key is: > 5DC4CC9BCEFC482B7208C7A077519EB1EE5C334761228D9F712387F331F73B9F > > AES IV is: > EDE37C9B8333573CFE4ABCAEBE6F05F2 > > - Mitch > > "Michel Gallant" <neut***@istar.ca> wrote in message news:%23nJ%232RHSFHA.3336@TK2MSFTNGP10.phx.gbl... > > OK I think I have figured out the problem! (or my lack of understanding). > > I implemented the documented keygen algorithm described here in C#: > > > > http://www.openssl.org/docs/crypto/EVP_BytesToKey.html > > > > D_i = HASH^count(D_(i-1) || data || salt) > > > > And, for a given salt, this produces (for MD5) exactly the same key > > as that generated in Java by PBEWithMD5AndDES, using a test count > > of say 2048 (which I *thought* was the default count for PBKD hashing). > > > > The Java implemention only exposes the IV value, but that > > is sufficient to show the agreement. Java follows the PKCS #5 v1.5 > > spec. which is exatly what the multi-hashing algorithm is! > > > > However, try as I might, using: > > OpenSSL enc -des -p -in cleartxt.txt -out decenc.txt > > I could NOT get the correct key and iv for the same salt. (Since MD5 > > is 16 bytes and DES key and iv are both 8 bytes, no "non standard extension" > > is required in this case. > > > > However, looking at the openssl enc.c source code and the call to EVP_BytesToKey(), > > the count parameter is 1 !! > > > > Applying that to my C# implemention produces exactly the same > > IV and Key values as output by openssl enc ..... > > > > So, that is strange .. that openssl enc does not provide an option to > > change the iteration count for PBKD keys! Or did i miss something? > > > > Anyway so that is how one reproduces the openssl enc .. key and iv > > values for the (randomly generated) salt. Pick a single iteration count > > for standard PKCS #5 v1.5 PDKD. > > > > If anyone wishes to see the C# implementation, i'll post it. > > > > - Mitch Gallant > > MVP Security > > > > > > "chlock" <tay***@innovaworks.net> wrote in message news:1114208337.806518.29820@z14g2000cwz.googlegroups.com... > > > Yeah....I doubt you're as confused as I am. > > > > > > The answer from Sipura is that I can not pass the key to the device. I > > > have to pass the password, and of course the salt must be prepended to > > > the file. > > > > > > So. Anybody seen a port of the PKCS5_PBE_keyivgen() function done in > > > C#? I found it in p5_crpt.c. > > > > > > So far I can't nail down what hash they use. And here's another > > > question(s): > > > > > > A hash always returns the same number of bits. So why would iterating > > > generate any extra bits for the IV? If I use SHA256 and hash 1000 > > > times, I'm still going to have 256 bits. Where do they come up with the > > > extra bytes for the IV? And if they use MD5, how do they ever get 256 > > > bits out of it? > > > > > > Man, I have a lot to learn, I'm afraid. > > > > > > > > >
Show quote
Hide quote
"chlock" <tay***@innovaworks.net> wrote in message Thanks for explaining. So, this can be hard with .Net.news:1114192921.262929.303790@f14g2000cwb.googlegroups.com... > Well...damn....I just typed this big old response, and lost it > somehow...must've killed the browser... > > To answer Rafal's question...I have to pass the password, not the > key...sorry for the confusion...I wasn't so clear myself at the time of > my first post. > > My options are: > > 1. Duplicate OpenSSL's key derviation function. > 2. Find out if I can simply pass the 256 bit key to the device. The > examples in Sipura's docs look like I can, which is what caused my > confusion. They seem to be showing a 256 bit, hex encoded key in their > example. Then yesterday, they emailed me and told me to give the device > the pass phrase. > > I'd prefer to make the KDF work. Which is a bit of a misnomer, cuz the > OpenSSL docs clearly state that the Key AND the IV are generated at the > same time. > > Thanks to Mitch for pointing out the PKCS5_DEFAULT_ITER. Maybe I can > find a similar value for the default hash. > Can't you just use the openssl instead of RijndaelManaged (for example, call the openssl.exe from .Net)? This wouldn't require reverse engineering the openssl libraries. Best Regards RG Yeah, I suppose I could. I've never been a big fan of shelling out from
my code. 
Other interesting topics
IsAuthenticated property on IIdentity interface
UIPermission Clipboard Logon user from service Using HttpContext from a web server? running dll from a network share Windows security context How do I filter an Active Directory search to an OU (organizational unit)? code level / db security over network AzMan - ADAM store. Help needed with TSL problem. |
|||||||||||||||||||||||
