user47236: Following my previous question on this topic Is there a way to store and share a private key through blockchain?, I might have a solution but I would like to improve the process.
Image that A is the owner of some private data, and want to give the ownership of this data to B, another member of the blockchain. The data is a private key so it can not be public, but it can be encoded using A or B public key.
So:

Secret data is encoded with A public key, and stored in A informations data /
B want to by A secret data
A decode the secret data (using his private wallet key) and encode the secret data with B public key
Ownership of the data is given to B
Now only B (and A also but that's a different story) can decode secret data.

Is there a way to simplify this process using smart contract? I assume a smart contract have access to A and B public key, but can a data be encoded/decoded with private key of the one executing the smart contract?

user90504: (Even though i'm on the bitcoin.stackexchange side this came up with an Ethereum tag so i'll answer from the Ethereum perspective)
Short answer is: Yes it is entirely possible. Using asymetric public key encryption as James mentioned. It is however also entirely non-economical. 
Some new, different, private/public chains have been specifically designed to handle data storage on-chain because current chains like Ethereum, make it cost prohibitive. As the amount of data you seek to store increases, the amount of effort to "mine" the transaction (with the data you want to store) also increases. That is why network fee's are calculate at a Byte rate. 
Check out Tjaden's answer here: https://ethereum.stackexchange.com/questions/872/what-is-the-cost-to-store-1kb-10kb-100kb-worth-of-data-into-the-ethereum-block 
My best attempt at answering the "smart contract to simplify" aspect would be 

Already knowing the decryption key

or

Being able to decrypt data in a smart contract to get the decryption key. 

In '2' you'd have a smart contract that would accept transactions with a set decryption. Every time A wanted to send a message that B could read, it would submit an encrypted, decryption key. B would have to find the transaction, decrypt the key, then use that key to decrypt the message. It's more like 2-auth but for an encrypted payload. 
This would not be elegant or efficient. There are better ways to accomplish the same task.

user65678: If I've understood correctly, I don't think you need block-chain technology to achieve what you want. This is exactly what asymmetric public key encryption is designed for. 
A simply encrypts some information using A's private key and B's public key... thereby ensuring:

Only B can decrypt the information 
B can verify the information was
encrypted by A (using A's public key)

There's no way for A to prove to B that their copy of the information has been destroyed or forgotten by A, but at least secure transmission is ensured.

47236: <p>Following my previous question on this topic <a href="https://bitcoin.stackexchange.com/questions/52064/is-there-a-way-to-store-and-share-a-private-key-through-blockchain">Is there a way to store and share a private key through blockchain?</a>, I might have a solution but I would like to improve the process.</p>

<p>Image that A is the owner of some private data, and want to give the ownership of this data to B, another member of the blockchain. The data is a private key so it can not be public, but it can be encoded using A or B public key.</p>

<p>So:</p>

<ul>
<li>Secret data is encoded with A public key, and stored in A informations data /</li>
<li>B want to by A secret data</li>
<li>A decode the secret data (using his private wallet key) and encode the secret data with B public key</li>
<li>Ownership of the data is given to B</li>
<li>Now only B (and A also but that's a different story) can decode secret data.</li>
</ul>

<p>Is there a way to simplify this process using smart contract? I assume a smart contract have access to A and B public key, but can a data be encoded/decoded with private key of the one executing the smart contract?</p>
 90504: <p>(Even though i'm on the bitcoin.stackexchange side this came up with an Ethereum tag so i'll answer from the Ethereum perspective)</p>

<p>Short answer is: Yes it is entirely possible. Using asymetric public key encryption as James mentioned. It is however also entirely non-economical. </p>

<p>Some new, different, private/public chains have been specifically designed to handle data storage on-chain because current chains like Ethereum, make it cost prohibitive. As the amount of data you seek to store increases, the amount of effort to "mine" the transaction (with the data you want to store) also increases. That is why network fee's are calculate at a Byte rate. </p>

<p>Check out Tjaden's answer here: <a href="https://ethereum.stackexchange.com/questions/872/what-is-the-cost-to-store-1kb-10kb-100kb-worth-of-data-into-the-ethereum-block">https://ethereum.stackexchange.com/questions/872/what-is-the-cost-to-store-1kb-10kb-100kb-worth-of-data-into-the-ethereum-block</a> </p>

<p>My best attempt at answering the "smart contract to simplify" aspect would be </p>

<ol>
<li>Already knowing the decryption key</li>
</ol>

<p>or</p>

<ol start="2">
<li>Being able to decrypt data in a smart contract to get the decryption key. </li>
</ol>

<p>In '2' you'd have a smart contract that would accept transactions with a set decryption. Every time A wanted to send a message that B could read, it would submit an encrypted, decryption key. B would have to find the transaction, decrypt the key, then use that key to decrypt the message. It's more like 2-auth but for an encrypted payload. </p>

<p>This would not be elegant or efficient. There are better ways to accomplish the same task.</p>
 65678: <p>If I've understood correctly, I don't think you need block-chain technology to achieve what you want. This is exactly what asymmetric public key encryption is designed for. </p>

<p>A simply encrypts some information using A's private key and B's public key... thereby ensuring:</p>

<ul>
<li>Only B can decrypt the information </li>
<li>B can verify the information was
encrypted by A (using A's public key)</li>
</ul>

<p>There's no way for A to prove to B that their copy of the information has been destroyed or forgotten by A, but at least secure transmission is ensured.</p>
