|Classes of Scott Arciszewski||>||Cipher Sweet||>||docs/internals/02-packing.md||>||Download|
CipherSweet's Multi-Part Message Packing Protocol
The packing algorithm is similar to the one used in PASETO, with one departure: The length that precedes the packed payload is only 32 bits long.
This was designed to mitigate canonicalization attacks, which are only relevant depending on how you feed data into your MAC.
LE32() encodes a 32-bit unsigned integer into a little-endian binary string. The most significant bit MUST be cleared for interoperability with programming languages that do not have unsigned integer support.
LE64() encodes a 64-bit unsigned integer into a little-endian binary string. The most significant bit MUST be cleared for interoperability with programming languages that do not have unsigned integer support.
cipherSweetPack() accepts an array of strings (usually denoted as
The first 8 bytes of the output will be the number of pieces. Typically
this is a small number (3 or 4). This is calculated by
Next, for each piece provided, the length of the piece is encoded via
An implementation may look like this:
As a consequence:
As a result, you cannot create a collision with only a partially controlled plaintext. Either the number of pieces will differ, or the length of one of the fields (which is prefixed to the input you can provide) will differ, or both.
Due to the length being expressed as an unsigned 64-bit integer, it remains infeasible to generate/transmit enough data to create an integer overflow.
The number of pieces should always be smaller than 2^31 (about 2 billion).