4 ms·

A cool application of this could be to release currently closed source code encrypted until some number of years in the future (10 or 20 would be my guess) at w

by slaymaker1907 4y ago

A cool application of this could be to release currently closed source code encrypted until some number of years in the future (10 or 20 would be my guess) at which point anyone holding the original encrypted source could view the plaintext. I'd rather vendors just open source in the first place, but this could be a nice way to have a sort of smart contract guaranteeing future access to source code.

layer8 4y ago
The problem being that there’s no proof that what was encrypted is actually the source code, before it can be decrypted. So you’d have to take the vendor’s word for it.
- ffhhj 4y ago
  Maybe using a zero-knowledge proof.
  - tnzk 4y ago
    Some reproducible builds with a confidential VM and use the digest of build artifacts might work.
- Kadin 4y ago
  Well, sure: but if the company doesn't want to release the source code at a future date, they just... don't do it. That's sort of a separate problem. If you assume the company (or the developers, whatever) actually want to reveal the code, but just don't want to give it away to their competitors today, it seems like it would work. One situation that seems relatively common is developers who are working on a commercial product who might want to see it open-sourced down the road. The developers (not the company) could prepare the source code on the company's hardware (i.e. where they normally do development), timelock-encrypt it, and then take it home with them or publish it somewhere. They would then have the assurance—since they actually prepared and encrypted the source code snapshot—of what's inside. Average Joe Coder might not have the pull to get their company to agree to such a scheme, but I can imagine some very high-profile people might. E.g. if you're a recognized expert in your field (think John Carmack or someone of his stature in whatever niche you want), maybe you put a requirement for timelocked access to the code you write as a must-have in your consulting contracts. Then you would still be able to get work with private companies, but have some assurance that your work would be publishable and benefit the public down the road. I'm sure you could probably even rig up some Git hook that timelock-encrypts every commit and pushes it to a public repo somewhere (Internet Archive, maybe?) that's expected to be available for a good long while.

layer8 4y ago

The problem being that there’s no proof that what was encrypted is actually the source code, before it can be decrypted. So you’d have to take the vendor’s word for it.

ffhhj 4y ago
Maybe using a zero-knowledge proof.
- tnzk 4y ago
  Some reproducible builds with a confidential VM and use the digest of build artifacts might work.
Kadin 4y ago
Well, sure: but if the company doesn't want to release the source code at a future date, they just... don't do it. That's sort of a separate problem. If you assume the company (or the developers, whatever) actually want to reveal the code, but just don't want to give it away to their competitors today, it seems like it would work. One situation that seems relatively common is developers who are working on a commercial product who might want to see it open-sourced down the road. The developers (not the company) could prepare the source code on the company's hardware (i.e. where they normally do development), timelock-encrypt it, and then take it home with them or publish it somewhere. They would then have the assurance—since they actually prepared and encrypted the source code snapshot—of what's inside. Average Joe Coder might not have the pull to get their company to agree to such a scheme, but I can imagine some very high-profile people might. E.g. if you're a recognized expert in your field (think John Carmack or someone of his stature in whatever niche you want), maybe you put a requirement for timelocked access to the code you write as a must-have in your consulting contracts. Then you would still be able to get work with private companies, but have some assurance that your work would be publishable and benefit the public down the road. I'm sure you could probably even rig up some Git hook that timelock-encrypts every commit and pushes it to a public repo somewhere (Internet Archive, maybe?) that's expected to be available for a good long while.