1
$\begingroup$

Suppose my server receives a message, the public key, and the signature. The message contains a time stamp.

Is there a way to get the time stamp from the signature to match it with the message time stamp. Or some other way to ensure the message was signed at the time that it says it was signed?

I am using ECDSA P-384 but open to some other algo if needed too.

$\endgroup$

2 Answers 2

9
$\begingroup$

There is no way to get time of signature from a standard ECDSA signature: it does not embed recoverable information†.

And under the conditions in this related question or messages with structure similar to NOSTR's event, it is not possible to ensure that the message was signed at the time that it says it was signed.


However, as noted in this other answer, if the final form of the message embeds a (digital) timestamp from a timestamping authority, that can prove that whatever this timestamp applies to existed at the time in the timestamp. Timestamps can be checked by anyone trusting the timestamping authority and holding it's trusted public key. So if we sign then timestamp, it proves the signature was made no later than the timestamp. And if we timestamp then sign, it proves the signature was made no earlier than the timestamp.

If we want to prove when the signature was made:

  • start from the message
  • append timestamp 1 of (a hash of) the message by a trusted authority
  • append a signature of all the above by the author of the message
  • append timestamp 2 of (a hash of) all the above by a trusted authority
  • in the context: if the initial message did not embed the sender's public key, prepend it

A verifier holding the timestamping authority's trusted public key can parse things and:

  • Verify that the public key in the signed and timestamped message is a valid ECDSA P-384 public key (This verification is required as a preliminary to signature verification, as stated in the last paragraph of sec1v2 §4.1.2 Key Deployment. Since in the context the public key is not certified, that can only be performed by the first method in §3.2.2 validation of Elliptic Curve Public Keys, that is §3.2.2.1. Since the curve is P-384, substep 2 applies, not substep 3.
  • Verify timestamp 2. This proves the message, timestamp 1 and signature existed at the time in timestamp 2, and was not altered since timestamped.
  • Verify the signature. This proves that the message (and timestamp 1) was not altered since it was signed by a party holding the private key matching the public key.
  • Verify timestamp 1. This proves the message existed at that time in timestamp 1, and was not altered since timestamped.

The combination of the above proves that the message was not altered since it was signed by a party holding the private key matching the public key, and (assuming trust in the timestamping authority) that this signing occurred between timestamp1 and timestamp2.

In the context of a server that trusts it's own time, we can do without timestamp2 and replace the time it embeds by the time the signed message is received. However, the trust acquired on the upper bound of when the signature was made becomes non-transferable. And insuring that the time of a server is neither accidentally wrong nor manipulated by adversaries is actually difficult.


† beyond some derivative of the key pair and hash of the message. Notably, that's typically enough to recover the public key knowing the signature and (the hash of) the message.

$\endgroup$
4
$\begingroup$

There needs to be a timestamping authority (TSA), but your need deviates slightly from what it achieves.

A signature from a TSA only guarantees the data existed before the said timestamp, where as you said you want the ECDSA signing time match the timestamp - a slight but significant difference.

References:

https://www.rfc-editor.org/rfc/rfc3161

https://www.freetsa.org/index_en.php

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.