-1

I have a use case where multiple parties need to generate a same ID based on trade details. However, there could be multiple trades with the same details and timestamp seem to be the only variable. The problem of timestamp is that it can only be generated by one party then shared with the other parties to consume.

Is there are way all parties could generate the same random number to use in generating the same ID based on trade details?

Some leads that I've considered - distributed/parallel random generator, nonce, google authenticator and related APIs.

Picking your brains on any means to generate a non-repeating, common yet unique number by multiple parties, preferably without going through internet (other solutions that seem to require a common network).

Update

I have a partial solution, but that is no longer stateful. Each trade party will keep a ledger keeping count of the contracts with different parties. So each time there is a trade, both sides would increment their counters of each other by 1. That number would be a representation of how many trades both parties have done, and that can be used as the unique salt. This allows both parties or multiple parties to generate the same hash with trade details and salt in different networks.

Community
  • 1
  • 1
George
  • 6,006
  • 6
  • 48
  • 68
  • Isn't this pretty much an RSA key? – Eli Sadoff Nov 12 '16 at 02:32
  • if 3 parties generate this ID with the same trade details multiple times for similar trades, the outputs should be different each time. Timestamp is the obvious nonce, but it requires a party to share this variable with the rest. I'm looking for one that all 3 can unanimously agree on. – George Nov 12 '16 at 02:34
  • Timestamp isn't necessarily nonce though. While rare, simultaneous actions can occur. I learned that the hard way treating a timestamp as nonce in a DB. – Eli Sadoff Nov 12 '16 at 02:36

1 Answers1

0

You ask: "Is there are way all parties could generate the same random number to use in generating the same ID based on trade details?"

Not strictly a random number, but a hash could be what you need. Put the required trade details into a very rigid fixed length standard format. Hash those details with a long hash, 256 bits at least or preferably 512 bits. The longer the hash the smaller the likelihood of a collision. SHA-512 is an obvious choice.

The trade details format must be very strictly defined; even a one bit difference in the input will flip around half the bits of the output. The SHA series are cryptographic hashes so they react strongly to small differences in their input.

rossum
  • 15,344
  • 1
  • 24
  • 38
  • The trade details could be exactly the same for different contracts, that's why I needed a salt or random number that both parties can generate the same. Something like tokens, except that tokens are pretty much tied to time and both parties have to generate at the same time or minute. – George Nov 13 '16 at 01:22
  • If the trade details are exactly the same, then the hashes will be exactly the same as well. Just take care that all the required details go into the hash, and no non-essential elements are included. The hash becomes your "random" number. – rossum Nov 13 '16 at 08:38