I would like to revive this conversation by addressing some points from the article and providing my perspective for achieving this milestone.
I think that it’s possible to implement the NFT standard as it’s described in the Medium article; however, I also think that the focus has largely been on the way steganography is applied to specific file types today. Feel free to correct me if I’m wrong about anything.
I’ll be adding my own commentary to the points made in the article. Skip to the end for my suggestions on how we can proceed with an implementation.
Cryptography will be used for encryption and authentication purposes, while steganography will be used to insert it into the NFT.
Cryptography is the practice and study of techniques that enable authentication, confidentiality, data integrity, and non-repudiation.
Authentication: the act of proving an assertion; the process of verifying an identity.
Confidentiality: a set of rules that limit access to certain types of information.
Data integrity: the assurance of data accuracy and consistency over its entire life-cycle.
Non-repudiation: a service that provides proof of the integrity and origin of data.
Modern cryptography provides us with the tools to implement a solution that meets all these criteria.
- Authentication: a token is attributed to a single address, which can only be controlled by the entity holding its private key.
- Confidentiality: the NFT standard must include a protocol that grants certain applications the ability to decrypt a token’s embedded payload with the the token owner’s private key.
- Data integrity: the NFT standard must include a protocol that proves a given token is in fact the correct token (i.e. has not been swapped out for a different token or value.) Additionally, we will leverage the Zenon ledger to reinforce data integrity.
- Non-repudiation: the NFT standard must include a protocol that proves all of the above has not been modified in any way without the token owner’s consent (i.e. a proof for all other proofs.)
Steganography on the other hand is the practice and study of techniques that enable one to conceal a message within another message and communicate without the knowledge of any third parties.
This is where things get a bit complicated.
Modern steganography solutions are limited in this respect. Even a determined security analyst can identify the presence of a concealed message.
We cannot realistically achieve this goal with open-source software.
If the algorithm for concealing a message is auditable by anyone, it can certainly be reverse-engineered to permit the discovery of an embedded message.
Summarized examples of steganography from the article:
- tattooing a message on a clean-shaven scalp then waiting for the hair to grow back
- painting four microscopic characters on a famous painting
- a famous painting superimposed over a portrait that can only be revealed with XRF spectroscopy
- lines and dots amidst an array of symbols were actually a message written in morse code
All of these eventually failed the criteria of communicating a message without third-party discovery.
It’s a matter of when, not if.
Examples of Digital Steganography
- Least Significant Bit
For every type of image file format, one can change the lowest bits to hold message data.
- Bit Plane Complexity Segmentation
BPCS uses multiple bit-planes, and so can embed a much higher amount of data (than LSB), though this is conditional on the individual image.
The next paragraph states:
Most NFTs are in the form of digital media content such as images, music, or videos.
With the help of digital steganography, the on-chain information can be cryptographically linked and embedded into the actual NFT using the techniques presented earlier.
As far as I know, the examples provided can only be applied to image, audio, and video files.
In order to embed a message in existing media, the application performing this task must be able to transcode each supported media type, preferably producing a result with the original encoding scheme.
For example: .avi input → embed cryptography proof → .avi output
This requires a unique solution per media type.
Also, these approaches do not apply to other common file types, such as text documents. A steganography solution for PDF files will not apply to DOCX files, or presentation files, or plaintext files.
Each of these will require their own solutions outside the examples provided by the article.
Note: I think it’s impossible to hide content in a plaintext file.
Use-case: Embedded Unlockable Content
The Virtual Hologram concept can be extended to support a novel use case: embedded unlockable content, while obsoleting counterfeits at the same time.
When you create an NFT, you should have the option to add additional content that can only be revealed by the NFT holder.
The “Save as” method would be useless, as only the NFT holder will be able to authenticate the NFT using its embedded Virtual Hologram.
The goal is to be able to unlock hidden, encrypted content that only the NFT holder can access.
The data carrier will be publicly accessible, publicly verifiable, and privately unlockable.
If digital media is publicly accessible, one cannot prevent others from “Saving As”, though the true value of the NFT will still remain obfuscated.
Should someone find a way to remove the embedded data, they will nevertheless only have the publicly accessible media, which may not be worth anything without the hidden counter-piece.
The recommended implementations:
Virtual Hologram implementation: minting should automatically insert the Virtual Hologram using a steganographic method
Spectral Attestation implementation: extract the Virtual Hologram and validate it using on-chain data
These will be slightly challenging to implement but absolutely possible given the current capabilities of the Syrius wallet and the Dart/Flutter SDKs.
Part of the challenge involves a design decision for integrating the steganographic method. I hope we can all reach an agreement for a preferred method soon in order to begin this work.
Some other considerations:
- The off-chain host for the data carrier must be trusted to provide a high degree of data integrity and availability.
- Alternatively, if the NFT payload is just encrypted text, it could be hosted on-chain.
- Is the unlockable content static or dynamic? If someone purchases an NFT and consumes its content, will it still have value?
- Will the content be time-sensitive, like Time-based One-time Passwords (TOTP)?
- Is the unlockable content a key to a particular event or digital forum? Why not make the ownership of the token the key, instead?
Suggestions for implementations
All that to say, we need to decide how we want to implement steganography. There are probably many ways to achieve this; some will be research-intensive and may result in a cumbersome wallet engine while others might be more lightweight and scalable.
Here’s what I’m proposing:
- We implement the solutions are they’re literally presented in the article. This will require individual transcoding capabilities for each file format that we want to support. This solution does not scale quickly and could lead to a slow NFT creation process for larger files.
- For what purpose, if the discovery of the embedded payload is inevitable? Permanent obfuscation is impossible given this project is open-source.
- Are we trying to create a functional replica of a file with an embedded payload that is non-trivial to remove?
Are we aiming for something like DRM?
- The algorithm will inevitably be reverse-engineered to remove that payload, if there is value in doing so.
- We implement an alternate solution that achieves a similar result – file functionality and an embedded, encrypted payload – with any file format today. This can be achieved by appending arbitrary bytes to any file such that we don’t break any existing magic byte structures that are currently in use.
- The goal is to leverage cryptography to unlock a hidden embedded payload.
- It should not be overly complicated to verify that there is an embedded payload. This reduces the bar for anyone to confirm that a Zenon NFT is in fact a Zenon NFT, not some random file.
- “Hidden embedded payload” means that upon launching the file normally, a user would not suspect there is anything hidden in the file. Upon deeper, byte-level analysis, one may surmise – or even conclude – that there is indeed something more to this file.
Keep in mind, we need a protocol that Syrius can apply to each file that we want to tokenize, whether that’s appending bytes or re-encoding a file entirely. The file must pass through Syrius before being uploaded to a file-hosting service.
Shameless plug – here’s what I’m proposing as a proof of concept for option number 2 and it scales to any file type (as far a I know) with little processing overhead.
Second plug – here’s the task in our Mattermost board. I’ll be updating its contents with suggestions from this thread. Feel free to contribute directly to the board!