Crypto API

Right now, there are a few Lua API's utilizing the bit library to do things like AES and SHA256. They're all horribly slow and inefficient. I'm proposing a new crypto API that does all these functions in Java.

Here's a list of functions that it should have.

SHA

crypto.sha256(string, repeat) -> Returns the SHA256 hash of the string, hashed over repeat times. There should be a limit on how big repeat can be.

crypto.sha512(string, repeat) -> Returns the SHA512 hash of the string, hashed over repeat times. There should be a limit on how big repeat can be.

AES

crypto.aes.encrypt(strinPlaintext, stringKey) -> Returns AES encrypted data using stringKey. The data should probably be encrypted using CBC mode (feedback needed, which mode would be best?).

The ciphertext should also be base64 encoded to prevent the LuaJ string bug.

crypto.aes.decrypt(stringCiphertext, stringKey) -> Returns the plaintext of the ciphertext.

Example:

local ciphertext = crypto.aes.encrypt("Hello, secure ComputerCraft!", "dan200")
print(crypto.aes.decrypt(ciphertext, "dan200")

RSA

crypto.rsa.createKeypair( [1024 or 2048 bits] ) -> Creates an RSA keypair (returned as a tuple)

crypto.rsa.encrypt(stringPlaintext, [ public or private key ]) -> Encrypts the plaintext with the given key.

crypto.rsa.decrypt(stringCiphertext, [ public or private key]) -> Decrypts the ciphertext with the given key.

Example:

local pub, priv = crypto.rsa.createKeypair(2048)
local ciphertext = crypto.rsa.encrypt("Hello, asymmetric encryption!", pub)
print(crypto.rsa.decrypt(ciphertext, priv))

I've been maintaining my AES implementation for 10 months now and I'm pretty pleased with it. 30Kb/s is pretty impressive and it is no more inefficient than the idea of a Lua VM running inside a Java VM. However no one uses it - there are about 800 hits on pastebin for the combined versions, and most of them will be from random people - not actual implementers.

I guess the two points I'm trying to make is that firstly, the implementations of SHA256 and AES are pretty good, no one writes performance critical code in ComputerCraft so a couple of milliseconds either way doesn't make a difference - the entire hard drive of a computer is 1Mb! The other point is that no one really needs it, there isn't much appetite for security in CC - password locks can be bypassed with the startup disk trick/tool, it is easy to listen in on rednet messages, etc… No one really is sending anything worth using industrial scale encryption to secure it with.

Also, it is far more fun writing them in Lua than just using a Java API for it.

SquidDev, on 18 March 2015 - 09:14 PM said:

…

I agree with what you have to say, the only pro I can see from the OP's suggestions is that it would be built-in.
@Sxw A thing you should think about is that usually suggestions that can be implemented on the Lua side doesn't get added, I can't say I'm against this suggestion, but I don't see the big need for it either.

Most suggestions of this kind can be implemented with peripherals, since yes it is possible to implement them in Lua direcly.
However, Immibis' Peripherals contains a Cryptographic Accelerator that does exactly what you want.
IIRC, it supports RSA 1024bit, cipher such as AES, RC4, Blowfish, DES with most of the modes, padding and keysize, hashing such as md4, md5, sha1, sha256.

The only thing infeasible in CC is RSA, calculating the modulus of the exponent was estimated to take half of a year for a 500-bit key when I implemented it.

To bring this back to life;

I fully support this idea. Sure, we may not need it as we have implementations, but they are slow. I don't know about you, but 10 seconds to generate a sha256 hash for a 320kb file isn't good enough for me. I implemented DSA, which has horrible performance issues because we can't really even use the bit API here today (can't handle the numbers)

I +1 this, as it's something everything should have. A computer in the real world accelerates AES, why can't we accelerate crypto functions as well?

EDIT: I agree writing stuff is fun, but who said you can't still write stuff and have a side API for it?

Doesn't dan200 have the philosophy of: "if it can be written in lua then write it in lua"?

This should DEFINETLY be implemented native to the mod, ive seen some of these encrypt algs from other people some of which aren't even calculating the values correctly, if this was embedded within the mod execution times would be much faster and available for the entire CC community not just those that had to go and dig through 10GB of forum posts to find one that still takes 5seconds to calc a single key. And also

SquidDev, on 18 March 2015 - 09:14 PM said:

I've been maintaining my AES implementation for 10 months now and I'm pretty pleased with it. 30Kb/s is pretty impressive and it is no more inefficient than the idea of a Lua VM running inside a Java VM. However no one uses it - there are about 800 hits on pastebin for the combined versions, and most of them will be from random people - not actual implementers.

I guess the two points I'm trying to make is that firstly, the implementations of SHA256 and AES are pretty good, no one writes performance critical code in ComputerCraft so a couple of milliseconds either way doesn't make a difference - the entire hard drive of a computer is 1Mb! The other point is that no one really needs it, there isn't much appetite for security in CC - password locks can be bypassed with the startup disk trick/tool, it is easy to listen in on rednet messages, etc… No one really is sending anything worth using industrial scale encryption to secure it with.

Also, it is far more fun writing them in Lua than just using a Java API for it.

The fact that the disk is so severely small should promote more push for efficient code and honestly anyone that doesn't try to make their code clean and quick is either in their first week of coding or should not programming because they obviously didn't get that computers are valuable and that you should be as minimalistic as possible while maintaining fully featured functionality. Sorry im just really hot about efficiency lol

jacky500, on 05 June 2015 - 08:21 PM said:

This should DEFINETLY be implemented native to the mod, ive seen some of these encrypt algs from other people some of which aren't even calculating the values correctly, if this was embedded within the mod execution times would be much faster and available for the entire CC community not just those that had to go and dig through 10GB of forum posts to find one that still takes 5 seconds to calc a single key.

The fact that the disk is so severely small should promote more push for efficient code and honestly anyone that doesn't try to make their code clean and quick is either in their first week of coding or should not programming because they obviously didn't get that computers are valuable and that you should be as minimalistic as possible while maintaining fully featured functionality. Sorry im just really hot about efficiency lol

Um, Google? "aes computercraft" comes up with my implementation as the second result. With the LuaJC compiler going it can easily reach 100kB/s, and at 11.5kB, it isn't really an impact on the file size. I wrote an build system (including porting a minifier and busted over to CC) just to I could streamline development of this. I know that this calculates the values correctly, there was a point when KillaVanilla's implementation didn't so I wrote some tests using the official test vectors - everything passed. I guess I'm a bit protective about this - I've spend many hours on this and don't want them to go to waste. This is after all the only CC program I've run a profiler on. Sorry, self promotion over. :P/>

I think there are perks about implementing something built in as opposed to using Immibis' Cryptographic Accelerator - most mod packs don't have it installed after all. However using it is possible, and falling back to another implementation is a possibility.

Personally I don't think optimisation/efficiency is important most of the time - I'd rather someone wrote readable code than hyper-optimised it. And more importantly I'd rather they had fun and learned. I've seen people start off using os.reboot() to emulate a while loop - but it is great watching people learn. Sure, their code isn't going to prove P == NP but it manages their big reactor so that's fine.

TLDR: There are some pretty good reasons to add this, I just don't think that it will be added any time soon.

+1

i would love to see the public/private key encyption and the hashing, it would be amazing so that we can finnaly secure rednet traffic using the public/private key method