All files can be seen as a number. MirandaFile will read them in binary, and add a one to the beginning, as a zero at the beginning can get confusing later. For each key entry, MirandaFile converts the number to base (first entry) and then interprets that result as base (second entry). Imagine the number is 8, (that's a very small file!) and the first key entry is 4. The result is 20 (base 4). Now imagine the second entry is 9. If RDI is enabled, I would then insert digits between 4 and 8 (inclusive) at random such that there will be an equal number of all possible digits on average. The string of characters "20" in base 9 represents the number eighteen. (that's 18 in base ten, which is what we usually use). Repeat for each successive pair. The resulting number, in binary, is the encrypted file. To decrypt, reverse the process, and ignore digits to large to be part of a number in a smaller base (that would mean the file was encrypted with RDI).

      The second number in each pair must be larger because in theory, if it were less, a digit in the base (first entry) number would be too high for that character string to be a base (second entry) number, and the math gets messed up.

      Note that MirandaFile does not actually store a character string for each base conversion, it is a little more mathy than that. If you want to know, check out the source code.

      This whole process is very computationally intensive, so encoding times can be long, especially with large files or keys. This process will result in larger encoded files than the originals, but to my knowledge, no one has yet found a reasonable way of cracking it.

      Keys are generated from password in a simple manner. First entry of first pair is 3+unicode value of first character. Second entry of first pair is 4+unicode value of first character + unicode value of second character. First entry of second pair is 3+ unicode value of third character, and second entry of second pair is 4+unicode value of third character + unicode value of fourth character, and so on. If there are an odd number of characters, it pretends there is an extra character value 0 at the end.

      If you are splitting a file, the first few entries of the bytes in the encrypted file will be like this: -1, a base 127 number representing how many bytes each section will occupy in the encrypted file (with each byte as a digit ones digit first, then 127s, etc.), -1, and then the encrypted file sections (in order, each occupying the same number of bytes).

      By the way, yes, I did pick the acronym and then make up stuff for it to stand for.