Syscrypt - A basic login mask with File Encryption

As you could read in the title, this Login System not only encrypts the password, but also the files which are saved on the computer.
Please note: this login system will slow down startup and shutdown significantly. To kinda work around this, there is no encryption happening on reboot.
It uses the AES for ComputerCraft API by KillaVanilla and the SHA256 API by GravityScore.
Syscrypt also automaticly runs the old startup file which was already there on installation.

Syscrypt is still in development. So there are some functions expected in login systems that syscrypt yet does not have.
Functions yet to be implemented:

• multiple accounts
• changeable passwords

Please not, that Syscrypt is now licensed with the MIT License.
Download: pastebin run 469Z93Zr

In case you've accidently overwritten the startup file or you want to run something else after decryption, no problem. Just rename your new startup file into boot and put it into the .syscrypt folder.
If you don't have the startup file from syscrypt anymore, just get it manualy with this command: pastebin get s3PazEbG startup

Feel free to tell me any bugs you find or suggestions in the comment section :)/>

That's pretty sweet, I've been seeing a bunch of people doing this kind of program, me included.
Few problems though, I know that KillaVanilla's AES api is incorrectly implemented, so it might be weaker than intended.
As well as GravityScore's sha256 api, it outputs the wrong hash when its input is 55 characters and it's quite a bit slower than my version, might be why startup/shutdown is slow.

A severe flaw in this system though, is that not anybody will use os.shutdown() or the shutdown command to shut a computer down, ctrl+s, peripheral.call(side, "shutdown") and unloading chunk will bypass your os.shutdown function and leave the filesystem unencrypted and without a password prompt.

how about on-the-fly decryption? I've seen it elsewhere on the forums and it would negate the shutdown problem

Lupus590, on 16 May 2016 - 10:11 PM said:

how about on-the-fly decryption? I've seen it elsewhere on the forums and it would negate the shutdown problem

Pretty much, that's how I do in mine, though it become difficult to do when you have to completely re-write fs.open, as well as replicating all the modes including append and binary.

Anavrins, on 16 May 2016 - 09:42 PM said:

That's pretty sweet, I've been seeing a bunch of people doing this kind of program, me included.
Few problems though, I know that KillaVanilla's AES api is incorrectly implemented, so it might be weaker than intended.
As well as GravityScore's sha256 api, it outputs the wrong hash when its input is 55 characters and it's quite a bit slower than my version, might be why startup/shutdown is slow.

A severe flaw in this system though, is that not anybody will use os.shutdown() or the shutdown command to shut a computer down, ctrl+s, peripheral.call(side, "shutdown") and unloading chunk will bypass your os.shutdown function and leave the filesystem unencrypted and without a password prompt.

The shutdown is slowed down by the encryption, not the Hashing. The SHA256 API is only used to save the password in a non-readable format and that the password can be interpreted as a base36 math.randomseed() so that the main keypair doesn't need to be saved anywhere. And in case somebody shuts down his computer by any other methode, then calling os.shutdown() the system will be kept in a reboot ready state. This is just, so that the API doesn't try to decrypt the decrypted files, which would cause unrepaireable damage to the files on the computer. I was aware of these issues beforehand, and as stated in OP it's still in development. I'll see what I can do…

Lupus590, on 16 May 2016 - 10:11 PM said:

how about on-the-fly decryption? I've seen it elsewhere on the forums and it would negate the shutdown problem

That is a good idea! The only problem is, I don't know how to implement such thing and wouldn't this also cause some issues with CC updates?

Chickenbreadlp, on 17 May 2016 - 09:53 AM said:

Anavrins, on 16 May 2016 - 09:42 PM said:

That's pretty sweet, I've been seeing a bunch of people doing this kind of program, me included.
Few problems though, I know that KillaVanilla's AES api is incorrectly implemented, so it might be weaker than intended.
As well as GravityScore's sha256 api, it outputs the wrong hash when its input is 55 characters and it's quite a bit slower than my version, might be why startup/shutdown is slow.

A severe flaw in this system though, is that not anybody will use os.shutdown() or the shutdown command to shut a computer down, ctrl+s, peripheral.call(side, "shutdown") and unloading chunk will bypass your os.shutdown function and leave the filesystem unencrypted and without a password prompt.

The shutdown is slowed down by the encryption, not the Hashing. The SHA256 API is only used to save the password in a non-readable format and that the password can be interpreted as a base36 math.randomseed() so that the main keypair doesn't need to be saved anywhere. And in case somebody shuts down his computer by any other methode, then calling os.shutdown() the system will be kept in a reboot ready state. This is just, so that the API doesn't try to decrypt the decrypted files, which would cause unrepaireable damage to the files on the computer. But I'll see what I can do…

Lupus590, on 16 May 2016 - 10:11 PM said:

how about on-the-fly decryption? I've seen it elsewhere on the forums and it would negate the shutdown problem

That is a good idea! The only problem is, I don't know how to implement such thing and wouldn't this also cause some issues with CC updates?

You could do the on-the-fly encryption by simply just overwriting the FS API, so backup the old functions, then create yours in place of the current FS :D/>. Can't see it causing issues? It could do, but you can make it so if an extra parameter is given to the fs.open function it won't encrypt meaning your need for updating the program is then not a problem.

DannySMc, on 17 May 2016 - 09:58 AM said:

Chickenbreadlp, on 17 May 2016 - 09:53 AM said:

Anavrins, on 16 May 2016 - 09:42 PM said:

That's pretty sweet, I've been seeing a bunch of people doing this kind of program, me included.
Few problems though, I know that KillaVanilla's AES api is incorrectly implemented, so it might be weaker than intended.
As well as GravityScore's sha256 api, it outputs the wrong hash when its input is 55 characters and it's quite a bit slower than my version, might be why startup/shutdown is slow.

A severe flaw in this system though, is that not anybody will use os.shutdown() or the shutdown command to shut a computer down, ctrl+s, peripheral.call(side, "shutdown") and unloading chunk will bypass your os.shutdown function and leave the filesystem unencrypted and without a password prompt.

The shutdown is slowed down by the encryption, not the Hashing. The SHA256 API is only used to save the password in a non-readable format and that the password can be interpreted as a base36 math.randomseed() so that the main keypair doesn't need to be saved anywhere. And in case somebody shuts down his computer by any other methode, then calling os.shutdown() the system will be kept in a reboot ready state. This is just, so that the API doesn't try to decrypt the decrypted files, which would cause unrepaireable damage to the files on the computer. But I'll see what I can do…

Lupus590, on 16 May 2016 - 10:11 PM said:

how about on-the-fly decryption? I've seen it elsewhere on the forums and it would negate the shutdown problem

That is a good idea! The only problem is, I don't know how to implement such thing and wouldn't this also cause some issues with CC updates?

You could do the on-the-fly encryption by simply just overwriting the FS API, so backup the old functions, then create yours in place of the current FS :D/>. Can't see it causing issues? It could do, but you can make it so if an extra parameter is given to the fs.open function it won't encrypt meaning your need for updating the program is then not a problem.

That sounds like an idea. Thank you! I'll see how exactly I'll implement it. But if you look into the OP you'll see, that there are still many things to do (for example a safe way to uninstall this).

Chickenbreadlp, on 17 May 2016 - 10:10 AM said:

DannySMc, on 17 May 2016 - 09:58 AM said:

Chickenbreadlp, on 17 May 2016 - 09:53 AM said:

Anavrins, on 16 May 2016 - 09:42 PM said:

That's pretty sweet, I've been seeing a bunch of people doing this kind of program, me included.
Few problems though, I know that KillaVanilla's AES api is incorrectly implemented, so it might be weaker than intended.
As well as GravityScore's sha256 api, it outputs the wrong hash when its input is 55 characters and it's quite a bit slower than my version, might be why startup/shutdown is slow.

A severe flaw in this system though, is that not anybody will use os.shutdown() or the shutdown command to shut a computer down, ctrl+s, peripheral.call(side, "shutdown") and unloading chunk will bypass your os.shutdown function and leave the filesystem unencrypted and without a password prompt.

The shutdown is slowed down by the encryption, not the Hashing. The SHA256 API is only used to save the password in a non-readable format and that the password can be interpreted as a base36 math.randomseed() so that the main keypair doesn't need to be saved anywhere. And in case somebody shuts down his computer by any other methode, then calling os.shutdown() the system will be kept in a reboot ready state. This is just, so that the API doesn't try to decrypt the decrypted files, which would cause unrepaireable damage to the files on the computer. But I'll see what I can do…

Lupus590, on 16 May 2016 - 10:11 PM said:

how about on-the-fly decryption? I've seen it elsewhere on the forums and it would negate the shutdown problem

That is a good idea! The only problem is, I don't know how to implement such thing and wouldn't this also cause some issues with CC updates?

You could do the on-the-fly encryption by simply just overwriting the FS API, so backup the old functions, then create yours in place of the current FS :D/>. Can't see it causing issues? It could do, but you can make it so if an extra parameter is given to the fs.open function it won't encrypt meaning your need for updating the program is then not a problem.

That sounds like an idea. Thank you! I'll see how exactly I'll implement it. But if you look into the OP you'll see, that there are still many things to do (for example a safe way to uninstall this).

Indeed, well I hope I helped!