Return to Answer

As is, the attack seems rather pointless. But one malicious potential is that because $\bar y$ allows to successfully verify a genuine message $(m,s)$, the verifier might grow trust in it and use $\bar y$ instead of $y$ in order to verify other messages. If we assume this, practical issues could arise:

1. That the attacker can somewhat find $(\bar m,\bar s)$ (with $\bar m\ne m$ and/or $\bar s\ne s$ depending on definition of security of a signature system) so that $v(\bar m,\bar s,\bar y)=\text{ok}$ ; $(\bar m,\bar s)$ will be accepted by a the verifier and in effect is a practical forgery.
2. That the legitimate verifier handed some genuine $(m',s')$ pair (such that $v(m',s',y)=\text{ok}$, and $m'\ne m$) finds that $v(m',s',\bar y)\ne\text{ok}$, and rejects the valid message; this in effect is a denial of service.

In many signature systems where the question's attack is possible, 1 or/and 2 is possible.

Elias suggests that if making a $\bar y$ as in the question is possible, then the signature scheme looses non-repudiation. That's an interesting point of view, but mine is that the definition of non-repudiation is a convention between parties, and that it would be a slippery slope (and an unusual one) to allow exhibition of $\bar y\ne y$ such that $v(m,s,\bar y)=\text{ok}$ to be a valid reason to stop accounting the legitimate holder of the private key matching the public key $y$ as responsible for having signed $m$ whenever $(m,s)$ becomes publicly available and $v(m,s,y)=\text{ok}$.

Two technical reasons are that, without breaking the established definition of security of a signature scheme, it could be that $\bar y$ was produced

• from $y$ and/or $s$, by anyone;
• or additionally with knowledge of the private key for $y$, e.g. by the legitimate key holder wanting to repudiate his/her approval of $m$.

Thus is we allowed what Elias proposes, we'd need to use signature schemes with a stronger and more complex definition of security than we do, for no benefit that I can discern beyond preventing what is explained in the first part of the answer.

As is, the attack seems rather pointless. But one malicious potential is that because $\bar y$ allows to successfully verify a genuine message $(m,s)$, the verifier might grow trust in it and use $\bar y$ instead of $y$ in order to verify other messages. If we assume this, practical issues could arise:

1. That the attacker can somewhat find $(\bar m,\bar s)$ (with $\bar m\ne m$ and/or $\bar s\ne s$ (depending on definition of security of a signature system) so that $v(\bar m,\bar s,\bar y)=\text{ok}$ ; $(\bar m,\bar s)$ will be accepted by a the verifier and in effect is a practical forgery.
2. That the legitimate verifier handed some genuine $(m',s')$ pair (such that $v(m',s',y)=\text{ok}$, and $m'\ne m$) finds that $v(m',s',\bar y)\ne\text{ok}$, and rejects the valid message; this in effect is a denial of service.

In many signature systems where the question's attack is possible, 1 or/and 2 is possible.

Elias suggests that if making a $\bar y$ as in the question is possible, then the signature scheme looses non-repudiation. That's an interesting point of view, but mine is that the definition of non-repudiation is a convention between parties, and that it would be a slippery slope (and an unusual one) to allow exhibition of $\bar y\ne y$ such that $v(m,s,\bar y)=\text{ok}$ to be a valid reason to stop accounting the legitimate holder of the private key matching the public key $y$ as responsible for having signed $m$ whenever $(m,s)$ becomes publicly available and $v(m,s,y)=\text{ok}$.

Two technical reasons are that, without breaking the established definition of security of a signature scheme, it could be that $\bar y$ was produced

• from $y$ and/or $s$, by anyone;
• or additionally with knowledge of the private key for $y$, e.g. by the legitimate key holder wanting to repudiate his/her approval of $m$.

Thus is we allowed what Elias proposes, we'd need to use signature schemes with a stronger and more complex definition of security than we do, for no benefit that I can discern beyond preventing what is explained in the first part of the answer.

As is, the attack seems rather pointless. But one malicious potential is that because $\bar y$ allows to successfully verify a genuine message $(m,s)$, the verifier might grow trust in it and use $\bar y$ instead of $y$ in order to verify other messages. If we assume this, practical issues could arise:

1. That the attacker can somewhat find $(\bar m,\bar s)$ (with $\bar m\ne m$ and/or $\bar s\ne s$ depending on definition of security of a signature system) so that $v(\bar m,\bar s,\bar y)=\text{ok}$ ; $(\bar m,\bar s)$ will be accepted by a the verifier and in effect is a practical forgery.
2. That the legitimate verifier handed some genuine $(m',s')$ pair (such that $v(m',s',y)=\text{ok}$, and $m'\ne m$) finds that $v(m',s',\bar y)\ne\text{ok}$, and rejects the valid message; this in effect is a denial of service.

In many signature systems where the question's attack is possible, 1 or/and 2 is possible.

Elias suggests that if making a $\bar y$ as in the question is possible, then the signature scheme looses non-repudiation. That's an interesting point of view, but mine is that the definition of non-repudiation is a convention between parties, and that it would be a slippery slope (and an unusual one) to allow exhibition of $\bar y\ne y$ such that $v(m,s,\bar y)=\text{ok}$ to be a valid reason to stop accounting the legitimate holder of the private key matching the public key $y$ as responsible for having signed $m$ whenever $(m,s)$ becomes publicly available and $v(m,s,y)=\text{ok}$.

Two technical reasons are that, without breaking the established definition of security of a signature scheme, it could be that $\bar y$ was produced

• from $y$ and/or $s$, by anyone;
• or additionally with knowledge of the private key for $y$, e.g. by the legitimate key holder wanting to repudiate his/her approval of $m$.

Thus is we allowed what Elias proposes to happen, then we'd need to use signature schemes with a stronger and more complex definition than we do, for no benefit that I can discern beyond preventing what is explained in the first part of the answer.

As is, the attack seems rather pointless. But one malicious potential is that because $\bar y$ allows to successfully verify a genuine message $(m,s)$, the verifier might grow trust in it and use $\bar y$ instead of $y$ in order to verify other messages. If we assume this, practical issues could arise:

1. That the attacker can somewhat find $(\bar m,\bar s)$ (with $\bar m\ne m$ and/or $\bar s\ne s$ depending on definition of security of a signature system) so that $v(\bar m,\bar s,\bar y)=\text{ok}$ ; $(\bar m,\bar s)$ will be accepted by a the verifier and in effect is a practical forgery.
2. That the legitimate verifier handed some genuine $(m',s')$ pair (such that $v(m',s',y)=\text{ok}$, and $m'\ne m$) finds that $v(m',s',\bar y)\ne\text{ok}$, and rejects the valid message; this in effect is a denial of service.

In many signature systems where the question's attack is possible, 1 or/and 2 is possible.

Elias suggests that if making a $\bar y$ as in the question is possible, then the signature scheme looses non-repudiation. That's an interesting point of view, but mine is that the definition of non-repudiation is a convention between parties, and that it would be a slippery slope (and an unusual one) to allow exhibition of $\bar y\ne y$ such that $v(m,s,\bar y)=\text{ok}$ to be a valid reason to stop accounting the legitimate holder of the private key matching the public key $y$ as responsible for having signed $m$ whenever $(m,s)$ becomes publicly available and $v(m,s,y)=\text{ok}$.

Two technical reasons are that, without breaking the established definition of security of a signature scheme, it could be that $\bar y$ was produced

• from $y$ and/or $s$, by anyone;
• or additionally with knowledge of the private key for $y$, e.g. by the legitimate key holder wanting to repudiate his/her approval of $m$.

Thus is we allowed what Elias proposes, we'd need to use signature schemes with a stronger and more complex definition of security than we do, for no benefit that I can discern beyond preventing what is explained in the first part of the answer.

As is, the attack seems rather pointless. But one malicious potential is that because $\bar y$ allows to successfully verify a genuine message $(m,s)$, the verifier might grow trust in it and use $\bar y$ instead of $y$ in order to verify other messages. If we assume this, practical issues could arise:

1. that the attacker can somewhat find $(\bar m,\bar s)$ (with $\bar m\ne m$ and/or $\bar s\ne s$ depending on definition of security of a signature system) so that $v(\bar m,\bar s,\bar y)=\text{ok}$ ; $(\bar m,\bar s)$ will be accepted by a the verifier and in effect is a practical forgery.
2. that the legitimate verifier handed some genuine $(m',s')$ pair (such that $v(m',s',y)=\text{ok}$, and $m'\ne m$) finds that $v(m',s',\bar y)\ne\text{ok}$, and rejects the valid message; this in effect is a denial of service.

In many signature systems where the question's attack is possible, 1 or/and 2 is possible.

Elias suggests that if making a $\bar y$ as in the question is possible, then the signature scheme looses non-repudiation. That's an interesting point of view, but mine is that the definition of non-repudiation is a convention between parties, and that it would be a slippery slope (and an unusual one) to allow exhibition of $\bar y\ne y$ such that $v(m,s,\bar y)=\text{ok}$ to be a valid reason to stop accounting the legitimate holder of the private key matching the public key $y$ as responsible for having signed $m$ whenever $(m,s)$ becomes publicly available and $v(m,s,y)=\text{ok}$.

Two technical reasons are that, without breaking the established definition of security of a signature scheme, it could be that $\bar y$ was produced

• from $y$ and/or $s$, by anyone;
• or additionally with knowledge of the private key for $y$, e.g. by the legitimate key holder wanting to repudiate his/her approval of $m$.

Thus is we allowed what Elias proposes to happen, then we'd need to change the definition of secure signature schemes, for no good reason that I can discern.

As is, the attack seems rather pointless. But one malicious potential is that because $\bar y$ allows to successfully verify a genuine message $(m,s)$, the verifier might grow trust in it and use $\bar y$ instead of $y$ in order to verify other messages. If we assume this, practical issues could arise:

1. That the attacker can somewhat find $(\bar m,\bar s)$ (with $\bar m\ne m$ and/or $\bar s\ne s$ depending on definition of security of a signature system) so that $v(\bar m,\bar s,\bar y)=\text{ok}$ ; $(\bar m,\bar s)$ will be accepted by a the verifier and in effect is a practical forgery.
2. That the legitimate verifier handed some genuine $(m',s')$ pair (such that $v(m',s',y)=\text{ok}$, and $m'\ne m$) finds that $v(m',s',\bar y)\ne\text{ok}$, and rejects the valid message; this in effect is a denial of service.

In many signature systems where the question's attack is possible, 1 or/and 2 is possible.

Elias suggests that if making a $\bar y$ as in the question is possible, then the signature scheme looses non-repudiation. That's an interesting point of view, but mine is that the definition of non-repudiation is a convention between parties, and that it would be a slippery slope (and an unusual one) to allow exhibition of $\bar y\ne y$ such that $v(m,s,\bar y)=\text{ok}$ to be a valid reason to stop accounting the legitimate holder of the private key matching the public key $y$ as responsible for having signed $m$ whenever $(m,s)$ becomes publicly available and $v(m,s,y)=\text{ok}$.

Two technical reasons are that, without breaking the established definition of security of a signature scheme, it could be that $\bar y$ was produced

• from $y$ and/or $s$, by anyone;
• or additionally with knowledge of the private key for $y$, e.g. by the legitimate key holder wanting to repudiate his/her approval of $m$.

Thus is we allowed what Elias proposes to happen, then we'd need to use signature schemes with a stronger and more complex definition than we do, for no benefit that I can discern beyond preventing what is explained in the first part of the answer.