Score:0

Verifying meeting by sending same signed random number to central authority?

br flag
JMC

I am trying to develop a simple protocol for two users to verify (with respect to a trusted central authority) that they have (intentionally) met/communicated with each other.

My idea was this: Users own a (public, secret) key pair of any common asymmetric system, such as RSA. Their public key also servers as their identifier. In order for two people to confirm that they have had contact, they will both generate a random 256bit number, share it with each other (in the indented application/use case, this is intended to happen only in person, not over distance) and then both individually, securely transmit (e.g. HTTPs) the concatenated number to a central authority encrypted with their respective private keys. They will also transmit their respective public key/id to identify themselves to the central authority, which in turn can verify that both have sent the same message after decrypting with their respective public keys, which both proves their identity and their prior communication.

I realize that it lends itself to a man-in-the-middle attack where a middle-man could relay two persons' random numbers to each other, effectively faking a meeting between these two and not including himself. The real system in which I intend to use this would make this practically impossible, as both users have to message the CA in a very short time frame and users would typically share random codes only in person, where such a MITM attack would be obvious.

Edit: The main purpose is for the two users to prove their intentional communication/meeting. There is no incentive and no harm done in conspiring to confirm in this way a meeting that has only occurred remotely, as long as both parties are aware of this action.

With this said, is this a bad idea, if yes, why?

knaccc avatar
es flag
If Alice and Bob have public keys A and B respectively, then Alice can just send the message "I am A, I met B" (signed with A) to the central authority. Bob sends "I am B, I met A" (signed with B). If this is not sufficient, please articulate why this simple solution would not meed your needs. If you need to indicate they met at a particular time, just ask both to include that timestamp in the message. Or you could include a sequence number so each can indicate they have met for the $n$th time.
JMC avatar
br flag
JMC
@knaccc I was thinking that in order to prove they actually are A/B they would need to prove they can sign a previously unknown message, otherwise someone who once snooped such a message somehow could just resend it later to pretend to be A or B having met the other, because then this attacker knows this one cleartext/chiffre pair.
knaccc avatar
es flag
When Alice signs the message "I am A, I met B", the central authority will verify that the signature could only have been signed with knowledge of the private key corresponding to the public key A. If Mallory signs the message "I am A, I met B", he can only do that with his public key M because he does not know Alice's private key. Therefore any signature created by Mallory will not verify against the public key A. If you are worried about a replay attack, where Mallory could pretend A and B met a second time, put a sequence number or timestamp in the messages so they cannot be reused.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.