Making a File Format

This program features a LOT of code I had to make work, it was a wild ride. It features compression, encryption, and Base32768 text output.

Now for the decisions: In the olden days of this program, it had at one point used Base16384, because Base32768 wasn’t implementable at the time. It also had no compression or encryption. It was sheerly a binary-to-text encoder.

In 2019 it became possible to use Base32768 in browser JS via TinyGma’s implementation, and the creator was fine with my use of it. So I did that, and this went better than previous attempts using KISSC that double-encoded and sucked in other ways. A bit later, suitable compression was achievable. I could have used a JS implementation of BZip2, but there were better ways to achieve the desired result of more data in less characters. A MUCH better way. BWTC. Later in 2019, I wanted encryption, so I decided to use AES256-CTR, because CTR does not use padding, which would dramatically increase character count, and it was much easier for JavaScript to process. I used a libre JS implementation, because rolling your own crypto is a TERRIBLE idea. This BWTC+AES256CTR+Base32768 soup became BWTC32Key on July 1st, 2019, and that version of the program is forwards-compatible with the 2023 version here. Both versions can read each other’s files (assuming you don’t touch the password box in the 2023 version). I chose in 2022 to add the ability to generate and read .B3K files (the program’s file format) within the program rather than a text editor, in the process improving modern Mac compatibility. That choice was needed because I had chosen a BOM at the start as part of the header to help text editors read it. That code also was written a certain way that ended up being helpful in the long run. Also, the text export was chosen at all so it would be more portable. Base32768 kept size down.

An important decision I had to make in 2023 was how to fix a bug relating to encryption. APPARENTLY, the passphrase was NOT being fed properly, so I had to go in and fix it, making it directly read the needed value. I also did this for the Compression Level box, something I chose to implement for completeness. I did not force the numbers to be 1-9, precisely so people could find out what that would do. (Good idea!)

Part of the security fix included using an implementation that would allow Unicode passwords.

A LOT more form fields were added compared to the 2019 version. Additionally, I keep the styling minimal to save RAM when storing large strings. Also, by choice, EVERYTHING is inside the HTML file. So size of the HTML file is a factor. Also, styling would make mobile users need to scroll. This program was an effort that took years.

A lot of techniques I did when doing this was to get everything to work together, including a lot of time spent getting everything fed into where it needs to go. I also made EVERYTHING fit in a single HTML file. I used Notepad++ for most of this. It was quite an experience.