A while back I mentioned to the public systems I created such as "Imperial Bank" which used strong professional grade encryption algorithms to store data. Such systems were first seen in public in Undead Assault 3 2015 towards the end of 2014 and was used to replace an existing insecure method of data storage. On top of that the map also boasted a secure import feature which with a bit of manual work (move bank file, copy checksum) allowed players to import a bank file from another author protected with standard (SC2 inbuilt) bank protection without compromising the protection. All of this was thanks to the Imperial Libraries I wrote which deal with bulk data storage, hashing, encryption, string encoding and bank management.
With the unfortunate demise of the map reboot due to a SC2 bug (queuing "Learn" ability orders) I decided it was time I made available to the public the systems used so that my effort might not go to waste.
Currently it is very much in a WIP stage. Some functionality might not be entirely correct or bug free. It also has no GUI wrapper due to the use of references (not supported by GUI) however that should not really hinder anyone from using it.
At the Imperial Bank system has some minor errors with SHA-1 hashing of blocks using incorrect padding behaviour which requires fixing. This was due to the rushed nature of production and the complexity of the solution at hand. It will work and should do so reliably (hundreds of people used it with no concrete error being reported) however it might become incompatible with future versions in its current state unless you set SHA1 compatibility to 0 (which turns on a minor error with hash finalization computation).
The SHA-1 hasher library with some other libraries can be used to compute SC2 bank signature strings. You can use this computed hash string to validate a user inputted one for moving maps between authors or regions. Computation of such a string is shown off in one of the test case triggers and has been proven to match the results generated by SC2 in over a hundred cases online.
The AES library was tested using a specification document which provided various results at various stages. The inverse cipher and cipher operations have been tested to cancel each other out. Since this is a block encryption algorithm it is recommended you do not encrypt data directly with it since that becomes subject to pattern attacks (where they learn the structure of the contained data). I would recommend either using it in some form of feedback mode (output goes to input of next block) or in counter mode (encrypt deterministic garbage which you add as noise to the data) which I used for Imperial Bank.
Imperial Bank is designed to store "blocks" of data and does so with both SHA-1 cryptographic hashes for error detection and with AES derived encryption for data masking. The keys are computed from a variety of sources including the bank owner, the block name and various map specific constants. Data is stored in base 64 meaning exactly 6 bits per character. Since the protection is quite large it is recommended to try to max out block length before moving to another block.
It is unclear if the system will run into oplimit problems for longer blocks, something that needs testing. It also does not support cross-region play as the necessary functions to add other accounts have not yet been implemented. The bank also has a secure archive header which checks for consistency with what has been stored. Imperial Bank is not compatible with sharing a bank for other purposes currently as it will detect the bank as damaged and reject it. Like all bank systems it is vulnerable to inside attack however in order to do this you need extensive knowledge of Galaxy and no over-the-internet program can do that for you unlike the standard signature system.
To generate blocks a bitfield library exists that allows you to write and read elements of variable bit length as integers. Currently there is no vector int support (good for general compression) however one or more are being considered for possible future updates. The idea is that you generate a bitfield of data and save it as a block or you load a block into a bitfield and extract the data from it.
Due to SC2Mapster migration the attachment broke. Below is a temporary link to the file on DropBox (might be removed in distant future).