Re: OpenSSL: Determining initialization vector (IV) created using OpenSSL::Cipher::Cipher#pkcs5_keyivgen with one argument

Hi Martin,

On Sun, Jun 10, 2012 at 5:48 PM, Martin Bo煬et <
[e-mail]> wrote:

>
> salt is initialized as null, but later set in the line
>
>
>
 salt = (unsigned char *)RSTRING_PTR(vsalt);
>

> The Ruby String vsalt's value is assigned to salt there.
>
> Except I believe that is inside the if block that checks whether or not
vsalt was passed in or not:

if(!NIL_P(vsalt)){
...
}

So that wouldn't get set, I believe. I should have explained my reasoning
in the original message to be clear. Maybe that isn't what NIL_P is doing
though or that when an argument isn't passed in it gets a non NULL value?
Perhaps NIL (in Ruby/C API) and NULL (in C) are different?

I probably should have also mentioned that the actual call in
encrypted_strings gem that we indirectly call is:
cipher.pkcs5_keyivgen(password), only one argument is passed in.


> > (b) at some point I would love to learn how to debug this myself. i.e.
> setup
> > my environment to trace the C code in the Ruby MRI runtime so I can fish
> for
> > myself next time.
>
>

You may simply use gdb or if you prefer some comfort, I frequently use

Netbeans to debug
> Ruby C code.
>
> > If the salt variable is NULL then what is the IV used in this case? I
> need
> > th IV for the Scala code otherwise I cannot decrypt what the Ruby code is
> > encrypting. Also I found a highly related StackOverflow question on this
> > [2], but the solution involves not using pkcs5_keyivgen method at all and
> > setting a known random IV on the OpenSSL::Cipher::Cipher object so it
> > doesn't answer my question sadly as I am not in a position to do this
> > migration yet.
>
> You shouldn't require the actual key and IV used to do password-based
> encryption. What you would normally do on the receiving end is to go
> through the same steps as you did when encrypting the initial message,
> using the same password, salt and iterations that the encrypting party
> used. In Java, this would look something like
>
> ----- start source
>
> //These three need to be exactly the same as the ones used in Ruby
> char[] password = ...
> byte[] salt = ...
> int count = ...
>
> PBEParamterSpec params = new PBEParameterSpec(salt, count);
> PBEKeySpec keySpec = new PBEKeySpec(password);
> SecretKeyFactory keyFac = SecretKeyFactory.getInstance("PBEWithMD5AndDES");
> SecretKey key = keyFac.generateSecret(keySpec);
> Cipher cipher = Cipher.getInstance("PBEWithMD5AndDES");
> pbeCipher.init(Cipher.DECRYPT_MODE, key, params);
> //now decrypt
>
> ----- end source
>
> Figuring out what the key and iv are that were generated would sort of
> defeat the purpose of password-based encryption. Although not
> impossible, it would definitely result in a lot more work.
>
> For your migration to using PBKDF2, I just added some notes on
> how to use it yesterday [1]. I also gave an example on SO how we
> did similar upgrading of password schemes in the past [2]. It talks
> about moving from MD5 to bcrypt but applies to arbitrary algorithms.
> I hope this still helps you in the process!
>

Thanks, I will definitely use that for reference in our longer-term plans.
Great idea with the two concurrent values!

I think I figured out a workaround anyway for the short-term deliverable
that can't wait for a migration path like that in the meantime. Testing now
and will post if successful.

Thanks! :)