Steganography NFT: What can it be used for?

[aminazgol]

This post is a follow-up to the official Zenon medium post on Steganography NFTs. In this post, I would like to open a discussion on the possible applications that Steganography enables in an NFT ecosystem.

It is important to understand the difference between Steganography and Cryptography from a use-case standpoint. Then you can argue that some of the use-cases for Steganography are actually possible to do with Cryptography.

Steganography is basically a higher level of security compared to Cryptography. When two parties are using cryptography, a third party can be aware of communication happening but they cannot reveal the actual messages being communicated. But Stegonagraphy is used when parties what to conceal the fact that communication is taking place and no third party can have a clue that some messages had been exchanged.

Steganography is expected to be a more resource-intensive process compared to cryptographic methods as it’s working with multimedia objects. So it is not logical to do an application using Steganography if it’s possible to be done by cryptography.

Examples:

Treasure hunt: An artist claims that in his next collection, only one of the NFTs contains a secret steganography text which is a 12 word phrase of a wallet with 1 BTC in it.

The fact that everyone knows that one NFT contains a message, makes it convenient to do this use-case by cryptography rather than Steganography.

For this case, we know that NFTs have metadata and the artist can add a reward attribute to the metadata of the NFT in a form of a cryptographic text and that reward is only unlockable by the owner’s private key. This attribute is empty for all the NFTs in the collection except for the one that is a treasure.

Some other examples of lottery, access to secret communities, discount codes, in-game items, and easter eggs, can similarly be done with cryptographic metadata.

The following is another example that also can be done with cryptography but I thought it’s cooler to do it with Steganography:

Multi Image NFT: An artist can list an NFT and claims it contains 5 arts in one file. If you buy it, you can unlock the file but you’ll only see 1 art out of 5. Depending on how many times this NFT had been passed on from one owner to another, the art content changes.

So in this forum, I wanted to ask the community to brainstorm on this matter and suggest use-cases for Steganography. I understand that sometimes we make doing things possible and we will be surprised by how creatively people will use it. But I think it’s worth raising the question at this stage.

What can we do with Steganography?

[0x3639]

Maybe some in game assets (NFTs), like a sword or gun, that have “programable” power. Maybe the power can be morphed or augmented by the player based on certain traits of the player. Basically smart objects in games.

[Zashounet]

A lot of cool and fun things can be done with all the mysteries Zenon has.
I have a few ideas cooking in my head, can’t wait to start working on this!

[aminazgol]

I get the idea, having a game object embedded within the NFT image. But this example also doesn’t have to be implemented with Steganography (the in-game object doesn’t have to be encoded into the image pixels) and could be implemented as a separate file linked to the NFT, therefore we avoid the intensive process of merging in the in-game object and the NFT image.

[coinselor]

From the original article, the use case that stands out the most to me is this:

Use-case: Embedded Unlockable Content

I have been a victim, and I have to admit I have also benefitted, from pirated media content. The reason anything can be pirated (and it’s the same reason bitcoin should have not existed) is that anything digital, just represents binary data that can be copied. Bitcoin was able to solve the issue for money.

Can the Zenon NFT standard solve the issue for everything else? This is what I’m extremely interested in. The article claims counterfeits become obsolete. But how exactly?

Let’s say I mint a numbered series of 100 NFTs that contain a 20min video course on how to sharpen a knife. I publish the first edition on Youtube for everyone to see publicly. Each holder of the NFT can also do some cryptgraphy + steganography wizardry in s y r i u s to unlock the content of another 20 minutes of secret pro tricks on knife sharpening.

Why can’t the person just ‘save as’ the content as he is watching it?

[aminazgol]

Well, to answer your last question I must say nothing stops them to ‘save as’ your content.
I explain my take on the article’s claim. quote from the article:

Moreover, adopting the Virtual Hologram will eradicate counterfeiting, the “Save as” method would be useless, as only the NFT holder will be able to authenticate the NFT using its embedded Virtual Hologram.

What this means is that there is something hidden inside the NFT that is only unlockable by the owner, so if other people ‘save as’ the NFT file they still cannot access the hidden content inside it. So that is why ‘save as’ is useless. But nothing is stoping the owner to copy the unlocked content.
So in your case, if someone buys the NFT and unlocks the video inside it, there’s nothing that can stop him/her from ‘save as’ or screen record your content and copy it somewhere else.

Now you mentioned it I did too think that this method can stop people from copying others’ NFTs as we can embed some information inside the pixels of the image/video that the network recognizes and deny any duplication of that image/video. But it’s obvious that editing the image is also as simple as copying it, so the virtual hologram can easily vanish if the person copying the file just changes the pixel saturation by 0.01 percent. So this is not possible to do with steganography!

[coinselor]

Perhaps there is a clever workaround to the issue if we think about it from the consumer side; instead of a fix to counterfeiting content we could mitigate it.

Would it be possible to stack two steganography layers on the same file? Meaning, the first layer unlocks the embedded content to the user, and the second layer hides the information like public address of owner, issue number, etc…

Once the unlockable content gets copied and redistributed, we could apply the same steganography techniques to figure out some information about the entity who did the copyright infringement.

Makes me wonder if there are current DRM techniques that employ cryptography/steganography in a similar way, and whether it’s effective or not.

It also makes me wonder what limiting factors applications would have with a ‘smart contract’ embedded in a virtual hologram if the owner is the only person capable of interacting with it.

[aminazgol]

It is possible to embed two layers of steganography on the same file. But regardless, current steganography algorithms are done in a very precise bit mapping approach. It means that if an image file has some steganography information inside, by changing only one bit (for example make one pixel of the image black) the whole steganography information inside the file will become unreadable.

[sol]

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.

The goal:

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:

1. tattooing a message on a clean-shaven scalp then waiting for the hair to grow back
2. painting four microscopic characters on a famous painting
3. a famous painting superimposed over a portrait that can only be revealed with XRF spectroscopy
4. 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:

1. The off-chain host for the data carrier must be trusted to provide a high degree of data integrity and availability.
2. Alternatively, if the NFT payload is just encrypted text, it could be hosted on-chain.
3. Is the unlockable content static or dynamic? If someone purchases an NFT and consumes its content, will it still have value?
4. Will the content be time-sensitive, like Time-based One-time Passwords (TOTP)?
5. 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:

1. 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.
2. 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!

[romeo]

@sol

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.

In your example - the embedded payload would be easily readable via a simple meta data reader correct? Or would it also be encrypted?

[sol]

For demonstration purposes, I opted to keep the data in cleartext.
The solution we implement would likely be obfuscated/encrypted, using other bytecode that isn’t human-readable.

[romeo]

@sol

The solution we implement would likely be obfuscated/encrypted, using other bytecode that isn’t human-readable.

Ok I see, thanks. Is there any reason why we couldn’t pursue both options in time? The method outlined in the article has it’s merits I believe and would be worth working on - perhaps starting with a single file type (most common NFT image type I guess)

[sol]

The constraint is dev time.

Given ample time and more devs working on this, I’d go for option 1, even though I think it’s a bit gimmicky. Sorry if that offends anyone. It’s one of those features that would certainly grab people’s attention if implemented correctly, though I’m not sure if it’s worth the effort required to pull off.

Like I mentioned, it would require specific solutions for each file type we want to support.
Does anyone disagree with this statement?

I’m afraid the launch would be lackluster and it might lose its flair if we marketed “Launching novel NFT Standard with hidden/unlockable content” and the caveat was “but we only support JPGs for the foreseeable future.”

In my mind, both options achieve the same goals; one is obviously a simpler implementation but I think it scales better than the original vision.

[0x3639]

@sol

The algorithm will inevitably be reverse-engineered to remove that payload, if there is value in doing so.

Just want to make sure I understand. Even if the payload is removed from the image, it should be protected with a password. Assuming the contents are secure, there should be no reason to remove the payload. Is that right?

[sol]

Assuming the contents are secure, there should be no reason to remove the payload.

Right, I personally don’t see reason why someone would want to strip a data carrier of its embedded content. I’m postulating that it could happen.
The data carrier is publicly accessible anyways; anyone can copy those bits – directly or indirectly – and use them as they please (“Save As”).
This applies for all tokenized media except for encrypted content (i.e. the public-facing bits are already encrypted.)

[sol]

I’ve been thinking about the technical details of the proposed NFT standard and I have some questions about the implementation, mostly with respect to limitations and design decisions. I apologize if my ramblings are incoherent.

Perhaps I’m boiling the ocean with my approach; ultimately, I’m trying to achieve a use case for steganography that is more than just single-use consumables.

Maybe I should just focus on the simplest implementation of steganography (LSB) and call it a day.

Some things to consider:

1. What if we want to temporarily or permanently reveal some of that embedded information to the world, or to certain people?
   • Context: medical records stored in the NFT. I want my doctor to have limited access to this information.
   • Alt context: OP’s post and the Multi-Image NFT.
   • Considerations:
     • multisig for NFT platforms
     • Certificate Authorities to revoke permissions after a time period has expired
2. Do we want to embed an encrypted payload in every token that’s minted, even if the payload is empty?
   • Context: anti-steganalysis mechanism where even if a data carrier is correctly identified to be a Zenon NFT, an adversary wouldn’t know if the embedded data is useful or not.
   • Counterpoint: If an adversary suspects there is embedded data in a carrier, steganography has failed its purpose.
   • Perhaps we will have two types of NFTs: immutable and mutable (as suggested by George)
   • Note: I am hard-pressed to identify a reason to combine steganography with an immutable NFT beyond one-time consumables.
3. If we do implement steganography in every token issued on NoM, then token transferability is limited to applications that can transcode the asset. Mobile and browser wallets will likely not be able to perform this task, or they may be limited to certain file types due to processing limitations.
4. The amount of data that can be embedded is largely bounded by the size of the container and the encoding method. I found an example of lossless steganography but it has some downsides that I think are unsuitable for our project (listed in section IV.)
   • Steganography tends to be lossy; the original bits are being manipulated and this can introduce visual artifacts that are perceivable to the human eye.
   • As more of the original data is replaced, embedded capacity increases, but so does “noise” in the carrier data.
   • My pseudo-steganography PoC enables virtually limitless container sizes, introduces no noise in the carrier data, but the presence of embedded data is trivial to detect.

Here’s some literature that I found interesting, particularly from page 16 onwards: Magic LSB Substitution Method (M-LSB-SM)

[coinselor]

ZK and homomorphic encryption might be relevant for the privacy preserving medical records use case. Here’s a neat implementation on eth to make data types private:

ZeeStar: Private Smart Contracts by Homomorphic Encryption and Zero-knowledge Proofs

[TrevorLeahy3]

Seems to me that multi sig built in could have a big impact on use cases for tokenizing real world assets or just shared digital ones.

I dont know about the multi image idea though, other than digital collectables or consumables not sure about practical usecases, more so just creative. What can you do with a multi image nft that you cant do with multiple seperate images and a smart contract?

What i keep coming back to is the special attestation idea and how useful/important it would be to be able to easily assert your ownership of an NFT on chain but also understood this was mainly done thru the metadata.

If this function needs steganography then every token minted should have the capacity to hold an encrypted payload but it also makes the practise public so doesnt really make as much sense.

If the assertion can be made outside of any steganography tools then more effort could be made into hiding the embedded data, which the Magic LSB Method sounded pretty good at.

[sol]

I revisited the NFT Standard article and determined that my initial idea of pseudo-steganography is likely the only viable way to achieve Mr Kaine’s vision. I don’t see any other way, based on research I’ve done about modern steganography capabilities.

I’ll explain why in this post.

TL;DR
I propose that we concatenate an encrypted, variable size data container to carrier data. We may potentially use LSB to embed the Virtual Hologram in the carrier data.

---

Excerpt from the Medium Article:

When you create an NFT, you should have the option to add additional content that can only be revealed by the NFT holder. Such content can be anything.
High definition content, messages, video content, access to secret communities, discount codes, or even smart contracts, treasures, and easter eggs are all potential candidates for unlockable content.

---

Mr Kaine knows people will be minting JPEGs, but stipulates that the solution should permit any content to be embedded in the carrier data.

I only know of one way this can be achieved.
Since the embedded data can be of variable size and can potentially be greater than the size of the original carrier data, we must find a steganographic technique that:

• is extremely flexible,
  • in terms of file size, file type
• is cryptographically malleable
  • in terms of asset transferability
• is not constrained by the size of the input data
• can be parsed by anyone to certify authenticity (Spectral Attestation)
• ideally, is accessible to mobile wallets and devices with less compute capabilities

---

A core limitation of modern steganographic techniques is the size of the carrier.

Generally, steganography introduces changes in the original file’s data in order to hide other data; replacing original data with anything else tends to lead to data loss.
You can’t replace bits and expect all the information to remain intact.

Of course, slight changes to the file may be imperceivable to humans, but there’s a relation between how much data that can be stuffed in carrier bits and visual/auditory/spatial degradation of carrier data quality.

Low impact to original bits
- more likely to maintain original file quality
- less capacity for the embedded file

Higher impact to original bits
- less likely to maintain original file quality
- more capacity for the embedded file

This is why steganography is generally lossy. Same applies to compression.

About lossless steganography...

There are few lossless solutions and they do not fit our needs. They rely on the chance that the carrier data contains the same subset of bits as the embedded data.
I’m not confident this will work for every file and users cannot be limited by their selection of files.
If you find any lossless solutions that could work in our context, please let me know.

---

Mr Kaine outlines two options in his article: LSB and BPCS.

LSB is primitive, popular, easy to implement for many file types, but it has the embedded data size constraint.

BPCS is a newer technique that depends on spatial noise in the carrier data to hide information, and it seems to be only applicable to image files.
It works well with image data of a realistic setting with lots of different shades, colors, edges, objects, etc, but fares poorly with flat, cartoon-like graphics.
It takes advantage of visual chaos; cartoons tend to have large areas of the same pixel color.

For example, BPCS would offer much higher capacity for the image on the left.

---

The final reason why those two methods won’t work – We need to encrypt the embedded contents, because our software is open source and the ledger is public.

A malicious actor will scrape all the carrier data by querying the ledger and extract the embedded payloads of each NFT.

I’ve tested AES-256-CBC and AES-256-GCM in Dart; we should expect ~4x file size output or greater. I could try other encryption schemes, as well.

Some results from a few tests:

Show results

Input files

• input.png = 180 KB
• secret.png = 120 KB
• secret.mp4 = 17230 KB

Unencrypted Output

• input.png + secret.png => output.png = 299 KB
• input.png + secret.mp4 => output.png = 17410 KB

AES-256-CBC Output

• input.png + encrypted(secret.png) => output.png = 907 KB
• input.png + encrypted(secret.mp4) => output.png = 105174 KB

AES-256-GCM Output

• input.png + encrypted(secret.png) => output.png = 908 KB
• input.png + encrypted(secret.mp4) => output.png = 78925 KB

Here’s some binwalk output, they’re all the same:

Show binwalk output

$ binwalk output.png

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             PNG image, 900 x 900, 8-bit/color RGBA, non-interlaced
41            0x29            Zlib compressed data, compressed

Visual representation of my proposal:

Note: The Virtual Hologram (VH) is likely to be a small value, like the container’s header (H) and trailer (T).

Alternatively, since the Virtual Hologram may be short and a fixed length (tbd), we could potentially leverage LSB to embed that in the carrier data for all file types.

---

I’ve updated my pseudo-steganography PoC but haven’t published it yet.
There are still some cryptography-related logistics I need to work out.

I welcome any feedback regarding my posts on this topic. I’m seeking criticism of the approach, in case there are flaws I haven’t considered.

If I don’t hear from anyone, I might just “do it myself.”

[romeo]

I have thoughts on this, but need time to sit down and respond. Agree with most of your points