# Tag Info

4

I'd treat your input as one 192 bit input instead of thinking about 5 separate inputs. If you don't need security, you can always reduce the number of rounds of cryptographic primitives. If you merely need statistically random output, 20% of the usual number of rounds should be fine with many hashes. A few suggestions: SipHash has good performance for ...

3

If the plaintext format is indeed as you describe, then you're out of luck: the insertion of the newlines and the consequent shifting of the plaintext records is enough to disrupt any structure in the ciphertext. If the plaintext were longer, say, 8 records, then it could work, but with just 7 records there's no way to switch the first and last record ...

3

$ROT(n)$ can be thought of as a character based stream cipher. It works because addition - the encryption method used - is commutative, i.e. $ROT(x, ROT(y, m)) = ROT(y, ROT(x, m))$. Another well known commutative function is $XOR$. It is used by the one time pad, but - more practically - also for block ciphers in streaming mode. So you can encrypt using AES ...

1

Yes, this should be solvable and should be doable in a reasonable amount of computation time, using a pretty cool homomorphic cryptosystem. Here is one approach: the participants jointly pick a random number $y$, publicly commit to $y$, and then they all prove/check in zero knowledge that $y$ is different from their numbers. If it isn't, they go back to ...

1

It'll be the same situation that NY City suffered some days ago: when you have little variability on your data, i.e., they have a fixed-small size, it'll always be fast to brute force. You don't say how long your number is, so I'll assume it can range from 0 - 10,000,000,000 (so, a unique number for each human being on Earth today, plus some spare). You ...

Only top voted, non community-wiki answers of a minimum length are eligible