SLIP-0039- How to properly split up the bits of a secret share about slips HOT 10 CLOSED

here is my C++ implementation. This is a first version. The code needs to be cleaned and improved, debugged, linked to a better (pseudo)random generator. All this will be done in the future.
https://github.com/jakubtrnka/ShamirsSecretSharingScheme

from slips.

My understanding of the problem is that translating 'data-bits' into field element bits is done in little-endian manner. I. e. data- or, say secret message, bits go in this way: d₀, d₁, d₂...d₇ whereas field elements bits in each octet are represented as f₇, f₆, f₅... , f₀
This is not about parsing message itself, but about implementing field arithmetic IMO.

from slips.

I guess I'm still confused, because the solution I discovered for how to do the secret sharing is to use GF 256 and essentially do the GF math on each byte in the secret when creating and then recovering.

Also when reviewing BIP0039 and how it splits up the data into 11 bits it followed the same pattern as the "MSB" example I listed above, so that's what I used in my code for this SLIP.

from slips.

@onvej-sl can you have a look?

from slips.

As jakubtrnka suggested, "little-endian fashion" refers to the way a byte is translated to a field element.

More formally: A byte is represented as a 8-tuple of bits. An element of GF(128) is represented as a polynomial over F(2) of degree at most 7. The mapping between bytes and field elements is as follows: A byte represented by

(b_1, b_2, b_3, b_4, b_5, b_6, b_7, b_8)

is mapped to the field element represented by

b_1*x^7 + b_2*x^6 + b_3*x^5 + b_4*x^4 + b_5*x^3 + b_6*x^2 + b_7*x^1 + b_8.

"Splitting up" is something completely different. It's applied to a bit array, which length even doesn't have to be a multiple of 8. And it's done in a "natural way". For example

1100000000111111

is split up to

1100000000 111111.

I see we should specify, whether the last chunk is padded by zeros (or something else) from the left or from the right. In other words, whether 111111 is interpreted as 11111100 (252) or 00111111 (63).

from slips.

I'm currently building C++ implementation. It will be ready for review in few days.

from slips.

We did some substantial improvements to our standard and we feel it's moving into right direction. Feel free to comment: https://github.com/satoshilabs/slips/blob/master/slip-0039.md

from slips.

@prusnak I'd be happy to implement it. Any suggestion how to do it to make it Trezor-friendly? I guess doing it in C++ is not much usefull for most people.

from slips.

We'll write the implementation for Python (both for python-trezor and trezor-core) first. Implementation in C (for trezor-mcu/trezor-crypto) might come later.

from slips.

I have only just learned of SLIP-0039. I spent the weekend writing my own implementation of SSSS in a trezor-T emulator. I kind of independently arrived at many of the features suggested in SLIP-0039, but I did not add any additional error correction over what is already happening with BIP39.

You can find my working prototype (I can deal and collect shares from an emulator) in the 'ssss' branch of https://github.com/howech/trezor-core.git, along with the 'allow_15_21_mnemonic_length' branch of https://github.com/howech/trezor-crypto.git

from slips.