A single-use-seal primitive is a unique object that can be closed over a message exactly once. Single-use-seal’s in physical terms can be predominantly observed on confidential documents, logistics where the containers are usually sealed.
Single-use-seal’s can be identified if they follow the following list of characteristics.
Close(l,m)→wl Close(l,m)→wl — Close seal ‘l’ over message ‘m’, producing a witness ‘wl’.
In the above statement, we are defining that the closure of seal ‘l’ over the message ‘m’, and the corresponding witness ‘wl’. The witness produced during the process should always be the same ‘wl’ iff both the seal ‘l’ & ‘m’ are same.
Verify(l,wl,m)→bool Verify(l,wl,m)→bool — Verify that the seal ‘l’ was closed over message ‘m’.
The above statement states that if we verify that seal ‘l’ is the exact closure of message ‘m’, it should return the exact boolean value no matter how many times we test.
If someone wants to attack the structure of working of the A single-use-seal implementation. The possible scenario that they can try is “They can create different seals using which they can verify the witness and extract the message”, “They can create different messages which can produce the same witness.” or “They can try with different seals and messages and try to produce the same witness”.
Attackers vs Single Use Seal
In the above picture, you can observe that the strength of the closure is much stronger and effective when the message, seal and the witness are all unique. If we use any other approach other than single-use-seal we will encounter any of the three problems which are prone to be attacked.
The real world use case of the single-use-seal can be obtained if there is a way in which you can create single-use-seals with proper authentication. In the use case, you can think of something like a unique public key can generate a new seal. But our concern is Authentication. So, We need to include the signature as a part of our closure and then seal it. The mathematical representation will be as follows
Gen(p)→l — Generate a new seal bound to public key ‘p’
In the above statement, we are generating a seal ‘l’ bound to the public key ‘p’.
Close(l,m,s)→wl — Close seal ‘l’ over message ‘m’, authenticated by a signature ‘s’ valid for public key ‘p’.
In the above equation, we had mentioned clearly the closure of the seal, message, signature produces the witness. Which actually is much more meaningful than what we discussed earlier. To make it much stronger we can use any cryptographic identity scheme, such as a Bitcoin-style predicate script, zero-knowledge proof, etc.
Single-use-seal
The Single-use-seal concept finds many applications in the crypto-verse. With the help of single-use-seal implementation, we can have simple agreements on the blockchain in which both the parties can seal committing to the agreement and witnesses being cryptographic signatures produced in the closure of the agreement. This topic can be extended further by the concept of disposable keys in which a unique private key is generated for every closure of an agreement and will be destroyed once the agreement/contract is closed between the parties.
