I am quite familiar with most of the common undergrad/grad security foundations; but I couldn't find anything related to this scenario:

A scheme/system where a piece of data can only be 'decrypted' AND read only once (potentially in a computer program).

Is it even possible? I have heard such things are there in the 'hardware world' (?). If my question is imprecise/incomplete, I'm willing to update. But I am actually interested in a generic design/protocol at the same time.

  • 39
    Put the user on a sealed, shielded, locked box, with both the message and the key. Never allow the user to leave the box. Ever. Bury the box on the ocean.
    – ThoriumBR
    Dec 2, 2019 at 15:57
  • 8
    @ThoriumBR Surely, launching the box into the sun would be more secure?
    – GammaGames
    Dec 2, 2019 at 23:07
  • 8
    Have you never watched Mission Impossible? Your mission, should you choose to accept it...
    – Mars
    Dec 3, 2019 at 1:13
  • 21
    @mars that method failed miserably, someone recorded the mission and millions of people around the world already know what the mission was.
    – ThoriumBR
    Dec 3, 2019 at 14:07
  • 3
    OTP is meant to encrypt only once. If you keep both the pad and the cyphertext available, it can be decrypted as many times as you want. Or make copies and everyone with a copy can do the same. OP wants to decrypt once and once only.
    – ThoriumBR
    Dec 3, 2019 at 16:25

6 Answers 6


There is no way to do this - this is a subset of what DRM schemes attempt to do.

If an end user can decrypt something once to see it, they can see it again. Any of the following may be possible:

  • first take a copy and decrypt that
  • copy the screen
  • edit the application

The only way you could get close would be to have total control over the hardware and software, so you could delete once it has been shown, but even then, someone could use a camera to take pictures of the screen etc.

So, I'd like instead to ask what you intend to use such a scheme for - as there are ways to have the same effect in many scenarios.

  • 18
    Well answered by Rory, as usual. The loopholes referred to in this answer are often referred to as the 'analog hole' (see en.wikipedia.org/wiki/Analog_hole), which is inevitable in most DRM and copy protection schemes.
    – mti2935
    Dec 2, 2019 at 14:16
  • 2
    @mti2935 The analog hole is only addressed by the second of Rory's example scenarios. The "make a copy beforehand" scenario is the hardest to control because that is generally completely outside of the influence of any kind of encryption scheme. Dec 2, 2019 at 22:27
  • 4
    Even if you do somehow manage to prevent all software/hardware forms of copying (including cameras, etc.), the data will still make it into the user's brain. They can copy it from there.
    – BenM
    Dec 2, 2019 at 22:46
  • 19
    The usual procedure for secret data to prevent "someone could use a camera to take pictures of the screen etc." is to have that hardware be in a secure facility where anyone entering is searched both on entry and exit for anything that might be used to record or transmit data, and the actual process of accessing the sensitive data can be supervised by armed guards that will try and prevent most methods of tampering with the hardware. It's also not 100% secure, nothing is, but it's quite effective and there are facilities like that.
    – Peteris
    Dec 3, 2019 at 0:49
  • 10
    @Peteris and even then someone with a good memory could just memorize everything and write it up once outside of the facility.
    – Falco
    Dec 3, 2019 at 8:19

As you already hinted at, such a thing is only possible in hardware. A software or encrypted data solution would always suffer from the option of making a copy before decryption.

In hardware, the scheme would be to destroy information on decryption. A naive approach would be to simply read a block into memory, destroy it on storage and then decrypt it.

That approach, of course, can fall victim to tampering - an attacker could manipulate the system so that the deletion fails, but whatever is doing the decryption believes it succeeded and so proceeds with decryption.

A more sophisticated approach would be to exploit some physical property in such a way that reading the information also destroys it. This is, in fact, what makes the largely theoretical quantum cryptography secure - you cannot eavesdrop (listen in) without destroying information, thus revealing the fact that someone is intercepting the message.

Outside of the quantum realm, there might be solutions using chemical or other physical processes, but they will also be subject to tampering.

  • 10
    +1 for the only answer mentioning quantum.
    – justhalf
    Dec 3, 2019 at 6:14
  • 5
    +1 for chemical. I was thinking about chemical stript that will oxydize and display the plain text for a limited amount of time Dec 3, 2019 at 11:06
  • 3
    @usr-local-ΕΨΗΕΛΩΝ There was a DVD rental scheme that did exactly that. The disks would turn dark (made unreadable) after exposure to oxygen. You had around 48 hours to watch the movie
    – slebetman
    Dec 4, 2019 at 7:49
  • 5
    @slebetman That's not the same as one-time decryption though. I could, in those 48 hours, dump the DVD to a file and watch it as much as I want. Not that I had ever done that with rental DVDs though back when redbox was a thing and you could get a DVD for a few bucks. Anyways, the point is that I just have a limited time with the medium, with no copy protection in place.
    – user163495
    Dec 4, 2019 at 9:35
  • 1
    Quantum storage also may not be secure, as there is possible way to peek at state without disturbing it: livescience.com/schrodingers-cat-can-be-peeked-at.html Dec 4, 2019 at 16:07

If a network is available, you could offload the decryption procedure (and the private key) to a service running on a secure server. You could then enforce whatever rules you want on the server.

The client would submit the opaque text to the service and ask it to decrypt it and return the plaintext content, and the server could decide whether the client should be allowed based on decryption history-- potentially blocking more than one decryption operation.

However there would be nothing preventing the caller from using the result of the decryption over and over, which is more or less the same as decrypting it over and over. There have been attempts to do so for music and movies (see protected media path) but it's a losing battle. If nothing else, a hacker could spoof the monitor hardware and record the input signal, or even just point an HD video camera at the monitor and record the content as it plays. A similar interception technique could be used for any sort of digital content. So the bottom line is... not, it's not really possible.

A more feasible approach would be to bake a serial number into the content itself and track it in an authorization server, or to bake in an expiration timestamp. You'd then need to enforce this on the receiving end, which would have to be a secure application. This is how a one-time password works, for example. But that requires you to own both ends of the data path and for the data itself to be useless outside of it.

  • Note that while recording the screen is always possible, it would leave you with a decrypted copy. This would still satisfy the OP request of a one time decryption as you don't have an encrypted copy. There are some use cases where that matters, e.g. when presenting the encrypted copy is a method of authentication.
    – Tom
    Dec 4, 2019 at 8:21
  • @Tom The requirement also states "AND read only once". Dec 5, 2019 at 21:27

It is not in any way practical, and fundamentally impossible (in a reliable way), but it may be possible to some extent.

The obvious hindrance which makes the endeavour fundamentally impossible is that whatever it is you decrypt, once you've read it, it's inside your head. So, to be sure the secret stays secret, there would have to be a poison pill mechanism of sorts. Maybe a capsule that contains a TTS engine and transmits the message to you via bone conduction, and then explodes, blowing off your head.
Because, you know, as long as you breathe, you can just tell someone. Still, let's hope you don't repeat aloud what the TTS is whispering in your head.

That aside, there exist data storage systems which can be read only once. DRAM and Ferroelectric RAM as a non-volatile alternative are two examples of that. These need either an explicit write-after-read built-in, or something different (e.g. capacitator circuit). Otherwise, reading the information destroys the information. Leave that out, and you have gone forward a big step.
Now, at the very least, one would have to make two copies (one onto a non-destructive-read storage, and then another one to actually have a copy). Still, that's quite within the realm of "doable", but depending on hardware compatibility it may be somewhat of a burden anyway (not sure you can just wire up two entirely different, incompatible storage types and copy data like in Star Trek, might very well be that it proves a bit more difficult than that!). But we're not at the end.

The decryption key, and even part of, or the complete the decryption executable (assuming loops are unrolled) might as well be stored on destructive-read storage inside the decryption hardware. The decryption key does not ever need to leave the chip, so other than for "data", there need to be no lanes for transmitting it. It's read during decryption, and after that it's gone. So... there you go.

Unless you assume someone might drill holes the size of a few dozen nanometers into the chip and use nano-wires to somehow wiretap into the storage, there's no way of getting to the data. I'm not saying this is impossible, just... that it's kinda crazy. No information is valuable enough to warrant that. Plus, I'd guess it might be a quite risky procedure since accidentially leaking a tiny charge or going a few nanometers too far left or right will inevitably destroy the key, too.

As the decryption key is usually very small (32 bytes or less), it could in fact be stored inside a secure enclave processor or similar, as is done in many mobile devices routinely nowadays. That storage could also have destructive reads (and no external access to enclaved data, much like on every modern phone). But it doesn't even need to.
You could have fuses such as in Samsung's Knox or Apple's SEP, which in principle allow you to decrypt the data N times (not just exactly once, but exactly N times, as many as you like). After that, the processor simply doesn't refresh (or explicitly overwrites) the key. Or, much less secure (but probably still good enough), it only refuses to decrypt.
Thus, making a copy of the encrypted data really won't do much good because you cannot decrypt the copy.

Of course, someone can still trivially copy the decrypted data, if there are any means of doing so. Usually there are, both digital and analog. If nothing else, you can have two or three people looking at the screen simultaneously, or take a photo.

That, however, is a problem that you just fundamentally cannot solve (except by an exploding device, or a device releasing nerve gas).


From a purely theoretical sense - it is only possible if you can make sure that after the first decrypt there are no copies in existence of both

  1. the decrypted data, and
  2. either the encrypted data or the key(s) needed to decrypt it.

In principle, you can only do this with the cooperation (willing or coerced) of the parties that handle these pieces of information that need to be deleted.

In practice, this can be enough depending on what you want to achieve, and what components of the system you are willing to trust.

For example, if you trust a typical iPhone (you shouldn't, in the absolute sense, but like all things in security, there are few absolutes, there is usually only probability and how much risk you are willing to accept), you could choose to assume that an iPhone app you wrote and its data cannot be tampered with by either malware or the human user, because that's the sort of thing Apple seems to try to ensure, and thus you can do decryption and make sure to delete the data in your code after.

(You can always imagine a meticulously secured and audited device that you made yourself if the iPhone feels too insecure or untrustworthy for you.)

This does not remove the "analog hole" if you are showing that data to the user or otherwise leaking it in an observable way, but that might be acceptable for some usecases - for example maybe you are not showing it to the user, but only using the decrypted data as part of some security scheme in the implementation details that the user does not directly need to see.

We can extend this example to data transmission: you could send the encrypted data through one data channel, the key through another, and so long as you trust at least one of those channels to be secure and to not retain the data passed through it, or you can trust that any middle-men who can eavesdrop on one channel will never be able to pass information with any who can eavesdrop on the other, then you have a decent guarantee that the only thing that ever decrypts it is your cooperating client code.

TL;DR: If you understand why it there is no perfect solution to this problem in principle, you can identify some situations where you can achieve it with high enough odds to be comfortable in practice. But those situations might not overlap with what you were hoping to do.


This is one of the promises of quantum communication - in theory, since observation fundamentally alters quantum states, it would be possible to create a "read once" communication protocol.

Of course, practical problems like "user can still take a picture of their screen with their phone" still remain.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .