Wow, that was a long time ago. I do still have the PDF, but I don't really wish to proliferate it, looking back now. In particular the 'paper' doesn't contain any cryptanalysis, and just 'assumes' it is secure. I was 19 when I wrote it.
That said, the design of the mode of operation was quite elegant and efficient. Assuming you are familiar with the field, it consisted of taking the core of BLAKE2 as a tweakable secure PRP, with an important modification.
The core's 10 rounds was split in two sequences of 5 rounds, that transform plaintext to midstate to ciphertext and similarly from ciphertext to midstate to plaintext. We called those alpha and beta, so E(x) = beta(alpha(x)).
Roughly, each block of plaintext or authenticated data was processed using an always uniquely tweaked blockcipher. We took the the midstates of processing those blocks, XOR'd them together and encrypted the resulting block to get our MAC t. The tweaks also contained the AD and message length (through lambda_A and lambda_M respectively), so length extension/contraction attacks were defeated.
The advantage of this scheme was that the authentication portion didn't require any additional primitives or crypto code, and was blazing fast. Furthermore, you only needed to do half of the computational load (for long messages) to verify that a message is genuine compared to fully decrypting the message. Finally the whole scheme is embarrassingly parallel - each block is independent from all others.
That said, only the reduced computational load for verifying isn't enough to offset choosing it over OCB3, which is very similar, and is proven secure.
That said, the design of the mode of operation was quite elegant and efficient. Assuming you are familiar with the field, it consisted of taking the core of BLAKE2 as a tweakable secure PRP, with an important modification.
The core's 10 rounds was split in two sequences of 5 rounds, that transform plaintext to midstate to ciphertext and similarly from ciphertext to midstate to plaintext. We called those alpha and beta, so E(x) = beta(alpha(x)).
Roughly, each block of plaintext or authenticated data was processed using an always uniquely tweaked blockcipher. We took the the midstates of processing those blocks, XOR'd them together and encrypted the resulting block to get our MAC t. The tweaks also contained the AD and message length (through lambda_A and lambda_M respectively), so length extension/contraction attacks were defeated.
Visually encryption looked like this (you can ignore the subscripts, they were designed so that they were always unique for each invocation): https://i.imgur.com/FZCaYvf.png And decryption: https://i.imgur.com/hkBsqMn.png
The advantage of this scheme was that the authentication portion didn't require any additional primitives or crypto code, and was blazing fast. Furthermore, you only needed to do half of the computational load (for long messages) to verify that a message is genuine compared to fully decrypting the message. Finally the whole scheme is embarrassingly parallel - each block is independent from all others.
That said, only the reduced computational load for verifying isn't enough to offset choosing it over OCB3, which is very similar, and is proven secure.