A message is “burnt” when an old message becomes entirely inaccessible to anyone. The term works for almost all cultures; the idea of destroying information by setting fire to the paper substrate that holds it is fairly much universal.

With care and forethought it is almost always possible to burn information in memory by overwriting it. Things are much less definite for stored information on common non-volatile media:

A messaging program/application works at and is normally restricted to the file level. So the only relevant message burning applicable functions available to to such a program/application will be deleting a file and overwriting data in an open file.

Files are sometimes backed up to other media at this level … sometimes automatically.

When a file is deleted at the file system level that normally just deindexes the data while leaving it completely accessible at the logical block level. Most file systems likely to be used on a platform used for messaging¹⁾ will greatly reduce the chance of access to data at the logical block level if the data is overwritten at the file level. Overwriting at the file level should thus be done as a matter of course before deleting any sensitive data and as a part of any explicit burning operation.

Data at the logical block level is fairly easy to access in practice. This is the level that file “undelete” utilities work at.

There are two forms of media in common use at this point in time (2021):

The media controller here is mostly going to be used for remapping bad sectors on the disk. As a result, an overwrite operation that successfully propagates down from the file level will usually result in a successful burn. The exception would arise when a disk sector with sensitive data in it becomes flaky and is mapped to another physical block. There is little chance of that happening unless the sensitive data occupies a significant portion of the disk.

Recovery of data at the physical block level is difficult as the media controller would have to be bypassed and the media controller almost always involves a separate hardware implementation. As a result physical access to the device would be required.

This is the form of media most likely to to be used on platforms used for encrypted messaging. Using it is complicated. One of the competing strategies for the media controller that comes out of this complexity is to delay the actual erasure of any data indefinitely.

As a result it is fairly safe to assume that any data written to flash media could be recoverable at the physical block level. Messages saved on such devices should be considered unburnable. Sometimes the media controller function is implemented in software so that physical access to the device might not be required for recovery.

The good news is that recovery of data at the physical level is difficult. Smart phone operating systems tend to encrypt the media by default which helps to increase the difficulty.

There is no practical reason why it is not possible to burn messages stored on media. Rotating magnetic media can be reliably erased with an overwrite. Solid state flash media can be reliably erased with the same erase that is used in routine operation.

The root problem is that the almost universally used C language file library has no way to specify that you would like some particular data to be treated with care and no way to specify that you would like that data to be actually erased. Until this is fixed there is no point in considering the problem at any other level.

More generally, any platform that leaves data laying around without any consideration of the needs of the user can not be considered truly secure. A secure platform should provide a reasonable amount of non-volatile storage that can be safely erased.

In the paper and ink age all that was required to securely delete data was a match. We are supposed to be making things better but now things are objectively much worse. The current situation has evolved to the point of absurdity.

This section is intended to support these points:

• Message burning at the file level should involve overwriting.
• Message burning at the file level is fundamentally unreliable.

Plain text should never touch media. Be wary of platforms that might copy RAM to media as part of some sort of swap or hibernation or program unloading scheme. Such schemes might involve encryption but that encryption might be weak or entirely pointless.

The user should perhaps be offered some sort of messaging mode that does not store messages on media, even temporarily. In general it is best to not have to deal with the message burning issue at all.

The idea here is that you encrypt one or more messages you might want to burn later. Then you burn the messages by burning the key. As this depends on the encryption remaining unbroken indefinitely it should be considered inferior to burning the actual messages. Any time a key is burned the material protected by that key should also be burned if at all possible and even if it might not be completely effective.

You need one unique key for each and every chunk of data you want to potentially burn in the future. That means you have to decide on the granularity of the scheme ahead of time. If you want to be able to burn each days worth of messages separately, then you need to encrypt each days worth of messages separately.

If you are doing this to avoid the issue of media message retention then you have the problem of finding a place to store the key. If you store it on the media you might find yourself back where you started.

In the context of this discussion forward secrecy is a special case of message burning by encryption. The messages to be burned are messages in transit recorded off the network by an adversary. By burning the key(s) used to protect the messages on the network then access to the surreptitious archive is prevented in a case where the keys might be discovered later by that adversary.

Unfortunately, users like to keep their old messages around and normally access to keys will also provide access to those old messages. Those messages in a sense hold the forward secrecy scheme hostage up to the point they are erased and that might not be completely possible. So the issues associated with message burning are more relevant in a system that provides forward secrecy. It can be assumed that any adversary capable of making an archive of messages from the network would have the power to recover even the most difficult to access partially burned messages.

A possible upside here is that there is no real point in burning the forward secrecy keys before the messages actually end up being burned. That might be an advantage as the then required key generation tends to be computationally intensive. Putting it off might help make your mobile app consume less battery energy.

The previous comment about offering the user a mode that doesn't touch media is particularly relevant for the case of forward secrecy.

You can store the burnable key in the users mind in the form of a passphrase. Then to burn they just have to vow to never use that passphrase again. You can only expect a user to remember at most a single passphrase so this is going to be all or nothing in practice. I only bring up the possibility because the situation with media might leave the user's mind as the only really secure place to store a key.

You could give the user the opportunity to store old messages to a passphrase as an alternative to getting rid of them entirely. The use of public key cryptography would mean that the user would not need to enter the passphrase unless they wanted to look at the messages. A rarely used passphrase is quickly forgotten but the result might be considered better than nothing. One or more passphrases could be stored on the easily burned medium of paper to make a hybrid system.

Encrypted Messaging index