1

i.e. To allow an unofficial software modification (which is too extensive to distribute as delta/patch files) to be distributed while ensuring the user owns the original software, it would be distributed in encrypted form - using the original software's file(s) as the key (or I guess a key derived from those files, assuming it is ensured that you cannot just use a pre-generated key from someone else).

Improve this question
8
  • 4
    It’s technically possible to derive a key from software files, but this makes no sense. As you already pointed out yourself, this doesn’t prevent users from sharing the key. You need to hand out individual license codes and grant access to updates based on those codes (and any abuse detection mechanism you have in place). If it’s too late to implement proper license codes, then send individual access tokens to your users (e.g., embedded in a URL) which let them download the update from a server. Commented Nov 27, 2024 at 15:24
  • 1
    As I understand the question, Hiccup wants to release a game mod. They want to modify the game and redistribute it, but they don't want to get into trouble with the game company. So the game company is in control of the licensing, not Hiccup. Commented Nov 28, 2024 at 9:21
  • Encrypting one file with (the hash of) another file is trivial. It doesn't solve your problem of unauthorized distribution of copyrighted material though (which is off topic here btw). Commented Nov 28, 2024 at 9:38
  • @Sjoerd: Then this is a legal question. And the term “unofficial” makes me think none of the OPs ideas have ever been discussed with the company, which means the OP is merely hoping that their odd approach will avoid legal trouble. Commented Nov 28, 2024 at 9:41
  • I'm voting to close this as off-topic. It's an imaginary solution to a legal problem that should be discussed with the copyright owner and/or a lawyer. Commented Nov 28, 2024 at 9:52

1 Answer 1

Reset to default
2

The straightforward way is to derive a key from the old software. E.g. you compute the SHA256 of the old software and use that as an AES key to decrypt the new software. However, this makes it possible for attackers to share the value of the cryptographic hash and decrypt the new software using that.

Research is ongoing in the field of big-key symmetric encryption, which allows keys of several gigabytes. This could be a way to use the whole old software distribution as a key. However, there is currently no mainstream recommended method to do this.

Another possibility is to XOR the new software with the old software, like a one-time pad. This is not very secure, but could be sufficient depending on your requirements.

Improve this answer
3
  • 1
    We can come up with all kinds of technical ideas, but unless the copyright owner of the original software has actually agreed to any of this, it's completely pointless. Just because the OP thinks encrypting the modification based on the original software will get them out of legal trouble doesn't mean this is actually the case. Commented Nov 28, 2024 at 9:48
  • As you already said yourself, the right solution depends on the requirements. But the requirements are entirely unclear until the OP has solved the underlying legal problem. Commented Nov 28, 2024 at 11:16
  • Thanks. I think XOR may be sufficient actually. Although I wonder if there would be some benefit to encrypting the original software first with a random key (to be distributed with the XORd data), since that would prevent recovery of e.g. the 00 bytes? (not that those necessarily matter that much for this use case). Commented Nov 28, 2024 at 14:33

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.