4 ms·

The conversion into a classical check bit sounds kind of trivial, since the bank has to do the verification of the check. Just add some EPR pairs to the token a

The conversion into a classical check bit sounds kind of trivial, since the bank has to do the verification of the check. Just add some EPR pairs to the token and use them for teleportation. The measurement results of the teleportation are the classical check. Edit: Ah, you can verify the signature without the bank. Instead of teleporting you sign a message like "I give this token to Bob. Bank please generate a replacement token for him because signing this message destroyed mine.".

amluto 10y ago
> The conversion into a classical check bit sounds kind of trivial, since the bank has to do the verification of the check. Just add some EPR pairs to the token and use them for teleportation. The measurement results of the teleportation are the classical check. Be very, very careful doing things like this. For example, if the bank knows a secret, uses it to verify your token, and returns the token back to you even if it was invalid, you get a nice oracle to use to attack the bank's secret. See, for example: https://arxiv.org/abs/1010.0256 https://arxiv.org/abs/1010.0256
- Strilanc 10y ago
  The protocol from the paper already includes a 'verify token' function. I don't see how teleporting the token, vs using a more typical quantum channel like a fiber optic line, would increase any of the risks. ... ... Maybe there are situations where an attacker could substitute their own EPR pairs into your token? EPR pairs aren't separately verifiable, so you wouldn't realize. And if the attacker intercepted the classical channel you used to send the measurement results for the teleportation then you would accidentally be sending the token to the attacker instead of the bank. Even if the attacker just listened in, and you or the bank realized the attack was happening when the verify failed, the protocol doesn't require checking with the bank before accepting a token and so the attacker can still spend the token.
  - amluto 10y ago
    What I meant was: be careful when applying an operation involving secrets to untrusted input. It's very easy to leak your secrets. This doesn't matter with this scheme because verification doesn't use any secrets. (Well, sort of. If you're taking advantage of "everlasting security", then the public key is secret.)

amluto 10y ago

> The conversion into a classical check bit sounds kind of trivial, since the bank has to do the verification of the check. Just add some EPR pairs to the token and use them for teleportation. The measurement results of the teleportation are the classical check. Be very, very careful doing things like this. For example, if the bank knows a secret, uses it to verify your token, and returns the token back to you even if it was invalid, you get a nice oracle to use to attack the bank's secret. See, for example: https://arxiv.org/abs/1010.0256 https://arxiv.org/abs/1010.0256

Strilanc 10y ago
The protocol from the paper already includes a 'verify token' function. I don't see how teleporting the token, vs using a more typical quantum channel like a fiber optic line, would increase any of the risks. ... ... Maybe there are situations where an attacker could substitute their own EPR pairs into your token? EPR pairs aren't separately verifiable, so you wouldn't realize. And if the attacker intercepted the classical channel you used to send the measurement results for the teleportation then you would accidentally be sending the token to the attacker instead of the bank. Even if the attacker just listened in, and you or the bank realized the attack was happening when the verify failed, the protocol doesn't require checking with the bank before accepting a token and so the attacker can still spend the token.
- amluto 10y ago
  What I meant was: be careful when applying an operation involving secrets to untrusted input. It's very easy to leak your secrets. This doesn't matter with this scheme because verification doesn't use any secrets. (Well, sort of. If you're taking advantage of "everlasting security", then the public key is secret.)