# Is this protocol secure?

Before anyone freaks out, this is purely speculative and I am not developing a cryptosystem!

I can't see anything wrong with this protocol, but my knowledge of cryptography is rather superficial:

• Decentralized nodes need to publish a piece of information (their state, e.g. available/busy) to a central server S.

• Each node has an RSA key pair.

• Node A and node B have already exchanged their public keys via some secure channel outside of this protocol.

• Node A sends a message to the central server S. The message contains:

1. A's public key
2. The (state, timestamp) pair
3. The signature for the above pair, which A calculated by using its private key

This may be the first time S sees A's public key. However, S makes sure the signature checks out, and registers A's new state provided that A's previous state is either older or non-existent.

• Node B asks S for A's state. In its request to S, B identifies A by means of A's public key fingerprint (SHA-256 or whatever the best practice is), which effectively acts as node ID.

• S forwards to B the state message it previously received from A. B independently checks that the signature is valid (B already had A's public key on record) and registers A's new state provided that A's previous state is either older or non-existent.

Questions:

1. Is there a way a malicious node can fool B by making it accept fake or outdated state messages in A's name?
2. Given that S has no prior knowledge of A's public key before receiving A's very first state message, is this protocol able to ensure that no malicious node can convince S to persist and propagate invalid state information in A's name or somehow enact some kind of denial of service (not by intense network activity that overloads S, but by intelligently breaking the protocol) whereby A is unable to propagate its real state?
3. Is there any other problem you may want to mention (leaving aside the questionable utility of the protocol)?

Thank you.

• Welcome to Cryptography.SE. It might be better to mention your goals. There might be already solutions for your aim. May 12 at 23:43
• Pure speculation with no intention to build anything. I am trying to educate myself.
– gd1
May 12 at 23:44
• Not enough data for a meaningful answer. What threat model? What security model do you want out of the sigature scheme? What signature scheme: RSA can't sign anything any more than "exponentiation" can sign something. RSASSA-PSS is very different from RSASSA-PKCS#1 v1.5, for example. crypto.stackexchange.com/questions/44188 May 13 at 1:08
• Thank you @SAIPeregrinus, I'll do more research.
– gd1
May 13 at 8:13

Question 2 can be easily answered. Yes, an attacker could easily overload this part of the system.

This may be the first time S sees A's public key. However, S makes sure the signature checks out, and registers A's new state provided that A's previous state is either older or non-existent.

An attacker can easily send their own public key instead of $$A$$'s key. Then sign with their own private key. The signature will, of course, be valid, so $$S$$ will accept it. If $$S$$ ties that key to the identifier for $$A$$ going forward, then future messages from the real $$A$$ would be blocked. Also, no $$B$$ will ever request a message with said key's fingerprint, so it will wait taking space in the message queue, leading to an easy way to fill the queue and stop any new messages from being processable.

• I should probably review asymmetric cryptography from first principles because I don't understand this: If S ties that key to the identifier for A going forward. S really can't do that in my humble understanding, because the only ID for A existing in the system is A's public key fingerprint. There is no other node ID. So if node C sends their own public key instead of A's public key, node C is seen as another node legitimately posting its state, not A. Of course, a DOS is feasible by clogging S with millions of public keys for bogus nodes. Thanks!
– gd1
May 13 at 8:23
• You didn't make the way $S$ stores node IDs in the description explicit. IF $S$ had some other node ID aside from the key fingerprint, then it would store the wrong fingerprint with that ID. Being very explicit about all details is important. May 13 at 16:41
• Yeah, I just casually said that "In its request to S, B identifies A by means of A's public key fingerprint [...], which effectively acts as node ID" but said nothing about S. Point taken, it really is all in the details! I shall edit the question.
– gd1
May 13 at 22:45