Question on iron encryption salt

[Jan Algermissen]

Hi all,

I'm working on porting iron to other languages and I am unsure regarding salt-representation compatibility between the string data types of the languages. If someone could help reduce my lack of JS-knowledge that would be great:

The salt generation in iron is done like this:

From https://github.com/hueniverse/iron/blob/master/lib/index.js

  // ...

encryption: {
        saltBits: 256,
        algorithm: 'aes-256-cbc',
        iterations: 1
    },
// ...

var generateSalt = function () {
        var randomSalt = Cryptiles.randomBits(options.saltBits);
       // ...
        var salt = randomSalt.toString('hex');
        return generateKey(salt);
    };

Cryptiles returns a Buffer of size saltBits / 8 , that is 32bytes. The call to toString('hex') will AFAIU turn every byte to two characters (e.g. 'F0'), leading to a string of 64 characters.

This salt is later on passed to the call to Crypto.pbkdf2():

Crypto.pbkdf2(password, salt, options.iterations, algorithm.keyBits / 8, function (err, derivedKey) {

Now, to port iron, I need to make sure, that the equivalent to Crypto.pbkdf2 in e.g. Java will produce the same key given the 64 chars long string. And I assume this depends on the conversion that happens inside Crypto.pbkdf2 when the salt string is passed to it.

Part of my confusion is I guess due to my understanding that the salt is actually 64bytes 'on the wire' (in the token) although a 32byte salt has been 'request'.

Can anyone help clean this up in my head?

Jan

[Eran Hammer]

Salt size (and other random strings) is based on entropy, not absolute string size. It also does not have to produce the same string since we just need a salt buffer that we can feed back into the crypto algorithms. The main concern is that the salt has enough entropy.

 

EH

--
You received this message because you are subscribed to the Google Groups "oz-protocol" group.
To unsubscribe from this group and stop receiving emails from it, send an email to oz-protocol...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jan Algermissen]

On Thursday, April 25, 2013 5:22:16 PM UTC+2, Eran Hammer wrote:

Salt size (and other random strings) is based on entropy, not absolute string size. It also does not have to produce the same string since we just need a salt buffer that we can feed back into the crypto algorithms. The main concern is that the salt has enough entropy.

Hmm, sorry. I just can't figure it out myself - maybe it's obvious, but you seem to be saying that given a salt string in node.js code like 'A0B1...' and calling

  derivedKey = Crypto.pbkdf2(password, salt, ....)

and using that derivedKey to encrypt

I can use that salt string(!) in a Java or C code to derive a key with PBKDF2 and successfully decrypt *without* being concerned about how the 'A0B1...' string(!) is interpreted (byte-wise) by the Java or C crypto function?

If I understand the node.js Buffer (assuming this is what Crypto uses internally) docs correctly, the default interpretation when turning String to Buffer is UTF-8. This is not necessarily the same in a Java or C crypto lib. And if they take byte arrays as input, I have to make the choice myself. So *must* I use UTF-8 or are you saying it does not matter, as long as the salt entropy remains sufficient?

Maybe (likely) I am just lacking knowledge, but it appears odd to pass the salt around when it does not matter for the subsequent decryption whether PBKDF2 actually is fed the same byte sequence.

Jan