Regarding ECB mode and Padding in ScatterChat v1.0's Protocol

Several people have pointed out the non-standard (I prefer "creative") use of AES ECB mode with padding on encrypted messages. This note demystifies why this was done.

In late summer 2005, it was realized that one cannot use AES CTR mode with a single key for asynchronous message transfers, lest the stream becomes corrupted. As a temporary solution, the protocol was changed to use ECB mode with extra padding to handle block repetitions manually. I am confident that this solution is secure, even though it is creative.

Work on ScatterChat v2.0 began in March 2006 to make the protocol less creative. Unfortunately, it could not be prepared in time for HOPE Number Six.

Documentation for the v2.0 protocol is coming soon.

-- JST Duce, Project Maintainer

August 5th, 2006.