Topic: Idea: selling files with bitcoin (Read 1217 times)

There are already sites that do this, but what the OP is doing is going for a trustless approach. Your suggestion (also widely used) requires trusting a third party. They have to trust that that third party doesn't read the contents of the files, and for the third party to release the file to the buyer and to release the funds to the seller. The trustless system suggested here is to remove that middleman who is also collecting commission. It allows the buyer and seller to buy and sell files while also giving an incentive to not scam.

After reading through the OP it seems that you are looking this in a manner that seems to be over complicated and bothersome for the average consumer of said 'file'.

There is a much simpler approach to this.

A trusted website where a producer of a 'file' can upload said 'file' to the website. This file is then sold via the website, the buyer get's the link to the purchase page from the seller. Once on this page he clicks "buy now" (or something to that effect) a unique bitcoin address is generated and the buyer is asked to transfer the asking price for the 'file' to this address, after a certain number of confirmations the file is released and the buy can download said 'file'.

The seller can have automatic withdrawals set up so that once a product has been bought and confirmed through the website. The BTC that was sent is then forwarded to the seller minus whatever commission the site is charging for providing this service.

The file contents would also be verified by the operators of the website and there is a review system so that buyers can review the file they have bought.

Wait a minute... so if the file is encrypted with seller's public key, how can buyer decrypt it? Am I missing something?

Wait a minute... so if the file is encrypted with seller's public key, how can buyer decrypt it? Am I missing something?

Now I know someone is working on this

the whole point of my proposal is that it avoids a middle man..

to say again:

- the seller encrypts the file symmetrically with his public key
- the buyer sends bitcoin to the associated bitcoin address
- the seller must publish the public key of the address to spend the payment

no middle are necessary

however, another issue with it is that the buyer has no guarantee that the file was actually encrypted with the address'es pubkey

The idea sounds a lot like darkleaks

https://medium.com/@ZozanCudi/darkleaks-information-blackmarket-1ee5ac28c892
https://github.com/darkwallet/darkleaks

There's a lot of hype and PR there, but it's a good idea nonetheless. Looks like development has stopped so don't be disheartened that someone else came up with the idea already.

Ah, yes of course, but I was actually thinking about symmetric encryption. The public key would be used for both encrypting it, and decrypting. In that case, it would work and the seller MUST publish the encryption key to spend the money, since it is his public key, which is published upon signing the transaction.

To decrypt a file encrypted with a public key, you need private key associated with it.

[1] https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki

ECDSA used in bitcoin is signing/verifying algorithm. It can not be used for encryption/decryption at all

-snip-

As for the encryption aspect... I don't see why the ECDSA signature keys can't be used as encryption keys.  The BTC ECDSA is based on a NIST-blessed elliptic curve (secp256k1), and you have a public-key-point and private-key on that curve.  If it's secure for signing, it will be at least very secure for encryption. 

Despite being a mathematician and studied cryptography before, I'm not a black-hat kind of guy.  I know that this will be very secure, but I don't know if there's maybe weaknesses in using a recommende ECDSA curve for encryption.  I just know it's possible to use it, and the security of the signature process implies a high degree of security in the encryption process.

-Eto

Elliptic Curve DSA and Elliptic Curve encryption are almost as closely related to one another as signing and encryption in RSA. 

   RSA Signing and Decryption:        both are exponentiation mod N with the private key
   RSA Verification and Encryption:   both are exponentiation mod N with the public key

In ECDSA and ECIES, the key-pair relationship is similar, but instead of simple exponentiation mod N, you're applying a different mathematical equation for all four operations (signing, verification, encrypting, decrypting).  The only real difference is that NIST has blessed different elliptic curves for ECDSA and ECIES.  That doesn't meant that the secp256k1 curve can't be used for encryption, it just means that people smarter than us have decided that different curves should be used for cryptography and signing. 

Unfortunately, in my graduate cryptography class, we didn't dive into elliptic curves far enough for me to know what kinds of vulnerabilities there are with naive elliptic curve selection, but there was also no reason why security of the two would be different on the same curve.  I would say that the security of ECDSA keys on the secp256k1 curve will provide sufficient security for encryption as well.  I wouldn't guard nuclear launch codes with it, but I would venture that your 256-bit key will give you at least 128-bits of security.

A more-likely explanation is that the security is actually identical between the two.  But it's standard practice in cryptographic protocols/implementations to use different keys for signing and encryption.  Perhaps this is why NIST chose two different curves:  so that if you decide to use NIST curves, you can't pick the same key for both, even if you wanted to.

But as has been said before:  you don't have the person's public key until they either give it to you, or you see a transaction signed with it.  Having their BTC address is not enough.

-Eto

To decrypt a file encrypted with a public key, you need private key associated with it.