amper5and / secrets.js Goto Github PK

When saving the .htm file from https://chuyskywalker.github.io/secrets-in-case-of-death/ and using it on a local machine without internet access, the generated secret files do not contain entry boxes for the keys, just one, big, blank text box.

From the console, newShare() throws the following error:

secrets.newShare(33, "<secret share>", "<secret share>")
Error: Invalid share : Share id must be an integer between 1 and 255, inclusive.

Site temporarily disabled

This page has been temporarily disabled due to a misconfigured custom domain.

Alternatively, http://amper5and.github.io/secrets.js/

The issue looks to be with the prefixing, which always appends an "8" (https://github.com/amper5and/secrets.js/blob/master/secrets.js#L246)

From what I can see, the following lines aren't quite right:

for(var i=0; i<numShares; i++){
    x[i] = config.bits.toString(36).toUpperCase() + padLeft(x[i],padding) + bin2hex(y[i]);
}

1. Why are we using base 36? For a larger number than 8, (ie, 200), there's no way that this will generate a valid hexadecimal value... ((200).toString(36) == '5k')

2. Assuming we meant this to be 16 instead of 36 (which makes much more sense), it still can result in an odd-length string, which is 👎 ((8).toString(16) == '8')

   • To illustrate why this is a bad time, here's a traceback:

   > new Buffer((8).toString(16), 'hex');
   TypeError: Invalid hex string
   at TypeError (native)
   at Buffer.write (buffer.js:568:21)
   at fromString (buffer.js:115:26)
   at new Buffer (buffer.js:54:12)
   at repl:1:1
   at REPLServer.defaultEval (repl.js:248:27)
   at bound (domain.js:287:14)
   at REPLServer.runBound [as eval] (domain.js:300:12)
   at REPLServer.<anonymous> (repl.js:412:12)
   at emitOne (events.js:82:20)

I think we should do what you did a bit later in the line with padLeft:

for(var i = 0; i < numShares; i++) {
    // x[i] is (even-length number of bits, any padding requested, and then the secret share)
    var prefix = padLeft(config.bits.toString(16).toUpperCase(), 2),
        padding = padLeft(x[i], padding);
    x[i] = prefix + padding + bin2hex(y[i]);
}

The question then becomes, what corresponding changes do we need for the combining portion of code...?

I think we would need to update the processShare method to make this work (https://github.com/amper5and/secrets.js/blob/master/secrets.js#L301)

(the lines affected are var bits = ... and var id = ...)

function processShare(share){
    var bits = parseInt(share.substring(0, 2), 16);
    if(bits && (typeof bits !== 'number' || bits%1 !== 0 || bits<defaults.minBits || bits>defaults.maxBits)){
        throw new Error('Number of bits must be an integer between ' + defaults.minBits + ' and ' + defaults.maxBits + ', inclusive.')
    }

    var max = Math.pow(2, bits) - 1;
    var idLength = max.toString(config.radix).length;

    var id = parseInt(share.substr(2, idLength), config.radix);
    if(typeof id !== 'number' || id%1 !== 0 || id<1 || id>max){
        throw new Error('Share id must be an integer between 1 and ' + config.max + ', inclusive.');
    }
    share = share.substr(idLength + 1);
    if(!share.length){
        throw new Error('Invalid share: zero-length share.')
    }
    return {
        'bits': bits,
        'id': id,
        'value': share
    };
};

Would it be possible to add a base58 encode/decode option?

Here's an implementation of the algorithm.
https://gist.github.com/inflammable/2929362

I'm trying to use PassGuardian to split a bitcoin wallet key, and I'd like the resulting output to be as short as possible. Right now I could still do this myself, taking the base58 key, decoding it to a number, splitting it with the secrets lib, and then base58 encoding the pieces.

However I'd like someone less computer savvy than myself to be able to reassemble the key if I'm not around.

I'll put up a $20 bounty (in bitcoins). I know that is probably not enough to cover the effort but maybe others will contribute.

the release is from 2013 and the GLOBAL fix is not on npmjs

The UI lets one split a secret into 3 shares with a threshold of 4. Even if the user should not happen, this is problematic as even if the user keeps all the shares they may lose the original data.

For example, asking for 3 shares with a threshold of 4 for the string "This is a test" yielded

8013171e9f3439af6dd2875d1c5b8a7f278c9de4b27fc0be977f59dbeadf0
80270671046eab48a3ff8190988d7242964cf2450c9c849d40b26b6446636
8036ae31f18f5afa8f5bcd903ed599f0ca79c9d3de9af5a1d0d035e9e279d

but decoded it as "畤燐ᠠޛ朦뮚᳗ꀶ뗛ᝬ臔굜�".

Since there is a non-negligible risk of data loss due to an operator error, the UI should refuse to encode the data if the threshold is greater than the number of shares.

This looks like it's just using a radix-16 RS code?

If so, then I don't think it's information theoretically secure. Classic SSS fixes the whole message in a single field element.

I think just doing an RS code over bytes/shorts results in sub-threshold shares leaking data about linear relationships between different words in the secret.

Do you have a citation for the approach that you're using?