0
$\begingroup$

I'm implementing crypto in Node, following this article: https://lollyrock.com/articles/nodejs-encryption/

It defines:

var crypto = require('crypto');
var algorithm = 'aes-256-ctr';
var password = 'd6F3Efeq'; // AKA passphrase

Then, it uses the password/passphrase for encrypt and decrypt the strings. Now, here my question: Is the password length going to change the encrypt/decrypt velocity?

For example: is the password/passphrase d6F3Efeq going to take less time to encrypt/decrypt than d6F3Efeqd6F3Efeqd6F3Efeqd6F3Efeq?

Edit: This is the way that the password/passphrase is used:

function encrypt(text){
  var cipher = crypto.createCipher(algorithm,password)
  var crypted = cipher.update(text,'utf8','hex')
  crypted += cipher.final('hex');
  return crypted;
}

function decrypt(text){
  var decipher = crypto.createDecipher(algorithm,password)
  var dec = decipher.update(text,'hex','utf8')
  dec += decipher.final('utf8');
  return dec;
}

PS.: I know that using createCipher is a bad idea and I should use other non-deprecated functions (like http://www.levigross.com/2014/03/30/how-to-write-an-encrypt-and-decrypt-api-for-data-at-rest-in-nodejs/), but I'm not asking about which crypto algorithm is better. I'm asking only about velocity/performance.

$\endgroup$
  • $\begingroup$ It should be noted that this is not the right way to do password-based encryption $\endgroup$ – Ella Rose Oct 25 '18 at 20:07
  • $\begingroup$ And that is the problem: A pass word/phrase (in the real world) is not uniformly random, like a cryptographic key is supposed to be. A passphrase may be truncated by the implementation (as the algorithm key has a max usable size), reducing the entropy of it. The correct way to do password-based encryption is to process the password with a key derivation algorithm to produce key(s). $\endgroup$ – Ella Rose Oct 25 '18 at 20:29
  • 2
    $\begingroup$ @EllaRose & all It uses a PBKDF. Unfortunately it is : "OpenSSL function EVP_BytesToKey with the digest algorithm set to MD5, one iteration, and no salt" and the function has been deprecated because of that. Broda, at least check the crypto functions before you use them! $\endgroup$ – Maarten - reinstate Monica Oct 25 '18 at 20:59
  • $\begingroup$ @EllaRose as I told you, I'm not encrypting any password. I guess we missed up "password" with "passphrase" $\endgroup$ – Broda Noel Oct 26 '18 at 14:09
  • 1
    $\begingroup$ @BrodaNoel There is no real distinction between "password" and "pass phrase", other than the latter typically consisting of groups of dictionary words (which are easier to remember) rather than an obscure collection of symbols (which is hard to remember). E.g. d6F3Efeq is a password, while correct horse battery staple is a pass phrase. Neither of the two should be mixed with the concept of a "key", which is what the algorithm actually uses. d6F3Efeq is not a key: an AES key is at least 128 bits, which is 16 bytes. I agree that we should conclude the discussion. $\endgroup$ – Ella Rose Oct 26 '18 at 15:35
5
$\begingroup$

No, password length does not perceptibly change encryption throughput. That's valid for overwhelmingly most password-based encryption schemes using AES-256, especially the secure ones.

More precisely,

  • The time it will take to encipher an extra kilobyte of data is fully independent of the password length. That's because the password is first transformed into a 256-bit key, and then this key is used for encryption/decryption/authentication, and the throughput of that later step does not depend at all on the value of the AES key (that would be a weakness of the AES implementation).
  • Even the time it takes to encipher/decipher/authenticate the first kilobyte does not perceptibly depend on the password length, for reasonable size thereof (say, up to 55-byte password, often much more). That's because the code that transforms the password into key falls into one of two categories:
    • Slow: for these, up to said limit at least, execution time depends almost only on parameters adjusted to slow things in order to make password search suitably difficult.
    • Fast, thus of negligible cost w.r.t. the rest. CAUTION: these are extremely vulnerable to password search.

Note: 55 bytes is a limit above which some common hash algorithms (SHA-256..) see their computation time abruptly increase, because they process their input data split into 64-byte blocks, and there's an overhead of 9 bytes.

Note: this answer is independent of the nodejs context. The linked page gives zero clue about how the password is changed to key, and this site is not about language-specific questions.

$\endgroup$
  • 3
    $\begingroup$ The NodeJS page itself does. It uses the bad, fast option. $\endgroup$ – Maarten - reinstate Monica Oct 25 '18 at 21:00
  • 2
    $\begingroup$ @MaartenBodewes: indeed. This means the page linked by the question gives disastrous sample code from a security standpoint! The doc you linked plain acknowledges that crypto.createCipher has disastrous specifications, and can only be scavenged by replacing password with the result of an external sound password-to-key derivation function. Problem is, it also invites to use crypto.createCipheriv, and I see no similar warnings there, when something tells me that the situation is no better. Oh my.. $\endgroup$ – fgrieu Oct 25 '18 at 21:48
  • $\begingroup$ On the bright side: it does supply PBKDF2 and scrypt. So if you want to derive a secure key using the Slow option then you should be able to do so. $\endgroup$ – Maarten - reinstate Monica Oct 25 '18 at 22:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.