2

I have a program (whereby people can download and run on their own computers) that will calculate a couple of unknown values each day. For simplicity sake, let's assume that the calculation is simply Rand(0, 1). The program will run and the user will get a value e.g. 0.230957203975.

He will then broadcast this value to anyone interested. He will say "my number today is 0.230957203975!". The problem is that the user can simply lie about the number.

How can we make it such that the user cannot lie? Or rather, how we can detect it if he lies?

I've came up with a solution, but it's sub-par and will be easily defeated. My solution is to broadcast the value 0.230957203975 along with a verification-value calculated as such:

verification_value = SHA2(MD5(RIPEMD(SHA2(HAVAL(GOST(MD5(0.230957203975)))))))

The problem is that the user can examine the machine code, and know the obscure mixture of hash functions used, enabling him to calculate the verification-value himself and lie about the number he had gotten.

I've browsed through Applied Cryptography, but none of the protocols mentioned there seems to have a solution. Is cryptography able to solve this problem?

Pacerier
  • 1,255
  • 2
  • 10
  • 16
  • Is verification-value known beforehand? If so, you can sign it with your private key. (Then everyone who has your public key can verify its correctness.) – Reid Jan 18 '14 at 03:17
  • @Reid,We can set the program up such that verification-value is known beforehand, However each user will be calculating many values and all of them needs to be verified. How could the verification-values be known beforehand when the value is still not known? – Pacerier Jan 18 '14 at 07:02
  • 1
    In 2, there is the problem that anyone (with your public key) can compute the verification_value accrediting a fake, and even you can not detect that. – fgrieu Jan 18 '14 at 09:23
  • Can you assume that a key embedded in the software remains secret? If yes, the simplest solution to your problem seems to be a MAC, such HMAC with SHA-256, used to generate verification_value as HMAC(key,0.230957203975), and re-generated from the alleged 0.230957203975for verification purposes. – fgrieu Jan 18 '14 at 09:57
  • 1
    @fgrieu, Since people can download and run the software, the key could definitely be extracted and leaked. Especially so since everyone's copy of the software is going to be using the same key for hashing/verifying right? – Pacerier Jan 18 '14 at 15:27
  • @Pacerier I think it would be helpful if you could edit your question and describe a bit more in detail what the values really are/what your application is really about (since your simple example, i.e., simply choosing a random number, in your setting does not seem to have a solution, since what you require is users to deliver a "proof" of honest computation of this value). Verifiable Computing or VRFs comes to my mind. – DrLecter Jan 18 '14 at 15:42
  • @Pacerier: if you can't assume a secret key in your software generating the message that is to be integrity-protected, then a MAC is not a solution, and I have worse news: there is not anything any cryptographic algorithm alone can do for you. You need to turn around the problem: perhaps find a way to keep a key secret (Smart Card ICs, or substitutes like OS-managed security); or modify the meaning of generating the message so that it becomes revealing an inherently verifiable message. – fgrieu Jan 18 '14 at 23:48
  • @DrLecter, it's a program to help people trade more effectively by reducing much of the manual work involved. Basically, it works like an alternative GUI for a trading site. One of the features I'm trying to implement is to keep the "history" of trades. For example, we assume the user bought 30 stuff at £100​ and sold them at £130 via my trading interface. Then, the interface would record this down in a history page. The user can share his history with anyone he wishes, but I'm trying to make it such that the results are verifiable (he cannot lie that he sold at £120 when he sold at £130) – Pacerier Jan 19 '14 at 03:02
  • @fgrieu, as my above comment to DrLecter, how could we modify the meaning of generating the message so that it becomes revealing an inherently verifiable message? – Pacerier Jan 19 '14 at 03:03
  • @Pacerier: Since the messages to protect inherently reflect the evolving will of a human, they can't be predetermined then revealed. Looks like you'll need other techniques: central clearing server, hierarchical PKI, or distributed trust based on individual private/public key pairs, to name some of the main families of applicable techniques; some of these might benefit from trusted hardware (Smart Cards). – fgrieu Jan 19 '14 at 07:04
  • @Pacerier as fgrieu says, the process to produce the message (trade decision) is basically a human decision and this process cannot be verified by such simple means. A human can always lie about the decision made. I do not think that it will be possible, but you would have to check by some means that the values the user has committed to for the history page are consistent with what the user has done on the trading site. Is there anything you could use from the trading site, e.g., they sign a confirmation what the user actually has traded? – DrLecter Jan 19 '14 at 10:28
  • @DrLecter, Yes it is based on human decision, but when my program record that decision, I want that record to be verifiable. So the user can lie and show us an altered record, but then we must be able to identify that it's fake. For example, he can say time=349058,amt=10,buy=100,sell=130,proof=GOI3098572GLIASD and we can tell whether it's real or fake. The trading site has APIs for me to do trades only, my program will record the trades done when they are done via my program. – Pacerier Jan 19 '14 at 16:19
  • @Pacerier if your program calls the API of the trade site to do the trades, then your program could call the API of the trade site to do the trade and if the trade is successful then your program could sign/request to sign then values (time=349058,amt=10,buy=100,sell=130) for the user. For instance, you could run/use a timestamping server to sign (time=349058,amt=10,buy=100,sell=130) or require your program to sign the values. Now it depends on the capabilities of an adversarial user which solution would be appropriate. – DrLecter Jan 19 '14 at 19:45
  • Sounds like a standard unsolvable DRM problem. Only thing you can do is throwing obfuscation at it and praying. – CodesInChaos Jan 21 '14 at 12:16

2 Answers2

2

From my point of view, multi-hashing will slow down things, but it won't add the security you are looking for in this case.

Is cryptography able to solve this problem?

Yes. What you need is a message authentication code (MAC), which is a short piece of information used to authenticate a message and to provide integrity and authenticity assurances on the message. Integrity assurances detect accidental and intentional message changes, while authenticity assurances affirm the message's origin.

For your further research endeavours, "MAC" and "HMAC" are the relevant keywords.

Nota Bene: In bis comment, @fgrieu hints at practically using a HMAC with SHA256... which indeed seems to be the most logic choice (because it's pretty minimal while currently offering expected security).

Community
  • 1
e-sushi
  • 17,891
  • 12
  • 83
  • 229
  • But the program is downloaded and run on the user's own computer, thus isn't there no way to hide the key from the user? As such, isn't using a MAC simply another form of obfuscation that can be easily defeated by a determined user? – Pacerier Jan 19 '14 at 02:46
  • 1
    @Pacerier Seems you're facing more than one crypto-problem. At first glimpse, Zero-Knowledge Proof comes to mind as a potential solution. There are a few Zero-Knowledge Proof Q&As around here (which are more enlightening than Wikipedia). E.g.: this one talks about password verification protocols - which could be a usable piece to your puzzle (just think "password = your key", so you don't have to store it as-is on the client-side). – e-sushi Jan 19 '14 at 14:16
  • @Pacerier Looking at your problem again, it's less of a "ensure that a “received value” is not altered" thing, but more of a "is user authorized to send a message" and "is message transmitted without interaction/modification by user" problem. In that case, you'll have to look at protocols related to authorization and co. instead of (H)MACs - as they will most probably be part of the individual protocols anyway. – e-sushi Jan 19 '14 at 14:24
  • 1
    @Pacerier There's one thing you won't be able to work around though: you can't verify the random number itself because (true) randomness can't be predicted and therefore not cross-checked. If you receive the number 0.230957203975 (by whatever means and protection), you will not be able to learn if I injected that number into your software or if it's the result of your software's random function. Simpler said: client-side software can always lie. Unless you control the security of that function (eg: server-sided), your client-sided idea will keep leaning towards the software-obfuscation area. – e-sushi Jan 19 '14 at 14:40
1

If you want to be sure the value is not altered in transit by an active attacker that is occupying the wire then what you need is an integrity mechanism that will guarantee that nobody has tampered with the message. Such mechanisms are instantiated with the employment of a message authenticated code (MAC) which are build on top of secure crypto primitives such as block ciphers and hash functions.

Also what do you mean by lying? Is it that on input $a$, $f(a)=b$ and the user submits $c$ instead. Then you just publish the function.On the other hand if you want to convince the other parties that the values you sign and you send is a truly and reliable evaluation of a function then you need a zero knowledge proof of knowledge of the output of the function if you want to keep the value secret

curious
  • 6,160
  • 6
  • 32
  • 45
  • MAC considers a symmetric setting in which two clients have agreed on a secret key – curious Jan 18 '14 at 17:16
  • 1
    Yes, upon f(a) = b, the user submits c instead. I'm not sure what you meant when you say publishing the function can solve the problem. Publishing the function wouldn't help, since the function is Rand(0, 1) (for the actual function see the comment I wrote to DrLecter) – Pacerier Jan 19 '14 at 03:05