List Tim Tiemens' implementation in readme

[jaromil]

Hi there,

You are missing Tim Tiemens implementation in Java https://github.com/timtiemens/secretshare

Also maybe relevant this end-user application I've made https://secrets.dyne.org which can split any plain-text material into secret shares using FastPFOR128 integer compression. I would love to find a C implementation compatible with the output of my software, which is written in Clojure and runs on Tim's Java library.

[dsprenkels]

Hey @jaromil,

I can add Tim Tiemen's implementation which whould be listed as:

Side channels: insecure (uses Java BigInteger class)
Tamper-resistant: insecure
Secret length: 512 bytes

Note it feels a bit unfair to list the implementation as insecure against tampering, because the readme file advises the user to encrypt the secret first. What'd you think?

About https://secrets.dyne.org: I like like the idea of having this, but not as a part of this library. One of the main goals of this sss library is to be fully side channel resistant. It is very hard (although not completely impossible) to implement this using reducing polynomials (e.g. primes) that are not given at constant time. If we implement this, we should probably "Implement all the libraries!". :smile:

I am thinking about a tool/manual/index with "all" implementations together. For me this is unfortunately something for another time (far away).

[jaromil]

OK, some remarks:

I am a bit confused by your definition of "side channels" and "tamper resistant", they are a bit generic and your documentation may benefit from a brief explanation and some references on what you mean.

I don't really know how the Java BitInteger class is insecure with regard to side channel attacks, but then I'm definitely not a Java nor JVM expert.

As of my personal preference, also evident in the Secrets implementation, I prefer to keep encryption and integrity checks separate to the actual secret split, for interoperability with any program one may want to use for that. In that I agree with Tim's approach.

As of secrets, it is certainly not a "secret sharing" implementation, but a functional application using both secret sharing, integer compression and a protocol called FXC to marshall everything into strings that are easy to communicate and write down.

If you succeed in your quest I'd give it a try (but yea, wishful thinking, time is a tyrant..) to port FXC to what would be an incompatible C implementation based on sss and some integer compression library that I haven't looked up yet. In any case I hope FXC provides some useful inspiration on what to do on top of a good secret-sharing implementation (perhaps better than Tim's, yet I'm pretty ok with that).

OT but FYI: I'll try to include your good work as a crypto primitive into this software I recently started writing https://github.com/decodeproject/zenroom its for an EU project where your university and my organisation are already partnering. Perhaps we'll have some opportunities to cross paths in the future? :^) ciao

[dsprenkels]

I am a bit confused by your definition of "side channels" and "tamper resistant", they are a bit generic and your documentation may benefit from a brief explanation and some references on what you mean.

So "side channels" refers to whether the implementation was implemented in a side channel resistant fashion. For example, to be resistant against timing attacks, you are not allowed to branch on secret data or do lookups dependent on secret data. I can maybe refer to Wikipedia. In Tim Tiemens' implementation BigInteger is used. As an example, deep in the implementation of OpenJDK, we see that there are a lot of if-statements (on secret data) in the implementation of div.

"Tamper resistant" refers to the fact that in "normal" Shamir secret sharing implementations, it may be possible for a bad guy to forge a different secret than the one that was initially shared. Crypto users tend to forget that encryption does not imply integrity, so that's why I chose to include it in this library.

I am thinking about leaving the "Tamper resistance" field empty with a note (because the readme mentions it).

In any case I hope FXC provides some useful inspiration on what to do on top of a good secret-sharing implementation (perhaps better than Tim's, yet I'm pretty ok with that).

Yeah it does. But I kinda hope that somebody else has the time to build the better tooling to do this. I am mostly just a humble crypto implementer. :P

Awesome to hear that you plan to include the sss library in your project. If you need anything specifically don't hesitate to ask me. Incidentally I am not directly affiliated with the PI.lab people, but I do know some of them informally. Anyway, drop me an email if you're ever in town and like to drink a cup of coffee. Good luck with your project. :)

[dsprenkels]

For good measure, I put the question on how to forge a share on StackExchange. I got some pretty good answers:

https://crypto.stackexchange.com/q/54578/45787

[jaromil]

OK, I see, its the case in which the attacker should know the secret, then can forge shares to change it. I'll address this in FXC.