Salsa20 and SHA3 support

[stbuehler]

Hi,

I started to code some basic Salsa20 and SHA3/Keccak stuff (https://github.com/stbuehler/sjcl/tree/feature-salsa20-and-sha3), and wanted to know whether there is any interest in having it upstream.

The SHA3 hash functions are already working, I still have to test the Salsa20 stuff.

Test cases are missing too ofc :)

[Nilos]

I am not sure about adding sha3 just yet because the standardization has not been done and as far as I know it is still in discussion. Anyhow I would be definitly interested in adding it as soon as all discussion and standardization has been done.

Regarding Salsa20 I am not sure. I like to add new opportunities to the library but on the other hand I do not see any advantage in adding Salsa20 as I do not see a special usecase for it and how it would advance sjcl. So if you give me a good reason why to include Salsa20, I might include it, otherwise I would most likely want to exclude it to not bloat the library (mainly for maintainability, I do not fear actual code size because the main compile-build will likely stay the same for a long time)

[bitwiseshiftleft]

Keep in mind that Salsa20 is very fast with vector instructions, but it’s considerably less impressive in Javascript. I tested Salsa20/12 back during SJCL’s design phase, and it was comparable in speed to AES.

On Nov 29, 2013, at 10:19 AM, Nilos notifications@github.com wrote:

I am not sure about adding sha3 just yet because the standardization has not been done and as far as I know it is still in discussion. Anyhow I would be definitly interested in adding it as soon as all discussion and standardization has been done.

Regarding Salsa20 I am not sure. I like to add new opportunities to the library but on the other hand I do not see any advantage in adding Salsa20 as I do not see a special usecase for it and how it would advance sjcl. So if you give me a good reason why to include Salsa20, I might include it, otherwise I would most likely want to exclude it to not bloat the library (mainly for maintainability, I do not fear actual code size because the main compile-build will likely stay the same for a long time)

— Reply to this email directly or view it on GitHub.

[alax]

@Nilos Salsa20 would allow the project to also work towards NaCl compatibility, only needing the addition of Curve25519 and Poly1305 to get to a workable state. There are a few NaCl javascript libraries available already, but none with the quality of SJCL (yet).

[stbuehler]

I already modified the sha3.js to not export sha3_* functions yet, and instead export them as keccak_*. It should be easy then to export the sha3_* functions as soon as the parameters are selected, and keep the original proposed parameters as keccak_*. As Keccak needs little endian input I also added a sjcl.bitArrayLE namespace to handle that part.

I'm not sure what your goal is regarding features; I think having only one cipher is a bad thing, if it breaks you have no alternatives. I think Salsa20 is one of the alternatives that is worth supporting.

As @alax said it'd be nice for NaCL compat, and I'm trying to implement triplesec.

[stbuehler]

My branch now should include test cases for all major variants (Keccak different widths and capacities, Salsa20/8+12+20 128/256 bit keys, XSalsa20).

@bitwiseshiftleft I just did some benchmarks in chromium (using uglifyjs to minify the sources), and Salsa20/12 is about 40% faster than AES-CBC (both with 256-bit key). Salsa20 ("/20") is comparable, but was still faster than AES-CBC.

Only one run, and one can see that even in nodejs running AES-CBC twice gives very different results, so this benchmark could probably be done better :)

• Chromium, Salsa20:

  AES-CBC: 4817ms Salsa20: 4463ms

• Chromium, Salsa20/12:

  AES-CBC: 4714ms Salsa20: 2954ms

• nodejs (closure compressed with makefile), Salsa20:

  AES-CBC: 6267ms Salsa20: 5029ms

• nodejs, Salsa20/12:

  AES-CBC: 6699ms Salsa20: 3402ms

//var sjcl = require('./sjcl');
//sjcl.beware["CBC mode is dangerous because it doesn't protect message integrity."]();

function benchmark_salsa20(random, msg) {
    var key = random.slice(0, 8);
    var nonce = random.slice(8, 10);
    var s = new sjcl.cipher.salsa20(key, nonce); // , 12 for Salsa20/12
    s.crypt(msg);
}

function benchmark_aes_cbc(random, msg) {
    var key = random.slice(0, 8);
    var iv = random.slice(8, 12);
    var aes = new sjcl.cipher.aes(key);
    sjcl.mode.cbc.encrypt(aes, msg, iv, []);
}

function do_benchmark(random, msg, methods) {
    for (var k in methods) {
        if (!methods.hasOwnProperty(k)) continue;
        var f = methods[k];
        var start = new Date();
        f(random, msg);
        var end = new Date();
        console.log(k + ": " + (end - start) + "ms");
    }
}

function bench(length) {
    length = length || 1024*1024;
    var methods = {
        "AES-CBC": benchmark_aes_cbc,
        "Salsa20": benchmark_salsa20
    };
    var msg = [];
    for (var i = 0; i < length/4; ++i) msg.push(0);
    var random = sjcl.random.randomWords(64, 0);
    do_benchmark(random, msg, methods);
}
bench(128*1024*1024);

[stbuehler]

See #144 for (X)Salsa20 and Chacha, and #173 for Keccak/SHA3.