stronger length validations

[brancz]

right now most attributes of database entities can be used to pollute the database

[brancz]

most of this is done with 1455615 however it is still possible to create unlimited parts and the length of shares is also unchecked

[brancz]

Secret lengths can be estimated since an encrypted share is always the size of its key bits in bytes - 11 bytes of minimum pkcs15 padding. So the share resulting from shamir's secret sharing can be maximum of 117 bytes (for a 1024 bit key). From here on we assume at least a 1024 bit size key pair.

Since a share looks like x-hex(y) the hex(y) part can be 117-1-(floor(log10(x))+1) long, which is 115 at maximum. Any hex value can be (16^n)-1 large at most. So in this case it is (16^115)-1.

After some experiments it seems that a length of 18 bytes per secret part is feasible, since its right at the jump of the mersenne primes 2^127 and (2^521)-1. So the maximum length of a secret is approximately the amount of parts * 18 in bytes after converting from UTF-8 to Base64.

We're going to use a 4096 bit private key as a benchmark for sizes. A 4096 bit rsa key is approximately 3250 characters long in UTF-8. In Base64 it is around 4400 characters. So as a general upper bound for now, we are going to use 5000 characters upper limit of a single secret. 5000/18 = 277 So we are going to limit a secret to a maximum of 277 secret parts, which in turn can each be around 18 bytes. 277 is the result of an integer division, so the actual amount of characters would be 18 * 277 = 4986, so we are actually using 278 parts which allows us to have 5004 characters.

[brancz]

starting with d7aebbab almost everything is limited to some value