BWTC32Key
| Line 9: | Line 9: | ||
| error resilience = yes | | error resilience = yes | ||
| patent license = unencumbered | | patent license = unencumbered | ||
| − | | reference impl = | + | | reference impl = https://sentogiga.github.io/bwtc32key |
| extensions = {{ext|b3k}} | | extensions = {{ext|b3k}} | ||
| released = 2019 | | released = 2019 | ||
| Line 25: | Line 25: | ||
The output of the encoder is a text string. B3K files are always [[UTF-16]] Big-endian text documents bearing the Byte Order Mark that contain said string. That string is a version of Base32768 which uses Hangul Syllable blocks and Han ideographs to allow font support while keeping size down in bytes. Also, the string is essentially a Korean message but in a different style. The file starts with a header of 0xFEFF4D00 and ends with a trailer of 0x4D01. The file CAN be concatenated, but to reverse that, one must use a text editor to extract the portion you need, due to the way the original program currently works. | The output of the encoder is a text string. B3K files are always [[UTF-16]] Big-endian text documents bearing the Byte Order Mark that contain said string. That string is a version of Base32768 which uses Hangul Syllable blocks and Han ideographs to allow font support while keeping size down in bytes. Also, the string is essentially a Korean message but in a different style. The file starts with a header of 0xFEFF4D00 and ends with a trailer of 0x4D01. The file CAN be concatenated, but to reverse that, one must use a text editor to extract the portion you need, due to the way the original program currently works. | ||
| − | All of the code is stream and chunk compatible, and this includes the AES256 implementation which uses the Counter mode. The password field only accepts 8 bit [[ASCII]] to minimize headaches, but due to there being no length limit, [[UTF-7]] or [[Punycode]] can be used to allow non-Latin passwords. Also, the encryption can be blanked, allowing the format to be used in things that encryption wouldn't be useful in, such as an image compression format. | + | All of the code is stream and chunk compatible, and this includes the AES256 implementation which uses the Counter mode. The password field only accepts 8 bit [[ASCII]] to minimize character set headaches, but due to there being no password length limit, [[UTF-7]] or [[Punycode]] can be used to allow non-Latin passwords to be used. Also, the encryption can be blanked out, allowing the format to be used in things that encryption wouldn't be useful in, such as an image compression format, essentially leaving the encryption feature unused when the password field is left blank or at default. |
| − | The format was written in pure | + | The format was written in pure [[JavaScript]] and is purely FOSS. The format was written by the author starting at age 16 and was definitely finished by the time they turned 17. This does show in the code. The compression and encryption functionality of this program coincidentally harks back to the Classic Mac OS days of [[PackIt]], which featured similar sequential concatenation and compression of multiple files and forks into the archive as well as encryption, all far more primitive and inefficient than BWTC32Key. |
| − | The Base32768 final step is essentially the antithesis of the original [[BinHex]], because instead of using an algorithm that doubles the binary input size via base 16, the base32768 step makes the AES256-CTR encrypted BWTC archive only 16/15 of the original size assuming the UTF-16BE with BOM output is the encoding to be fed into the output text file that uses the .B3K extension instead of the .txt extension used for normal plain text documents. It should be noted that since the BWTC compressor is very simple compared to even the original bzip, and that the 256bit [[AES]] variety used is the counter mode which needs | + | The Base32768 final step is essentially the antithesis of the original [[BinHex]], because instead of using an algorithm that doubles the binary input size via base 16, the base32768 step makes the AES256-CTR encrypted BWTC archive only 16/15 of the original size assuming the UTF-16BE with BOM output is the encoding to be fed into the output text file that uses the .B3K extension instead of the .txt extension used for normal plain text documents. It should be noted that since the BWTC compressor is very simple compared to even the original bzip, and that the 256bit [[AES]] variety used is the counter mode which needs no padding, the format is very slim and subtle. |
| − | As a text based format that closely resembles human text, it can be used where text is required, | + | As a text based format that closely resembles human text, it can be used where text is exclusively required (in most cases), while also being similar in spirit to authentic human scripts, which allows it to be injected into written works as if it were a Korean section of actual human writing, with no humanly-distinguishable traces at all. Also, due to it being stream compatible, broadcasting it can be done as a means of sending data through live channels as a stream of data one could opt into. Another feature it has is that it will never decode corrupt input, without computing anything. Meaning, it will fail if the magic number of the BWTC archive ("bwtc") isn't present in the compressed data due to corruption or the wrong key, or if the Base32768 text itself has junk thrown in or isn't properly formed or decodable. And if the corruption corrupts the Base32768 text data itself, or even the UTF16BE (with BOM) encoded Base32768 text itself, it will also fail un either case. This ensures that corrupted files will not be created by the decoder or your system, which can help stop damage to your system if something like a firmware blob or an executable was affected. This format does not care about file information of any kind. Hence, this is why it can be used as a chunk or stream format in cases where file info isn't needed. This is only possible because of the encryption feature being optional to apply to the input, thus allowing data (such as uncompressed image data, typeface data, soundbank data, and open streams) that would be pointless and unwise to encrypt to be able to be used with this format. As mentioned before, live input streams are allowed, and real time data input is as well. And in other implementations, multiple files could be encoded and then concatenated, optionally with different keys per file, all with the right logic. |
== Links == | == Links == | ||
| − | * The format implementation is at [https://sentogiga.github.io/bwtc32key/ Github Implementation] | + | * The author's format implementation is at [https://sentogiga.github.io/bwtc32key/ Github Implementation] |
* The github repository is at [https://github.com/sentogiga/bwtc32key The Repo] | * The github repository is at [https://github.com/sentogiga/bwtc32key The Repo] | ||
[[Category:Transfer Encodings]] | [[Category:Transfer Encodings]] | ||
Revision as of 01:40, 28 January 2020
BWTC32Key is a single-file compression tool and format with optional encryption, that also is text-armored.
Discussion
The code is based upon specific JavaScript implementations of Base32768 AES, SHA-256, and a spiritual successor to the original bzip format. The code is based upon JS code that runs in pure JS with no dependencies and is housed in the HTML frontend as a single monolithic program.
The output of the encoder is a text string. B3K files are always UTF-16 Big-endian text documents bearing the Byte Order Mark that contain said string. That string is a version of Base32768 which uses Hangul Syllable blocks and Han ideographs to allow font support while keeping size down in bytes. Also, the string is essentially a Korean message but in a different style. The file starts with a header of 0xFEFF4D00 and ends with a trailer of 0x4D01. The file CAN be concatenated, but to reverse that, one must use a text editor to extract the portion you need, due to the way the original program currently works.
All of the code is stream and chunk compatible, and this includes the AES256 implementation which uses the Counter mode. The password field only accepts 8 bit ASCII to minimize character set headaches, but due to there being no password length limit, UTF-7 or Punycode can be used to allow non-Latin passwords to be used. Also, the encryption can be blanked out, allowing the format to be used in things that encryption wouldn't be useful in, such as an image compression format, essentially leaving the encryption feature unused when the password field is left blank or at default.
The format was written in pure JavaScript and is purely FOSS. The format was written by the author starting at age 16 and was definitely finished by the time they turned 17. This does show in the code. The compression and encryption functionality of this program coincidentally harks back to the Classic Mac OS days of PackIt, which featured similar sequential concatenation and compression of multiple files and forks into the archive as well as encryption, all far more primitive and inefficient than BWTC32Key.
The Base32768 final step is essentially the antithesis of the original BinHex, because instead of using an algorithm that doubles the binary input size via base 16, the base32768 step makes the AES256-CTR encrypted BWTC archive only 16/15 of the original size assuming the UTF-16BE with BOM output is the encoding to be fed into the output text file that uses the .B3K extension instead of the .txt extension used for normal plain text documents. It should be noted that since the BWTC compressor is very simple compared to even the original bzip, and that the 256bit AES variety used is the counter mode which needs no padding, the format is very slim and subtle.
As a text based format that closely resembles human text, it can be used where text is exclusively required (in most cases), while also being similar in spirit to authentic human scripts, which allows it to be injected into written works as if it were a Korean section of actual human writing, with no humanly-distinguishable traces at all. Also, due to it being stream compatible, broadcasting it can be done as a means of sending data through live channels as a stream of data one could opt into. Another feature it has is that it will never decode corrupt input, without computing anything. Meaning, it will fail if the magic number of the BWTC archive ("bwtc") isn't present in the compressed data due to corruption or the wrong key, or if the Base32768 text itself has junk thrown in or isn't properly formed or decodable. And if the corruption corrupts the Base32768 text data itself, or even the UTF16BE (with BOM) encoded Base32768 text itself, it will also fail un either case. This ensures that corrupted files will not be created by the decoder or your system, which can help stop damage to your system if something like a firmware blob or an executable was affected. This format does not care about file information of any kind. Hence, this is why it can be used as a chunk or stream format in cases where file info isn't needed. This is only possible because of the encryption feature being optional to apply to the input, thus allowing data (such as uncompressed image data, typeface data, soundbank data, and open streams) that would be pointless and unwise to encrypt to be able to be used with this format. As mentioned before, live input streams are allowed, and real time data input is as well. And in other implementations, multiple files could be encoded and then concatenated, optionally with different keys per file, all with the right logic.
Links
- The author's format implementation is at Github Implementation
- The github repository is at The Repo
