Secure way to 'sign' programs?

Title says, well, most of it. I'm making an OS, and I plan to add addons. However, is there a way, that they can be 'signed' in a way where the 'certificate' cannot easily be stolen?

In short, no.

Anything you do to your program, I (or any halfways decent programmer) could undo. The only thing I can think of is requiring a password upon installation, which is provided in the forum post. But then again, they could easily steal the password as well. You could add comments to your code indicating it's yours… but it'd be simple to remove them before redistributing it.

KingofGamesYami, on 28 November 2015 - 09:32 PM said:

In short, no.

Anything you do to your program, I (or any halfways decent programmer) could undo. The only thing I can think of is requiring a password upon installation, which is provided in the forum post. But then again, they could easily steal the password as well. You could add comments to your code indicating it's yours… but it'd be simple to remove them before redistributing it.

Actually… I came up with an idea. A webserver which can decrypt addon data, but the decryption key is never exposed to the client. There is a 'developer mode' which will allow unsigned addons, but when it's off, addons MUST be encrypted.

KingofGamesYami, on 28 November 2015 - 09:32 PM said:

In short, no.

Anything you do to your program, I (or any halfways decent programmer) could undo. The only thing I can think of is requiring a password upon installation, which is provided in the forum post. But then again, they could easily steal the password as well. You could add comments to your code indicating it's yours… but it'd be simple to remove them before redistributing it.

I don't think he's asking whether or not it's possible to prevent the program itself from being stolen, but rather he wants to be able to sign addons in such a way that one can verify the integrity of the addon, but not get a hold of the certificate. I'm no expert in cryptography by a long shot, but I believe what you're looking for is asymmetric encryption. The author would have a private key and a public key, and to demonstrate their authenticity would sign a message and send it to the user, who would then decrypt the message with the public key. If the message is unchanged, then the author is probably who they say they are. If anyone really knows their stuff on this subject, feel free to correct me as I've done minimal research.

Edit: @Quartz Looks like you're thinking in the same vein as I am, so maybe I'm not crazy :P/>

Yevano, on 29 November 2015 - 12:58 AM said:

I'm no expert in cryptography by a long shot, but I believe what you're looking for is asymmetric encryption. The author would have a private key and a public key, and to demonstrate their authenticity would sign a message and send it to the user, who would then decrypt the message with the public key. If the message is unchanged, then the author is probably who they say they are. If anyone really knows their stuff on this subject, feel free to correct me as I've done minimal research.

More or less, yeah. Worth noting that certificates aren't involved in the signing process (they're a different can of worms): you simply set up the OS with the public key, and the addon signer with the private one. If the OS can't decrypt an addon with that public key then it knows it didn't come from a trusted source.

This relies on all addons being installed by your OS, and all addon code being inspected before signing to ensure there's no malicious instructions (inspected by you, the developer of the OS, the only one who has the private signing key and is able to sign stuff). If anyone can run any code on a system without your OS's permission (eg by convincing the user to switch to developer mode), then they can likely take full control of it and remove all future signature checks from the code of your OS.

Obviously such compromisation is pretty trivial to pull off if they have physical access to the system, but that's not your concern.

Yevano, on 29 November 2015 - 12:58 AM said:

KingofGamesYami, on 28 November 2015 - 09:32 PM said:

In short, no.

Anything you do to your program, I (or any halfways decent programmer) could undo. The only thing I can think of is requiring a password upon installation, which is provided in the forum post. But then again, they could easily steal the password as well. You could add comments to your code indicating it's yours… but it'd be simple to remove them before redistributing it.

I don't think he's asking whether or not it's possible to prevent the program itself from being stolen, but rather he wants to be able to sign addons in such a way that one can verify the integrity of the addon, but not get a hold of the certificate. I'm no expert in cryptography by a long shot, but I believe what you're looking for is asymmetric encryption. The author would have a private key and a public key, and to demonstrate their authenticity would sign a message and send it to the user, who would then decrypt the message with the public key. If the message is unchanged, then the author is probably who they say they are. If anyone really knows their stuff on this subject, feel free to correct me as I've done minimal research.

Edit: @Quartz Looks like you're thinking in the same vein as I am, so maybe I'm not crazy :P/>

Yeah, that's what I was looking for. Also, I googled asymmetric encryption, and it says anyone can encrypt w/ the public key, but only the private key can decrypt it. Weird…

Bomb Bloke, on 29 November 2015 - 01:32 AM said:

Yevano, on 29 November 2015 - 12:58 AM said:

I'm no expert in cryptography by a long shot, but I believe what you're looking for is asymmetric encryption. The author would have a private key and a public key, and to demonstrate their authenticity would sign a message and send it to the user, who would then decrypt the message with the public key. If the message is unchanged, then the author is probably who they say they are. If anyone really knows their stuff on this subject, feel free to correct me as I've done minimal research.

More or less, yeah. Worth noting that certificates aren't involved in the signing process (they're a different can of worms): you simply set up the OS with the public key, and the addon signer with the private one. If the OS can't decrypt an addon with that public key then it knows it didn't come from a trusted source.

This relies on all addons being installed by your OS, and all addon code being inspected before signing to ensure there's no malicious instructions (inspected by you, the developer of the OS, the only one who has the private signing key and is able to sign stuff). If anyone can run any code on a system without your OS's permission (eg by convincing the user to switch to developer mode), then they can likely take full control of it and remove all future signature checks from the code of your OS.

Obviously such compromisation is pretty trivial to pull off if they have physical access to the system, but that's not your concern.

I will say that addons will likely be sandboxed, and they will NOT run with full system-level access. But yeah, that's the most likely way it'll happen. I'm looking for a lua asymmetric encryption algorithm right now, actually.

Quartz101, on 29 November 2015 - 02:27 PM said:

Yeah, that's what I was looking for. Also, I googled asymmetric encryption, and it says anyone can encrypt w/ the public key, but only the private key can decrypt it. Weird…

You can use either key to encrypt your data but you have to use the opposite key to decrypt. This video explains why you may want to encrypt with either key (or even both types of keys).
[media]http://www.youtube.com/watch?v=GSIDS_lvRv4[/media]

Asymmetric is a style used in various scenarios. For example, when generating a shared key for secure online communications, it's the public key used for encryption and the private key used for decryption. The point is that there's two keys, and their capabilities are not the same.

The terms "private" and "public" really mean exactly that, and nothing more. You keep one key to yourself, and you allow the other to be made visible to anyone who wants to use it. Whether you reveal the encrypting key or the decrypting key depends on what it is you're trying to do - prove that only you can produce messages the decryption key can decrypt, or ensure that only you can read messages the encryption key encrypted.

After some googling, I learned RSA is the best way for asymmetric encryption. Is there a secure lua RSA thing(not 1lann's) that supports CC, too? Or, of course, I could write up a nodejs thing to do the work for me, with my OS sending the request, but that doesn't seem so secure, and it seems cheaty…

Quartz101, on 29 November 2015 - 03:46 PM said:

After some googling, I learned RSA is the best way for asymmetric encryption. Is there a secure lua RSA thing(not 1lann's) that supports CC, too? Or, of course, I could write up a nodejs thing to do the work for me, with my OS sending the request, but that doesn't seem so secure, and it seems cheaty…

After looking around a little, I might also suggest that you first hash the program you mean to send using SHA2, then encrypt the hash with your private key. Send the encrypted hash and the program to the user. To verify integrity, the user only has to hash the program again, decrypt the encrypted hash, and check that the two hashes are equal.

The first thing I stumbled upon was http://luaforge.net/projects/sha1-rsa/ which seems to include the bigint functions required to do asymmetric encryption. I don't think it has its own key pair generation, so you'll have to use a different program for that, but that's a one time thing anyway so not really a big deal I guess.

Edit: Why not 1lann's? Unless his implementation is just incorrect, (even the one I sent you could be, I have no idea) it seems like his would work fine. You just need to make sure you use a different key pair generator, because as he says in his OP, the one he implemented in Lua is very insecure.

Yevano, on 29 November 2015 - 05:02 PM said:

Edit: Why not 1lann's? Unless his implementation is just incorrect, (even the one I sent you could be, I have no idea) it seems like his would work fine. You just need to make sure you use a different key pair generator, because as he says in his OP, the one he implemented in Lua is very insecure.

That's what I meant. The key pair generator is insecure.

Also, would it be possible to make a Node.js server to generate the keypairs, and CC gets them?

Quartz101, on 29 November 2015 - 07:49 PM said:

Also, would it be possible to make a Node.js server to generate the keypairs, and CC gets them?

I don't see why not. For best security just make sure you send the keys through https.

Well, put simply, even with the help of a BigInt library in CC, the amount of time that it would take to do most asymmetric encryption would be off the charts.
1lann's RSA, which is using 256-bits key, is very slow in CC, and not at all secure against cracking on a real computer.

So a good way of doing is using some kind of PHP code do to it for you instead of doing it in CC.
You'd have a separate program to sign the add-ons, and your OS would have code to verify them.

But in the end, your code is still modifiable to the user, and could easily remove that verify portion.

Anavrins, on 29 November 2015 - 10:21 PM said:

Well, put simply, even with the help of a BigInt library in CC, the amount of time that it would take to do most asymmetric encryption would be off the charts.
1lann's RSA, which is using 256-bits key, is very slow in CC, and not at all secure against cracking on a real computer.

So a good way of doing is using some kind of PHP code do to it for you instead of doing it in CC.
You'd have a separate program to sign the add-ons, and your OS would have code to verify them.

But in the end, your code is still modifiable to the user, and could easily remove that verify portion.

Am I wrong in thinking that only the key pair generation is really slow, not the actual encryption and decryption? It seems he's already going have a server to generate those, and I don't think encrypting and decrypting a SHA2 hash would take very long.

I was thinking in generating a checksum of the program, uploading it to a webserver and whenever you want to install a program just compare its checksum with the one on the webserver.

The time it takes to generate the key pair is mostly irrelevant (as that only needs to be done once, ever), and the time it takes to encrypt the hashes also doesn't matter much (as that only needs to be done once per addon update release). Decryption of addon hashes has to be done once for every time an addon is installed (and is the only time you'd need to do any encryption-related processing within ComputerCraft itself), and I'd be surprised if decryption of, say, a mere sixteen character hash would be too painful to sit through.

RoD, on 29 November 2015 - 11:10 PM said:

I was thinking in generating a checksum of the program, uploading it to a webserver and whenever you want to install a program just compare its checksum with the one on the webserver.

Not exactly "signing", but truth be told, I'd say this'd be more than sufficient. Heck, just having a paste (controlled by Quartz) with the list of "authorised addon" paste IDs would be sufficient. The difference is that these ways, if someone were to gain unauthorised access allowing them to modify that list, they'd be able to add their own paste IDs / hashes to it (whereas with encryption implemented, they'd also need to get their hands on the private key in order to do it).

Edit:

What am I thinking, if you wanted any form of "addon authorisation" you'd at least need to post the hashes. Otherwise you could be tricked into "authorising" a good addon which could later be "updated" into a bad one.

But let's assume the point is to sign for the sake of signing.

Here's what i've (partially) decided on:
1. Every developer has a unique key.
2. A server on the web will store the keys
3. The SERVER will handle encrypting/decrypting.
4. The addon itself will be encrypted, and the OS will download the key it needs to decrypt it.
5. Only signed/encrypted addons will be ran unless dev mode is on
6. Anyways, the OS will sandbox everything, so you would need root exploit (or a disk) to remove verification
7. And I might have some sort of intergrity checker in the OS itself.

Honestly, is this signing? I don't know. Checksums would be hard to handle. If there is a more 'sign'-y alternative, tell me.

Also, isn't CC really glitchy with HTTPS?

Here's how I would do it.
Though I have a strong interest in cryptography, I'm in no way an expert at it, so it is up to you to decide if you trust me or not.

Spoiler

Server Setup:

• Only one keypair should be used, meaning that only you can sign peoples add-ons, yes it may be tedious, but having multiple dev keys would open the possibility for random devs to be able to sign some random malware add-on for someone else.
• Server should handle the encryption/decryption (of course)

Signing:

• Singing should be done by hashing the add-on, sending that hash to the server for encryption, joining that encrypted hash (signature) to the unmodified add-on in some way.
• Although the add-on source is still in plain-text, nobody will be able to change it without triggering a verification error.

Verifying:

• Verifying should be done by hashing the add-on, reading the add-on signature, send the signature to the server for decryption and comparing if the file's hash matches the server provided hash.
• Your OS should refuse any add-on that lacks a proper signature, with the exception of your OS's "dev mode".

Anavrins is summing things up about correctly. There's no way you'd want more than one key pair, and you wouldn't want to hand a unique key to each developer - there's simply no point, since they won't be signing anything!

You also wouldn't bother encrypting entire addons when just a hash would suffice.

Anavrins, on 30 November 2015 - 12:27 AM said:

Here's how I would do it.
Though I have a strong interest in cryptography, I'm in no way an expert at it, so it is up to you to decide if you trust me or not.

Spoiler

Server Setup:

• Only one keypair should be used, meaning that only you can sign peoples add-ons, yes it may be tedious, but having multiple dev keys would open the possibility for random devs to be able to sign some random malware add-on for someone else.
• Server should handle the encryption/decryption (of course)

Signing:

• Singing should be done by hashing the add-on, sending that hash to the server for encryption, joining that encrypted hash (signature) to the unmodified add-on in some way.
• Although the add-on source is still in plain-text, nobody will be able to change it without triggering a verification error.

Verifying:

• Verifying should be done by hashing the add-on, reading the add-on signature, send the signature to the server for decryption and comparing if the file's hash matches the server provided hash.
• Your OS should refuse any add-on that lacks a proper signature, with the exception of your OS's "dev mode".

I think I get it…
So, this would be in the start of signed addons?

--[[
RSA KEY WHATEVER BEGIN
...
RSA KEY END
--]]

Well, you might put an encrypted signature there if you wanted. The actual keys wouldn't go into the addons themselves.

Bomb Bloke, on 30 November 2015 - 11:38 AM said:

Well, you might put an encrypted signature there if you wanted. The actual keys wouldn't go into the addons themselves.

SO, the signatures are on the webserver, right?

Indeed - the "signatures" being encrypted hashes of the approved addons. The OS gets the signature from the server (or where ever - again, pastebin's perfectly suitable), and then decrypts it (or uses a remote server for decryption, if it really has to; though as I've said before, I doubt decryption of a mere hash would be all that taxing on a ComputerCraft system). It also hashes the addon script it downloaded. It should then have two hashes - if they're the same, then it knows that the addon it downloaded is an addon you personally signed off on, because you're the only guy in a position to provide matching encrypted hashes.

You could provide the signatures to the addon authors, and have them embed them into their addons, if you really wanted. This complicates matters though - adding the signature to an addon means that the hash changes, thereby invalidating the signature. So your OS would need to discount the signature from the script file when generating the hash, were you to do it that way!

If it helps, the process Anavrins wrote for you is the same as the one Yevano gave you.

The signature must not be on the server, they should be attached to the add-on in some way.
A good way I can think of is as a comment, in the first line of the add-on's code.
Reading it is as simple as…

local file = fs.open("add-on", "r")
local signature = file.readLine()
local code = file.readAll() #-- Won't contain the first line
local code_hash = sha.digest(code)

Anavrins, on 30 November 2015 - 08:15 PM said:

The signature must not be on the server, they should be attached to the add-on in some way.
A good way I can think of is as a comment, in the first line of the add-on's code.
Reading it is as simple as…

local file = fs.open("add-on", "r")
local signature = file.readLine()
local code = file.readAll() #-- Won't contain the first line
local code_hash = sha.digest(code)

That way anyone can copy the first line of the add on :|

RoD, on 30 November 2015 - 08:57 PM said:

Anavrins, on 30 November 2015 - 08:15 PM said:

The signature must not be on the server, they should be attached to the add-on in some way.
A good way I can think of is as a comment, in the first line of the add-on's code.
Reading it is as simple as…

local file = fs.open("add-on", "r")
local signature = file.readLine()
local code = file.readAll() #-- Won't contain the first line
local code_hash = sha.digest(code)

That way anyone can copy the first line of the add on :|

And?
They can't do anything with it, putting it in their own malicious add-on will cause a verification error, that's the whole point of a signature…

Indeed, the next few lines would go something like this:

if code_hash ~= decrypt(signature) then
  error("Signature mis-match.")
end

Every addon, and every update to each addon, requires its own unique signature, provided by Quartz. If one single bit within an addon is changed, the new hash will no longer match the one stored in the old encrypted signature and verification will fail.

Bomb Bloke, on 01 December 2015 - 12:21 AM said:

Indeed, the next few lines would go something like this:

if code_hash ~= decrypt(signature) then
  error("Signature mis-match.")
end

Every addon, and every update to each addon, requires its own unique signature, provided by Quartz. If one single bit within an addon is changed, the new hash will no longer match the one stored in the old encrypted signature and verification will fail.

thats what i was talking about.

I'm not sure I take your meaning. A given signature is only good for verifying a specific addon. It doesn't matter who gets their hands on it, if that's what you're worried about; the only thing that needs to be hidden is the private key used to generate encrypted signatures in the first place.

So, based on all this, I have came up with this:

The signature is the hash of the program encrypted with my private key(the signature will be a seperate file, addon.sig)
The server will have a list of approved signatures, each developer will have some sort of web thing where they upload the contents and the .sig is generated
The addons will not run without a valid signature unless developer mode is active.
To prevent a developer from changing an addon to malicious and signing it, I will review all addons. It will NOT wait for me to review it, but I will revoke the certificate if it's malicious and the signature will stop working.

Quartz101, on 01 December 2015 - 08:32 PM said:

The signature is the hash of the program encrypted with the hash of the contents (the key will be a seperate file, addon.sig)

No… the signature is the hash of the program encrypted with a private key located on your http server.

Anavrins, on 01 December 2015 - 08:52 PM said:

Quartz101, on 01 December 2015 - 08:32 PM said:

The signature is the hash of the program encrypted with the hash of the contents (the key will be a seperate file, addon.sig)

No… the signature is the hash of the program encrypted with a private key located on your http server.

Oops, typo. Will fix!

Quartz101, on 01 December 2015 - 08:32 PM said:

It will NOT wait for me to review it, but I will revoke the certificate if it's malicious and the signature will stop working.

… by which time it'll potentially be too late, making the whole infrastructure pointless.

And again, there're no "certificates" involved here.

Indeed, and really, you wouldn't want to get involved with certificates just for a CC project…

When I say certificate, I mean signature.

I use them interchangeably, sorry.

Bomb Bloke, on 01 December 2015 - 10:24 PM said:

… by which time it'll potentially be too late, making the whole infrastructure pointless.

I might do a first-submit review, and after that, there will be a 'Report' button.
And anyways, addons won't have major permissions that could do serious damage.

All I see here, with encryption, is pretty big. Why don't you just have some kind of private key(e.g. "ABCDEFGH" [Not recommend for use]), which is ONLY stored on the web server. Then you use the hash to do the following:

Giving the "certificate"

You accept some users App with some code

print("Hello World!")

After you checked everything is correct, you hash it(I am using SHA256 here): "866b5033009e3e3f3e40bef180e6924d937996a57fc8b5ce85090b5d14459f1f"
Now you put your private part in "866b5033009e3e3f3e40bef180e6924d937996a57fc8b5ce85090b5d14459f1fABCDEFGH"
And again into the hash algorithm: "c5f60fcf016e063b49d885137bbde4f652755a6667f724d77e5f8655685371d3"
Now you bring that hash with your app(e.g. first line)

c5f60fcf016e063b49d885137bbde4f652755a6667f724d77e5f8655685371d3
print("Hello World!")

And you are done with that.

Checking for the "certificate"

You read out the first line

local f = fs.open("app","r")
local hash = f.readLine()
local cont = f.readAll()
local toVerify = hashAlgo(cont)

Then you send "toVerify" and "hash" to your server, which then checks if the "certificate" is ok by doing the following:
Hash together "toVerify" and "ABCDEFGH" and if the result equals "hash" then the app is not modified.
In this example "hash" would be "c5f60fcf016e063b49d885137bbde4f652755a6667f724d77e5f8655685371d3" and "toVerify" would be "866b5033009e3e3f3e40bef180e6924d937996a57fc8b5ce85090b5d14459f1f" and if you appened "ABCEDFGH" to that and hash it the result would equal "hash", which means the App is not modified.

What is if the App is modified?

Lets get thru that.
The attacker modifies the App and changes it to this.

print("I am deleting your files")
fs.delete("*")

The attacker doesn't know your secret and can't reproduce the hash, so he has to put no hash, the old hash or only the hash for the content.

No hash

In this case, the first line will be read, which is "print("I am deleting your files")". in case you use sha256, this will fail, because a sha256 hash always has 64 characters, so it will never be equal to the hash used to check it. Also it will be pretty un-likely that the attacker puts in a 64 character string in his first line.

The old hash

The code would look like this:

c5f60fcf016e063b49d885137bbde4f652755a6667f724d77e5f8655685371d3
print("I am deleting your files")
fs.delete("*")

In this case the hash is read and the process described above is done.
The sha of the part where the code really is(Line 2,3) is "61b6af12a316e7ab3309c968eaa12952465f2ce33e750bf0fe104d70c3ffb0c5".
If you append your secret to that "61b6af12a316e7ab3309c968eaa12952465f2ce33e750bf0fe104d70c3ffb0c5ABCDEFGH".
The hash of that is "e8924a286417ae50d8d5d6c536dd7d7f9ffd1cd726ab6c924165b26d19151eb1". That is not equal to the hash specified in the App. The App is now proven to be modified.

Only the hash of the content

Same case as above, but now the attacker uses this code:

61b6af12a316e7ab3309c968eaa12952465f2ce33e750bf0fe104d70c3ffb0c5
print("I am deleting your files")
fs.delete("*")

"61b6af12a316e7ab3309c968eaa12952465f2ce33e750bf0fe104d70c3ffb0c5" is the hash of lines 2 & 3.
Now the algorithm checks it and first hashes the content of the app(lines 2 & 3), which results into "61b6af12a316e7ab3309c968eaa12952465f2ce33e750bf0fe104d70c3ffb0c5". Now it appends your secret: "61b6af12a316e7ab3309c968eaa12952465f2ce33e750bf0fe104d70c3ffb0c5ABCDEFGH". Which is "e8924a286417ae50d8d5d6c536dd7d7f9ffd1cd726ab6c924165b26d19151eb1". This is not equal to the hash specified in the App. The App is proven unsafe again.

Also before you start complaining, I have a reason why I write "certificate"

I am no cryptographic expert either, but that is, what I would do, to make sure the content is not modified.

That'd work. It'd be relatively easy to crack, but I doubt anyone would try.

Luca0208, on 02 December 2015 - 08:03 PM said:

Also before you start complaining, I have a reason why I write "certificate"

… and that is?

Bomb Bloke, on 02 December 2015 - 10:21 PM said:

That'd work. It'd be relatively easy to crack, but I doubt anyone would try.

How would you want to crack it? You need the secret thingy. I am assuming no one changes the code for checking the add-on.

Bomb Bloke, on 02 December 2015 - 10:21 PM said:

Luca0208, on 02 December 2015 - 08:03 PM said:

Also before you start complaining, I have a reason why I write "certificate"

… and that is?

1. The author of the topic uses certificate to describe what he wants, so I use the same word to describe it, to make it easier for him to understand.
2. I put it in "", because you guys are right, it is not an actual certificate.

Luca0208, on 03 December 2015 - 05:39 PM said:

How would you want to crack it? You need the secret thingy. I am assuming no one changes the code for checking the add-on.

Long story short, hashing is not an encryption method. Hashes can be reversed, and that process is only made easier when half of the desired result is already known.

Again, it'd be difficult enough that I believe no one would try; not for a ComputerCraft OS, anyway.

Bomb Bloke, on 04 December 2015 - 01:57 AM said:

Hashes can be reversed

If that is true, that would mean every password you entered somewhere is insecure and you should really be worried.

Luca0208, on 04 December 2015 - 07:10 PM said:

Bomb Bloke, on 04 December 2015 - 01:57 AM said:

Hashes can be reversed

If that is true, that would mean every password you entered somewhere is insecure and you should really be worried.

Some hashes can be reversed, however most cannot be reversed. Rainbow tables exist which is simply a list with common passwords and the hashed values, one of the reasons why I believe plain hashes are insecure.
Generally if something needs to be stored as a password one hashes it. However, the common mistake is not to salt, which should be done so the hashes are secure. Read more on salting here: https://en.m.wikipedia.org/wiki/Salt_(cryptography)

This has nothing to do with signing right now…
Hashes cannot be reversed, (except MD4, which can be recovered in less than 2 steps o.O)…
They can be looked up from a list of pre-generated hashes.

But in our example of signatures, hashes are not used for password storage, but mostly as a small "sum-up" of the file needed to be signed.
SHA256 cannot be reversed, you won't have a random custom program's hash in your rainbow table, knowing half or all of the file's content doesn't matter.