AOTP

This document briefly describes AOTP (Ayras One Time Pad)

At the end of the file is a description of the letters being used to identify files in examples

Description:
AOTP allows a user to encrypt multiple different files and release them in sequential order.
To decrypt a file, the next part is required, thus making it impossible for a user to decrypt
a released file without the next encrypted part being released.

Encryption:
1. The user selects all files he wants to release and puts them into order (S1 to S5) with S1 being the first to release
2. The application searches for the biggest file and creates a random key (K) with the same size + 8
3. S5 -> H5, H5 xor K -> E5
4. S4 -> H4, H4 xor E5 -> E4
3. S3 -> H3, H3 xor E4 -> E3
4. ...
5. ...
6. S1 -> H1, H1 xor E2 -> E1

Generating H:
1. Write 8 byte number (ulong) to H
2. Append S to H
3. Append Random Padding to H to match size of K

Releasing Parts:
Parts are released in order E1 to E5 and after E5, K is released.
nobody is able to decrypt Ex without having E(x+1), or K (in case of the last Ex)

Decryption:
Decryption happens in the reverse order of encryption.
After releasing E2, users can do E1 xor E2 -> H1 -> S1 but they cannot decrypt E2 itself.
Users continue to decrypt Ex to Hx and convert Hx to Sx with each E being released.

Advantages:
- Release Files but make it technically (almost) impossible to decrypt them without next parts.
- K is only used once. (K cannot be constructed in any ways from E parts only)
- Very fast. (xor is built in CPU function even in RISC processors)
- All files are the same size making them indistinguishable.
- Even if somebody manages to acquire K, they cannot use it before the last file is released.
- If decrypting the first 8 bytes, users know how many bytes are needed to decrypt E and can skip the padding.
- Bytewise encryption and decryption. Allows seeking forward and backwards at any time and thus allows streaming of Ex directly to Sx
- Attacking/compromising the RNG used to generate K only affects the last E and not the other parts.

Disadvantages:
- If all files are from the same type and have the same header, people can decrypt static parts of the header (not that it would be useful).
- If sending a 100 MB Archive and a 10 KB text file, the text file is blown up to 100 MB to match K
- If releasing files in the wrong order things can get pretty fucked up.
- Encryption is done from the last H to the first (reverse direction of releasing parts). So all parts need to be pre-computed before releasing the first E.

Conclusion:
- A very simple and fairly strong (I assume) cipher method for controlled release of information.
- No patented algorithms being used.
- Decryption and encryption uses the same amount of memory, a few bytes of RAM are already enough for basic operation in an embedded device.
  Technically no Ram is needed: Load byte to register A, load byte to register B, A xor B (assuming result lads in A), store A
  This assumes, both sources can be read directly from input to registers
- K is only used once, which is intended by OTP but still multiple files are encrypted using it. Changing K changes all E parts.
- K cannot be constructed from the E parts (you need the last S (or H) and the last E but then you do not need K because you have S already)
- Encryption and decryption can be done by human with a simple XOR Table

Letters used:
S -> Unencrypted source file
H -> Headered version of S (basicaly 8 byte integer containing the original size of S + S itself + random data for padding to match size of K) but could be extended with more meta data
K -> Key of last S
E -> OTP encrypted version of E (last H xor K, Hx xor E(x+1))