jBCrypt 0.3 C# Port (BCrypt.net)

Question

After looking into a bug in the original jBCrypt v0.1 C# port: BCrypt.net (Related Question). I decided to compare the new jBCrypt code against the old C# port to look for discrepancies and potential issues like the related question's bug.

Here is what I've found:

// original java (jBCrypt v0.3):
private static int streamtoword(byte data[], int offp[]) {
        int i;
        int word = 0;
        int off = offp[0];

        for (i = 0; i < 4; i++) {
            word = (word << 8) | (data[off] & 0xff);
            off = (off + 1) % data.length;
        }

        offp[0] = off;
        return word;
}


// port to C# :
private static uint StreamToWord(byte[] data, ref int offset)
{

    uint word = 0;

    for (int i = 0; i < 4; i++)
    {
        // note the difference with the omission of "& 0xff"
        word = (word << 8) | data[offset];
        offset = (offset + 1) % data.Length;
    }

    return word;
}

if the prior is incorrect would the following fix it?

private static uint StreamToWord(byte[] data, ref int[] offsetp)
{

    uint word = 0;
    int offset = offsetp[0];
    for (int i = 0; i < 4; i++)
    {
        word = (word << 8) | (uint)(data[offset] & 0xff);
        offset = (offset + 1) % data.Length;
    }

    offsetp[0] = offset;

    return word;
}

Dizen

Incidentally, the "31 log-rounds integer overflow" bug also exists in jBCrypt (thanks to your post, I filed a bug report with jBCrypt's maintainer). So, doing a comparison between the two wouldn't have located that issue. :-) – Amick

Answer 1

The & 0xff is required in the Java version because in Java, bytes are signed. (Some argue that this is a bug.)

In C#, bytes are unsigned, so the & 0xff is unnecessary.

Amick

Thanks. :o) You wouldn't happen to know what was updated to fix this security issue (mindrot.org/files/jBCrypt/internat.adv), would you? I'd like to up the C# ported version. – Dizen

Yes, it was fixed to use UTF-8 instead of US-ASCII to convert the chars in the passphrase to bytes. In Java, if a character can't be encoded, it is replaced with ?, rather than throwing an exception. – Amick

@David: Thankfully it seems BCrypt.NET already does the Right Thing in that department, so you have no worries. :-D – Amick

muchos gracias, sir. I can now sleep soundly. :o) – Dizen