Systems and methods for using non-fungible tokens for wallet backup and secret sharing

Abstract

Methods and systems for hiding secret messages or data in an NET are described. A system may access data specified by a user to embed within a digital asset. The system may determine a steganography scheme to use to embed the data and embed the data within the digital asset according to the steganography scheme. The system may store the digital asset embedded with the data on a decentralized storage network and receive an associated first Uniform Resource Identifier (URI). The system may create, using the first URI, a metadata of the digital asset embedded with the data. The system may store the metadata on the decentralized storage network and receive an associated second URI. The system may create a non-fungible token (NET) based on the second URI and store the NET on a blockchain. The user or other users may subsequently retrieve the digital asset from the decentralized storage network and extract the data embedded therein.

Description

ATTORNEY DOCKET PATENT APPLICATION 088603.01091 of 43Systems and Methods for Using Non-Fungible Tokens for Wallet Backup and Secret SharingTECHNICAL FIELD

[0001] This disclosure generally relates to utilizing a non-fungible token (NFT) for cryptocurrency wallet backup or as a secret- sharing medium. In particular, the disclosure relates to techniques for embedding a secret message and / or backup data in a digital asset using steganography and storing the digital asset with embedded message / data on a decentralized storage network.BACKGROUND

[0002] Non-fungible tokens (NFTs) are digital assets that represent ownership or proof of authenticity of a unique item or piece of content, typically stored on a blockchain. An NFT is considered non-fungible because each one is unique. For example, an NFT may be created for a photo, a video, an audio file, or any other digital object, item, or format. Once an NFT is created, it is tokenized or minted on a cryptocurrency service such as a blockchain, thereby securing the NFT’s ownership (i.e., the ownership history of the NFT is permanently stored on the blockchain and cannot be altered).

[0003] Blockchain is a decentralized, distributed ledger technology that records transactions across multiple computers, ensuring that registered transactions cannot be altered retroactively. This technology offers numerous benefits, including decentralization, transparency, immutability, and security. These features make blockchain particularly suitable for storing ownership information of NFTs (non-fungible tokens). For example, NFT ownership information secured by the Ethereum blockchain is both secure and publicly accessible, enabling the verification of authenticity and ownership. This ensures that no one can alter the record of ownership or create a new NFT by simply copying and pasting the digital asset; the copied asset would not be recognized as the original, authentic instance. These properties of blockchain and NFTs make them highly effective for tracking copyright ownership and maintaining records of digital assets, which is why they have become popular in the digital art world.ATTORNEY DOCKET PATENT APPLICATION 088603.01092 of 43SUMMARY OF PARTICULAR EMBODIMENTS

[0004] NFTs typically involve storing the digital asset itself on a decentralized storage network, such as the Interplanetary File System (IPFS). The NFT's metadata, which includes details about the digital asset and its storage location on the network, is then minted and secured on a blockchain. This approach ensures that the digital content remains decentralized and accessible while the blockchain provides a secure and immutable record of the asset's ownership and metadata.

[0005] Embodiments described herein leverage the accessible and secure nature of NFTs to store secret messages. Examples of secret messages include, but are not limited to. digital wallet backups, passwords, confidential communications, or any other private digital file (e.g., images, audio, video). The secret message can be concealed within an NFT asset, which is stored on a decentralized storage network. While the NFT remains publicly accessible, the hidden secret message is decipherable only by those who know how to decode it. In particular embodiments, the secret message is encrypted and hidden within the NFT asset using steganography. Additionally, the security of the secret can be enhanced by obfuscating the exact location within the NFT asset where the message is hidden. Thus, even if an unauthorized party is aware that the NFT asset contains a hidden message, deciphering it would be challenging without knowing the precise location of the concealed payload.

[0006] The following numbered examples represent embodiments of the present disclosure.

[0007] Example 1 - a method including, by a computing system: accessing data specified by a user to embed within a digital asset; determining one or more steganography schemes to use to embed the data; embedding the data within the digital asset according to the one or more steganography schemes; storing the digital asset embedded with the data on a decentralized storage network; receiving, from the decentralized storage network, a first uniform resource identifier (URI) identifying the digital asset embedded with the data; creating, using the first URI, a metadata of the digital asset embedded with the data; storing the metadata on the decentralized storage network; receiving, from the decentralized storage network, a second URI identifying the metadata; creating a non-fungible token (NFT) based on the second URI associated with the metadata; and storing the NFT on a blockchain.ATTORNEY DOCKET PATENT APPLICATION 088603.01093 of 43

[0008] Example 2 - the method of Example 1, further including: retrieving, using the first URI, the digital asset embedded with the data from the decentralized storage network; and extracting, using the one or more steganography schemes, the data embedded within the retrieved digital asset embedded with the data.

[0009] Example 3 - the method of any one of Examples 1 to 2, wherein the one or more steganography schemes include a pseudo-random placement scheme for determining pseudorandom locations in the digital asset at which to embed portions of the data.

[0010] Example 4 - the method of Example 3, wherein the pseudo-random placement scheme uses an encryption key associated with the user to compute the pseudo-random locations.

[0011] Example 5 - the method of any one of Examples 3 to 4, wherein the pseudo-random placement scheme computes pseudo-random intervals between the pseudo-random locations in the digital asset.

[0012] Example 6 - the method of any one of Examples 3 to 5, wherein: the digital asset is an image; the pseudo-random locations correspond to identified pixel locations in the image; and each of the identified pixel locations in the image has color values that are respectively associated with three color channels.

[0013] Example 7 - the method of Example 6, wherein embedding the data within the digital asset according to the pseudo-random placement scheme includes: for each of the identified pixel locations, overwriting a least significant bit of at least one of the color values associated with that identified pixel location with a portion of the data, wherein said at least one of the color values is associated with a selected color channel of the three color channels.

[0014] Example 8 - the method of any one of Examples 1 to 7, wherein the one or more steganography schemes include a frequency obfuscation scheme, and wherein embedding the data within the digital asset according to the frequency obfuscation scheme includes: for each pixel location in the image other than the identified pixel locations, overwriting a least significant bit of a color value associated with that pixel location with noise, wherein the color value is associated with the selected color channel.

[0015] Example 9 - the method of Example 8, further including: determining to use the frequency obfuscation scheme based on an analysis of a background portion of the image.ATTORNEY DOCKET PATENT APPLICATION 088603.01094 of 43

[0016] Example 10 - the method of any one of Examples 1 to 2, wherein the one or more steganography schemes include a sequential placement scheme for determining sequential locations in the digital asset at which to embed portions of the data.

[0017] Example 11 - the method of any one of Examples 1 to 10, wherein the one or more steganography schemes are selected from a plurality of steganography schemes based on an analysis of a size of the digital asset and a size of the data, wherein the plurality of steganography schemes includes at least a pseudo-random placement scheme and a sequential placement scheme.

[0018] Example 12 - the method of any one of Examples 1 to 11. wherein the plurality of steganography schemes further includes a selection of one or more color channels of the digital asset to use for embedding the data.

[0019] Example 13 - the method of any one of Examples 1 to 12, wherein the data is encrypted.

[0020] Example 14 - the method of Example 13, further including: accessing a master encryption key associated with the user; and deriving a plurality of child encryption keys from the master encryption key using a key derivation scheme, wherein a child encryption key of the plurality of child encryption keys is used to encrypt the data.

[0021] Example 15 - the method of Example 14, further including: sharing the child encryption key with a device associated with a second user with whom the user wants to share the data, wherein the child encryption key enables the device to decrypt the data after the device retrieves the digital asset embedded with the data from the decentralized storage network and extracts the data from the retrieved digital asset embedded with the data.

[0022] Example 16 - the method of any one of Examples 13 to 15, further including: jointly creating a shared encryption key with a group of users that includes the user; and encrypting the data using the shared encryption key.

[0023] Example 17 - the method of any one of Examples 1 to 16, wherein the data to embed within the digital asset includes one or more of: a secret message intended for another user; or a backup of a cryptocurrency wallet associated with the user.

[0024] Example 18 - the method of any one of Examples 1 to 17, wherein the digital asset is or further includes one of an image, a video, or an audio.ATTORNEY DOCKET PATENT APPLICATION 088603.01095 of 43

[0025] Example 19 - In some aspects, techniques described herein relate to one or more computer-readable non-transitory storage media embodying software that is operable when executed by a computing system to perform the method of any one of Examples 1 to 18.

[0001] Example 20 - In some aspects, the techniques described herein relate to a system including: one or more processors; and one or more computer-readable non-transitory storage media coupled to the one or more processors and including instructions operable when executed by the one or more processors to cause the system to perform the method of any one of Examples 1 to 18.BRIEF DESCRIPTION OF THE DRAWINGS

[0002] The patent or application file contains at least one drawing executed in color. Copies of this patent or patent application publication with color drawing(s) will be provided by the Office upon request and payment of the necessary fee.

[0003] FIG. 1 is an example interaction / flow diagram showing one exemplary process for storing backup data and / or secret message(s) on a decentralized storage network and blockchain.

[0004] FIG. 2 illustrates an example method for retrieving a digital asset (e.g., image) from a blockchain and message / data embedded in the digital asset.

[0005] FIG. 3 is a block diagram illustrating an example process involving a creator embedding an encrypted message in a digital asset (e.g., NFT image) and storing the digital asset on a storage network, and a reader retrieving the digital asset and extracting and decrypting the hidden message from the digital asset.

[0006] FIG. 4 illustrates an example of embedding or hiding a secret message within an image.

[0007] FIG. 5 illustrates an example of embedding nested messages within an NFT digital asset.

[0008] FIG. 6 illustrates an example of embedding an audio clip in an NFT image.

[0009] FIGS. 7A and 7B illustrate two example backup configurations associated with a cryptocurrency wallet. In particular, FIG. 7A illustrates a single key wallet backup configuration associated with a user of a client device. FIG. 7B illustrates another example backup configuration in a multi-party computation (MPC) scenario.ATTORNEY DOCKET PATENT APPLICATION 088603.01096 of 43

[0010] FIG. 8 illustrates an example image with a single-color background, causing the need for a frequency obfuscation mode to embed data within a digital asset.

[0011] FIG. 9 illustrates an example method for embedding a message and / or data in a digital asset (e.g., image) and storing the embedded message / data as NFT on a decentralized storage network.

[0012] FIG. 10 illustrates an example computer system on which embodiments described herein may be implemented.DESCRIPTION OF EXAMPLE EMBODIMENTS

[0013] NFTs have gained significant popularity among cryptocurrency users. Because of the secure, transparent, and immutable nature of NFTs, NFTs have been utilized for various purposes, the most well-known of which are digital art, collectibles, and smart contracts.

[0014] A high-level NFT framework involves several key components and processes: selecting a blockchain platform (such as Ethereum®) and appropriate token standards (like ERC- 721 or ERC-1155), creating and storing digital assets on decentralized storage networks (such as IPFS), and minting these assets as NFTs using smart contracts. When an NFT is stored on a decentralized storage network, a corresponding URI is created to specify the location where the NFT is stored uniquely. The URI is generated based on the particular NFT instance. Thus, if the NFT changes (e.g., if the digital image of the NFT is altered), a different URI will be generated. In other words, each NFT on the decentralized storage network has a unique URI and is immutable. The URI, along with other metadata of the NFT, is then used to mint the NFT on the blockchain. In this manner, ownership information of the NFT is securely registered on the blockchain, and the actual digital data of the NFT (e.g., an image of a digital artwork) is separately stored on the decentralized storage network and typically accessible to anyone with the NFT’s URL

[0015] The embodiments described herein leverage NFTs' accessible yet secure characteristics to store and potentially share private messages or data (also referred to as secret or hidden messages). Such private messages or data may be read or accessed by the creator / owner of the NFT or a select group of individuals who are given read access. Thus, even though the digital asset of the NFT is accessible to the public, the private message hidden within the digital asset can be configured to be only readable by those who are given read access.ATTORNEY DOCKET PATENT APPLICATION 088603.01097 of 43

[0016] The hidden message hidden within an NFT could be any digital data. For example, the hidden message within an NFT may be utilized as a backup for cryptocurrency wallets. Most cryptocurrency wallets (e.g„ BIP32 / 39 single key, multi-party computation (MPC), smart wallet) recommend that users create a backup to store mnemonic words, private keys, or private key shares. Conventionally, a user could store the wallet backup on a personal device or server. However, storing important data on a personal device poses several risks and challenges, including theft, loss, hardware failure, malware, unauthorized access, and lack of redundancy. An alternative is storing the wallet backup on a third-party provider’s cloud service, but doing so has shortcomings, including security and privacy concerns. There is always a risk of data breaches or unauthorized access by malicious actors, as third-party servers are common targets for cyberattacks. The data's privacy may also be compromised if the provider accesses or shares it without consent. Dependence on the third-party provider further means that any downtime, service disruption, or data loss on their end directly affects data availability. Additionally, there may be compliance and regulatory issues if the third-party server does not meet the required standards for data protection. Lastly, users may face limited control over their data and potential challenges in ensuring data portability or complete deletion upon termination of the service.

[0017] The shortcomings of conventional approaches can be addressed by storing a wallet backup using NFT, according to the embodiments described herein. The NFT framework provides the user with a trustless and more reliable backup. As will be described in further detail below, a wallet backup could be hidden within an NFT, such as an image, video, or any other digital file. The NFT could then be minted and stored on a decentralized storage network. The immutable nature of NFTs ensures the integrity of the NFT, along with the data hidden within it. Authenticity is also ensured since the NFT’s ownership is securely logged on the blockchain. Lastly, since the NFT is stored on a decentralized storage network, the user would not have to place trust in any particular third-party service provider.

[0018] Aside from wallet backups, embodiments described herein may be used to store and share secret messages with select parties. For instance, secret messages may be embedded in an NFT. For example, private letters or messages between couples or close friends can be hidden and shared securely using NFTs without the risk of censorship or third-party viewership. With conventional messaging systems (e.g., email or chat systems), users have to trust the serviceATTORNEY DOCKET PATENT APPLICATION 088603.01098 of 43 providers to protect their privacy and not sensor content. Using NFTs as a medium for secretsharing eliminates this trust issue, as the data is protected and censorship-resistant.

[0019] As will become more apparent with the detailed descriptions below, the techniques described herein are advantageous in various applications in which data privacy, security, integrity, and data availability are important. While the examples below use wallet backup and secret sharing to illustrate the technical concepts, the embodiments described herein are not so limited and can be used in other applications as well. For example, NFTs could also store authentication credentials (e.g., passwords), financial information, legal documents (e.g., wills and trust), private communications, and backup and recovery keys, among others.Example Workflows for Utilizing NET for Backup / Secret Sharing

[0020] As previously described, embodiments described can leverage an NFT workflow. FIG. 1 is an interaction / flow diagram 100 illustrating example interactions between a client application 102, a decentralized storage network 104, and a blockchain 106. In particular, FIG. 1 provides a high-level NFT workflow showing one exemplary process for storing backup data (e.g., cryptocurrency wallet key(s), passphrases, mnemonic words, etc.) and / or secret message(s) on the decentralized storage network 104 utilizing NFT. It should be noted that the interaction / flow diagram shown in FIG.l is for exemplary purposes only and is not limited to these interactions. The present disclosure for hiding secrets in NFTs could be implemented using other NFT workflows as well.

[0021] In FIG. 1, client application 102 may be a software application running on a user's client device (e.g.. mobile device, desktop computer). For example, the client application 102 is a cryptocurrency application that allows the user to buy and sell various cryptocurrencies and other digital assets, such as NFTs. The decentralized storage network 104 is a system where data is distributed and stored across multiple nodes on a peer-to-peer network rather than relying on a single central server. Doing so splits data into fragments and spreads them across various computers, thereby enhancing security and reliability and preventing a single point of failure. As an example, the decentralized storage network 104 is an Interplanetary File System® (IPFS), which is a decentralized peer-to-peer network through which data is stored and shared across multiple computers around the world, making it highly resilient and resistant to censorship. The decentralized storage network 104 can be used with blockchain technology to track NFT dataATTORNEY DOCKET PATENT APPLICATION 088603.01099 of 43 locations and transactions. The blockchain 106 is a digitally distributed, decentralized, public ledger that exists across a network of computers. The blockchain 106 stores data in blocks linked together in a chain. The data is chronologically consistent because one cannot delete or modify the chain without consensus from the network. Popular examples of a blockchain 106 used for NFT include Ethereum® and Solana®.

[0022] Referring now to the interaction / flow diagram 100, the process begins with the client application 102, at block 110, determining a secret message or backup data to embed in a digital asset. For example, a boyfriend has a private message that he wants to share with his girlfriend. As another example, a user wants to store a backup of his cryptocurrency wallet, such as a private encryption key(s), a passphrase(s), mnemonic words, etc. The user may provide such a secret message and / or backup data to the client application 102 and instruct it to hide the secret message or data within an NFT, such as an image / photo, a video, or any other digital asset. The message / data are embedded in the digital asset so that their presence is concealed when the asset is being viewed. For example, if the secret message / data is hidden within an image, another party viewing the image could only perceive the image without perceiving the hidden message / data. The technique for hiding the message is broadly called steganography. FIGS. 4 to 7B illustrate some examples of hiding or embedding a message / data within an image, which will be described in further detail later.

[0023] Referring again to FIG. 1, after the client application 102 receives the instruction to embed the message / backup data in an NFT, it may optionally encrypt the message / backup data at block 112. If the user finds it acceptable for unintended parties to read the hidden message, they may choose to leave the message / data unencrypted. For instance, an artist minting their digital artwork in an NFT might wish to hide a signature or public message within the digital artwork, such as the name of the artwork. This message is intended to be discovered and read by those who find it, and in such cases, the user may intentionally leave it unencrypted. In scenarios where the user wants to ensure that only intended recipients can read the hidden message / data, the user can instruct client application 102 to encrypt the message / data. Encryption techniques based on encryption keys can be used for this purpose. The choice of encryption technique depends on the particular use case. Detailed examples of encryption methods and key- sharing mechanisms to enable others to decrypt the hidden message / data are provided elsewhere herein.ATTORNEY DOCKET PATENT APPLICATION 088603.010910 of 43

[0024] At block 114, the client application 102 may embed the message / data (encrypted or not) in a digital asset, such as, for example, an image or any other type of digital asset. Client application 102 may use one or more steganography techniques to embed or hide the message / data in the digital asset. For instance, in one embodiment, a sequential placement technique is used where one or more digital bits of the message are stored in each pixel of an image sequentially (or according to a pre-determined pattern). For example, the least significant bit of each color channel of each pixel may be overwritten to store a single bit of the hidden message. For instance, if each color channel (e.g., red, green, or blue channel) is represented by 8 bits, the least significant bit of a color channel of a pixel can be used to store 1 bit of the hidden message, leaving 7 of the more significant bits to encode the color value of that color channel of the pixel. Since there are typically three color channels in a pixel, each pixel could hide 3 bits of the hidden message. The hidden bits across multipole color channels of multiple pixels together form the digital information of the hidden message. Thus, when extracting the hidden message from the digital asset, the application performing the extraction would need to know which bits in the digital asset correspond to the hidden message and reassemble those bits to reconstruct the hidden message. When an image / photo viewer displays the digital asset, the viewer will generate colors corresponding to the complete bit depth (e.g., 8 bits per color channel) without knowing about the hidden message. Since the least significant bit is overwritten or replaced by a portion of the hidden message, the inclusion of the message in the digital asset amounts to noise when the image is displayed. However, since the more significant bits still represent the original color of the digital asset, the image would still appear similar to the original version, especially to the naked eye.

[0025] To further minimize the impact of the hidden message on the appearance of the digital asset, another approach is to hide the hidden message using the red and / or blue channels only because the human eye is less sensitive to those color channels. Since the human eye is more sensitive to the green channel, this approach leaves the green channel untouched when embedding the hidden message. When the digital asset is displayed, only the red and / or blue channels will include noise due to the hidden message. However, the noise would be less perceptible since the user’s eyes are not as sensitive to the red and blue channels.

[0026] In the aforementioned steganography examples, the locations where messages or data are stored within a digital asset are predictable. For instance, one could extract the leastATTORNEY DOCKET PATENT APPLICATION 088603.010911 of 43 significant bits of each pixel's red and / or blue channels in a digital image to reassemble the hidden message or data. Since the digital asset may be stored on a decentralized storage network and accessible to the public, anyone could analyze the digital asset and identify the pattern used to hide the message or data. Therefore, it is important to encrypt the hidden message or data to prevent unauthorized access.

[0027] The hidden message or data can be made more secure if its storage location within the digital asset is unknown to unauthorized persons. Without knowing where to find the hidden message or data, unauthorized persons cannot attempt decryption. Thus, certain embodiments described herein focus on methods for concealing the locations where bits of hidden messages or data are stored within a digital asset. For example, instead of storing bits of a hidden message or data sequentially in the pixels of an image, specific embodiments employ a pseudo-random placement technique, where the storage locations are determined by calculated pseudo-random intervals between pixels used for hiding data. In another embodiment, a frequency obfuscation technique is used, where the entire least significant bit (LSB) of the image's pixels (e.g., RGB pixels, B-only pixels, or R-only pixels) is overwritten with random noise, combined with the pseudo-random placement of the hidden message / data. With many different steganography options that can accommodate various sizes of hidden data, particular embodiments of application 102 determine the best possible hiding methods given the size of the hidden message / data and the size of the digital asset. For example, when embedding hidden messages / data within a digital image, application 102 may use a single color channel (e.g., red or blue channel) if there is a sufficient number of pixels to hide the given message / data. Doing so would minimize the perceptible noise introduced by the hidden message / data in the digital image. If using a single color channel is insufficient, application 102 may use two color channels (e.g., red and blue) or all three color channels (e.g., red. green, and blue). The application 102 may also selectively use sequential vs. pseudo-random placement schemes, depending on the size of the hidden message / data and the digital asset. The pseudo-random placement mode is generally preferred to enhance security, but the relative size difference between the hidden message / data and the digital asset would need to be greater. Detailed descriptions regarding how the message / data is embedded into the digital asset and the different steganography techniques are covered and / or discussed in further detail elsewhere herein.ATTORNEY DOCKET PATENT APPLICATION 088603.010912 of 43

[0028] Once the message / data is embedded in the digital asset, the client application 102 may proceed with minting the NFT. At block 116, the client application 102 may store the digital asset with the embedded message / data in the decentralized storage network 104, such as IPFS®. At block 118, the decentralized storage network stores the digital asset with the embedded message / data. For example, the decentralized storage network stores an image with an embedded secret message, such as image 408 shown in FIG. 4. Based on the data being stored, the decentralized storage network would generate a corresponding uniform resource identifier (URI), uniquely specifying the location where the digital asset is stored on the network. The client application 102, as indicated by reference numeral 120, may receive the uniform resource identifier (URI) of the digital asset that is stored in the decentralized storage network 104.

[0029] At block 122, the client application 102 may create metadata of the digital asset (e.g., image) using at least the digital asset’s URI. The metadata may include, for example and without limitation, the digital asset’s description, features, location, etc. As indicated by reference numeral 124, the client application 102 may store the metadata of the digital asset in the decentralized storage network 104. At block 126, the decentralized storage network (e.g., IPFS) stores the digital asset’s metadata (image’s metadata) and creates a corresponding URI. The client application 102, as indicated by reference numeral 128, may receive the URI of the digital asset’s metadata that is stored in the decentralized storage network 104.

[0030] At block 130, the client application 102 may create an NFT based on the URI of the metadata. In particular, the client application 102 creates the NFT, such as an NFT smart contract conforming to ERC-721 or ERC-1155, in which the metadata’s URI (called token URI) is stored on the blockchain 106. As indicated by reference numeral 132, the client application 102 may store the NFT or token URI corresponding to the digital asset’s metadata URI on the blockchain 106. At block 134, the blockchain 106 records the NFT or token URI.

[0031] Once the minting process is completed, the digital asset corresponding to the NFT is accessible via the decentralized storage network. A person may access the digital asset using its URI and optionally extract its hidden message / data. FIG. 2 illustrates an example method 200 for retrieving a digital asset (e.g., image) and extracting message / data embedded in the digital asset. Method 200 may be performed by a client application (e.g., software application, web browser) running on a user's client device. For instance, method 200 may be performed by the clientATTORNEY DOCKET PATENT APPLICATION 088603.010913 of 43 application 102 discussed in reference to FIG. 1. Alternatively, method 200 may be performed by a different client application running on a second client device associated with a second user.

[0032] Method 200 begins at block 202, where a client application reads an NFT or token URI from a blockchain, such as blockchain 106, shown in FIG. 1. The token URI provides the application with the storage location of the digital asset’s metadata on the decentralized storage network. At block 204, using the token URI, the client application reads or obtains the digital asset’s metadata (e.g., image metadata) from the decentralized storage network. As discussed above in reference to FIG. 1. the metadata may include the URI of the digital asset in the decentralized storage network. At block 206, using the digital asset’s metadata (e.g., including the URI of the digital asset), the client application obtains the digital asset (e.g., image) stored in the decentralized storage network. The resulting digital asset obtained in block 206 may include embedded encrypted secret message and / or backup data, as discussed above in reference to FIG. 1. For example, the resulting digital asset may be the image 408 in which a secret message is embedded, as shown in FIG. 4.

[0033] At block 208, the client application may decrypt the secret message and / or data embedded in the digital asset. This process involves extracting the hidden secret message / data from the digital asset and, if the message / data is encrypted, decrypting the extracted message / data using a suitable key. The client application would first determine the steganography scheme used to determine where the secret message / data is hidden within the digital asset (e.g., the color channels used, and / or whether sequential or pseudo-random storage locations are used). If the creator of the NFT owns the client application, it would already know the steganography scheme used or be able to obtain it from the creator. Suppose the client application belongs to another user. In that case, it may obtain the steganography scheme from the creator via any suitable communication means (e.g., via a QR code, chat message, secure email, etc.). Based on the steganography scheme, the client application may extract the relevant bits from the digital asset and reassemble the secret message / data.

[0034] If the reassembled secret message / data is encrypted, the client application will then decrypt it. A variety of encryption / decryption techniques may be used, depending on the desired use case. For example, if the secret message / data is to be read by the NFT creator only, the secret message / data could have been encrypted using the creator’s public key and decrypted using theATTORNEY DOCKET PATENT APPLICATION 088603.010914 of 43 corresponding private key. In use cases where the creator intends for others to read the secret message / data, the encryption / decryption technique used would need to be more flexible and scalable, which will be described in more detail elsewhere herein. At block 210, responsive to decrypting, the client application obtains the secret message and / or backup data embedded in the digital asset (e.g., image).

[0035] FIG. 3 is a block diagram that illustrates an example creation process 300 for embedding a secret message into an NFT and an example reading process 320 for extracting the secret message from the NFT. As depicted, a first user 302 may have a master encryption key 304. From this master encryption key, the first user 302 may create multiple child encryption keys 306a, 306b, ..., 306n (individually and / or collectively herein referred to as 306). The process for key creation / derivation is discussed in detail later below.

[0036] The first user 302 may instruct an application (e.g., client application 102) to embed a desired message 307 (or any other form of digital data) into an NFT. Using one of the child encryption keys 306, such as child encryption key 306c, the application may encrypt message 307 to create an encrypted message 308.

[0037] The application then embeds the encrypted message 308 in a digital asset 310, such as an NFT image. The application may determine the optimal steganography scheme for hiding the encrypted data / message 308 in the digital image 310. The application may use one or more of the steganography techniques described herein (e.g., sequential placement, pseudo-random placement, and / or frequency obfuscation) to embed the encrypted message 308 into the digital asset 310. Once the embedding is complete, the resulting digital asset 310 is stored in a decentralized storage network 312 (e.g., IPFS) using the NFT minting smart contract flow, as discussed in reference to FIG. 1.

[0038] FIG. 3 further illustrates an example process 320 for a second user 322 (e.g., another user or the first user 302) to decrypt and obtain the secret message 307 from the digital asset 310. In particular embodiments, the first user 302 may directly or indirectly share the encryption key 306c with the second user 322 (if they are the same person, no sharing would be necessary). The key 306c may be shared using any conventional means, such as sending it via a secure communication channel. The second user 322 may further obtain a token URI of the digital asset 310 from the first user 302 (again, if they are the same person, no sharing is necessary). TheATTORNEY DOCKET PATENT APPLICATION 088603.010915 of 43 token URI may be created using the NFT minting smart contract flow, as discussed in reference to FIG. 1. A client application associated with the second user 322 may obtain the digital asset 310 from the decentralized storage network 312 using the token URI, as discussed in reference to FIGS. 1 and 2. The client application may then analyze the digital asset 310 and extract the embedded encrypted message 308. The client application may determine the locations where bits of the encrypted message 308 are hidden by using the information provided by the first user 302 and / or metadata stored in the digital asset 310. For example, as described in further detail elsewhere herein, the client application may read the metadata stored in the LSBs of the first, e.g., 48 pixels in the digital asset 310 to determine the steganography scheme used for hiding data. Such information will allow the client application to find the hidden bits and reassemble them into the encrypted message 308. Then, the client application of the second user 322 may use the encryption key 306c to decrypt the data / message 308 to recover the hidden message 307.Examples of Embedding Secret Messages or Backup Data within a Digital Asset

[0039] As discussed elsewhere herein, secret messages (e.g., private messages between couples or friends) and / or user’s backup data (e.g., cryptocurrency wallet keys, passphrases, etc.) may be embedded or hidden within a digital asset, such as, for example and without limitation, within an image, video, audio, etc. For simplicity and ease of explanation, the digital asset is herein simply referred to as an image. FIGS. 4-7B illustrate examples of hiding or embedding a message / data within an image. Each of these figures is discussed below.

[0040] FIG. 4 illustrates an example of embedding or hiding a secret text message 404 within an image 402. To the naked eye, the resulting image 408 after the embedding looks nearly identical to the original image 402 before the embedding. Generally, to embed a message / data in an image, the user may provide a client application with a message / data (e.g., message 404) and an original image 402 in which the message is to be embedded. An image type that utilizes lossless compression is used so that the embedded secret message / data does not get corrupted after lossy compression / encoding. For example, PNG® uses a lossless compression algorithm called DEFLATE®. The client application may also ensure that the original image 402 in which to embed the message 404 is large enough to hide the secret. For example, a 512x512 pixels image may hide up to 512x512x3 bits if every color channel of every pixel is used to store one bit of the secretATTORNEY DOCKET PATENT APPLICATION 088603.010916 of 43 message 404. If the secret message is much smaller, the application may instead select to use only the red channel to hide the secret message 404, in which case the 512x512 image could accommodate up to 512x512x1 bits of hidden message. Further, as described in further detail elsewhere herein, if the secret message 404 is small enough not to require every pixel of the original image 402 to be used, the client application could instead use a pseudo-random pixel interval for hiding the secret message 404.

[0041] Once the suitable original image 402 is selected and loaded, binary data is parsed, and the image is decompressed and de-filtered to obtain the values of individual color channels of every pixel. For instance, the header chunk (e.g., IHDR in PNG) is read, and related information (e.g., bit depth) is extracted. Then, the image data chunk (e.g., IDAT in PNG) is read. This may include recovering the filtered data (e.g., de-filtering) for each scanline data. Specifically, each scanline of pixel data is applied by a filter to enhance the compression ratio and need to reverse the filter to view / manipulate the pixel data. Once that’s done, the secret message 404 is embedded or hidden in the image, such as image 402. For the minimum impact on the original image 402, generally the least significant bits (LSB) of the red, green, and / or blue channels of select pixels are replaced with a corresponding number of bits of the secret data. If the secret message 404 is small enough, then the message is hidden in the LSB of only red (R) or blue (B) pixels since the human eye is sensitive to green color (e.g., if only the LSB of the red and blue channels are used, then each select pixel could hide 2 bits of data). Next, a cyclic redundancy check (CRC) is performed to check the integrity of the image in which the secret message is embedded. For this, CRC (e.g., CRC-32 for PNG case) is re-computed on each data chunk, and then the CRC information is updated. Finally, the resulting image with the embedded message / data (e.g., image 408) is saved. This final step may include applying a filter to each scanline, compressing the image losslessly, and then saving image 408.

[0042] A message / data may be embedded in multiple layers in some embodiments. Any type of message can be embedded, and the nested messages can be of different media types (e.g., text, image, audio, video, PDF, etc.). As an example, FIG. 5 illustrates an example where a message / data 502 from a creator is first embedded into a first image 501 (other digital media may be used instead of an image) using any suitable steganography scheme described herein. This results in an embedded first image 506 that contains the message / data 502. Then, the embeddedATTORNEY DOCKET PATENT APPLICATION 088603.010917 of 43 first image 506 is embedded into a second image 510 (or any other desired media type) using the same or a different steganography scheme. The result is an embedded second image 512 that contains the embedded first image 506, which includes the secret message / data 502. To read the message / data 502, a client application would perform the reverse operations. For example, the client application would first extract the embedded first image 506 from the embedded second image 512 and then extract the message 502 therefrom (extraction may include decryption at each stage as needed). The client application performing this extraction process would need to obtain instructions from the original creator on the sequence of operations required.

[0043] It should be noted that a message / data to embed is not limited to text, binary data, passphrases, mnemonic words, or keys and that a variety of other types of files are also possible to embed and are within the scope of the present disclosure. For example, FIG. 6 illustrates an example of embedding an audio clip in an image. Specifically, FIG. 6 illustrates an example where an audio clip 604 (e.g., 30 seconds of winter sound) is embedded into an image 602, which is a 2048x2048 pixels image. The resulting image 608 with the embedded audio clip 604 looks identical to the original image 602 and conceals the presence of the audio clip 604. This example illustrates that any digital message / data can be embedded within another digital asset according to the embodiments described herein.

[0044] As mentioned, particular embodiments may use the techniques described herein to back up credentials associated with cryptocurrency wallets. FIGS. 7A and 7B illustrate two example backup configurations associated with a cryptocurrency wallet. In particular, FIG. 7A illustrates a single key wallet backup configuration associated with a user of a client device 702. The user of the client device 702 may have wallet credentials 703 associated with a cryptocurrency wallet (e.g., one or more mnemonic words, private keys, or private key shares) that the user wishes to back up by hiding them in an NFT on a decentralized storage network 706. The user may optionally encrypt the wallet backup data. Since the backup is intended for the user’s own use (i.e., it would likely not be shared), the client device 702 may use any suitable method to encrypt the wallet backup data, so long as the key needed for decryption is not shared with others. For example, the client device 702 may use a password, passkey, social security number, and / or biometric data (e.g., fingerprint, face, or retina recognition) to encrypt / decrypt the wallet backup data. The client device 702 may hide the wallet backup data (encrypted or not) in a digital asset using theATTORNEY DOCKET PATENT APPLICATION 088603.010918 of 43 steganography techniques described herein to create an embedded digital asset 704 that contains the hidden wallet backup data. Then, using the NFT workflow described with reference to at least FIG. 1, the client device 702 may mint the digital asset 704 into an NFT and store the digital asset 704 on a decentralized storage network 706 for later access.

[0045] FIG. 7B illustrates another example backup configuration in a multi-party computation (MPC) scenario. In the context of cryptocurrency wallets, MPC is a cryptographic protocol that allows multiple parties to jointly compute a function over their inputs (key shares) while keeping those inputs private. In simpler terms. MPC enables a group of participants to collaborate on generating and managing cryptographic keys without any single participant having full access to the keys. A predefined threshold of the key shares is needed in order to derive the credentials needed to authorize transactions on the wallet.

[0046] MPC wallets may utilize cryptographic protocols to distribute private key shares among multiple shareholders, such as 712a, 712b. and 712c, in a secure manner. The shareholders 712a-c may be different computing devices owned by the same person who owns the cryptocurrency wallet, or the shareholders 712a-c may be different persons with joint control over the cryptocurrency wallet. The shareholders 712a-c may wish to back up their respective key shares 713a-c in NFTs using the techniques described herein. As with the single key wallet embodiment described above, the shareholders 712a-c may optionally and independently encrypt their respective key shares 713a-c, and they may use independent encryption key(s) or mechanisms for encryption. The computing devices of the shareholders 712a-c may use the techniques described herein to hide their respective key shares 713a-c (encrypted or not) in digital assets. The embedded digital assets 714a-c, which respectively contain the key shares 713a-c, may then be minted and backed up on a decentralized storage network 706 (e.g., IPFS) using the NFT workflow, as discussed at least in reference to FIG. 1.Data Format for Steganography

[0047] In particular embodiments, the message / data being hidden or embedded has a prefix of metadata with a predetermined format to be used by a client application to uncover the hidden message / data. The following provides an example data format:Metadata (18B) I Data (a user message with variable length) I CRC (4B)ATTORNEY DOCKET PATENT APPLICATION 088603.010919 of 43In the above, “metadata,” which has a predetermined length of 18 bytes, represents the information configured to be used by a reader client application to uncover the hidden message / data. “Data,” which can be of variable length, represents the embedded message / data, which can be encrypted or unencrypted. “CRC,” which has a predetermined length of 4 bytes, represents an error-detecting code commonly used in digital networks and storage devices to detect accidental changes to raw data. The CRC portion in the message may include CRC-32 (IEEE 802.3 with the polynomial OxEDB 88320) on encrypted or non-encrypted data for data integrity checks when the data is recovered.

[0048] When preparing a message / data to be embedded, an application would generate corresponding metadata. Then, as part of the steganography process, the application would embed the metadata in the image before embedding the message / data and CRC. As an example, in the sequential RGB placement mode (e.g., one of the steganography techniques for embedding data in the LSB of all three color channels of each pixel of an image), discussed later below, the 18B of metadata are positioned before the data section in steganography, occupying the first 48 pixels of the image (48 pixels x 3 bits each = 144 bits = 18 bytes).

[0049] The metadata may include several pieces of information that will be used by the application to recover the hidden message / data. For example, the metadata may be formatted as follows:Metadata = Header (6B) I Length (4B) I Method (8B)Each of the header, length, and method portions of the metadata is discussed below.

[0050] The “header,” which may be 6 bytes in length, may include the following information:Header = Magic bytes (4B) I Message type (15b) I Encryption (lb)“Magic byes.” which may be 4 bytes in length (e.g., 0x53544547 or “STEG” in Ascii), may be a series of specific bits used to signal the presence of hidden data to trigger specific actions by the reading application. In response to detecting the magic bytes, the reader application would know that it needs to detect the rest of the header information and other metadata to uncover the hidden message / data. The “encryption” bit is reserved for flagging whether the hidden message / data is encrypted. For example, ‘1’ may indicate that the message / data is encrypted, and ‘0’ may indicate that it is not encrypted. This information would let the reader application know whetherATTORNEY DOCKET PATENT APPLICATION 088603.010920 of 43 decryption is needed. For data encryption, AES-256 in GCM mode is preferred. If not available, AES-256 in CBC mode is acceptable. Generally, CBC mode is more readily available in most cryptographic libraries. The “message type,” which may be 15 bits in length, is designated to explicitly list allowed file types in a whitelisting manner to prevent the inclusion of potentially malicious executables (e.g., .exe). The following is an example table illustrating different message types that may be included:

[0051] The “length” field in the metadata specifies the length of the hidden message / data, which can be encrypted or non-encrypted.

[0052] The “method” portion in the metadata specifies the particular steganography scheme used for hiding the message / data. The “method” field includes the following subfields: Method = Mode (2B) I N (2B) I Child key index (4B)The “N” portion, which may be 2 bytes in length, is a number used to determine the hiding pixel interval used in the pseudo-random placement technique (discussed further below). In short, the N specifies the maximum interval between pixels where hidden bits are placed. For example, given a generated value, e.g., 52, taking its modulo against an N-7 would result in 3, which corresponds to a pixel interval of 3 before the next pixel is used to hide data.

[0053] The “child key” field, which may be 4 bytes in length, is used in particular embodiments to identify the particular child key in a list of child keys needed to decrypt the hiddenATTORNEY DOCKET PATENT APPLICATION 088603.010921 of 43 message / data. The 4 bytes allocated to this field represent over 4.29E9 possible keys, which is more than enough for most applications. If the data is unencrypted, the child key index is ignored, and the child key is set to zeroes.

[0054] The “mode” field, which may be 2 bytes in length, represents the mode by which the data is hidden. The following table illustrates example mode types, each mode type indicating where the data should be hidden, a particular steganography technique (e.g., placement technique) used for hiding the data, and the implementation priority for that mode type:In the table above, pixel locations where data is hidden are determined based on a pseudorandom technique, as described elsewhere herein. In particular embodiments, the interval between pixels selected for hiding data is based on the “N” field used in the modulo operation, as described above. If the pixel interval modulo N is zero, then the pixel selection mode is equivalent to a sequential placement technique (discussed below) since there is no interval between selected pixels.Steganography Technique: Sequential Placement

[0055] When hiding a message in an image, two options may be considered for how the binary-converted message / data is hidden in a digital asset. These two options may include a sequential placement mode and a pseudo-random placement mode. As discussed above, the message's metadata occupies the first 48 pixels of the image, in particular embodiments. As such, the data and the CRC fields are stored starting from the 49thpixel, either sequentially or pseudo- randomly.

[0056] In the sequential placement mode, the message is stored in each pixel of the digital asset sequentially. For example, assume the message / data to be hidden corresponds to the binaryATTORNEY DOCKET PATENT APPLICATION 088603.010922 of 43 data “101110”. When storing data in all three color channels of every pixel sequentially (i.e., in RGB mode), this binary data may be stored as follows:1 -> 49thpixel’s R channel’s LSB0 49thpixel’s G channel’s LSB1 -> 49thpixel’s B channel’s LSB1 -> 50thpixel’s R channel’s LSB1 -> 50thpixel’s G channel’s LSB0 -> 50thpixel’s B channel’s LSB

[0057] In B mode, the binary data “101110” may be stored as follows:Steganography Technique: Pseudo-random Placement

[0058] In the sequential mode, although the data is encrypted, the public may at least see (or guess) the ciphertext because the data is written sequentially, which may not be desirable in some cases. The pseudo-random mode is designed to effectively hide the encrypted data itself by obfuscating the bit locations. The pixel interval is defined as follows:Pixel interval = hash (magic bytes I encryption key I hiding pixel index) modulo N

[0059] In this example, “hash” represents a particular hash function that takes as input a series of data (e.g., Secure Hash Algorithm 256-bit is an example of a hash function). In this particular example, the hash function takes “magic bytes” as part of its input, which may be a 4- byte value (e.g., 0x53544547, which is “STEG” in Ascii). The use of magic bytes is optional, but it is helpful to reduce the potential for rainbow table attacks. The hash function further takes the “encryption key,” which is the key used to encrypt the message / data, as input.

[0060] Using the encryption key as part of the algorithm for determining the pseudorandom pixel locations for hiding pixels ensures that only those who know the key can compute the pixel locations. Without the key, the locations cannot be computed. If the data is not encrypted, the encryption key would be a series of zeros.

[0061] In particular embodiments, the hash function takes the hiding pixel index as input. The series of hiding pixel indices correspond to the series of pixels where messages / data areATTORNEY DOCKET PATENT APPLICATION 088603.010923 of 43 hidden. For example, the pixel index 0x00 corresponds to the first pixel where data is hidden, pixel index 0x01 corresponds to the second pixel where data is hidden, pixel index 0x02 represents the third pixel where data is hidden, and so on. The pixel index field may be any length. For example, if the pixel index field has 4 bytes, the number of pixel indices can represent more than 4 billion pixels. In RGB hiding mode, where each pixel can hide 3 bits, 4 billion pixels would allow 12Gbits to be hidden, which is more than sufficient for most applications.

[0062] Based on the above, the hash function outputs a numeric hash output. The hash output is then divided by N to obtain a reminder (i.e„ hash output mod N). The application may select the value for N (e.g., a 1-byte value, a 2-byte value, etc.). Since the size of N dictates the maximum interval between pixels used for hiding data, there is a trade-off between hiding density and obfuscation level. A larger N means that the range of interval between pixels used for hiding data is greater (i.e., improved obfuscation level), but a larger possible interval also means fewer pixels are likely used for hiding data. The application should attempt to use the largest possible value of N to optimize the obfuscation level while ensuring that the number of pixels in the digital asset can accommodate the size of the hidden message / data. Practically speaking, as long as N is 2 or greater, it is computationally infeasible to extract the encrypted data (ciphertext) from an image from a reverse engineering perspective (except in cases where the image has a single-color background, which will be discussed in further detail below). As a reference, NIST recommends a security strength of 256b (e.g., AES-256): 2256« 1.16xl077. The typical backup or secret size is at least 32 bytes. For 32 bytes of data with N = 8, the adequate security is 8256~ 1.55xl0231, far beyond the recommended security strength. Note that if N=l, it is basically the same as the sequential placement. Getting the pixel interval is generally the most time-consuming part of this steganography algorithm.

[0063] By way of a non-limiting example, assume that:• Encryption key =0x5EHA2D321B495A5239A7A8F90D0C802BA337710DC70AF8B3B118BC23C37B C7D• N = 7• Data to hide: “011001110010”Hiding data in RGB color channels (e.g., mode 0x0010)ATTORNEY DOCKET PATENT APPLICATION 088603.010924 of 43Then, the message is embedded as shown in the following table (assuming the first 48 pixels are used to store metadata). Since the pixel interval between the first pixel (0x00000000) and second pixel (0x00000001) is 0, data is hidden at pixels #49 and #50 sequentially without a gap. The pixel interval after pixel index 0x0000001 is 1, according to the table above, so pixel #51 is skipped, resulting in the next chunk of hidden bits being stored at pixel #52. Lastly, since the interval after pixel index 0x00000002 is 6, the next chunk of data is stored at pixel #59.

[0064] Hiding messages or data pseudo-randomly makes them more challenging to find, but this approach reduces the maximum amount of data that can be hidden in a given digital asset compared to sequential storage methods. As can be seen from the table above, when using the pseudo-random placement approach, certain pixels might not hide any data. This results in a potential decrease in the maximum data size that could be hidden in a given digital asset. The table below compares data sizes that could be hidden in various digital images using different steganography placement modes.ATTORNEY DOCKET PATENT APPLICATION088603.0109 25 of 43

[0065] The table above demonstrates that the number of channels used for hiding data and the placement mode (i.e., sequential or pseudo -random) impact the data size that could be hidden in an image. Using the 512x512 image resolution as an example, the maximum data size that could be hidden in sequential pixels in all three RGB color channels is 98,304 bytes. If only one color channel is used (e.g., R or B) instead, the maximum data size that could be hidden in sequential pixels drops by one-third to 32,768 bytes. When using pseudo-random placement mode, the intervals between pixels where data are hidden are determined pseudo-randomly. As a result, the exact data size that can be hidden in the image cannot be determined ahead of time. If data is hidden in all three color channels using pseudo-random placement mode with a modulo of N=7, a 512x512 image could potentially accommodate 55,296 bytes of data on average and 12,288 bytes in the worst-case scenario (in other words, if the interval between pixels is always at the maximum given the modulo setting of N=7).

[0066] Thus, in particular embodiments, when a software application is considering the optimal steganography scheme to use, it would consider whether the scheme would allow the given digital asset (e.g., image) to accommodate the size of the message / data to be hidden. For example, the application would select a steganography scheme that allows the digital asset to accommodate the size of the message / data while minimizing the impact on the quality of the digital asset (e.g., using fewer color channels would have a lower impact on the image quality) and maximizing the difficulty level of finding the hidden message / data in the digital asset. For example, a message / data hidden using pseudo-random placement is harder to find than sequential placement, and a more extensive range of pseudo-random pixel intervals also makes finding the hidden message / data more difficult (i.e., a larger N value).

[0067] Thus, based on the given sizes of the digital asset and the message / data to be hidden, particular embodiments of the application would recommend one or more steganography schemes to the user. The application would then carry out the rest of the embedding and NFT workflow using the selected steganography scheme, as shown in described with reference to at least FIG. 1. If the message / data cannot fit within the digital asset under any steganography scheme or the user’ s preferred scheme, the application would inform the user so that the user could provide a largerATTORNEY DOCKET PATENT APPLICATION 088603.010926 of 43 digital asset, reduce the size of the message / data to be hidden, and / or select a different preferred scheme.Steganography Technique: Frequency Obfuscation

[0068] While most public steganography libraries are vulnerable to reverse-engineering tools that rely on pattern searching using conventional methods (e.g., sequential RGB, B-only, R- only, XY, YX, and diagonal analyses), the pseudo-random placement mode, discussed above, is highly effective against these tools. However, many NFTs. unfortunately, use a single-color background, as shown in FIG. 8. In such cases, advanced statistical or frequency-based analysis may reduce the effectiveness of the pseudo-random placement, although it cannot completely reveal the locations of the pixels that hide the message. To address this, another steganography technique is a frequency obfuscation mode, in which the entire LSB of the image’s RGB, B-only, or R-only pixels is overwritten with random noise, along with the pseudo-random placement of the message. In doing so, noise is introduced in the entire range of possible locations where data is hidden, thereby obfuscating the pixel locations where the actual message / data is hidden. This approach effectively equalizes the signal frequency, making the pseudo-random placement immune to all known reverse-engineering methods. Note that while the frequency obfuscation increases the data embedding time, it does not affect the data extraction time. While the noise introduced by the frequency obfuscation technique is beneficial from the standpoint of making reverse engineering more difficult, it also slightly worsens the appearance of the digital asset (due to the noise). Thus, in particular embodiments, the application may selectively determine whether to use the frequency obfuscation technique. For example, through either user selection or automatic detection of solid backgrounds (e.g., based on frequency analysis techniques), the application may determine whether to apply the frequency obfuscation technique (e.g., if there is a solid background or low-frequency change in the digital asset, the application may opt to apply the frequency obfuscation technique).Encryption Using Personal Private Key

[0069] As previously described, a user may optionally encrypt the secret message / data before embedding it into an NFT digital asset. Any suitable encryption technique may be used, depending on the use case. In scenarios where a user has a mobile and cloud-based Multi-PartyATTORNEY DOCKET PATENT APPLICATION 088603.010927 of 43Computation (MPC) system for securing a cryptocurrency wallet, deriving child keys from a master key would be beneficial to prevent key leaks. The master key may be generated using any suitable technique. For example, in the VSS-once (Verifiable Secret Sharing) approach, the mobile device generates a master NFT encryption key using AES-256. This key is then split into several shares and distributed to different shareholders. Except during key generation, the master NFT encryption key is never reconstructed.

[0070] When encrypting a message / data, a child key is derived from the master NFT key. Any suitable key derivation scheme may be used to derive the child encryption keys. For example, Bitcoin Improvement Proposal 32 (BIP-32) is a suitable scheme out of various key derivation schemes. BIP-32 supports both hardened and normal derivation. Utilizing BIP-32’ s non-hardened derivation has the implementation advantage of allowing related libraries to be reused, and nonhardened derivation makes it compatible with MPC wallets.

[0071] An example of a derivation path for a child key using BIP-32 is expressed as: Master key / Purpose key / Child key index. Key derivation may use the secp256kl elliptic curve, which is commonly used in the cryptocurrency context. The “Master key” may be derived either from a single user device or through an MPC process, depending on the security assumption. The “Purpose key” specifies the intended use or structure of the derived keys, and it may be a value, such as 0x53544547 (“STEG” in Ascii), which is still within the normal derivation range. Lastly, the “Child key index” may include, e.g., a 4-byte number [0x00000000, OxFFFFFFFF], which can accommodate 4.29B possible child keys. Based on the derivation path, the key derivation algorithm would output a child key for each child key index. When using child keys to encrypt new messages / data, the client application should track the used child key indices so that a key is not reused.

[0072] An example NFT workflow in which child keys are used for message / data encryption is provided below and with reference again to FIG. 3. A user 302 may have a message / data 307 to embed in a digital asset. The user 302 may decide whether to encrypt the message / data 307. Based on the user’s instructions, an application determines the optimal steganography scheme to use, as described elsewhere herein. The application then prepares the message / data for embedding. In particular embodiments, the metadata for the message / data, asATTORNEY DOCKET PATENT APPLICATION 088603.010928 of 43 described elsewhere herein, may be encrypted using a particular child key (e.g., the child key corresponding to child key index 0x00000000).

[0073] If the user selects data encryption, the application will derive the next available (unused) child key using the method described above (e.g., the child key corresponding to index 0x00000001 or above). If the master key used for child key derivation is derived from a single- user device, a dedicated mnemonic may be required rather than reusing the mnemonic words typically used for wallet blockchain keys. If MPC is used instead, multiple shareholders of the key shares will collaborate to derive the child key without reconstructing the master NFT encryption key. For example, assume a situation where shares of the master NFT encryption key are held by the user’ s mobile device and in the cloud. The cloud may derive the target NFT encryption child key share and send it to the mobile device. The mobile device, in response, may then derive the target child key share and construct the child encryption key. The child encryption key (e.g., child key 306c) may then be used to encrypt the message / data 307. If the same message / data is embedded in multiple digital assets, it is acceptable to reuse the same child key, but it is also acceptable to use a new one. Once the encrypted message / data 308 is generated and embedded within the digital asset 310. the digital asset 310 may be minted using the process described with reference to at least FIG. 1.Sharing of Child Encryption Key

[0074] There may be cases where a user may want to share a data encryption key with one or more other users. One example case may be when a user embeds a private message in an image that is meant to be revealed only to specific users. The private message may be indefinitely stored in a decentralized storage network, such as IPFS. This approach would be useful for social groups wanting to share specific secrets or messages, or for gifting an NFT with a hidden message. Sharing messages in this manner avoids the risk of censorship, which is ever present in conventional platforms (e.g., email, social networking platforms, etc.). Thus, when sharing messages through such conventional platforms, the user must trust the underlying platform. In contrast, as a secretsharing medium that persists messages / data, NFT eliminates any need for such trust.

[0075] As shown in FIG. 3, the child key 306c used by a creator 302 to encrypt a message / data 307 may be shared with another user 322 to enable that user 322 to decrypt the encrypted message / data 308 hidden within a digital asset 310. The child key 306c may be sharedATTORNEY DOCKET PATENT APPLICATION 088603.010929 of 43 with user 322 via any secure means. For example, a particular type of wallet (e.g., a meme wallet) may generate a unique private-public key pair for each user, intended for use as the initial encryption. For example, a unique user ID, private-public key, nickname, and other information are created during user registration. A user 302 may send his / her information (e.g., nickname, user ID, and public key) in QR code format to others (e.g., user 322) via email or other means. When certain users are registered as friends, they may communicate in an end-to-end encrypted manner, even for the first communication in offline mode (e.g., where one user is offline, making it impossible to create a real-time ECDH session key) by leveraging traditional ECDH using the user’s ID public key. Such a secure communication channel can then be used by the user’s 302 device to send the child key 306c to the other user’s 322 device. Specifically, the user 302’ s wallet could encrypt the child key using the ECDH key and then send it to the other user 322. The other user’s 322 device could then use ECDH to decrypt the encrypted data and obtain the child key.Joint / Group Key Creation

[0076] In some instances, instead of a single user generating an encryption key, the key could be jointly created by a group of people. For instance, in some cases, it may be desirable to use shared keys among multiple people instead of a user relying on his / her derived child key. This approach is also useful for supporting private peer-to-peer (P2P) messaging in a group. For example, the jointly created encryption key may be used by the group of users to encrypt / decrypt messages shared between each other, without needing to generate child encryption keys and / or rely on other derived keys. Any group member may use the gro up-created key to encrypt and decrypt messages / data hidden in NFTs that are shared with group members. There are various algorithms to generate a key jointly or generate a shared key in group settings. Some of these algorithms include, for example and without limitation, Extended or Multi-Party Diffie-Hellman (MPDH) key exchange protocol, Burmester-Desmedt (BD) protocol, tree-based group key exchange protocol, and paring (e.g., bilinear pairings) based key exchange protocol.Example Method

[0077] FIG. 9 illustrates an example method 900 for embedding a message and / or data in a digital asset (e.g., image) and storing the embedded message / data as NFT on a decentralized storage network. At block 910, a computing system running an application (e.g., client applicationATTORNEY DOCKET PATENT APPLICATION 088603.010930 of 43102) accesses data (e.g., a text message, audio, image, video, or any other type of data) specified by a user to embed within a digital asset (e.g., an image, video, audio, or any other type of digital file). As discussed elsewhere herein, secret messages (e.g., private messages between select users) and / or user’s backup data (e.g., cryptocurrency wallet keys, passphrases, etc.) may be embedded or hidden within a digital asset. For simplicity and ease of explanation, an image is used as an example of a digital asset in which data may be hidden.

[0078] At block 920, the application may determine whether to encrypt the data. For instance, a user associated with the application may decide whether to encrypt the data. If the result of the determination or the user’s decision is affirmative, then a suitable encryption key for encrypting the message is created or selected. As discussed elsewhere herein, master encryption may be used. Otherwise, a child encryption key may be created from the master encryption key and used for the encryption. Alternatively, a joint or group shared key may be jointly created by a group of users.

[0079] At block 930, the application determines one or more steganography schemes to use to embed the data (encrypted or not). The application may be configured to determine the optimal steganography scheme to use based on an analysis of data and the digital asset. For example, as described elsewhere herein, the application may analyze the sizes of the data and digital asset and determine whether utilizing a particular combination of one or more steganography schemes would allow the data to fit within the digital asset.

[0080] At block 940, the application prepares the data for embedding. For example, the application may generate metadata for the data that specifies, e.g., the message / data type of the data, whether the data is encrypted, the length of the data, and the steganography scheme(s) used to hide the data.

[0081] At block 950, the application embeds the data within the digital asset according to the one or more steganography schemes. The steganography scheme(s) may be one or more of a sequential placement scheme, a pseudo-random placement scheme, or a frequency obfuscation scheme, as discussed elsewhere herein. For images, the steganography schemes may also specify which combination of color channels (e.g., R, G, B) to use for hiding data.

[0082] Once the data has been embedded, the application continues with the NFT minting smart contract flow. For example, at block 960, the application stores the digital asset embeddedATTORNEY DOCKET PATENT APPLICATION 088603.010931 of 43 with the data on a decentralized storage network. At block 970, the application receives, from the decentralized storage network, a first uniform resource identifier (URI) identifying the digital asset embedded with the data. At block 980, the application creates, using the first URI, a metadata of the digital asset embedded with the data. At block 990, the application stores the metadata on the decentralized storage network. At block 995, the application receives, from the decentralized storage network, a second URI identifying the metadata. At block 996, the application creates a non-fungible token (NFT) based on the second URI associated with the metadata. At 997, the application stores the NFT on a blockchain. Thereafter, the application may share with others any information required for extracting and decrypting the data from the digital asset. Based on such information, the user and / or other users may retrieve the digital asset embedded with the data from the decentralized storage network, extract the data, and optionally decrypt the data, as described in further detail elsewhere herein.

[0083] Particular embodiments may repeat one or more steps of the method of FIG. 9, where appropriate. Although this disclosure describes and illustrates particular steps of the method of FIG. 9 as occurring in a particular order, this disclosure contemplates any suitable steps of the method of FIG. 9 occurring in any suitable order. Moreover, although this disclosure describes and illustrates an example method for embedding a message and / or data in a digital asset (e.g., image) and storing the embedded message / data as NFT on a decentralized storage network, including the particular steps of the method of FIG. 9. this disclosure contemplates any suitable method for embedding a message and / or data in a digital asset (e.g., image) and storing the embedded message / data as NFT on a decentralized storage network, including any suitable steps, which may include a subset of the steps of the method of FIG. 9, where appropriate. Furthermore, although this disclosure describes and illustrates particular components, devices, or systems carrying out particular steps of the method of FIG. 9, this disclosure contemplates any suitable combination of any suitable components, devices, or systems carrying out any suitable steps of the method of FIG. 9.Example Computer System

[0084] FIG. 10 illustrates an example computer system 1000. In particular embodiments, one or more computer systems 1000 perform one or more steps of one or more processes, algorithms, techniques, or methods described or illustrated herein. In particular embodiments, oneATTORNEY DOCKET PATENT APPLICATION 088603.010932 of 43 or more computer systems 1000 provide the functionality described or illustrated herein. In particular embodiments, software running on one or more computer systems 1000 performs one or more steps of one or more methods described or illustrated herein or provides functionality described or illustrated herein. Particular embodiments include one or more portions of one or more computer systems 1000. Herein, reference to a computer system may encompass a computing device and vice versa, where appropriate. Moreover, reference to a computer system may encompass one or more computer systems, where appropriate.

[0085] This disclosure contemplates any suitable number of computer systems 1000. This disclosure contemplates computer system 1000 taking any suitable physical form. As example and not by way of limitation, computer system 1000 may be an embedded computer system, a system- on-chip (SOC), a single-board computer system (SBC) (such as, for example, a computer-on- module (COM) or system-on-module (SOM)), a desktop computer system, a laptop or notebook computer system, an interactive kiosk, a mainframe, a mesh of computer systems, a mobile telephone, a personal digital assistant (PDA), a server, a tablet computer system, an augmented / virtual reality device, or a combination of two or more of these. Where appropriate, computer system 1000 may include one or more computer systems 1000; be unitary or distributed; span multiple locations; span multiple machines; span multiple data centers; or reside in a cloud, which may include one or more cloud components in one or more networks. Where appropriate, one or more computer systems 1000 may perform without substantial spatial or temporal limitation one or more steps of one or more methods described or illustrated herein. As an example and not by way of limitation, one or more computer systems 1000 may perform in real time or in batch mode one or more steps of one or more methods described or illustrated herein. One or more computer systems 1000 may perform at different times or at different locations one or more steps of one or more methods described or illustrated herein, where appropriate.

[0086] In particular embodiments, computer system 1000 includes a processor 1002, memory 1004, storage 1006, an input / output (I / O) interface 1008, a communication interface 1010, and a bus 1012. Although this disclosure describes and illustrates a particular computer system having a particular number of particular components in a particular arrangement, this disclosure contemplates any suitable computer system having any suitable number of any suitable components in any suitable arrangement.ATTORNEY DOCKET PATENT APPLICATION 088603.010933 of 43

[0087] In particular embodiments, processor 1002 includes hardware for executing instructions, such as those making up a computer program. As an example and not by way of limitation, to execute instructions, processor 1002 may retrieve (or fetch) the instructions from an internal register, an internal cache, memory 1004, or storage 1006; decode and execute them; and then write one or more results to an internal register, an internal cache, memory 1004, or storage 1006. In particular embodiments, processor 1002 may include one or more internal caches for data, instructions, or addresses. This disclosure contemplates processor 1002 including any suitable number of any suitable internal caches, where appropriate. As an example and not by way of limitation, processor 1002 may include one or more instruction caches, one or more data caches, and one or more translation lookaside buffers (TLBs). Instructions in the instruction caches may be copies of instructions in memory 1004 or storage 1006, and the instruction caches may speed up retrieval of those instructions by processor 1002. Data in the data caches may be copies of data in memory 1004 or storage 1006 for instructions executing at processor 1002 to operate on; the results of previous instructions executed at processor 1002 for access by subsequent instructions executing at processor 1002 or for writing to memory 1004 or storage 1006; or other suitable data. The data caches may speed up read or write operations by processor 1002. The TLBs may speed up virtual-address translation for processor 1002. In particular embodiments, processor 1002 may include one or more internal registers for data, instructions, or addresses. This disclosure contemplates processor 1002 including any suitable number of any suitable internal registers, where appropriate. Where appropriate, processor 1002 may include one or more arithmetic logic units (ALUs); be a multi-core processor; or include one or more processors 1002. Although this disclosure describes and illustrates a particular processor, this disclosure contemplates any suitable processor.

[0088] In particular embodiments, memory 1004 includes main memory for storing instructions for processor 1002 to execute or data for processor 1002 to operate on. As an example and not by way of limitation, computer system 1000 may load instructions from storage 1006 or another source (such as. for example, another computer system 1000) to memory 1004. Processor 1002 may then load the instructions from memory 1004 to an internal register or internal cache. To execute the instructions, processor 1002 may retrieve the instructions from the internal register or internal cache and decode them. During or after execution of the instructions, processor 1002ATTORNEY DOCKET PATENT APPLICATION 088603.010934 of 43 may write one or more results (which may be intermediate or final results) to the internal register or internal cache. Processor 1002 may then write one or more of those results to memory 1004. In particular embodiments, processor 1002 executes only instructions in one or more internal registers or internal caches or in memory 1004 (as opposed to storage 1006 or elsewhere) and operates only on data in one or more internal registers or internal caches or in memory 1004 (as opposed to storage 1006 or elsewhere). One or more memory buses (which may each include an address bus and a data bus) may couple processor 1002 to memory 1004. Bus 1012 may include one or more memory buses, as described below. In particular embodiments, one or more memory management units (MMUs) reside between processor 1002 and memory 1004 and facilitate accesses to memory 1004 requested by processor 1002. In particular embodiments, memory 1004 includes random access memory (RAM). This RAM may be volatile memory, where appropriate. Where appropriate, this RAM may be dynamic RAM (DRAM) or static RAM (SRAM). Moreover, where appropriate, this RAM may be single-ported or multi-ported RAM. This disclosure contemplates any suitable RAM. Memory 1004 may include one or more memories 1004, where appropriate. Although this disclosure describes and illustrates particular memory, this disclosure contemplates any suitable memory.

[0089] In particular embodiments, storage 1006 includes mass storage for data or instructions. As an example and not by way of limitation, storage 1006 may include a hard disk drive (HDD), a floppy disk drive, flash memory, an optical disc, a magneto-optical disc, magnetic tape, or a Universal Serial Bus (USB) drive or a combination of two or more of these. Storage 1006 may include removable or non-removable (or fixed) media, where appropriate. Storage 1006 may be internal or external to computer system 1000, where appropriate. In particular embodiments, storage 1006 is non-volatile, solid-state memory. In particular embodiments, storage 1006 includes read-only memory (ROM). Where appropriate, this ROM may be maskprogrammed ROM, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), electrically alterable ROM (EAROM), or flash memory or a combination of two or more of these. This disclosure contemplates mass storage 1006 taking any suitable physical form. Storage 1006 may include one or more storage control units facilitating communication between processor 1002 and storage 1006, where appropriate. Where appropriate,ATTORNEY DOCKET PATENT APPLICATION 088603.010935 of 43 storage 1006 may include one or more storages 1006. Although this disclosure describes and illustrates particular storage, this disclosure contemplates any suitable storage.

[0090] In particular embodiments, I / O interface 1008 includes hardware, software, or both, providing one or more interfaces for communication between computer system 1000 and one or more I / O devices. Computer system 1000 may include one or more of these I / O devices, where appropriate. One or more of these I / O devices may enable communication between a person and computer system 1000. As an example and not by way of limitation, an I / O device may include a keyboard, keypad, microphone, monitor, mouse, printer, scanner, speaker, still camera, stylus, tablet, touch screen, trackball, video camera, another suitable I / O device or a combination of two or more of these. An I / O device may include one or more sensors. This disclosure contemplates any suitable I / O devices and any suitable TO interfaces 1008 for them. Where appropriate, TO interface 1008 may include one or more device or software drivers enabling processor 1002 to drive one or more of these I / O devices. I / O interface 1008 may include one or more I / O interfaces 1008, where appropriate. Although this disclosure describes and illustrates a particular TO interface, this disclosure contemplates any suitable I / O interface.

[0091] In particular embodiments, communication interface 1010 includes hardware, software, or both providing one or more interfaces for communication (such as, for example, packet-based communication) between computer system 1000 and one or more other computer systems 1000 or one or more networks. As an example and not by way of limitation, communication interface 1010 may include a network interface controller (NIC) or network adapter for communicating with an Ethernet or other wire-based network or a wireless NIC (WNIC) or wireless adapter for communicating with a wireless network, such as a WI-FI network. This disclosure contemplates any suitable network and any suitable communication interface 1010 for it. As an example and not by way of limitation, computer system 1000 may communicate with an ad hoc network, a personal area network (PAN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), or one or more portions of the Internet or a combination of two or more of these. One or more portions of one or more of these networks may be wired or wireless. As an example, computer system 1000 may communicate with a wireless PAN (WPAN) (such as, for example, a BLUETOOTH WPAN), a WI-FI network, a WI-MAX network, a cellular telephone network (such as, for example, a Global System for MobileATTORNEY DOCKET PATENT APPLICATION 088603.010936 of 43Communications (GSM) network), or other suitable wireless network or a combination of two or more of these. Computer system 1000 may include any suitable communication interface 1010 for any of these networks, where appropriate. Communication interface 1010 may include one or more communication interfaces 1010, where appropriate. Although this disclosure describes and illustrates a particular communication interface, this disclosure contemplates any suitable communication interface.

[0092] In particular embodiments, bus 1012 includes hardware, software, or both coupling components of computer system 1000 to each other. As an example and not by way of limitation, bus 1012 may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a front-side bus (FSB), a HYPERTRANSPORT (HT) interconnect, an Industry Standard Architecture (ISA) bus, an INFINIBAND interconnect, a low- pin-count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCIe) bus, a serial advanced technology attachment (SATA) bus, a Video Electronics Standards Association local (VLB) bus, or another suitable bus or a combination of two or more of these. Bus 1012 may include one or more buses 1012, where appropriate. Although this disclosure describes and illustrates a particular bus, this disclosure contemplates any suitable bus or interconnect.

[0093] Herein, a computer-readable non-transitory storage medium or media may include one or more semiconductor-based or other integrated circuits (ICs) (such, as for example, field- programmable gate arrays (FPGAs) or application-specific ICs (ASICs)), hard disk drives (HDDs), hybrid hard drives (HHDs), optical discs, optical disc drives (ODDs). magneto-optical discs, magneto-optical drives, floppy diskettes, floppy disk drives (FDDs), magnetic tapes, solid-state drives (SSDs), RAM-drives, SECURE DIGITAL cards or drives, any other suitable computer- readable non-transitory storage media, or any suitable combination of two or more of these, where appropriate. A computer-readable non-transitory storage medium may be volatile, non-volatile, or a combination of volatile and non-volatile, where appropriate.

[0094] Herein, “or” is inclusive and not exclusive, unless expressly indicated otherwise or indicated otherwise by context. Therefore, herein, “A or B” means “A, B, or both,” unless expressly indicated otherwise or indicated otherwise by context. Moreover, “and” is both joint and several, unless expressly indicated otherwise or indicated otherwise by context. Therefore, herein,ATTORNEY DOCKET PATENT APPLICATION 088603.010937 of 43“A and B” means “A and B, jointly or severally,” unless expressly indicated otherwise or indicated otherwise by context.

[0095] The scope of this disclosure encompasses all changes, substitutions, variations, alterations, and modifications to the example embodiments described or illustrated herein that a person having ordinary skill in the art would comprehend. The scope of this disclosure is not limited to the example embodiments described or illustrated herein. Moreover, although this disclosure describes and illustrates respective embodiments herein as including particular components, elements, feature, functions, operations, or steps, any of these embodiments may include any combination or permutation of any of the components, elements, features, functions, operations, or steps described or illustrated anywhere herein that a person having ordinary skill in the art would comprehend. Furthermore, reference in the appended claims to an apparatus or system or a component of an apparatus or system being adapted to, arranged to, capable of, configured to, enabled to, operable to, or operative to perform a particular function encompasses that apparatus, system, component, whether or not it or that particular function is activated, turned on, or unlocked, as long as that apparatus, system, or component is so adapted, arranged, capable, configured, enabled, operable, or operative. Additionally, although this disclosure describes or illustrates particular embodiments as providing particular advantages, particular embodiments may provide none, some, or all of these advantages.

Claims

ATTORNEY DOCKET PATENT APPLICATION 088603.010938 of 43CLAIMSWhat is claimed is:

1. A method comprising, by a computing system: accessing data specified by a user to embed within a digital asset; determining one or more steganography schemes to use to embed the data; embedding the data within the digital asset according to the one or more steganography schemes; storing the digital asset embedded with the data on a decentralized storage network; receiving, from the decentralized storage network, a first uniform resource identifier (URI) identifying the digital asset embedded with the data; creating, using the first URI, a metadata of the digital asset embedded with the data; storing the metadata on the decentralized storage network; receiving, from the decentralized storage network, a second URI identifying the metadata; creating a non-fungible token (NFT) based on the second URI associated with the metadata; and storing the NFT on a blockchain.

2. The method of Claim 1, further comprising: retrieving, using the first URL the digital asset embedded with the data from the decentralized storage network; and extracting, using the one or more steganography schemes, the data embedded within the retrieved digital asset embedded with the data.

3. The method of Claim 1, wherein the one or more steganography schemes comprise a pseudo-random placement scheme for determining pseudo-random locations in the digital asset at which to embed portions of the data.

4. The method of Claim 3, wherein the pseudo-random placement scheme uses an encryption key associated with the user to compute the pseudo-random locations.ATTORNEY DOCKET PATENT APPLICATION 088603.010939 of 435. The method of Claim 3, wherein the pseudo-random placement scheme computes pseudo-random intervals between the pseudo-random locations in the digital asset.

6. The method of Claim 3, wherein: the digital asset is an image; the pseudo-random locations correspond to identified pixel locations in the image; and each of the identified pixel locations in the image has color values that are respectively associated with three color channels.

7. The method of Claim 6, wherein embedding the data within the digital asset according to the pseudo-random placement scheme comprises: for each of the identified pixel locations, overwriting a least significant bit of at least one of the color values associated with that identified pixel location with a portion of the data, wherein said at least one of the color values is associated with a selected color channel of the three color channels.

8. The method of Claim 7, wherein the one or more steganography schemes comprise a frequency obfuscation scheme, and wherein embedding the data within the digital asset according to the frequency obfuscation scheme comprises: for each pixel location in the image other than the identified pixel locations, overwriting a least significant bit of a color value associated with that pixel location with noise, wherein the color value is associated with the selected color channel.

9. The method of Claim 8, further comprising: determining to use the frequency obfuscation scheme based on an analysis of a background portion of the image.

10. The method of Claim 1, wherein the one or more steganography schemes comprise a sequential placement scheme for determining sequential locations in the digital asset at which to embed portions of the data.ATTORNEY DOCKET PATENT APPLICATION 088603.010940 of 4311. The method of Claim 1, wherein the one or more steganography schemes are selected from a plurality of steganography schemes based on an analysis of a size of the digital asset and a size of the data, wherein the plurality of steganography schemes comprises at least a pseudorandom placement scheme and a sequential placement scheme.

12. The method of Claim 11, wherein the plurality of steganography schemes further comprises a selection of one or more color channels of the digital asset to use for embedding the data.

13. The method of Claim 1, wherein the data is encrypted.

14. The method of Claim 13, further comprising: accessing a master encryption key associated with the user; and deriving a plurality of child encryption keys from the master encryption key using a key derivation scheme, wherein a child encryption key of the plurality of child encryption keys is used to encrypt the data.

15. The method of Claim 14, further comprising: sharing the child encryption key with a device associated with a second user with whom the user wants to share the data, wherein the child encryption key enables the device to decrypt the data after the device retrieves the digital asset embedded with the data from the decentralized storage network and extracts the data from the retrieved digital asset embedded with the data.

16. The method of Claim 13, further comprising: jointly creating a shared encryption key with a group of users that includes the user; and encrypting the data using the shared encryption key.

17. The method of Claim 1, wherein the data to embed within the digital asset comprises one or more of:ATTORNEY DOCKET PATENT APPLICATION 088603.010941 of 43 a secret message intended for another user; or a backup of a cryptocurrency wallet associated with the user.

18. The method of Claim 1, wherein the digital asset is one of an image, a video, or an audio.

19. One or more computer-readable non-transitory storage media embodying software that is operable when executed by a computing system to: access data specified by a user to embed within a digital asset; determine one or more steganography schemes to use to embed the data; embed the data within the digital asset according to the one or more steganography schemes; store the digital asset embedded with the data on a decentralized storage network; receive, from the decentralized storage network, a first uniform resource identifier (URI) identifying the digital asset embedded with the data; create, using the first URI, a metadata of the digital asset embedded with the data; store the metadata on the decentralized storage network; receive, from the decentralized storage network, a second URI identifying the metadata; create a non-fungible token (NFT) based on the second URI associated with the metadata; and store the NFT on a blockchain.

20. A system comprising: one or more processors; and one or more computer-readable non-transitory storage media coupled to the one or more processors and comprising instructions operable when executed by the one or more processors to cause the system to: access data specified by a user to embed within a digital asset; determine one or more steganography schemes to use to embed the data;ATTORNEY DOCKET PATENT APPLICATION 088603.010942 of 43 embed the data within the digital asset according to the one or more steganography schemes; store the digital asset embedded with the data on a decentralized storage network; receive, from the decentralized storage network, a first uniform resource identifier (URI) identifying the digital asset embedded with the data; create, using the first URI, a metadata of the digital asset embedded with the data; store the metadata on the decentralized storage network; receive, from the decentralized storage network, a second URI identifying the metadata; create a non-fungible token (NFT) based on the second URI associated with the metadata; and store the NFT on a blockchain.

Images