encryption/decryption

[jonathanong]

i have an initial implementation here: 427f188

Some notes/questions/etc.

• Should we using initialization vectors? not sure how much security that adds. maybe make it optional.
• want to change .cipher = to something else so we can do .cipher(message) and .decipher(message). .hash_algorithm= and .cipher_algorithm=?

without any feedback i'm going to just chug along

/cc @expressjs/owners

[dougwilson]

Should we using initialization vectors?

node.js will derive the IV from the password, but it's not as secure. You should have both sides handshake to exchange an IV to use, but I don't think this is feasible with cookies, so it probably just has to be left out.

Basically if you leave it out, the same cleartext always encrypts to the same ciphertext. But of course if you let the user set it and it just stays the same, that doesn't do anything, because the cleartext will still be the same for the same ciphertext.

[defunctzombie]

Nonces in the cookie can help mix up the cyphertext.
On May 17, 2014 7:13 PM, "Douglas Christopher Wilson" <
notifications@github.com> wrote:

Should we using initialization vectors?

node.js will derive the IV from the password, but it's not as secure. You
should have both sides handshake to exchange an IV to use, but I don't
think this is feasible with cookies, so it probably just has to be left out.

Basically if you leave it out, the same cleartext always encrypts to the
same ciphertext. But of course if you let the user set it and it just stays
the same, that doesn't do anything, because the cleartext will still be the
same for the same ciphertext.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/14#issuecomment-43426755
.

[dougwilson]

Nonces in the cookie can help mix up the cyphertext.

Make sure the nonce is at the start of the cleartext if you do this, since changes cascade from start to end :)

[jonathanong]

okay updated it with optional iv support. let me know what you guys think before i release 2.0.0

@dougwilson your code coverage magic would be appreciated :)

[Fishrock123]

What's the reasoning behind removing the encoding option? Just wondering, not sure if it actually mattered now.

[dougwilson]

@dougwilson your code coverage magic would be appreciated :)

Sure, can do :)

[dougwilson]

What's the reasoning behind removing the encoding option?

The output from this should be opaque to the user; allowing them to say if they want it in hex or base64 is weird; they should just treat it as an opaque string i.m.o.

[Fishrock123]

Fair enough.

[dougwilson]

Actually, @Fishrock123 re-looking at the new docs, it looks like we're just returning Buffer objects directly, which would be the real reason the encoding was removed, haha, since it's no longer stringifying the Buffers.

[jonathanong]

yeah trying to make this a more generic crypto library. also, encoding is a hassle when you've got a bunch of other stuff to deal with.

[dougwilson]

@jonathanong I have some questions about this library's interface when you have some time; specifically regarding encodings.

[emilbayes]

What is holding this back?